HL7 SOA-Aware Enterprise Architecture

1. HL7 SOA-Aware Enterprise Architecture Impact Summary November 17, 2008

2. PrefaceA few notes … • There are three main outputs from last week’s discussion • This is hard!!!! • Oh [expletive deleted]!

3. 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

4. Artifacts 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

5. Infrastructure 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

6. SAEAF • 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

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

8. The SAEAF Applied (2)Governance and Other “Standards” (DRAFT)

9. Education and Tooling • See Below

10. Organizational 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.”

11. Organizational Impacts (2) • The orange outlines define the proposed organizational outlines • Reference Frameworks supports a line of business • Agnostic Reference Frameworks • Line of Business Analysis • Cross Functional Project Teams that combine the previous three as needed to define specs

12. 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

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

14. Organizational Impacts (5) • There needs to be a dedicated mechanism to bring artifacts and processes from HL7 member organizations in to support the SAEAF

15. Need for 1-3 Alpha Projects • Due by May 2009 WGM? • Need for dedicated support to early implementors • See Criteria Below

16. Criteria 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

17. Conclusions (1) • This is hard!!!! • Oh [expletive deleted]!

18. 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