HITSP Services Aware Framework Second Draft Interim Report

1. HITSP Services Aware FrameworkSecond Draft Interim Report Framework Review Working Group November 15, 2008

2. HITSP Framework ReviewInterim Report Foundations Framework Review Working Group November 15, 2008 enabling healthcare interoperability

3. Table of Contents Overview Organization and Participation Work to Date • Agreed to Work Plan • Defined Scope of Problem • Gathered information • Conducted a preliminary evaluation of options • Prepared interim report Next Steps - Modify the HITSP Harmonization Framework Next Steps - Add Service Construct to Framework References Appendices

4. Overview • This is an interim report from the HITSP Foundations Framework Review Working Group on its evaluation of options and proposed directions to modify the HITSP Harmonization Framework to incorporate Services. • We invite timely feedback from the Program Team and TC Leadership to help inform and refine our next deliverable. We intend to proceed to develop a proposed plan to deliver by December 31.

5. Organization and Participation • Leadership • John Quinn, HL7 • Elliot Sloane, IHE • Key Representation and Participation (See Appendix 1 for listing) • HITSP TC leadership and staff • HL7, FHA and IHE • NHIN Leadership • Other interested parties • Logistics • 6 conference calls

6. Work to Date • Developed work plan • Defined scope of problems • Gathered information • Conducted a preliminary evaluation of options • Prepared interim report

7. 1. Developed and Updated Work Plan • Major Tasks of Framework Review WG • Define the scope of the problems we want to address in the Framework Review. • Understand the Services Aware Enterprise Architecture Framework (SAEAF) that HL7 is developing and the NHIN Draft Specifications • Based on our HITSP expertise, evaluate how SAEAF, NHIN specs and/or direct service wrappers to HITSP constructs can be applied (assuming they can). • Issue a report of the above with expected directions (November 15) • Redesign the Framework as necessary to support services, interoperability service contracts and avoid any rip and replace • Develop an implementation and transition plan to present to TC Leadership by December 31

8. 2. Defined Scope of Problems • Identified Problems • Implementers desire to reuse constructs in new and novel contexts Use of a single construct, e.g., C32 Summary, outside of the context of an Interoperability Specification is not conformant despite HITSP intention to promote reuse • Current HITSP framework does not consistently incorporate services Use of services is not fully harmonized between HITSP, CCHIT and the NHIN trial implementations • Defining conformance at different levels of “the stack” Platform independent conformance versus platform dependent instance • Producing 2009 extension and gap fillers is too cumbersome using current framework Would require 13 new or edited Interoperability Specifications • Current HITSP documents and their interrelationships are perceived as complex and complicated for use by implementers • Current framework requires changes across many documents when one document is changed

9. Defined Scope of Problems Other Challenges to Consider Alignment with HITSP current framework, templates and concepts and relationships Includes concepts of stakeholders, business actors, technical actors, Information Exchange Requirements (IERs), and Data Requirements (DRs) Coordination with and transition from existing framework and documents A primary benefit of adapting a service aware framework that enables use of services is to allow use outside the context of an Interoperability Specification although an IS may still invoke the services Existing Interoperability Specifications and their constructs must be evaluated to determine if, how and when they will be modified or amended to use services Some current constructs may be candidates for expression as services but may have to be maintained as both a traditional construct and a service until and if all IS have moved to use of services

10. 3. Gathered Information on Options • HL7 Services Aware Enterprise Architecture Framework (SAEAF) that HL7 is developing • Presentation of SAEAF and Interoperable Services Role Specification by HL7 Architecture Review Board (ArB) experts • Evaluate The Open Group Architecture Framework (TOGAF) and possible other alternatives versus RM-ODP to inform work • NHIN draft Services Specifications • Presentation by NHIN leadership • Other materials - TBD

11. Preliminary Evaluation of Options • HL7 SAEAF • Uses the Reference Model for Open Distributed Process views combined with layers of constraint/conformance as Services Aware Framework • 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. - SAEAF • 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 – SAEAF • SAEAF layers support specifications and conformance at increasing level of constraint from model to actual implementations – this may permit interoperability of different implementations through shared transitions from the platform independent level • NHIN Draft Service Specifications • Instantiated interface for 10 primarily core services • Based on three platform decisions: Web Services, PKI security and HL7 V 3.0 messaging/CDA R2 • Draft Data Use and Reciprocal Support Agreement (DURSA) for governance

12. Interim Report – Proposed Next Steps • Modify the HITSP Harmonization Framework to incorporate services • Define how HITSP can use existing constructs and new constructs as service constructs within the HITSP Framework • Estimate Impact on HITSP and Stakeholders • Draft implementation, transition and governance plan to recommend to TC Leadership by December 31 for their subsequent approval

13. Next Steps: Modify the HITSP Harmonization Framework • Define services within collaborative framework • Complete evaluation of alternatives • Begin with minimum necessary required changes • Add views and layers to the framework to enable inclusion of services independent of Interoperability Specification context • Use layered conformance model including platform independent specifications and platform bound implementations • Expand HITSP framework to include independent service constructs • Define context for use of service constructs • Define classification of services types • When to use • See draft lists at Appendix 2

14. Next Steps: Define HITSP use of service constructs • Define how HITSP can use existing constructs and new constructs as service constructs in the HITSP Framework • Create new Service construct (template) • Includes platform independent definition Business process (summary of “use case”) Interface specification Behaviors Information content (may call HITSP component) Conformance statement • Employs existing Foundational concepts (See Appendix 3) IERs, DRs, Business and Technical Actors • Self contained and self-contexted (no IS required) • Can be used by any business actor in or out of Interoperability Specification • Create new draft template

15. Next Steps – Impact Analysis Estimate the resources required, risks and benefits of proposed plan and options if any Consider HITSP, its volunteers and stakeholders

16. Next Steps - Prepare Implementation and Transition Plan • Include example HITSP service • Develop an implementation, transition and governance plan to present to TC Leadership and Program Team by December 31 for acceptance • Recommend necessary changes to processes and templates for 2009 – may follow acceptance of plan

17. References Available in Foundations Framework Folder at HITSP.org • HL7 SOA-Aware Enterprise Architecture Service Role Specifications - HL7_SAEAF_ISRS.ppt • Services-Aware Enterprise Architecture Framework (SAEAF) for HL7 (V0.8) • NHIN Materials (available on request and agreement) • Approved NHIN Trial Implementations Service Interface Specifications • Core Content Specifications • Pending NHIN Trial Implementations Service Interface Specification • Test DURSA • NHIN Services One Pager – Craig Miller – NHIN Services One Pager.doc • HITSP Services – First Pass Taxonomy – Keith Boone -HITSP Services.doc • MEANS - A Multi-Enterprise Architecture of Networked Services Standards - EnterpriseArchitecture_Board_10-6.ppt • Current Framework and Fundamental Concepts - Framework and Foundations.ppt

18. Appendix 1 – Working Group Participants

19. Appendix 2 – Services Hierarchy SAEAF Classification of Services Core Process Capabilities Infrastructure First Pass of HITSP Constructs as Services 1. Document Sharing 2. Patient Indexing 3. Security 4. Content Definition 5. Healthcare Services 6. Health Coverage 7. Decision Support 8. Dynamic Data 9. Data Aggregation 10. General Communication NHIN Interface Specifications Subject Discovery Query for Documents Retrieve Documents Query Audit Log Authorization Framework Consumer Preferences Profile Messaging Platform Pseudonymization Health Information Event Messaging NHIE Service Registry See references