HL7 Interoperability Paradigms Fundamental Methodological

Download HL7 Interoperability Paradigms Fundamental Methodological

Post on 07-Dec-2014




1 download

Embed Size (px)




<ul><li> 1. April 9, 2009 <ul><li>OHT Architecture Project: </li></ul></li></ul> <ul><li>Update and Integration with HL7 SAEAF </li></ul> <p> 2. OHT Architecture Project Q2 2009 Content </p> <ul><li>Architecture principles</li></ul> <ul><li>Tool classification mechanism </li></ul> <ul><li>a set of templates, patterns and</li></ul> <ul><li>processes that enable</li></ul> <ul><li>interoperability of OHT tools.</li></ul> <ul><li>Identification of potential barriers </li></ul> <ul><li>Recommendation of a governance</li></ul> <ul><li>process for the harvesting,</li></ul> <ul><li>categorization and custodianship</li></ul> <ul><li>of architecture artifacts. </li></ul> <ul><li>Executed internal and external</li></ul> <ul><li>communication plan </li></ul> <ul><li>Architectural Principles Q2/09 </li></ul> <ul><li>Tooling Architectural Vision Q3/09</li></ul> <ul><li>Architectural Framework Q3/09 </li></ul> <ul><li>Tooling Classification and</li></ul> <ul><li>Governance recommendations Q4/09 </li></ul> <ul><li>Principles, Architecture Framework </li></ul> <ul><li>Specification Stack w examples </li></ul> <ul><li>Tool classification </li></ul> <ul><li>Recommendations to the Board </li></ul> <ul><li>Expectation for detailed Technical </li></ul> <ul><li>Architecture Solutions </li></ul> <ul><li>Expectation for Architectural</li></ul> <ul><li>Framework that allows for a Tooling </li></ul> <ul><li>Architecture to emerge through </li></ul> <ul><li>Projects </li></ul> <ul><li>Desire to reuse tooling components </li></ul> <ul><li>Desire to relearn from best practices </li></ul> <ul><li>Customer expectations to optimize</li></ul> <ul><li>and align Tooling investments </li></ul> <ul><li>Funding for Architecture Project</li></ul> <ul><li>team members</li></ul> <ul><li>Active cooperation from other</li></ul> <ul><li>OHT Project Committers </li></ul> <ul><li>Successful communication to </li></ul> <ul><li>OHT projects Q2/Q3 </li></ul> <p>Added Deleted &amp; Changed Milestones Packaging Editions Dependencies Pressures Statistics Contributing Participants: NCI, Infoway, NHS, NextJ, IHTSDO, NEHTA, HL7 3. Architecture Project Charter (1)</p> <ul><li>The objective of the OHT Architecture Project is to enable the adoption, development, and deployment of an evolving set ofinteroperabletools. </li></ul> <ul><li><ul><li>Tools are defined as any software component that is not a clinical 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.</li></ul></li></ul> <ul><li><ul><li><ul><li>Definition of tool intentionally left somewhat loose as that is not the primary focus of the AP.Rather it is enabling interoperability. </li></ul></li></ul></li></ul> <ul><li>These tools support the development and deployment of software that enablescomputable semantic interoperabilityin the health-care/life sciences/clinical research domains. </li></ul> <ul><li><ul><li>Recognition that CSI can occur in a multitude of ways and complexities </li></ul></li></ul> <ul><li><ul><li><ul><li>One-way data export </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Integrated real-time behavior coordination </li></ul></li></ul></li></ul> <p> 4. Architecture Project Charter (2) </p> <ul><li>The OHT Architecture Project operates under the Open Health Tools Development Policy and Process (described athttp://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.</li></ul> <ul><li>As its initial goal, the Architecture Project will develop anarchitecture framework </li></ul> <ul><li><ul><li>which will enable theevolutionary developmentof an OHT Platform architecture </li></ul></li></ul> <ul><li><ul><li><ul><li>consistent with the various enterprise architectures built and deployed by OHT stakeholders. (i.e. supporting appropriate CSI) </li></ul></li></ul></li></ul> <ul><li>(Frameworks must be specified top-down.EAS then develops bottom-up.) </li></ul> <p> 5. Architecture Project Charter (3) </p> <ul><li>Deliverables include:</li></ul> <ul><li><ul><li>a set of architecture principles. </li></ul></li></ul> <ul><li><ul><li><ul><li>Focus on CSI rather than architecture in general</li></ul></li></ul></li></ul> <ul><li><ul><li>a tool classification mechanism that enables stakeholders to contribute and have access to architecture artifacts that underlie the tools</li></ul></li></ul> <ul><li><ul><li>a Conformance/Compliance Framework adapted to tooling interoperability, including an explicit Specification Stack</li></ul></li></ul> <ul><li><ul><li>a set of templates, patterns and processes that enable interoperability of OHT tools</li></ul></li></ul> <ul><li><ul><li>identification of potential barriers to interoperability and recommendations to overcome them</li></ul></li></ul> <ul><li><ul><li>a recommendation to the board of a governance process to assist in the harvesting, categorization and custodianship of architecture artifacts</li></ul></li></ul> <ul><li><ul><li>an executed internal and external communication plan</li></ul></li></ul> <p> 6. 4Q08 2Q09 1Q09 3Q09 4Q09 First Conceptual Meeting Informal Organizational Meetings Orlando/Paris OHT Architecture Project Q2 2009 Architecture Principles &amp; Best Practices -harmonized with current projects Draft Framework &amp; Current State Examples Tooling Classification &amp; Governance recommendations 7. SAEAF Background (1) A Services-Aware Enterprise Architecture for HL7 </p> <ul><li>April 08:HSSP-sponsored Services in Healthcare conference, Chicago, IL (attended by HL7 CTO) </li></ul> <ul><li>May 08: HL7 CTO asks the HL7 ArB todevelop a straw-man proposal for services development within the context of an HL7 Enterprise Architecture </li></ul> <ul><li><ul><li> Specify the artifacts and processes necessary to allow HL7 to define specifications for SOA integration. </li></ul></li></ul> <ul><li><ul><li> Define an HL7 Enterprise Architecture Framework (EAF) which contextualizes HL7 specifications in a SOA environment. </li></ul></li></ul> <ul><li><ul><li>Consider services first, but dont exclude messages or documents as Interoperability Paradigms </li></ul></li></ul> <ul><li><ul><li><ul><li> HL7 EAF should beservices-aware , notservice-specific </li></ul></li></ul></li></ul> <p> 8. SAEAF Background (2) A Services-Aware Enterprise Architecture for HL7 </p> <ul><li>Summer 08:HL7 Executive Committee agreed to sponsor three face-to-face ArB EAF Jump-Start meetings </li></ul> <ul><li><ul><li>Modeled after Left-Hand Side of the RIM project (1998) </li></ul></li></ul> <ul><li><ul><li>Three 3-day F2F meetings in June, July, August, 2008 </li></ul></li></ul> <ul><li><ul><li><ul><li>Transparent process </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>Open attendance </li></ul></li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>Published agendas </li></ul></li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>Published artefacts and works-in-progress </li></ul></li></ul></li></ul></li></ul> <ul><li>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 </li></ul> <p> 9. SAEAF Background (3) A Services-Aware Enterprise Architecture for HL7 </p> <ul><li>Jump-Start Deliverables (largely contained in the collection of SAEAF documents) to include (but not be limited to): </li></ul> <ul><li><ul><li>EA framework informed by service specification considerations and industry experience ( services-aware ) </li></ul></li></ul> <ul><li><ul><li>Identification and initial specification of required infrastructure currently missing or incomplete in HL7 </li></ul></li></ul> <ul><li><ul><li><ul><li>Behavioral Framework (BF) </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Enterprise Conformance &amp; Compliance Framework (ECCF) </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Governance Framework (GF) </li></ul></li></ul></li></ul> <ul><li><ul><li>Operational vision for SAEAF deployment</li></ul></li></ul> <ul><li><ul><li><ul><li>Integration with existing HL7 and HSSP processes </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>complimentary to existing relationships (e.g. OMG) </li></ul></li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>extension to message and document Interoperability Paradigms </li></ul></li></ul></li></ul></li></ul> <p> 10. </p> <ul><li>HL7 ArB </li></ul> <ul><li><ul><li>Yongjian Bao, GE Healthcare </li></ul></li></ul> <ul><li><ul><li>Jane Curry, Health Information Strategies </li></ul></li></ul> <ul><li><ul><li>Grahame Grieve, Jiva Medical </li></ul></li></ul> <ul><li><ul><li>Anthony Julian, Mayo </li></ul></li></ul> <ul><li><ul><li>John Koisch, NCI </li></ul></li></ul> <ul><li><ul><li>Cecil Lynch, OntoReason </li></ul></li></ul> <ul><li><ul><li>Charlie Mead, CTO NCI </li></ul></li></ul> <ul><li><ul><li>Nancy Orvis, DoD MHS </li></ul></li></ul> <ul><li><ul><li>Ron Parker, Canada Health Infoway </li></ul></li></ul> <ul><li><ul><li>John Quinn, Accenture, CTO HL7 </li></ul></li></ul> <ul><li><ul><li>Abdul Malik Shakir, Shakir Consulting </li></ul></li></ul> <ul><li><ul><li>Mead Walker, Health Data and Interoperability </li></ul></li></ul> <p>SAEAF Background (4) Jump-Start Participants </p> <ul><li>Other </li></ul> <ul><li><ul><li>Alex DeJong, Siemens </li></ul></li></ul> <ul><li><ul><li>Ed Larsen, HITSP </li></ul></li></ul> <ul><li><ul><li>Galen Mulrooney, JP Systems, VA </li></ul></li></ul> <ul><li><ul><li>Scott Robertson, Kaiser </li></ul></li></ul> <ul><li><ul><li>Rich Rogers, IBM </li></ul></li></ul> <ul><li><ul><li>Ann Wrightson, NHS UK </li></ul></li></ul> <ul><li>Participants brought a wide range of perspectives to the discussion </li></ul> <p> 11. SAEAF Value Proposition (1): Working Interoperability </p> <ul><li>Interoperability Paradigm (Messages, Documents, Services):specifications which enable two or more (HL7) trading partners to collaborate in the context of a specific business interaction </li></ul> <ul><li><ul><li>No assumptions of size, character, or identity of parties </li></ul></li></ul> <ul><li><ul><li><ul><li>Nations, Enterprises, Departments, Individual, Systems, etc. </li></ul></li></ul></li></ul> <ul><li><ul><li>No assumptions of exchange details (What, Why, How, etc.) </li></ul></li></ul> <p> 12. SAEAF Value Proposition (2): Working Interoperability </p> <ul><li>Working Interoperability: </li></ul> <ul><li><ul><li>The collection of structures, processes, and components </li></ul></li></ul> <ul><li><ul><li><ul><li>that support Computable Semantic Interoperability </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>in the context of a Conformance/Compliance Framework. </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>SAEAF facilitates theexplicitandlayeredexpression </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>of the set of static, functional, and behavioral semantics that collectively enable Working Interoperability. </li></ul></li></ul></li></ul> <ul><li>Specifications developed to enable Working Interoperability </li></ul> <ul><li><ul><li>are defined in such a manner so as to ensure that they are </li></ul></li></ul> <ul><li><ul><li><ul><li>usable, useful, durable, and that they are </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>implementable in a variety of deployment contexts </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>in a repeatable, comprehensible manner. </li></ul></li></ul></li></ul></li></ul> <p> 13. SAEAF Value Proposition (2): Working Interoperability (WI) </p> <ul><li>WI :thedeterministicexchange of data/information in a manner thatpreserves shared meaning </li></ul> <ul><li>Two parties interoperate based on a combination of </li></ul> <ul><li><ul><li>certified level of conformance to formal Conformance Statements (CnS) </li></ul></li></ul> <ul><li><ul><li>stated level ofexplicit compliance to integrated specifications or standards expressed via Compliance Statements (CmS) </li></ul></li></ul> <ul><li><ul><li> levels help quantify degree-of-difficult in achieving WI </li></ul></li></ul> <p>Agree on Reference view Agree on Conceptual view Agree on Platform-Independent view Agree on Platform -Specific view A B D C F Component Component E 14. RM-ODP (1)ISO Standard (RM ODP, ISO/IEC IS 10746|ITU-T X.900 ) Why? True? Where? How? What? An instance of a SAEAF Specification Stack is made up ofConformance Statementswhich areasserted as validby a technology binding and verified byCertification .ECCF cells contain artifacts -- developedde novoor drawn from pre-existing specifications -- that are (often) generated viaConstraint Patterns. They are sorted by RM-ODP Viewpoints. 15. RM-ODP (2)ISO Standard (RM ODP, ISO/IEC IS 10746|ITU-T X.900 ) </p> <ul><li>Non-hierarchicalandNon-orthogonal </li></ul> <ul><li><ul><li>Each Viewpoint can (and most often will) contain a hierarchy of layered information </li></ul></li></ul> <ul><li><ul><li>DistinguishConformance vs Compliance Statements </li></ul></li></ul> <ul><li><ul><li><ul><li>CnS validated/certified via technology implementation </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>CmS (often implicitly) validated (i.e. transformation is correct) </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Both may generate hierarchical layers in a SS instance </li></ul></li></ul></li></ul> <p>An instance of a SAEAF Specification Stack is made up ofConformance Statementswhich areasserted as validby a technology binding and verified byCertification .ECCF cells contain artifacts -- developedde novoor drawn from pre-existing specifications -- that are (often) generated viaConstraint Patterns. They are sorted by RM-ODP Viewpoints. Information Business / Enterprise Computational Engineering Technology 16. The SAEAF ECCF Context (1) </p> <ul><li>Group A developsSpecification X </li></ul> <ul><li>Group A publishesSpecification X </li></ul> <ul><li><ul><li>Developers want to implementSpecification X </li></ul></li></ul> <ul><li>Group B developsSpecification Y </li></ul> <ul><li>Group A wants to saySpecification X uses Specification Y </li></ul> <ul><li>ECCF ContextCertify that </li></ul> <ul><li><ul><li>Specification X is correctly implemented </li></ul></li></ul> <ul><li><ul><li>Specification Y is correctly referenced </li></ul></li></ul> <p> 17. The SAEAF ECCF Context (2) </p> <ul><li>Problem: </li></ul> <ul><li><ul><li>What does correctly implemented mean? </li></ul></li></ul> <ul><li><ul><li>What does correctly referenced mean? </li></ul></li></ul> <ul><li><ul><li>How can we define these conceptsexplicitly ? </li></ul></li></ul> <ul><li><ul><li><ul><li>Support repeatable/reproduciblecertification of correctness </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>Computational </li></ul></li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>Human-assisted </li></ul></li></ul></li></ul></li></ul> <ul><li>If explicit definitions and processes are not established -- e.g. via the ECCF -- implicit assumptions will be inconsistently made explicit as they are realized in technology components, and are usually only apparent at run-time </li></ul> <p> 18. The SAEAF ECCF Context (3) </p> <ul><li>Answers based on threeinter-related but separate concepts </li></ul> <ul><li><ul><li>Conformance </li></ul></li></ul> <ul><li><ul><li>Compliance </li></ul></li></ul> <ul><li><ul><li>Consistency </li></ul></li></ul> <ul><li>Each definesone or more relationships between components/artifacts in an instance of the Specification Stack </li></ul> <ul><li><ul><li> transformations </li></ul></li></ul> <ul><li><ul><li><ul><li>Constraint (most common) </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Extension (must be well-defined to sustain WI) </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Other </li></ul></li></ul></li></ul> <ul><li><ul><li> dependencies (use of one Specification by another) </li></ul></li></ul> <p> 19. The SAEAF ECCF Context (4) </p> <ul><li>Conformance </li></ul> <ul><li><ul><li>Conformance Statementscertified/validated byTechnology realization/binding </li></ul></li></ul> <ul><li>Compliance </li></ul> <ul><li><ul><li>Compliance Statementsimplicitlyvalidate that Source artifactis correctly transformed </li></ul></li></ul> <ul><li><ul><li><ul><li>between Specification Stack levels-of-abstraction </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>Conceptual-layer Information Model (DAM)is transformed toPIM Class Model </li></ul></li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>transformation of a single, cell-specific artifact </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>Generalized Constraint Pattern </li></ul></li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li><ul><li>Restriction of possible value sets on an attribute </li></ul></li></ul></li></ul></li></ul></li></ul> <p> 20. The SAEAF ECCF Context (5) </p> <ul><li>Consistency </li></ul> <ul><li><ul><li>Does involve the logical notions of if I have A, I need to have B </li></ul></li></ul> <ul><li><ul><li><ul><li>Activity Diagram in Computational VP which exposes a data grammust consistently use the semantics of a </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Class Diagram in Information VP in which the specific semantics of the data gram are represented </li></ul></li></ul></li></ul> <ul><li><ul><li>Doesnotinvolve transformations between specification artifacts </li></ul></li></ul> <ul><li><ul><li><ul><li>Transformations are about Compliance </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>not Conformance </li></ul></li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>not Consistency </li></ul></li></ul></li></ul></li></ul> <p> 21. ECCF Terms of Art </p> <ul><li>Specification Stack </li></ul> <ul><li>Conformance Statement (and associated Assertion) </li></ul> <ul><li>Conformance Certification (validation of Assertions) </li></ul> <ul><li>Compliance Statement (and associated Transformation) </li></ul> <ul><li>Compliance Certification (usually implicit) </li></ul> <ul><li>Consistency (logical coupling of SS artifacts for single topic) </li></ul> <ul><li>Traceability (vertical per-column navigation of SS instance) </li></ul> <ul><li>Jurisdiction (see Governance presentation) </li></ul> <ul><li>Provenance (see Governance presentation) </li></ul> <p> 22. The ECCF Specification Stack (1) </p> <ul><li>The ECCF Specification Stack </li></ul> <ul><li><ul><li>Classifies artifacts by RM-ODP Viewpoints </li></ul></li></ul> <ul><li><ul><li>Specification levelsengineering level-of-abstractions </li></ul></li></ul> <ul><li><ul><li><ul><li>Conceptual Level Concept (Requirements/Analysis) Model </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Platform-Independent Logical Model </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li>Platform-Specific Implementable Model </li></ul></li></ul></li></ul> <ul><li><ul><li><ul><li><ul><li>notan implementationper se </li></ul></li></ul></li></ul></li></ul> <p>An instance of a SAEAF Specification Stack is made up ofConformance Statementswhich areasserted as validby a technology binding and verified byCertification . ECCF cells contain artifacts -- developedde novoor drawn from pre-existing specifications -- that are (often) generated viaConstraint Patterns. They are sorted by RM-ODP Viewpoints. 23. ECCF Specification Stack (2) </p> <ul><li>A given instance