HL7 Interoperability Paradigms Fundamental Methodological

• 1. April 9, 2009
  • OHT Architecture Project:

• Update and Integration with HL7 SAEAF

2. OHT Architecture Project Q2 2009 Content

• Architecture principles

• Tool classification mechanism

• a set of templates, patterns and

• processes that enable

• interoperability of OHT tools.

• Identification of potential barriers

• Recommendation of a governance

• process for the harvesting,

• categorization and custodianship

• of architecture artifacts.

• Executed internal and external

• communication plan

• Architectural Principles Q2/09

• Tooling Architectural Vision Q3/09

• Architectural Framework Q3/09

• Tooling Classification and

• Governance recommendations Q4/09

• Principles, Architecture Framework

• Specification Stack w examples

• Tool classification

• Recommendations to the Board

• Expectation for detailed Technical

• Architecture Solutions

• Expectation for Architectural

• Framework that allows for a Tooling

• Architecture to emerge through

• Projects

• Desire to reuse tooling components

• Desire to relearn from best practices

• Customer expectations to optimize

• and align Tooling investments

• Funding for Architecture Project

• team members

• Active cooperation from other

• OHT Project Committers

• Successful communication to

• OHT projects Q2/Q3

Added Deleted & Changed Milestones Packaging Editions Dependencies Pressures Statistics Contributing Participants: NCI, Infoway, NHS, NextJ, IHTSDO, NEHTA, HL7 3. Architecture Project Charter (1)

• The objective of the OHT Architecture Project is to enable the adoption, development, and deployment of an evolving set ofinteroperabletools.

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

• • • Definition of tool intentionally left somewhat loose as that is not the primary focus of the AP.Rather it is enabling interoperability.

• These tools support the development and deployment of software that enablescomputable semantic interoperabilityin the health-care/life sciences/clinical research domains.

• • Recognition that CSI can occur in a multitude of ways and complexities

• • • One-way data export

• • • Integrated real-time behavior coordination

4. Architecture Project Charter (2)

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

• As its initial goal, the Architecture Project will develop anarchitecture framework

• • which will enable theevolutionary developmentof an OHT Platform architecture

• • • consistent with the various enterprise architectures built and deployed by OHT stakeholders. (i.e. supporting appropriate CSI)

• (Frameworks must be specified top-down.EAS then develops bottom-up.)

5. Architecture Project Charter (3)

• Deliverables include:

• • a set of architecture principles.

• • • Focus on CSI rather than architecture in general

• • a tool classification mechanism that enables stakeholders to contribute and have access to architecture artifacts that underlie the tools

• • a Conformance/Compliance Framework adapted to tooling interoperability, including an explicit Specification Stack

• • a set of templates, patterns and processes that enable interoperability of OHT tools

• • identification of potential barriers to interoperability and recommendations to overcome them

• • a recommendation to the board of a governance process to assist in the harvesting, categorization and custodianship of architecture artifacts

• • an executed internal and external communication plan

6. 4Q08 2Q09 1Q09 3Q09 4Q09 First Conceptual Meeting Informal Organizational Meetings Orlando/Paris OHT Architecture Project Q2 2009 Architecture Principles & Best Practices -harmonized with current projects Draft Framework & Current State Examples Tooling Classification & Governance recommendations 7. SAEAF Background (1) A Services-Aware Enterprise Architecture for HL7

• April 08:HSSP-sponsored Services in Healthcare conference, Chicago, IL (attended by HL7 CTO)

• May 08: HL7 CTO asks the HL7 ArB todevelop a straw-man proposal for services development within the context of an HL7 Enterprise Architecture

• • Specify the artifacts and processes necessary to allow HL7 to define specifications for SOA integration.

• • Define an HL7 Enterprise Architecture Framework (EAF) which contextualizes HL7 specifications in a SOA environment.

• • Consider services first, but dont exclude messages or documents as Interoperability Paradigms

• • • HL7 EAF should beservices-aware , notservice-specific

8. SAEAF Background (2) A Services-Aware Enterprise Architecture for HL7

• Summer 08:HL7 Executive Committee agreed to sponsor three face-to-face ArB EAF Jump-Start meetings

• • Modeled after Left-Hand Side of the RIM project (1998)

• • Three 3-day F2F meetings in June, July, August, 2008

• • • Transparent process

• • • • Open attendance

• • • • Published agendas

• • • • Published artefacts and works-in-progress

• 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

9. SAEAF Background (3) A Services-Aware Enterprise Architecture for HL7

• Jump-Start Deliverables (largely contained in the collection of SAEAF documents) to include (but not be limited to):

• • EA framework informed by service specification considerations and industry experience ( services-aware )

• • Identification and initial specification of required infrastructure currently missing or incomplete in HL7

• • • Behavioral Framework (BF)

• • • Enterprise Conformance & Compliance Framework (ECCF)

• • • Governance Framework (GF)

• • Operational vision for SAEAF deployment

• • • Integration with existing HL7 and HSSP processes

• • • • complimentary to existing relationships (e.g. OMG)

• • • • extension to message and document Interoperability Paradigms

10.

• HL7 ArB

• • Yongjian Bao, GE Healthcare

• • Jane Curry, Health Information Strategies

• • Grahame Grieve, Jiva Medical

• • Anthony Julian, Mayo

• • John Koisch, NCI

• • Cecil Lynch, OntoReason

• • Charlie Mead, CTO NCI

• • Nancy Orvis, DoD MHS

• • Ron Parker, Canada Health Infoway

• • John Quinn, Accenture, CTO HL7

• • Abdul Malik Shakir, Shakir Consulting

• • Mead Walker, Health Data and Interoperability

SAEAF Background (4) Jump-Start Participants

• Other

• • Alex DeJong, Siemens

• • Ed Larsen, HITSP

• • Galen Mulrooney, JP Systems, VA

• • Scott Robertson, Kaiser