1. 7/2/2016 1:52 AM HL7 SOA-Aware Enterprise Architecture Executive Summary HITSP October 28, 2008 Executive Summary HITSP October 28, 2008

2. Page 2 The Goal of the HL7 Enterprise Architecture Working Interoperability In the end, this is what we need for any interoperability: Definition of Information to be exchanged Definition of Functions by which the information is exchanged Mappings to Real World Events and Business Processes Reference Terminology / Language for understanding these things Engineering / Technology Bindings to deliver these things HL7 and its Standardized Specifications should deliver these things for stakeholders so that actual Implementations may be built

3. Page 3 Who needs Working Interoperability? The Users of an HL7 Service Specification Two or more groups interested in collaborating and sharing healthcare/life sciences data/information using computer systems –No assumption of any scale Nations Enterprises Individuals

4. Page 4 What do the “clouds” need to interoperate? Requirements for Implementable Working Interoperability Computable Semantic Interoperability (CSI) – –Measurable goals, –“Plug and play” patterns of implementation –Incremental adoption yields Incremental Benefit Implementable Specifications –Including governance as modeled, testable specifications Conformance/Compliance Model –Fit with the way organizations model, use, and test components –Implementation Guides (“Are you ready? How does this work with our new ABC Interface Engine?”) Services (and service realizations) that reflect the “…ilities” –Scalability, composability, extensibility, etc.

5. Page 5 The SAEAF (Part 1) Services Services are abstract specifications that explicitly define the semantics necessary to unambiguously specify a testable, enforceable run-time contract between two enterprise-level components, i.e., there is an explicit definition of the service's semantics for integration context, operations, informational components, and both internal and external behaviors. –From Objects, Messages, and Services: A Comparison; Koisch and Mead; Whitepaper, 2008 Services (and SOA) are not technology per se. Rather, they are a framework for approaching the problem of how to design distributed capabilities (information and functionality sharing). They are not equivalent to Web Services The HL7 Services Aware Enterprise Architecture Framework (SAEAF, pronounced “SAFE”) was commissioned to find the language, processes, and artifacts to talk about a Enterprise Architecture appropriate for an SDO.

6. Page 6 The SAEAF (Part 2) HL7, MDA, CSI, SOA, and Distributed Systems Architecture The intersection of HL7, MDA, Distributed Systems Architecture, SOA, and CSI provide a goal, the artifacts, portions of a methodology, and the framework for defining robust, durable business-oriented constructs that provide extensibility, reuse, and governance. You are here (Vous êtes ici) Service Oriented Architecture Reference Model For Open Distributed Processing Model Driven Architecture Computable Semantic Interoperability Health Level 7

7. Page 7 The SAEAF (Part 3) RM-ODP Multi-Dimensional Specification Pattern from the 5 Viewpoints Why? True? Where? How? What? ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 )

8. Page 8 The SAEAF (Part 4) The HL7 Specification Stack – Detail of the The Specification and Conformance Patterns SpecificationEnterprise / Business Viewpoint Information Viewpoint Computational Viewpoint Engineering Viewpoint Conformance Level ReferenceEHR-FM, Clinical Statements RIM, Structured Vocab, ADTs EHR-FM-Reference AnalysisBusiness Context, Reference Context DIMDynamic Blueprint, Functional Profile(s) N/ABlueprint Conceptual Design Business Governance CIM, LIMDynamic Model, Interface Specification N/APlatform Independent Implementable Design N/ATransforms, Schema Orchestration, Interface Realization Execution Context, Specification Bindings, Deployment Model Platform Bound

9. Page 9 The SAEAF Applied Incremental approach to Working Interoperability through Conformance Reference Blueprints Platform-Independent Platforms Two parties who wish to integrate build on the Specification Stack to achieve “Working Interoperability.” C and D have the easiest time interoperating because they agree on a platform. This is desirable, but not a precondition to interoperability. Should B wish to interoperate with D, B will need to write adapters that provide semantic interchanges for policy, behavior, and information, which would be derivable from examining the specifications. B and E can interoperate by agreeing on a Blueprint Specification, but they will have to write adapters to provide semantic interchanges (as above). A has the farthest to go to interoperate with anyone else. Adapters will have to be written to traverse several layers (as above) A B DC A is Referentially Conformant to HL7 B has Platform-Independent Conformance to HL7 C has Platform-Bound Conformance to HL7 D has Platform-Bound Conformance to HL7 E is Blueprint Conformant to HL7 E

10. Page 10 The SAEAF Applied (2) Governance and Other “Standards” (DRAFT) SpecificationEnterprise / Business Viewpoint Information Viewpoint Computational Viewpoint Engineering Viewpoint Conformance Level Reference EHR-FM, Clinical Statements, CEN 13606 RIM, Structured Vocab, ADTs, BRIDG, CEN 13606 EHR-FM, CEN 13606 N/A Reference Analysis Business Context, Reference Context, HSSP, CDA Profiles CDA Profiles, Terminology Bindings HL7 Behavioral Framework, BPDM, SoaML, HSSP N/A Blueprint Conceptual Design IHE Profiles, J2EE,.NET, WS-* Value Set Bindings, HL7 Templates, OpenEHR Archetypes, IHE Profiles, ASC X12, DICOM WS-CDL, WS- BPEL, BPMN 1 and 2, IHE Profiles, EbXML, ASC X12 N/A Platform Independent Implementable Design N/AXML Schema, XSL WSDL, WS-*, J2EE,.NET, EbXML WS-*, J2EE,.NET, EbXML Platform Bound

11. Page 11 Summary – Next Steps for HL7 Formal Business Architecture Model (BAM) for HL7 Continued specification of an HL7 Behavioral Framework, including alignment with industry standards Formalization of Contract Specification Adoption of Policy / Rules Expression Language Implications on Process (such as Software Engineering Processes (SEP)) and Tooling Developmental Governance that supports this framework –Includes potential impacts on publication, tooling, specification development, and inter-workings between WGs Organizational Collaboration Governance recommendations