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

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

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

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

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

7. 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 | ITU-T X.900 )

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

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

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

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