HL7 SOA-Aware Enterprise Architecture

04/21/23 19:10

HL7 SOA-Aware Enterprise ArchitectureHL7 SOA-Aware Enterprise Architecture

Impact Summary

November 17, 2008

Impact Summary

November 17, 2008

Page 2

PrefaceA few notes …PrefaceA few notes …

• There are three main outputs from last week’s discussion

– This is hard!!!!

– Oh [expletive deleted]!

–

Page 3

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

Page 4

Artifacts and MethodologyArtifacts and Methodology

• Some form of Templates, Models, Patterns for WG's need to be created.

– Including project management documents

– Ultimately a checklist of artifacts?

– RPF / EPF

• Reference and Implementation Guides and Assists

• Will require a dedicated effort, even given the fact that a lot of these things exist in HL7 member organizations and could be brought in

– NCI, Infoway

• Nice, but not essential to make these tool based

– Ultimately, there should be tooling

Page 5

Infrastructure AlignmentInfrastructure Alignment

• HDF and Core Principles need to align with SAEAF

– This may be easy if you make the HDF the project management template and move the other sections to either other documents or move the HDF into the SAEAF.

• Alignment includes

– Refinement at the requirements level (direct impact on the HDF material)

– the recommendations are "Stronger" than "recommended best practice“

– They are mainly focused on refinement of "produce specification" step in the HDF

– Will involves decomposition and some replacement

Page 6

SAEAFSAEAF

• SAEAF needs to be evolved along its main themes

– Conformance/Compliance

– Governance

– Constraint patterns expressed for all (RM-ODP) viewpoints

• Some of these might require some transition to new formalisms

– Business Viewpoint (questionable and minor disruption)

– Computation and Behavioral Framework (big disruption)

– Information (very little disruption here)

– Publication (big disruption here).

• Ballots

• Normative / Reference Edition

Page 7

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 (not comprehensive)

EHR-FM, Clinical

Statement Pattern

RIM, Structured Vocab, ADTs,

Clinical Statement Pattern, CDA,

UCUM

EHR-FM, Behavioral Framework

ITS, RIMBAA Reference

Analysis Business Context,

Reference Context, CDA

Profiles

DIM, R-MIM, CMET’s(Bindings), CIM (eg, R-MIM)

Dynamic Blueprint, Functional Profile(s), [Storyboard], CDA

Profiles

N/A Blueprint

Conceptual Design

Business Governance

HMD, CIM Dynamic Model, Interface

Specification, [Storyboard]

N/A Platform Independent

Implementable Design

N/A Transforms, Schema, LIM

Orchestration, Interface Realization

Execution Context,

Specification Bindings,

Deployment Model

Platform Bound

Page 8

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

RIM, Structured Vocab, ADTs, BRIDG, CEN

13606

EHR-FM, N/A Reference

Analysis Business Context,

Reference Context, HSSP,

CDA Profiles

CDA Profiles, Terminology

Bindings

HL7 Behavioral Framework, BPDM,

SBVR, SoaML, HSSP

N/A Blueprint

Conceptual Design

J2EE, .NET, WS-*

Value Set Bindings, HL7

Templates, OpenEHR

Archetypes, ASC X12, DICOM

SaoML, WS-CDL, WS-BPEL, BPMN 1

and 2, EbXML, ASC X12

N/A Platform Independent

Implementable Design

IHE Profiles, N/A

XML Schema, XSL, IHE Profiles

IHE Profiles, WS-CDL, WSDL, WS-*,

J2EE, .NET, EbXML

WS-*, J2EE, .NET,

EbXML

Platform Bound

Page 9

Education and ToolingEducation and Tooling

• See Below

Page 10

Organizational ImpactsOrganizational Impacts

• There are two lines of business of HL7 under the SAEAF

– Crafting specifications that define integration aspects of components that support the "business of healthcare / life science / regulatory reporting“

– Adoption / Adaptation / creation of frameworks that support the “line of business” specifications

• The SAEAF defines domain governance based on the “line of business specifications” explicitly, and on the reference framework implicitly

– That is, the SAEAF allows for the creation / adoption / adaptation of frameworks as needed, and then proceeds to define conformance and compliance (and all other governance supporting that) in terms of standardized “line of business” specs

• Most conformance assertions to “HL7” will be in terms of a given specification as defined under the SAEAF

– “Our scheduling application is HL7 compliant because we use the HL7 Scheduling Service Role as defined in the Scheduling Service Role Specification. We claim compliance because our implemented components exhibit the integration semantics as defined in that spec.”

Page 11

Organizational Impacts (2)Organizational Impacts (2)

The orange outlines define the proposed organizational outlines

1. Reference Frameworks supports a line of business

2. Agnostic Reference Frameworks

3. Line of Business Analysis

4. Cross Functional Project Teams that combine the previous three as needed to define specs

Page 12

Organizational Impacts (3) Organizational Impacts (3)

• POTENTIAL Recommendations

– breaking up some groups (e.g. structured docs, and others) between their components that build frameworks, and those portions that define standards for the "business of healthcare“

– creating two groups that create reference frameworks, one dedicated to a line of business (like clinical statements) and also to non-line of business frameworks (like the RIM and BF)

– TSSSD moves under ArB as a means of effecting the SAEAF through

Page 13

Organizational Impacts (4)Organizational Impacts (4)

• All work to create Line of Business specs happens within a cross-functional group that includes

– Project Management

– Sponsoring Workgroup and involvement from Line of Business (#3 above)

– Mentors for the Reference Frameworks (as needed) (#1 and #2 above)

Page 14

Organizational Impacts (5)Organizational Impacts (5)

• There needs to be a dedicated mechanism to bring artifacts and processes from HL7 member organizations in to support the SAEAF

Page 15

Need for 1-3 Alpha ProjectsNeed for 1-3 Alpha Projects

• Due by May 2009 WGM?

• Need for dedicated support to early implementors

• See Criteria Below

Page 16

Criteria for Alpha Project SelectionCriteria for Alpha Project Selection

• Crosses two or more WorkGroups (but less than 15!)

• End-to-End business case with implementers ready to do it

– Crisply defined scope - no fuzzyness. That is, Meets a fully functional requirement

– Dedicated resources (either from HL7 and / or from sponsors, probably both)

– Not already under way – perhaps initiated but not started (in inception phase)

• Not about the foundational or structural frameworks - ISRS and / or behavioral specification (that is, is focused on line of business)

• Hit as much of the SAEAF framework as possible.

– Should reflect a subcomponent of Mind map of Publishing, which may mean separate publishing

Page 17

Conclusions (1)Conclusions (1)

– This is hard!!!!

– Oh [expletive deleted]!

–

Page 18

Conclusions (2)Conclusions (2)

• The ArB feels like it has defined the broad groups of work that needs to be undertaken to implement the SAEAF within HL7.

• We also feel like there are definite next steps, such as fleshing out the impacts and the instantiation of alpha projects

• However, we don’t feel that the ArB can make more recommendations until these exemplar impacts are assessed and we gain some understanding as to how strategy will be affected by the SAEAF

– For example, we can suggest more very concrete organizational restructurings (along the lines of slide 11), but hesitate to do so without more detail