Saeaf education series 1 introduction and overview april 2009
Download
1 / 71

SAEAF Education Series 1: Introduction and Overview April 2009 - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on

SAEAF Education Series 1: Introduction and Overview April 2009. HL7 Services-Aware Enterprise Architecture Framework (SAEAF). SAEAF Education Series (1) . The SAEAF Education Series includes the following: 1: Introduction and Overview SAEAF Value Proposition: Working Interoperability

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SAEAF Education Series 1: Introduction and Overview April 2009' - laird


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Saeaf education series 1 introduction and overview april 2009 l.jpg
SAEAF Education Series1: Introduction and OverviewApril 2009

HL7 Services-Aware

Enterprise Architecture Framework

(SAEAF)


Saeaf education series 1 l.jpg
SAEAF Education Series (1)

  • The SAEAF Education Series includes the following:

    • 1: Introduction and Overview

      • SAEAF Value Proposition: Working Interoperability

      • SAEAF Structural Components

        • Behavioral Framework

        • Conformance/Compliance Framework

        • Governance Framework

      • SAEAF Organizational Implications

        • Education

        • Change Management

        • Alpha Projects


Saeaf education series 2 l.jpg
SAEAF Education Series (2)

  • The SAEAF Education Series includes the following:

    • 2: Behavioral Framework

      • Contracts, Roles, Collaborations

      • Implementation Patterns for the BF

      • Mapping to HL7 Dynamic Model

      • More topics possible as deck is developed (Feb 09)


Saeaf education series 3 l.jpg
SAEAF Education Series (3)

  • The SAEAF Education Series includes the following:

    • 3: Enterprise Conformance/Compliance Framework (ECCF)

      • The multi-dimensional world of

        • Conformance

        • Compliance

        • Consistency

        • Certification

        • Traceability, Jurisdiction, and Provenance

      • Layered specifications and layered ECCF

      • Relationship of ECCF to SAEAF Governance


Saeaf education series 35 l.jpg
SAEAF Education Series (3)

  • The SAEAF Education Series includes the following:

    • 3: Enterprise Conformance/Compliance Framework (ECCF)

      • A multi-dimensional world

        • Conformance

        • Compliance

        • Consistency

        • Certification

        • Traceability, etc.

      • The SAEAF Specification Stack and the ECCF

      • ECCF and SAEAF Governance


Saeaf education series 4 l.jpg
SAEAF Education Series (4)

  • The SAEAF Education Series includes the following:

    • 4: SAEAF Governance

      • Role of TSC

      • Role of ArB

      • Role of other SDOs

      • Organizational Impacts

      • More topics possible as deck is developed (Feb 09)


Saeaf education series 5 l.jpg
SAEAF Education Series (5)

  • The SAEAF Education Series includes the following:

    • 5: SAEAF Examples

      • Service Interoperability Paradigm

      • Message Interoperability Paradigm

      • Document Interoperability Paradigm

      • More topics possible as deck is developed (Feb 09)


Saeaf series part 1 introduction and overview to saeaf 1 l.jpg
SAEAF Series Part 1: Introduction and Overview to SAEAF (1)

  • Pre-requisites

    • No SAEAF pre-reqs

    • Essential: Familiarity with the problems of achieving working interoperability in the healthcare / life sciences / clinical research domain

    • Helpful: General knowledge of HL7

  • Outcomes

    • Understanding of the organizational principles and contexts around which SAEAF was developed

    • General understanding of core components of SAEAF

    • Preparation for all other SAEAF Education materials


Saeaf series part 1 introduction and overview to saeaf 2 l.jpg
SAEAF Series Part 1: Introduction and Overview to SAEAF(2)

Topics discussed in this deck include:

  • SAEAF Background

  • SAEAF Value Proposition: Working Interoperability (WI)

  • SAEAF Facts and The Lens of SAEAF

  • SAEAF, SOA, and EA: Core Principles

  • History of Services in HL7

  • SAEAF Operationalization and Implications

  • Summary Conclusions


Background 1 a services aware enterprise architecture for hl7 l.jpg
Background (1)A “Services-Aware Enterprise Architecture for HL7”

  • April 08: HSSP-sponsored “Services in Healthcare” conference, Chicago, IL (attended by HL7 CTO)

  • May 08: HL7 CTO asks the HL7 ArB to “develop a straw-man proposal for services development within the context of an HL7 Enterprise Architecture”

    • “Specify the artifacts and processes necessary to allow HL7 to define specifications for SOA integration.”

    • “Define an HL7 Enterprise Architecture Framework (EAF) which contextualizes HL7 specifications in a SOA environment.”

    • Consider services first, but don’t exclude messages or documents as Interoperability Paradigms

      • “HL7 EAF should be services-aware, not service-specific”


Background 2 a services aware enterprise architecture for hl7 l.jpg
Background (2)A “Services-Aware Enterprise Architecture for HL7”

  • Summer 08: HL7 Executive Committee agreed to sponsor three face-to-face “ArB EAF Jump-Start” meetings

    • Modeled after “Left-Hand Side of the RIM” project (1998)

    • Three 3-day F2F meetings in June, July, August, 2008

      • Transparent process

        • Open attendance

        • Published agendas

        • Published artefacts and works-in-progress

  • September 08: CTO and TSC requested that initial results of the Jump-Start process be presented at the Vancouver WG meeting via a series of joint-WG meetings and open ArB sessions


Background 3 a services aware enterprise architecture for hl7 l.jpg
Background (3)A “Services-Aware Enterprise Architecture for HL7”

  • Jump-Start Deliverables (largely contained in the collection of SAEAF documents) to include (but not be limited to):

    • EA framework “informed by” service specification considerations and industry experience (“services-aware”)

    • Identification and initial specification of required infrastructure currently missing or incomplete in HL7

      • Behavioral Framework (BF)

      • Enterprise Conformance & Compliance Framework (ECCF)

      • Governance Framework (GF)

    • Operational vision for SAEAF deployment

      • Integration with existing HL7 and HSSP processes

        • complimentary to existing relationships (e.g. OMG)

        • extension to message and document Interoperability Paradigms


Background 4 a services aware enterprise architecture for hl7 l.jpg
Background (4)A “Services-Aware Enterprise Architecture for HL7”

  • Operationalization of SAEAF within HL7 (to be overseen by HL7 TSC)

    • Organizational impact

      • Within HL7 and between HL7 and other organizations

    • Tooling impact

  • Additional SAEAF considerations:

    • Use/reuse of existing/legacy HL7 artifacts

      • RIM

      • Data Types

      • CDA

      • RMIMs

      • Vocab


Background 5 a services aware enterprise architecture for hl7 l.jpg
Background (5)A “Services-Aware Enterprise Architecture for HL7”

  • “Services-aware but not services-specific” -- SAEAF is not SOA

    • Consideration given to three HL7 “interoperability paradigms” (“HL7 Unified Field Theory”)

      • Messages

      • Documents

      • Services

  • The SAEAF work draws on “service-aware principles” e.g.

    • Contracts, Roles, and Collaborations (“behavior”)

    • Conformance & Compliance

    • Governance


Background 6 jump start participants l.jpg
Background (6)Jump-Start Participants

  • Other

    • Alex DeJong, Siemens

    • Ed Larsen, HITSP

    • Galen Mulrooney, JP Systems, VA

    • Scott Robertson, Kaiser

    • Rich Rogers, IBM

    • Ann Wrightson, NHS UK

  • Participants brought a wide range of perspectives to the discussion

  • HL7 ArB

    • Yongjian Bao, GE Healthcare

    • Jane Curry, Health Information Strategies

    • Grahame Grieve, Jiva Medical

    • Anthony Julian, Mayo

    • John Koisch, NCI

    • Cecil Lynch, OntoReason

    • Charlie Mead, CTO NCI

    • Nancy Orvis, DoD MHS

    • Ron Parker, Canada Health Infoway

    • John Quinn, Accenture, CTO HL7

    • Abdul Malik Shakir, Shakir Consulting

    • Mead Walker, Health Data and Interoperability


Saeaf value proposition 1 working interoperability l.jpg
SAEAF Value Proposition (1):Working Interoperability

  • Working Interoperability:

    • The collection of structures, processes, and components

      • that support Computable Semantic Interoperability

      • in the context of a Conformance/Compliance Framework.

      • SAEAF facilitates the explicit and layered expression

      • of the set of static, functional, and behavioral semantics that collectively enable Working Interoperability.

  • Specifications developed to enable Working Interoperability

    • are defined in such a manner so as to ensure that they are

      • usable, useful, durable, and that they are

      • implementable in a variety of deployment contexts

        • in a repeatable, comprehensible manner.


Saeaf value proposition 2 working interoperability l.jpg
SAEAF Value Proposition (2):Working Interoperability

Interoperability Paradigm (Messages, Documents, Services): specifications which enable two or more (HL7) trading partners to collaborate in the context of a specific business interaction

No assumptions of size, character, or identify of parties

Nations, Enterprises, Departments, Individual, Systems, etc.

No assumptions of exchange details (What, Why, How, etc.)


Saeaf value proposition 3 working interoperability l.jpg
SAEAF Value Proposition (3):Working Interoperability

D

C

E

Component

Component

B

F

Agree on

“Platform -Specific” view

A

Agree on

“Platform-Independent” view

Agree on “Conceptual” view

Agree on “Reference” view

A -- F: trading partners

  • Interoperability: the deterministic exchange of data/information in a manner that preserves shared meaning

  • Two “trading partners” interoperate based on a certified “level of shared compliance” to interoperability specifications/standards

  • Certified “level of conformance” determine degree of automated interoperability that is possible and/or difficulty of the transformations that are required to enable interoperability


Saeaf facts 1 l.jpg
SAEAF Facts (1)

  • Architecture: “A set of resources, relationships, and processes that collectively define a system and its products-of-value.”

  • HL7 is concerned with two architectures

    • #1: The organization of HL7 dedicated to producing specifications that promote interoperability within (between member participants) the “other” architecture, i.e.

    • #2: The collective “enterprise architecture” that supports healthcare, life sciences, and clinical research


Saeaf facts 2 l.jpg
SAEAF Facts (2)

  • SAEAF…

    • is a set ofFrameworks for producing specifications that support aspects of “HL7 architecture #2”

      • SAEAF is not meant to be a “complete” EA

      • SAEAF focuses on the critical interoperability aspects of HL7 specifications in each of the three HL7 Interoperability Paradigms

    • has structural, relationship, and process implications for architecture #1

    • defines the artifacts and specification semantics needed to support interoperability in healthcare, life sciences, and clinical research


Saeaf facts 3 l.jpg
SAEAF Facts (3)

  • The 3 component Frameworks of SAEAF:

    • Behavioral Framework (deck 2)

      • Specification of integration semantics of IT components

      • Linkage of integration semantics to real-world behaviors

    • Conformance/Compliance Framework (deck 3)

      • Layered to enable “degrees” of conformance and compliance

    • Governance Framework (deck 4)

      • Internal HL7 governance

      • HL7 relationships to other organizations specifying standards

    • NOTE: there is no formal “Static Framework” listed because of the existing maturity of the HL7 RIM, ADT specification, CDA, etc. which are used to describe static semantics in HL7 specifications


Saeaf facts 4 l.jpg
SAEAF Facts (4)

  • SAEAF…

    • is now stable/mature enough to begin “pilot” implementations that:

      • produce SAEAF-compliant message, document, and service specifications

      • utilize and provide feedback for SAEAF-centric Education

      • execute under SAEAF-triggered Change Management processes

      • report to the TSC or its designate

  • Focus of TSC activities going forward (additional deck)

    • Education

    • Change Management

    • Alpha Projects in all Interoperability Paradigms


The lens of saeaf 1 contextualizing saeaf l.jpg
The Lens of SAEAF (1):Contextualizing SAEAF

  • SAEAF: intersection of SOA, MDA, CSI, Distributed Systems Architecture, and HL7 (e.g. HDF, Core Principles) provide goals, artifacts, portions of a methodology, and a framework for defining the HL7 EA, a robust, durable business-oriented set of constructs that provide extensibility, reuse, and governance.

Service Oriented

Architecture

Health Level 7

Computable Semantic

Interoperability

Reference Model

For Open Distributed

Processing

Model Driven

Architecture

You are here (Vousêtesiçi)


The lens of saeaf 2 services oriented architecture l.jpg
The Lens of SAEAF (2):Services-Oriented Architecture

  • SOA (Services-Oriented Architecture)

    • SAEAF is “services-aware,” i.e., not “just about services

  • Service awareness (at the architecture level) surfaces need for:

    • Behavioral Framework built around Contracts and Roles

    • Well-defined Conformance/Compliance Framework

    • Focus on Governance

    • Attention to “separation of concerns” (static vs dynamic)

    • Technology-Independent specifications


The lens of saeaf 3 model driven architecture l.jpg
The Lens of SAEAF (3):Model-Driven Architecture

  • MDA (Model-Driven Architecture) enables

    • Levels of abstraction that layer complexity from Conceptual through Logical to Implementation

      • Support/enforce SOA thinking

      • Support partitioning of artifacts to layers of Conformance/Compliance Framework

    • Solid tooling support


The lens of saeaf 4 computable semantic interoperability csi l.jpg
The Lens of SAEAF (4):Computable Semantic Interoperability (CSI)

CSI (Computable Semantic Interoperability)

Pillar #1: Common Model across all domains-of-interest

Multiple domains  one or more domain analysis models Common Model Components  Universally applied

Pillar #2: Model #1 bound to robust data type specification

Pillar #3: Methodology for binding terms from concept-based terminologies

Pillar #4: A formally-defined process for specifying the static and behavioral semantics of the interoperability scenario


The lens of saeaf 5 computable semantic interoperability csi l.jpg
The Lens of SAEAF (5):Computable Semantic Interoperability (CSI)

CSI (Computable Semantic Interoperability)

Individual domains-of-interest may share common concepts (e.g. Person)

CSI informs SAEAF artifact generation

facilitate expression of explicit semantics across multiple domain models (e.g. multiple Clinical Domain Models for constructed in separate clinical domains)


The lens of saeaf 6 rm odp l.jpg
The Lens of SAEAF (6)RM-ODP

  • RM-ODP (Reference Model for Open Distributed Processing)

    • ISO standard

    • View Points + Ontology for human semantic interoperability and for creating specifications of distributed systems


Rm odp 1 iso standard rm odp iso iec is 10746 itu t x 900 l.jpg
RM-ODP (1) ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 )

  • SAEAF used the Reference Model for Open Distributed Processing (RM-ODP) as its lingua franca categorize the various artifacts

    • Five non-orthogonal, non-hierarchical Viewpoints in which Conformance Assertions are made or validated

      • Conformance Statements made (Conformance asserted):

        • Enterprise/ Business VP

        • Informational VP

        • Computational VP

        • Engineering VP

      • Conformance Statements validated (Conformance tested)

        • Technology VP


Rm odp 2 iso standard rm odp iso iec is 10746 itu t x 900 l.jpg
RM-ODP (2) ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 )

Why?

What?

How?

Where?

True?

SAEAF Specification Stack is made up of Conformance Assertions and Compliance Validations.

In SAEAF, the artifacts are constructed via Constraint Patterns sorted by RM-ODP Viewpoints.


Rm odp 3 iso standard rm odp iso iec is 10746 itu t x 900 l.jpg
RM-ODP (3) ISO Standard (RM – ODP, ISO/IEC IS 10746 | ITU-T X.900 )

Information

Computational

Business /Enterprise

Engineering

Technology

  • Non-hierarchical and Non-orthogonal

    • Each Viewpoint can (and often will) contain a hierarchy of layered information


The lens of the saeaf 7 health level 7 l.jpg
The Lens of the SAEAF (7):Health Level 7

  • HL7

    • SAEAF takes a number of enterprise architecture best practices / approaches and contextualizes them to HL7 including

      • Use of existing HL7 artifacts

        • Core Principles

        • HDF

        • RMIMs

        • etc.

      • Awareness of HL7 business context

      • Dedication to HL7 Mission and Goals RE Working Interoperability


Saeaf soa and ea core principles 1 l.jpg
SAEAF, SOA, and EA: Core Principles (1)

  • Objectives of the SAEAF project:

    • Facilitate organization-wide development of service specifications

      • Enable “Unified Field Theory,” i.e. contextualization and utilization of SAEAF principles, processes, and practices in the development of other HL7 specifications (e.g. messages, documents, etc.)

    • Explicit definition of/support for

      • Behavioral Framework (deck 2)

        • Contract-based integration

        • Functional specification

      • Conformance/Compliance Framework (deck 3)

        • Requirements traceability

      • Explicit expression of policy and governance (deck 4)


Saeaf soa and ea core principles 2 l.jpg
SAEAF, SOA, and EA: Core Principles (2)

  • SAEAF draws on a “Combination of Forces”

    • Existing HL7 artifacts (RIM, ADT’s, CDA, etc.)

    • RM-ODP methodology and framework as the lingua franca

    • Application Model-Driven Architecture (MDA)

    • Commitment to and framework for achieving Computable Semantic Interoperability (CSI)

    • Necessity of a Conformance/Compliance Framework

      • “…the micrometer, T-square, and plumb-bob of an Enterprise Architecture…”

    • Service-awareness/SOA perspectives and explicitness


Saeaf soa and ea core principles 3 l.jpg
SAEAF, SOA, and EA: Core Principles (3)

  • Given the Value Proposition (Working Interoperability), the following requirements surface, i.e. the need for:

    • Definition of Data/Information to be exchanged

    • Definition of Functions that enable/perform the exchange

    • Traceable Mappings of functions to Real World Events and Business Processes

    • Reference Terminology / Language for sorting and discussing the above

    • Engineering Deployment Topologies and Technology Bindings to achieve/instantiate Working Interoperability


Saeaf soa and ea core principles 4 syntactic vs semantic interoperability l.jpg
SAEAF, SOA, and EA: Core Principles (4)Syntactic vs Semantic Interoperability

  • Main Entry: in·ter·op·er·a·bil·i·ty: ability of a system ... to use the parts or equipment of another system

  • interoperability: ability of two or more systems or components toexchange information and to predictably use the information that has been exchanged.

Source: Merriam-Webster web site

Syntax  Structure

Semantics  Meaning

Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]

Semanticinteroperability

Syntactic interoperability(interchange)

Semantic Interoperability means reliable, predictable exchange of meaning between two parties, be they machine or persons.


Saeaf soa and ea core principles 5 pillars of csi redux l.jpg
SAEAF, SOA, and EA: Core Principles (5)Pillars of CSI -- redux

  • #1 - Common model across all domains-of-interest

    • Information model vs Data model

    • Semanticsof shared concepts – Domain Analysis Model

    • Includes, but does not necessarily require, dynamic/behavioral semantics

      • Functions

      • Behavior

      • Interactions

  • #2- (static) Model bound to robust data type specification

    • HL7 V3 Abstract Data Type Specification (R2)

    • ISO DT Specification


Saeaf soa and ea core principles 6 pillars of computable semantic interoperability l.jpg
SAEAF, SOA, and EA: Core Principles (6)Pillars of Computable Semantic Interoperability

  • #3 - Methodology for binding terms from concept-based terminologies

    • Domain-specific semantics bound to cross-domain concepts

  • #4 - A formally-defined process for specifying the static and behavioral semantics of the interoperability scenario, e.g.

    • RM-ODP- and MDA-based Service Specification Methodology

    • Service interfaces and interactions semantics (“Contracts,” “Service Roles,” “Interactions”)

    • Methodology for specifying exchange/wire format

  • CSI Pillars form a key component of WI Value Proposition


Saeaf soa and ea core principles 7 integration vs interoperability l.jpg
SAEAF, SOA, and EA: Core Principles (7)Integration vs Interoperability

  • Implementers need a framework to provide:

    • 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

      • Reflect the semantics of integration (CSI)

    • 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?”)


Saeaf soa and ea core principles 8 integration vs interoperability l.jpg
SAEAF, SOA, and EA: Core Principles (8)Integration vs Interoperability

  • Any single instance of integration is simple, though not necessarily easy.

    • Engineers of any single system understand it well enough to allow integration with any other single system

    • Integration is an manufacturing/implementation issue, i.e. deployment of computational components

  • Interoperability is an engineering/architectural concern that allows for the creation of multiple context-specific integration solutions

    • The complexity and high-change of healthcare requires WI  requires an EAS

      • “Enterprise Architecture is more than just an implementation or technology perspective.”


Saeaf soa and ea core principles 9 enterprise integration paradigms l.jpg
SAEAF, SOA, and EA: Core Principles (9)Enterprise Integration Paradigms

  • Service/service-aware perspectives make explicit

    • Integration dimensions

      • Static (“the data”)

      • Functional (“what data goes in and/or comes out”)

      • Behavioral (“who interacts with whom?”)

      • Business Context (“who is interacting where and why?”)

    • Integration dimensions ~RM-OPD Viewpoints

      • Static  Informational

      • Functional & Behavioral  Computational

      • Business Context  Enterprise, Computational, Engineering

    • Integration Points between interacting components

      • Testable and Enforceable


Saeaf soa and ea core principles 10 summary services and service awareness 1 l.jpg
SAEAF, SOA, and EA: Core Principles (10)Summary: Services and Service Awareness (1)

  • Services/service-awareness perspectives are

    • supported by various artifacts

      • that allow them to be specified technologically neutrally

      • support conformance,

      • provide a framework for specification of various semantics, and

      • are necessary for integrating systems across the enterprise.


Saeaf soa and ea core principles 11 summary services and service awareness 2 l.jpg
SAEAF, SOA, and EA: Core Principles (11)Summary: Services and Service Awareness (2)

  • Services/service-aware perspectives are

    • not technology-specific per se.

    • are a framework for approaching the problem

      • of how to design distributed capabilities (information and functionality sharing)

  • SAEAF is notdefining “service” per se

    • SAEAF is using perspectives from the SOA world

      • Hence the phrase “service-aware perspective”

  • Services are not equivalent to Web Services


Saeaf soa and ea core principles 12 summary services and service awareness 3 l.jpg
SAEAF, SOA, and EA: Core Principles (12)Summary: Services and Service Awareness (3)

Services/service-aware perspective focus on

Virtualization

Composition

Unity of Purpose and Separation of Concerns

Parsimony

Technology Independence

Specifications supporting Layered Conformance and Compliance


Saeaf soa and ea core principles 13 services and service awareness text from bf document l.jpg
SAEAF, SOA, and EA: Core Principles (13)Services and Service Awareness (text from BF document)

  • Because services cannot directly leverage the principles that make objects so enduring (e.g. encapsulation, polymorphism, and inheritance.), it is necessary to construct a set of principles that support service-oriented definition and design.

  • Enterprise Architecture is the framework that provides the service specification foundation and thus plays a critical role in successful service design.  The following principles are considered essential for enterprise-level service specifications which explicitly define testable, verifiable four-dimensioned service contracts:

    • Virtualization

    • Composition

    • Unity of Purpose and Separation of Concerns

    • Parsimony

    • Technology Independence

    • Specification supports a Layered Conformance Policy

  • These principles are validated and coordinated in the Service Classification Scheme, as well as in crafting individual services via Specification Best Practices

    • see SAEAF deck 2 (Behavioral Fframework)


History of services in hl7 1 l.jpg
History of Services in HL7 (1)

  • Early efforts

    • ebXML

    • Web Service Profile for HL7

  • 2005: The Health Services Specification Project (HSSP)

    • HL7 established an agreement with the Object Management Group (OMG) to share intellectual capital in support of the cooperative development of healthcare-specific services

      • HL7 would specify requirements and some analysis artifacts (Service Functional Model)

      • OMG would create the technical specification in conjunction with industry


History of services in hl7 2 l.jpg
History of Services in HL7 (2)

  • In support of HSSP, HL7 formed the SOA SIG (now WG)

  • Produced several SFMs balloted as DSTUs

    • Resource Locate and Update Service (RLUS)

    • Entity Identification Service (EIS)

    • Decision Support Service (DSS)

    • Clinical Research Functional Query Service (CRFQS)

    • Several currently in-process

      • Privacy and Security Services (PASS)

      • Service Provider Registry (SPR)


History of services in hl7 3 l.jpg
History of Services in HL7 (3)

  • Alignment of SAEAF and HSSP: artifacts

    • Service Functional Model (SFM)

      • Essentially the same as the SAEAF Analysis Specification artifact

        • Should be readily interchangeable for the purposes of HL7 SAEAF and HSSP coordination


History of services in hl7 4 l.jpg
History of Services in HL7 (4)

  • Alignment of SAEAF and HSSP: process

    • Service Specification Framework served as one of the inputs into the SAEAF

    • SAEAF extends the HL7 portion of HSSP by defining Logical and Platform specifications within HL7

      • Functional Profiles and Semantic Profiles

      • OMG has expressed interest in aligning these SAEAF artifacts with OMG artifacts

        • SAEAF allows artifacts to be built outside of HL7

  • Both the SAEAF and the HSSP Processes support MDA, Constraint Patterns


History of services in hl7 5 l.jpg
History of Services in HL7 (5)

  • HL7, Services, HSSP, and OMG

    • The HSSP Process provides one means of intersection between HL7 and OMG

      • The HSSP process is one exemplar means of creating constrained specifications based on the SAEAF’s Analysis Specification outside of HL7.

    • Other Intersections include MDA, SOA ML, UML, BPDM

    • The HSSP Process is encouraged and Facilitated by greater specification on the HL7 side

  • Ongoing HL7/OMG relationship is considered important to both organizations


History of services in hl7 6 l.jpg
History of Services in HL7 (6)

  • The HSSP Process exposed other SDOs to the initial aspects of HL7 Service Specifications

  • SAEAF enables HL7 standards to “stand on their own” or be built in collaboration with other organizations (e.g. OMG)

    • Consumable and implementable within the context of a formal Conformance/Compliance Framework

  • The ArB drew heavily on HSSP and the NCI’s caBIG® experience in developing the SAEAF


History of services in hl7 7 l.jpg
History of Services in HL7 (7)

  • Services – even as abstractions – have helped surface gaps in the HL7 pantheon of work products

    • Explicit representation of functional and dynamic (behavioral) semantics

    • Malleable integration points with multiple system architectures

  • The development of the SAEAF drew heavily on service-based constructs


History of services in hl7 8 arb position on hssp l.jpg
History of Services in HL7 (8)ArB Position on HSSP

  • Following discussions with HSSP representatives, the ArB affirms that the HSSP framework is in conceptual alignment with the HL7 SAEAF with respect to both processes and artifacts. In particular, the MDA-based process, i.e., the HSSP Service Specification Framework, produces a Service Functional Model, a Platform-Independent Model, and a Platform-Specific model that are, in principle, in alignment with the HL7 SAEAF. However, it needs to be made clear that this alignment is between the overarching HSSP process/artifacts -- which by definition include at least two participating organizations (e.g., HL7 and OMG) -- and HL7 as the sole producer of SAEAF-compliant processes/artifacts. This is an important distinction because it will almost certainly be the case that the SAEAF framework will result in processes/artifacts produced completely within HL7 which are not necessarily defined in the HSSP, thereby resulting in some degree of non-alignment. As the SAEAF artifacts and processes mature, it remains an open question as to how (or if) any variations between the SAEAF and the HSSP will be addressed.


Saeaf operationalization and implications 1 timeline 1 l.jpg
SAEAF Operationalization and Implications: (1)Timeline (1)

September 2008

Initial SAEAF draft released

TSC formally adopts SAEAF as “path forward” for EAS

BoD endorses SAEAF and TSC position

“Alpha project” for SAEAF deployment proposed by TSC

April 09: staffed and funded

Candidate projects identified (all IPs)

Details of project in a separate deck (5) and document

Focus is on education and change management

Scalability

Governance

?Backward compatibility?


Saeaf operationalization and implications 1 timeline 2 l.jpg
SAEAF Operationalization and Implications: (1)Timeline (2)

High-level Rollout timeline (TSC approved)

May WGM

ArB OOC

2008

2009

2010

Sept WGM

January WGM

January WGM

Sept WGM

  • 2009

    • January WGM – Impact and Education, Drafts for Comment

    • ArB OOC – Finalize SAEAF

    • May WGM – Finalize SAEAF, launch Alpha project

  • 2008

    • September WGM – Planning and Socialization

    • SAEAF initial comment period


Saeaf operationalization and implications 3 intra hl7 implications 1 l.jpg
SAEAF Operationalization and Implications: (3)Intra-HL7 Implications (1)

HL7 Interoperability Paradigms (messages, documents, services)

Fully-specified Domain Analysis Model (DAM) is the Crtical Success Factor on the road to WI

Provides traceability to Logical and Physical levels

Binds Informational and Computational Viewpoints

Serves as placeholder for remaining RM-ODP Viewpoint CAs

Serves as placeholder for additional Policy or Governance topics


Saeaf operationalization and implications 3 intra hl7 implications 2 l.jpg
SAEAF Operationalization and Implications: (3)Intra-HL7 Implications (2)

Figure 11: Differences and Commonalities between the Specificationsdelimited by the major category of HL7

Interoperability Paradigm (i.e.services, documents, and messages). Note that there is a common set of Analysis-level

artifacts (detailed below) that collectively define a Conceptual Level of Compliance. Different analysis-derived artifacts

then specify the Design and Implementation details of each Interoperability Paradigm. In all cases, elements of the SAEAF

map to a well-defined “phase” of a standard Software


Saeaf operationalization and implications 3 intra hl7 implications 3 l.jpg
SAEAF Operationalization and Implications: (3)Intra-HL7 Implications (3)

Note the common DAM artifacts for all IPs.

Provides a more formal framework for the CDA-based notion of “highly-informational vs less-informational” exchanges of information

1001 0100 0100

1001 0100 0100

1011 1110 0101

1011 1110 0101

Highly “Informational” Systems

*

1001 0100 0100

1011 1110 0101

*

Less “Informational” Systems

1001 0100 0100

1011 1110 0101

*HL7 Clinical Document Architecture: Single standard forcomputer processable and computer manageable data

(Wes Rishel, Gartner Group)

Figure 12: The Integration Points for Highly Informational Systems may meet different Quality and Functional Requirements than the systems themselves.

Thus Highly Informational Systems may expose non-computable information, and vice versa.


Saeaf operationalization and implications 3 intra hl7 implications 159 l.jpg
SAEAF Operationalization and Implications: (3)Intra-HL7 Implications (1)

HL7 Work Groups

Much of recent reorganization aligns well with SAEAF

Project-based activity vs static “vertical” organization

Promotion of fully-specified services to the level of “equal” with messages and documents will require a group to manage the details of specific normative specifications that will developed for services

Service Specification Normative artifacts including

Normative artifact for Contract

Normative artifact for Service Role Specification


Saeaf operationalization and implications 3 inter hl7 implications 1 l.jpg
SAEAF Operationalization and Implications: (3)Inter-HL7 Implications (1)

HL7 has a number of explicit (MoU) and implicit relationships with other SDO and de facto SDOs

ArB recommends that these relationships all be made as explicit as possible in the context of SAEAF

Following are a number of specific examples

More details in SAEAF Introduction and Governance documents


Saeaf operationalization and implications 3 inter hl7 implications 2 l.jpg
SAEAF Operationalization and Implications: (3)Inter-HL7 Implications (2)

Object Management Group (OMG)

SAEAF artifacts may accelerate OMG ability to produce implementations of “healthcare services”

HL7 could supply “full Conceptual and PIM-level” artifacts as input into OMG RFP process

SAEAF expects to significantly leverage

MDA-based transforms

SOA Pro/UML Metamodel for Services (UMPL)

Business Process Definition Metamodel (BPDM)

Business Process Modeling Notation (BPMN)

Behavioral Framework documentation contains an analysis of SOA ML


Saeaf operationalization and implications 3 inter hl7 implications 3 l.jpg
SAEAF Operationalization and Implications: (3)Inter-HL7 Implications (3)

CBDI Consultancy

ArB used CBDI Service taxonomy to inform SAEAF

W3C

SAEAF will leverage CDL and WS-* specifications

Orlando meeting marked kick-off of HL7/OMG/W3C HCLS collaboration

OASIS

ArB will continue to monitor the Normative SOA architecture for input from both a “pure services” and “services-aware” perspective


Saeaf operationalization and implications 3 inter hl7 implications 4 l.jpg
SAEAF Operationalization and Implications: (3)Inter-HL7 Implications (4)

Joint Interoperability Council (JIC)

HL7

ISO

CEN

CDISC

CSI Pillar #2 supported by ISO 21090, a product of JIC effort

HL7 plans to move SAEAF into the JIC dialogue

National Institute of Standards and Technology (NIST)

Introduction of ECCF into NIST testing of HL7 artifacts and systems


Saeaf operationalization and implications 3 inter hl7 implications 5 l.jpg
SAEAF Operationalization and Implications: (3)Inter-HL7 Implications (5)

Tooling/Open Health Tools

Focus on Working Interoperability and the critical role of architecture

Adopting SAEAF ECCF for use in tool specification

Mission/Charter:

  • To enable the adoption, development, and deployment of an evolving set of interoperable tools. These tools support the

  • development and deployment of software that enables computable semanticinteroperability in the health-care/life sciences/clinical

  • research domains. Tools are defined as any software component that is not aclinical end-user application, although such software

  • components may form part of an end user application. Tools are intended to be

  • useful and usable for their intended purpose and to inter operate with each other.

  • The OHT Architecture Project operates under the Open Health Tools Development Policy and Process (described at

  • http://www.openhealthtools.org/Documents/Open%20Health%20Tools%20-%20Development%20Process.pdf ) and is chartered

  • by the Board to articulate and adopt a formal architecture framework, architecture principles and best practices that are focused on

  • relevant interoperability and the use of standards. As its initial goal the Architecture Project will develop an architecture framework

  • that will itself enable the evolutionary development of an OHT Platform architecture consistent with the various enterprise

  • architectures built and deployed by OHT stakeholders.

  • Deliverables include:

  • a set of architecture principles.

  • a tool classification mechanism that enable stakeholders to contribute and have access to architecture artifacts that underlie the tools.

  • a set of templates, patterns and processes that enable interoperability of OHT tools.

  • identification of potential barriers to interoperability and recommendations to overcome them.

  • a recommendation to the board of a governance process to assist in the harvesting, categorization and custodianship of

  • architecture artifacts.

  • an executed internal and external communication plan.


Saeaf summary 1 l.jpg
SAEAF Summary (1)

  • SAEAF is not a replacement for, or an alternative to, HL7’s existing products, engagements, or offerings.

  • SAEAF is an effort to reframe, encompass, and support existing HL7 work streams, and to focus them around a more explicit framework for expressing interoperability semantics.

  • SAEAF is the result of a shared belief by the HL7 CTO, ArB, and TSC that the Health Enterprise requires this level of specificity and rigor to achieve scalable, agile interoperability.

    • HL7 is establishing a leadership position in this discussion


Saeaf summary 2 l.jpg
SAEAF Summary (2)

  • HL7 SAEAF aligns with strategic direction of national health-centric organizations

    • US DoD / VA

    • HITSP

    • Canada Health Infoway

    • NCI CBIIT (caBIG®, BIG Health®)

    • NeHTA

  • HL7 SAEAF aligns with other industry standards

    • WS-CDL

    • SOA Pro

    • HISA


Saeaf summary 3 l.jpg
SAEAF Summary (3)

  • The HL7 Services-Aware Enterprise Architecture Framework (SAEAF) provides a framework for specification of standardized “artifacts that enable Working Interoperability” that can be used by the HL7 community regardless of the chosen Interoperability Paradigm (messages, documents, services).

  • The SAEAF defines specific artifacts and a formal constraint pattern that provide traceability from requirements through analysis to design and implementation.

  • SAEAF-compliant specifications align with conformance levels specified in a Conformance/Compliance Framework (C/C F) that enable HL7 consumers to adopt HL7 specifications in different contexts at different levels of interoperability.


Saeaf summary 4 l.jpg
SAEAF Summary (4)

  • The HL7 Services Aware Enterprise Architecture Framework was undertaken to identify/define the language, processes, and artifacts to talk about a Enterprise Architecture appropriate for an SDO using services or services-aware thinking as a backbone concept in developing and deploying standards to enable Working Interoperability.

  • 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 (although service constructs (as well as other Interoperability Paradigm constructs) may be realized using Web Services technology.


Saeaf summary 5 the lens redux l.jpg
SAEAF Summary (5)(The Lens Redux)

  • 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 SAEAF, a robust, durable business-oriented set of constructs that provide extensibility, reuse, and governance.

Service Oriented

Architecture

Health Level 7

Computable Semantic

Interoperability

Reference Model

For Open Distributed

Processing

Model Driven

Architecture

You are here (Vousêtesiçi)


Saeaf summary 6 conclusion l.jpg
SAEAF Summary (6):Conclusion

  • “Services-aware but not services-specific”

    • Consideration given to three HL7 “interoperability paradigms” (“HL7 Unified Field Theory”)

      • Messages

      • Documents

      • Services

  • The SAEAF work draws on “service-centric principles” e.g.

    • Contracts and Behavior

    • Separation of Concerns

    • Conformance/Compliance

    • Governance

SAEAF: A “Services-Aware Enterprise Architecture for HL7”



ad