Open Healthcare Framework


Introduction

The project has been created. Please visit the project page.

The Eclipse Open Healthcare Framework Project is a proposed open source project under the Eclipse Technology Project.

This proposal is in the Project Proposal Phase (as defined in the  Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.ohf newsgroup.

Overview

The goal of the Open Healthcare Framework (OHF) is to extend the Eclipse Platform to create an open-source framework for building interoperable, extensible healthcare systems. We also intend to develop a complementary set of exemplary tools. OHF will enable software providers and integrators to cost-effectively create customized offerings for healthcare delivery organizations that comply with government regulations and industry standards.

The Open Healthcare Framework will develop infrastructure, tools, components, and services that will support development of both client and server applications. Client development will be based on RCP and server components will be based on J2EE together with core Eclipse concepts such as plug-in based extensibility.

The essential functional elements of OHF V 1.0 are well understood by domain experts. While there is significant engineering effort required, we feel that the work plan as proposed here can be implemented given sufficient resources, and does not involve an unrealistic level of technical risk. Consequently we propose this project be considered as an incubator within the Technology PMC.

However, OHF does represent a significant element of business innovation. We are aware of no other efforts to build a platform for constructing EHR applications. Consequently we expect it will take both time and effort to grow an OHF community within the healthcare industry. We are optimistic that there will be considerable growth in the team in the first 6-12 months after successfully passing the Creation Review and being established as an Eclipse project. Our development plans are deliberately open-ended so that we can employ these additional resources effectively as they become available. If we are wrong in our optimism, our development plan can still succeed, but clearly will take longer to reach its goals.

Background

Healthcare in the United States has been characterized as a $1.7 trillion cottage industry. It is highly fragmented, labor intensive, barely connected, extremely competitive, with many different vendors and solutions that are all proprietary. Against this backdrop, the U.S. Department of Health and Human Services issued regulations to require that healthcare organizations establish administrative, physical and technical infrastructure to safeguard sensitive health information as well as to implement standards to improve efficiency in healthcare delivery. The US government estimates dramatic cost savings at more than $250 billion annually if the healthcare industries can be automated.

Other countries around the world suffer from the same problems. The United Kingdom has committed to several large regional programs such as the NHS National Programme for Information Technology in England, with a focus on building core infrastructure. Finland is also pursuing a nationally coordinated program focusing on infrastructure development for health. These programs, along with many others, include basic IT and telecommunications infrastructure, standards, and shared software development.

Healthcare systems throughout the world face the same challenges and opportunities: the amount and complexity of detailed healthcare information is overwhelming. The ability to gather the information has outstripped the capacity to understand and process it. In spite of years of standardization work and implementation, many commercial and proprietary solutions and systems lack even useful levels of interoperability. Industry standards and specifications are broad, complex and in some cases lack implementations. Privacy, security and accuracy are issues of critical concern.

An Electronic Health Record (EHR) is a collection of documents containing a patient's health information that are created in compliance with standard specifications that define document structure, data types, terminology/vocabulary, semantics and essential processing requirements. Existing EHR systems and healthcare applications typically grew organically and often lack a clear architecture. Next generation systems are being designed as distributed, loosely-coupled systems that comply with emerging standards for EHR document structure and EHR system functional requirements as defined by HL7, ASTM, ISO, CEN and other standards bodies. However, while they are better structured than their predecessors, they are still monolithic, vertically integrated applications that share little or no code with their sister applications, and indeed offer little or no interoperability.

We believe there is an opportunity to provide a common, vendor-neutral framework that includes generic components, integration mechanisms, supporting tools and workflows, together with a process for staged customization to meet national standards, allow differentiation of commercial products, and meet the requirements of healthcare delivery organizations.

Vision and Scope

As part of our development effort, we will identify a set of functions that are useful for EHR and general health application development. We will classify these functions into one of three categories:

  • healthcare specific functions.
  • cross-industry functions
  • cross-industry healthcare-led functions (i.e. there is applicability outside the healthcare domain, but specific expertise and requirements in the healthcare domain)

For those functions in the cross-industry category, we will attempt to reuse components being developed within other open source efforts, with first preference for Eclipse projects. For healthcare specific functions, we will differentiate between components that will be part of the OHF platform and developed by the open source project, third party code which we will reuse, and components that will be developed by commercial vendors and integrators. This differentiation will be based on criteria such as the existence of relevant accepted standards or existing implementations by potential contributing members, degree of general use and acceptance in the industry, and the nature of the business and standards environment relevant to the function

We will develop infrastructure, tools, components, and services to implement these functions and enable development of healthcare applications using the OHF framework. Development will follow an agile approach. We will continue to refine our scope, architecture and development plans on an ongoing basis.

The OHF project will offer a multi-tier customization strategy, in which the generic OHF elements are customized to meet national standards; vendor specific differentiation; regional and local variations in delivery; etc. Even if we are successful, legacy systems will be with us for some time to come. We will facilitate the development of adaptors and connectors so that legacy systems can share data with OHF based systems and we will architect OHF so that OHF based subsystems can be used within reengineered legacy systems

Functional Architecture

The figure below describes the functional architectural model underlying the development plan for OHF.

OHF Framework Extensions: Similar to other projects that build on the RCP and the Eclipse Platform, we will implement extensions and additions to the RCP. UI frameworks tailored to our user community and security extensions to the OSGI runtime are examples. In addition, we see a requirement for a server plug-in framework but have not decided on an implementation.

Tools: A number of custom editors and other tools will be developed to support OHF applications. OHF is willing to collaborate with other organizations wishing to use Eclipse extensions for their own tooling.

Identity Management: Applications must keep track of users, providers, resources and patients. Since legislation now typically mandates that patients must have access to at least a subset of their medical records, patients and providers acquire both active ("user") and passive ("resource") roles at different times.

User / Context Management: The authentication of the user and cleanly maintaining the user's session throughout the application is the foundation of good security. The user's session is closely associated with the user's context, which refers to state that is maintained when users interact with healthcare applications at the point-of-use (e.g., a clinical desktop). OHF will define a context framework and interoperate with other applications using HL7's Clinical Context Management Specification (CCOW). Context management additionally includes user-centric session management required to facilitate user mobility, where session state is persisted and accessible as the user relocates.

Security and Privacy: The usual security concerns are present as well as some that are specific to health care, usually again driven by legislation. Support for privacy in OHF goes beyond the standard application of security methodologies to protect confidential healthcare data, it must be pervasive, e.g. procedural support for privacy and integrity (including audit facilities) should be part of the message and document processing chains.

The OHF project hopes to actively collaborate with the Higgins Trust Framework Project in the Identity Management, User and Context Management, and Security and Privacy areas.

Health Records: The core function of most healthcare systems is to create, store, search, retrieve and present records of health care events. In recent years healthcare standards have increasingly focused on this area, and have enabled a common implementation of these important function points.

Interoperability: HL7 has released an updated version of the HL7 Standard, which is the primary general healthcare information standard. Both HL7 V2 - the currently implemented version - and the newly released V3 will be in use for some time, so we intend to support both in our first release. DICOM (Digital Imaging and Communications in Medicine) specifies the standards relevant to medical imaging. As the project proceeds we expect to take account of other relevant standards, such as HL7's CDA and ASTM's CCR document standards.

A terminology service is a key component of any Healthcare system. Essentially, it is a semantic interoperability support service. There are many different terminologies in use in health care, both small and large (e.g. the core terminology of the SNOMED database, operated by the College of American Pathologists, contains over 357,000 health care concepts with unique meanings). The HL7 Common Terminology Services (CTS) defines an API for accessing terminological content. The primary initial focus of the OHF project will be to implement this infrastructure; we are hoping to work with vendors and other organizations with either expertise, IP, or both, to provide the content.

Archetypes are static models of clinical knowledge that can be used to describe the health records; they have recently gained acceptance in the healthcare community as the "best practice" technology. OHF will work with CEN and other archetype implementers to integrate archetypes with health records services. Other forms of meta-data representation such as schema, and OWL (W3C Web Ontology Language) will also be supported.

Development Plan

Phase 1: Planning 
The first step (currently on-going) is to complete the function identification and classification. The process of refining the development plans for Phase 2 and Phase 3 is also well underway. In addition, we are seeking early adopters for Phase 2 and Phase 3 products.

Phase 2: Interoperability 
We first plan to develop around two main function points for Interoperability: the HL7 Common Terminology Services, and HL7 based messaging and communications. Framework extensions and tools will be developed as required to support these activities. Interoperability has consistently been identified by vendors and users as potential "low hanging fruit", hence is our initial priority area.

Phase 3: Basic OHF 
The following functions are candidates for inclusion in Phase 3:

  • Basic Health Records support (Record Location, Storage and Access)
  • Basic Identity Management (Person/Provider identification)
  • Security Framework - context, login support, trust frameworks and Role Based Access Control
  • Basic Context Management
  • Components for DICOM, CCR, CDA

Refinements of existing development phases and a roadmap for additional development phases may be expected as the project proceeds.

Proposed Milestones 

We expect that it will take a project of this complexity several months to get off the ground. Phase 1 is targeted to be complete by the end of the 3rd quarter of 2005, Phase 2 to be complete by mid-2006 and Phase 3 by end 2007. With additional resources we could pull these dates in. 

Not Currently in Plan 

Although the OHF is being designed to assist developers who are building healthcare applications, we will not be developing a complete client or server application. Our focus is components, tools, and frameworks. We are hoping to recruit early adopters who will develop applications based on OHF.

A number of potential components are currently not in plan due to resource restrictions, lack of sufficiently mature standards or uncertainties regarding commercial interest. These include the following:

  • Workflow management and scheduling
  • Process Automation
  • Legacy systems and migration support
  • Healthcare financials

As the project proceeds we intend to have a clearly articulated roadmap that outlines areas that we are committed to grow the OHF into; areas that we might include; and areas that are outside the scope of the project. We have had some initial discussions along these lines but do not have consensus or a complete picture to offer at this time.

Liaison with Industry Standards Groups

The OHF solutions will rely on many standards, but most particularly those provided by HL7, OMG, NEMA (DICOM), ASTM (CCR), IHE, CEN and ISO. Wherever possible, the OHF solutions will provide comprehensive compliant support for the relevant standards. Of particular interest is the joint OMG-HL7 initiative to promote interoperable Healthcare IT systems, especially the Healthcare Services Specification Project.

A number of the individuals and organizations expected to participate in the project are already members of these standards activities and, in some cases, are significant contributors to existing and emerging healthcare standards. OHF intends to collaborate with the standards development organizations, either formally or through OHF participants who maintain joint involvement.

Organization

Proposed project leads

Mr. Grahame Grieve 
Jiva eHealth Solutions 
Telephone: +61 3 9450 2230 
Facsimile: +61 3 9450 2299 
E-Mail: grahameg at jivaehealth.com 
Web: www.jivaehealth.com

Mr. Don Jorgenson 
Inpriva, Inc. 
Telephone: +1 970-472-1441 
Facsimile: +1 970-472-5658 
E-Mail: djorgenson at inpriva.com 

Initial Committers 

Dmitry Bakuntsev, ITG 
Igor Yasno, ITG 
Kim Clohessy, IBM 
Marc Erickson, Inpriva 
Don Jorgenson, Inpriva 
Grahame Grieve, Jiva eHealth Solutions 
Paul Trevithick, SocialPhysics 
Joel West, San Jose State University

Interested parties

The following organizations have expressed interest in joining the project:

  • Mayo Clinic

  • Department of Defense (Health Affairs)

  • Veterans Health Administration

  • SerAPI (Finland)

  • InterMountain Health

  • Jiva eHealth Solutions

Updated June 17, 2005