caCIS Design

1. caCIS Design A Collaboration and Component View of the caCIS Proof of Concept

2. Decomposing caCIS E H R • Native E H R • Business Capability Adapter • Clinical Information System • Trading Partners Tolven caCIS caCIS Trading Partner • Each Layer is described in terms of the services that it exposes • The POC reflects these Layers

3. caCIS Service Unit • The caCIS Architecture Specification defines a unit of service architecture as • Specifications – CFSS, PIM, Models • Ports - WSDL(s)+ Schema • Parts, optionally including choreography, persistence, and / or business logic; and connectors • In the POC, these Parts are stubs hinting at full functionality • In Deployed caCIS, these must be real units of work • This Service unit may be deployed anywhere to expose information or functionality

4. caCIS and Tolven • Tolven is the Platform to build Business Capability Adapters • Extension of native E H R functionality along particular lines • Tolven is an extensible, semantically specific, form-based toolkit to generate business functionality • It is self contained, but can be extended to support externally defined interfaces, like caCIS • POC reflects and leverages this extensible technical design • seeks to build simple business capabilities to prove integration

5. caCIS Deployment (Logical Overview) Tolven 2 Clinical Service Layer Tolven 1 Business Service Layer Virtual EHR Scaffold Integration Layer ESB ESB Tolven Referral Generation Tolven Referral Generation Choreography Tolven Referral Acceptance Tolven Referral Acceptance Complete Patient Profile Controlled Communication Environment Order Management E H R Clinical Systems Analytics

6. Clinical Services • Tolven is used to build the business capability to manage MedicationLists and Allergies • Services expose these types • Exposed through QRL Services • May involve translation or transformation

7. Services Composition • An example of Services Composition is CDA Building • The Clinical Services are composed to create CDA documents • Exposed through a Transactional service • Must choreograph assembly of dependencies (services) • May have to deal with translation • May apply arbitrary rules

8. caCIS Virtual EHR (vEHR) • The Virtual E H R houses infrastructure to manage certain services, functionality, and components that are separate from an E H R or from a Business Capability Adapter • For the POC, these components are simple to prove various Architectural Concepts • For Deployed caCIS, issues like security and engineering robustness will need to be dealt with • caCISvEHR represents a level of abstraction away from local deployments • the NCI caCIS team can build essential components in a controlled environment • Expose services commonly in various environments • Control End points in Trading Partner transactions

9. caCIS Trading Partner • caCISvEHR also manages Interoperability Specifications • Example – Referral Management • Pre-Condition - Manage Allergy, Medication List • CDA Creation and Verification • Referral Order Management • CDA Verification for the Trading Partner

10. caCIS Deployment Logical Overview

11. caCIS Logical Mapping

12. caCIS Deployment Phase 1