1 / 11

HL7 SOA-Aware Enterprise Architecture

Explore the HL7 Enterprise Architecture framework for achieving working interoperability in the healthcare/life sciences domain by defining information exchange, functions, mappings, reference terminology, and technology bindings.

iharris
Download Presentation

HL7 SOA-Aware Enterprise Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. The Goal of the HL7 Enterprise ArchitectureWorking 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?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?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. 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. 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êtesici)

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

  8. The SAEAF (Part 4)The HL7 Specification Stack – Detail of the The Specification and Conformance Patterns

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

  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

More Related