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