HL7 SOA-Aware Enterprise Architecture Executive Summary HITSP October 28, 2008

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

Who needs Working Interoperability 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

What do the “clouds” need to interoperate 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. Governance implies two things: there is governance at the “cloud” level, and also within HL7 communities. These things were dealt with in some detail, though the ArB did not feel that we could make many recommendations until the framework was put in place that would support these things. Thus, this report is about the framework.

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. An example of the semantics: The four dimensions of integration: static semantics, functional semantics, behavioral semantics, and integration context semantics (business rules, usage context) Services are the integration points that systems expose to communicate with other systems (as opposed to a user).

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. Health Level 7 Service Oriented Architecture Computable Semantic Interoperability Reference Model For Open Distributed Processing Model Driven Architecture You are here (Vous êtes ici)

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

The SAEAF (Part 4) The HL7 Specification Stack – Detail of the The Specification and Conformance Patterns Specification Enterprise / Business Viewpoint Information Viewpoint Computational Viewpoint Engineering Viewpoint Conformance Level Reference EHR-FM, Clinical Statements RIM, Structured Vocab, ADTs EHR-FM - Analysis Business Context, Reference Context DIM Dynamic Blueprint, Functional Profile(s) N/A Blueprint Conceptual Design Business Governance CIM, LIM Dynamic Model, Interface Specification Platform Independent Implementable Design Transforms, Schema Orchestration, Interface Realization Execution Context, Specification Bindings, Deployment Model Platform Bound

Platform-Independent The SAEAF Applied Incremental approach to Working Interoperability through Conformance 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) C D B Platforms E Platform-Independent A Blueprints Reference 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

The SAEAF Applied (2) Governance and Other “Standards” (DRAFT) Specification Enterprise / 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 Analysis Business Context, Reference Context, HSSP, CDA Profiles CDA Profiles, Terminology Bindings HL7 Behavioral Framework, BPDM, SoaML, HSSP 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 Platform Independent Implementable Design XML Schema, XSL WSDL, WS-*, J2EE, .NET, EbXML WS-*, J2EE, .NET, EbXML Platform Bound

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 Rings 3 and 4 were out of bounds for the immediate EA, but may be next steps that the TSC wishes to engage in. Developmental Governance not only includes the way that standards are developed within HL7, but also how they are adopted (that is, in what ways do layered specifications support different organizations governance structures). This second notion is the glue between what happens internally and what happens between collaborating organizations to deploy interoperable solutions.