Which Concepts?

1. Which Concepts? • Not necessarily in any order of priority or development • POC – Proof of concept • Concept: Semantically precise, working Interoperability • Concept: Commonly specified, variably deployed services • Find efficient ways to deal with patterns like CDA, QRL, RIM • Concept: Design by contract; integration by contract • Concept: Outcomes and E H R components working together • Concept: Security can be created as a framework / specification to aid in understanding integration points with services and deployment sites • Concept: W3C Semantic components to variably bind to infrastructure; create loose couplings between functionality and information bindings (?) • Concept: Services at different conformance levels • Concept: Infrastructure • Concept: Rapid Prototyping • Concept: Loose Coupling between semantically precise services providing a backbone for integration with EHRs. • Concept: Services to loosely couple business capabilities with technology artifacts • Concept: Loose Coupling with Front End Systems (Tolven) • Concept: Multiple ESBs, data stores, and front ends supporting working interoperability

2. Referral Service Architecture – Deployment Solution Tolven 2 Clinical Service Layer Tolven 1 Business Service Layer 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 User-facing systems to manage data input, verification, and potential insertion into clinical business processes Security - ?; Represents org-to-org comms; protocol and information transformations available; Transactional Integrity; Community Contract User-facing systems to view data transmissions, verify patient state, and test information rendering Secured for authenticated access for “writes” and “reads”; Transactional Integrity; Business Rules Analytics Secured for authenticated access for “writes” – authorized for “reads” Secured for authenticated access for “writes” and “reads” POC Business Integration Bus The POC is a controlled environment, and provides the facilities for securing the communications, watching the shared states between trading partners, and so on.

3. Integration Points Tolven 2 Clinical Service Layer Tolven 1 Business Service Layer 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 Clinical Systems Analytics The POC is a controlled environment, but integration environments are not. What a NCCCP site chooses to adopt depends on their goals and current capabilities. The caEHR deployment solution will provide these components as integration points, but will not decompose them further for the January release.

4. Concepts per Logical Level Tolven 2 Clinical Service Layer Tolven 1 Business Service Layer 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 Clinical Systems Analytics Working interoperability can be built quickly; may develop infrastructure to create efficiencies; can use semantic components to make extensibility to NCI more clear Services and Service Patterns can be quickly built / instantiated to support many business pieces; can support transactional integrity Tolven can be designed and built to support the business functionality with defined integration points to the caEHR architecture Other components from the VEScaffold can be reused here to support communications between organizations (trading partners). These are key integration points to understand and support for caEHR. Also support community contracts (interoperability specifications) to support LRTs between multiple business partners Services and Service Patterns can be quickly built / instantiated to support many clinical pieces

5. POC Stage 1 - CDA Clinical Service Layer Business Service Layer Virtual EHR Scaffold CDA Generation Clinical Systems Choreography CDA Acceptance Complete Patient Profile Analytics Working interoperability can be built quickly; may develop infrastructure to create efficiencies; can use semantic components to make extensibility to NCI more clear Services and Service Patterns can be quickly built / instantiated to support many business pieces; can support transactional integrity Other components from the VEScaffold can be reused here to support communications between organizations (trading partners). These are key integration points to understand and support for caEHR. Also support community contracts (interoperability specifications) to support LRTs between multiple business partners Services and Service Patterns can be quickly built / instantiated to support many clinical pieces Stubbed out clinical repositories (fake?) with test or stub data

6. POC Stage 2 - Orders Business Service Layer Virtual EHR Scaffold Integration Layer CDA Generation CDA Generation The ESB / Scaffold serves as in two capacities. First (most importantly) choregraphing and orchestrating the transactions. Secondly, as an information router and transactional store. For this Stage, we should not have to do a lot of work here. Choreography CDA Acceptance CDA Acceptance Complete Patient Profile Controlled Communication Environment Order Management The focus of this Stage of the POC is in managing these behaviors, and working the clients to manage these shared states. We should seek to find efficiencies in how we deal with these components (CDL? BPEL? Custom Libs?). Clients should be POC (Command Line, etc) Information routed to service endpoints can be consumed and managed by clients. As a POC, these services (operations) need to be the focused

7. POC Stage 3 - Tolven Tolven 2 Clinical Service Layer Tolven 1 Business Service Layer 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 Clinical Systems Analytics Tolven client for back end data entry – POC, lightweight, focused on data elements from iSPY2Tolven client for Referral Generation / Order Management – based on functionality found in POC Stage 2 Tolven client for Referral Acceptance / Order Management Tolven client for user facing information expression and approval. Tolven should be seen as a stand alone component. It is obviously made up of a bunch of stuff that we need to wall off. This shows of Tolven represents certain integration points with the architecture and can be replaced by other systems.

8. POC Stage 4 - Outcomes Clinical Service Layer Tolven 1 Business Service Layer Virtual EHR Scaffold ESB Outcomes can be configured into services exposing clinical data, aggregated into special service implementations, and analyzed to support particular outcomes flavors. These services and their implementations will be the focus on this stage. Tolven will provide a front end to capture this report, render it, and handle subsequent communications. Alternatively, we could build lightweight clients to manage these things. Tolven Outcomes Report on Diagnostics Choreography Complete Patient Profile Clinical Systems Analytic components will be one of the promary challenges or this stage. These analytic components will manifest in services, in w3c semantic components, and in particular libraries. The topology of these components is a primary consideration for this phase. Analytics

9. POC Stage 5 - Security Tolven 2 Clinical Service Layer Tolven 1 Business Service Layer 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 Clinical Systems Analytics Application Security Access / Auth Security Application Security Application Security Internal Auth Security with Strong Logging / conformance Checking Application Security Auth / Access Security Internal Auth Security Access / Auth Security Security Frameworks can be built from existing and emerging services, and can support the different layers of access / auth / id that are needed for caEHR.

10. POC Stage 6 – Extension to Roadmap Phase 2 Tolven 2 Clinical Service Layer Tolven 1 Business Service Layer 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 Clinical Systems Analytics

11. Stages Stage 1 Stage 2 Stage 3 Stage 4 Stage 5 Stage 6 Now Jan 2011 Then

12. Definition of Terms • Architecture Framework – The meta-model against which architecture specifications are developed. Governance and Specification are common parts of a framework. See the SAIF. • Architecture Specification – The meta-model against which architectures are deployed. Collection of functional specifications, information specifications, deployment specifications, technical libraries, patterns, practices • Architecture Deployed – The deployed artifacts that support the business of an organization. Includes “centrally” deployed infrastructure. • Infrastructure – components that promote and facilitate reusability, extensibility, and scalability. Often, these components are deployed “centrally” within a distributed system to create economies of scale