hl7 soa-aware enterprise architecture

04/21/23 19:11

HL7 SOA-Aware Enterprise ArchitectureHL7 SOA-Aware Enterprise Architecture

Executive Summary

HITSP

October 28, 2008

Executive Summary

HITSP

October 28, 2008

The Goal of the HL7 Enterprise ArchitectureWorking InteroperabilityThe 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

Who needs Working Interoperability?The Users of an HL7 Service SpecificationWho 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?Requirements for Implementable Working InteroperabilityWhat 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.

The SAEAF (Part 1)ServicesThe 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.

The SAEAF (Part 2)HL7, MDA, CSI, SOA, and Distributed Systems ArchitectureThe 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 OrientedArchitecture

Reference ModelFor Open DistributedProcessing Model Driven

Architecture

Computable SemanticInteroperability

Health Level 7

The SAEAF (Part 3)RM-ODP Multi-Dimensional Specification Pattern from the 5 Viewpoints

The SAEAF (Part 3)RM-ODP Multi-Dimensional Specification Pattern from the 5 Viewpoints

Enterprise View: concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part

Information View: concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;

Computational View: concerned with the functional decomposition of the system into a set of objects thatinteract at interfaces – enabling system distribution;

Engineering View: concerned with the infrastructure required to, and distributionof, the computing resources defined in the Computational View.

Technology View: concerned with the choice of technology to support system distribution

Why?

True?

Where?

How?

What?

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

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

Analysis Business Context,

Reference Context

DIM Dynamic Blueprint, Functional Profile(s)

N/A Blueprint

Conceptual Design

Business Governance

CIM, LIM Dynamic Model,

Interface Specification

N/A Platform Independent

Implementable Design

N/A Transforms, Schema

Orchestration, Interface

Realization

Execution Context,

Specification Bindings,

Deployment Model

Platform Bound

The SAEAF Applied Incremental approach to Working Interoperability through Conformance

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

The SAEAF Applied (2)Governance and Other “Standards” (DRAFT)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 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/A XML Schema, XSL

WSDL, WS-*, J2EE, .NET,

EbXML

WS-*, J2EE, .NET,

EbXML

Platform Bound

Summary – Next Steps for HL7Summary – 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

hl7 soa-aware enterprise architecture

Documents