caCIS Deployment and Integration Brief

1. caCIS Deployment and Integration Brief Lorraine Constable, Guidewire Architecture John Koisch, Guidewire Architecture

2. caCIS Ecosystem Knowledge Management Analytics Data Research Consumer Health Semantically Aware Service Bus Semantic Adapter Package Semantic Adapter Package Trading Partners Trading Partners Semantic Adapter Package Semantic Adapter Package Semantic Adapter Package Graphical User Interface Trading Partners Care Delivery v0.9 by Lawrence Brem on 1/6/11

3. caCIS Architecture Cancer Clinical Information Suite caGrid 2.0 Enterprise Service Bus Legacy Data caCIS Semantic Bus caCIS Graphical User Interface Infrastructure Adapter RDB to RDF Mapper RDF Server RDF SPARQL Care Delivery Client Trading Partners SA Semantic Persistence Layer (HL7 RIM, ISO-21090, BRIDG, LSDAM Semantic Adapter Package Authentication & Authorization Research Trading Partners Semantic Adapter Package Client SA Service Infrastructure Semantic Adapter Package Consumer Health Client Trading Partners Choreography Engine SA Semantic Adapter Package Semantic 2.0 Infrastructure Semantic Knowledge Store Local Knowledge Cache Metadata Management v0.9 by Lawrence Brem on 1/6/11

4. caCIS Deployment Scenarios • Service integration only (no container or desktop integration): • Adoption/adaption of service specification or code via integration of specification/code into an existing, traditionally-defined EHR system. • Container Integration including GUI (“desktop”): • The full caCIS container and associated persistence layer, semantic bus, ESB, etc. is integrated into an existing system via the use of the various SAs supplied by the caCIS team. NOTE: This path implies that the decision-making desktop is provided by the caCIS container. • Container integration excluding GUI (“desktop”): • The desktop from the previous option is instead hosted by an existing EHR provider as part of their already-developed clinical care desktop which is already accessing various transaction data for clinical care. The caCIS reasoning container remains a separate logical and physical component which provides data to the host desktop via published caCIS service interfaces. • Container adsorption (including “desktop”): • Using the full collection of caCIS service specifications and service implementations, an existing EHR integrates all caCIS functionality into its existing system. NOTE: in order to accomplish this, the existing system must have a RIM-aware persistence framework (e.g. RIMBAA-compliant) and an overlying OWL-based reasoning layer with access to the RIM layer.

5. caCIS EAS Components

6. Architecture - Other • Frameworks • Information • Computational • Specification • Exception Handling • Run Time Contract Binding • Choreography engines + Configurations • Document Exchange • Virtual E H R Scaffold • ISO 21090 localized datatype specification • Service and Information Specifications, patterns and practices • HL7 + SOA • Identification • RLUS • Orders • Document Management

7. Decomposing caCIS

8. Decomposing caCIS E H R • Native E H R • Business Capability Adapter • Clinical Information System • Enterprise Business Logic • Trading Partners Tolven Platform Ind Integration Layer caCIS caCISvEHR Scaffold caCIS Trading Partner • Each Layer is described in terms of the services that it exposes • The Deployment Plan should reflect these Layers

9. 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

10. caCIS Engineering Model Packages

11. Component Packages Core Relationships • This is the logical structure for implementation and integration • The BCA and the vEHRS will be the core integration components and will provide security as defined in the Security Scaffolding

12. caCIS Reference Implmentation Integration Points • Overall, the caCIS Reference Implementation exposes • 3 sets of Externally-facing integration points • 6 sets of Internally-facing integration points

13. vEHRS– Reference Implementation ESB + Integration Engine + Interoperability • The vEHRS is an ESB with some specialty components • The ESB will provide a JBI-compliant architecture • Within the scaffolding, an Integration Engine will also be deployed

14. Tolven – Reference Implementation Business Capability Adapter • Tolven is broken into several components • If you are developing with Tolven, you need to worry about all of these • If you are integrating within the caCIS Reference Implementation, you only need to be concerned with two. • In the caCIS configuration, Tolven will not be exposed directly to external systems, but integration will be mediated through the ESB

15. JBI– Reference Implementation ESB Architecture • ServiceMix is a JBI-compliant ESB • JBI is organized as a pluggable architecture with two types of components • Binding Components – channels and ports • Service Engines – Capability • JBI provides a coherent way of routing information to internal components like Tolven and external trading partners (for example, in referrals)

16. Service Engines within caCIS • JBI provides the organizing principle for our interoperability components • Key Service Engine extensions include • Clinical Document Exchange • Order Request Management • Each caCIS Service Engine plugin defines its interface design via the caCIS Service Specification portfolio

17. Mirth – Reference Implementation Integration Engine • Mirth is an HL7 Integration Engine • Provides coherent, pluggable approach to handling message endpoints in a clinical environment • It provides another set of external integration points for the caCIS Reference Implementation and Site Deployments • It also provides the ability to manage trusted traffic within the boundaries of the caCIS Reference Implementation

18. Implementing Using the Packages

19. ConformanceCommunity

20. ConformanceBehavioral Model

21. ConformanceShared State

22. Implementation Packages Within the Model • Implementations of capability within caCIS represent configurations of these components • There are several implementation packages represented within the model, with more coming

23. Sample Implementation Package – Patient Registry • caCIS will not create a Patient Registry of its own • The model shows how caCIS can piggy back on a local implementation of a Patient Registry, and still provide authoritative information via Query • Integration Engine – ADT Message Endpoint • Tolven – ADT Message Endpoint • Tolven Persistence • TolvenRESTful service • caCISTolven Patient Reg Adapter (Consumer) • caCISTolven Patient Reg Adapter (Provided Interface)

24. Logical Deployment Models

25. caCIS Deployment Phase 1

26. caCIS Deployment w Tolven only, including other Clinical Systems Clinical Service Layer Tolven Clinical Systems Business Service Layer Virtual EHR Scaffold Tolven Bus caGRID 2.0 Vital Signs Immunizations Outcomes History Choreography Problem List Referral Medication List Allergy Complete Patient Profile PACS Lab Systems Analytics Orders Systems

27. caCIS Deployment w Tolven and other EHR Clinical Components, as well as other Clinical Systems Clinical Service Layer Business Service Layer Tolven Clinical Systems Virtual EHR Scaffold Tolven Bus Immunizations caGRID 2.0 History Problem List Outcomes E H R Clinical Systems Referral Choreography Vital Signs History Medication List Complete Patient Profile Allergy PACS Analytics Lab Systems Orders

28. caCIS Deployment woTolven, but with other Clinical Systems Clinical Service Layer E H R Clinical Systems Business Service Layer Virtual EHR Scaffold caGRID 2.0 Vital Signs Outcomes Immunizations History Referral Choreography Problem List Medication List Allergy Complete Patient Profile PACS Lab V2 Messages Analytics Orders

29. caCIS Deployment w Tolven Preserving Encapsulation Boundaries Clinical Service Layer Tolven Clinical Systems Business Service Layer Virtual EHR Scaffold Tolven Bus Vital Signs Immunizations Outcomes History Choreography Problem List Referral Medication List Allergy Complete Patient Profile Analytics

30. Deployment Models

31. Key question: • How is NCI going to work in the same space as a site or vendor? • A helpful model is Commercial Development in a Municipality • The Skyscraper forms one community that exists within the other • There is some functionality that the building itself brings (HVAC, Security, Mail Access, Phone / Data Access, Plumbing, People Movers) • People come to the building for who is in the offices (doctors, dentists, accountants, architects, software companies). • The buildings services are incidental, but define the fulfillment patterns of the occupants’ delivery • The NCI’s building systems support the cancer center (the skyscraper) with vendor systems (the office suites) NCI, sites, and vendors

32. Three models for NCI functionality to work with a Vendor’s and Site systems • Native Functionality – adding functionality to systems using native code, patterns, components (using the building’s security system for your bank vault) • Side-by-side Functionality – Use NCI’s code and applications to provide functionality that Vendors typically may not cover (HVAC, Security) • Middle Out– Take scenarios that involve multiple systems and show value in the interoperability (Steam plant recycling, Phone / data access are the nearest corollaries) • Each of these takes some coordination and planning 3 Deployment Models

33. The NCI has focusing on two areas now (not just one), and all three models are applicable • Clinical Interoperability • Research Interoperability The problem with Deployment Models • The problem for the architecture is that – even in these examples – where you integrate to provide interoperability is variable

34. caCIS Deployment Scenarios • Service integration only (no container or desktop integration): • Adoption/adaption of service specification or code via integration of specification/code into an existing, traditionally-defined EHR system. • MIDDLE OUT • Container Integration including GUI (“desktop”): • The full caCIS container and associated persistence layer, semantic bus, ESB, etc. is integrated into an existing system via the use of the various SAs supplied by the caCIS team. NOTE: This path implies that the decision-making desktop is provided by the caCIS container. • NATIVE • Container integration excluding GUI (“desktop”): • The desktop from the previous option is instead hosted by an existing EHR provider as part of their already-developed clinical care desktop which is already accessing various transaction data for clinical care. The caCIS reasoning container remains a separate logical and physical component which provides data to the host desktop via published caCIS service interfaces. • SIDE By SIDE • Container adsorption (including “desktop”): • Using the full collection of caCIS service specifications and service implementations, an existing EHR integrates all caCIS functionality into its existing system. NOTE: in order to accomplish this, the existing system must have a RIM-aware persistence framework (e.g. RIMBAA-compliant) and an overlying OWL-based reasoning layer with access to the RIM layer. • REPLACE NATIVE

35. Addenda

36. 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 • The same service specification may be deployed as an adapter against • Persistence • Business Logic

37. 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