"People developing software don't understand the complexities of health care, and the health care professionals don't understand what it takes to produce that software. It's hard for them to understand each other, so [one major benefit of OHT] will be to bring them together in one room."
Healthcare has been characterized as a multi-trillion dollar cottage industry. It is highly fragmented, labour intensive, barely connected, extremely competitive, and has many different vendors and proprietary solutions. The rising cost of healthcare is straining budgets at all levels of government and imposing financial burdens on corporations and individuals alike. Against this backdrop, legitimate concerns about privacy have led to a plethora of regulations requiring complex administrative, physical and technical infrastructure to safeguard sensitive health information. Governments are attempting to impose standards and specifications from the top down to improve efficiency in healthcare delivery. These standards are broad, complex and, for the most part, lack implementations. In short, things are in a bit of a mess.
A consensus is emerging around two initiatives that promise to improve the current situation. The first is to foster widespread adoption of Electronic Health Records (EHR). The second is to improve accessibility and interoperability between EHR systems. In this article, we present Open Health Tools (OHT), an open source ecosystem where members of the health and information technology (IT) professions can collaborate to build interoperable EHR systems.
Open Health Tools
Interoperability problems and their resulting inefficiencies can result in increased costs, medical error, poor care, and even death. There are studies showing that lack of immediate access to patient care records results in thousands of deaths every year. In the U.S. alone, it is estimated that 200,000 people die every year from medical errors, many of which would be preventable if we had connected, interoperating EHR systems.
While interoperability is important, progress towards interoperable EHR systems remains painfully slow. Former Intel Chairman Andrew Grove compares healthcare with the mainstream IT industry: "When it comes to operational efficiency, nothing illustrates the chasm between the two industries better than a comparison of the rate of implementation of electronic medical records with the rate of growth of e-commerce". While IT offers huge opportunities to improve healthcare systems and the quality of care, it also presents us with enormous challenges.
OHT is an international open source organization that was formed in 2007 to accelerate the implementation of EHR systems and promote interoperability. OHT was incubated within the Eclipse Foundation and Health Level 7. At the time of writing, it has over 30 members representing a cross-section of the healthcare community from Australia, Canada, the U.S., the United Kingdom, and continental Europe. The members of OHT believe that open source can be a powerful lever to expedite EHR deployment, improve interoperability between systems, and accelerate the delivery of the attendant social and economic benefits. They subscribe to the basic principles underlying open source development: i) contributors primarily work to satisfy their own requirements; ii) software is contributed to a common pool when it makes business sense to do so; iii) development effort is coordinated by senior developers and architects who ensure that the end result is timely and coherent; and iv) all participants share in and leverage the final result.
Many open source efforts target healthcare. However, none has gained significant traction. We believe there are reasons why OHT will succeed where other efforts have not:
- OHT has brought together national health agencies, vendors, care providers, standards organizations, academics, researchers, and payers.
- OHT has a very clear sense of its primary mission to develop and deliver running software.
- OHT has no internal confusion about acting as a quasi-standards organization (although many of the key standards groups are members) nor is it a vendor association promoting members' products (although many vendors are also OHT members).
- OHT understands that its ecosystem needs to balance the social benefits of making code freely available with the business necessity of helping its commercial members generate profits--a portion of which then can directly or indirectly flow back into OHT.
This last point is the key to long term sustainability. We encourage the use of commercial friendly processes and licenses such as the Eclipse Public License (EPL) and help members promote products and discover synergies and new opportunities. We believe that this sets OHT apart from most open source healthcare efforts which don't see it as their business to promote commerce and tend to use viral licenses such as the Free Software Foundation's GPL or LGPL under the misguided notion that this will prevent "misuse" of their software by commercial entities. What these licenses do in practice is destroy opportunities to create value-added products by making it difficult to combine open source and proprietary software in the same package.
The Quest for Interoperability
Proprietary boundaries are largely responsible for the current situation of non-interoperable EHR systems. Different proprietary systems have different information architectures. Current standards such as HL7 do not completely disambiguate EHR structures, even when implementations claim to be compliant. It is quite possible, in fact it is typical, to have HL7 compliant but non-interoperable implementations. With care providers, payers, patients and healthcare professionals all demanding action, the path of least resistance for most vendors is to propose incremental solutions that paper over the cracks between current implementations with "least common denominator" integration approaches. Gateways are a typical response: those parts of the record structures that can be mapped between two EHR implementations will be, but some information is normally lost because the two information architectures cannot be completely aligned. It is easy to see that things just get worse when health records are moving across several proprietary boundaries.
The result is usually primitive interoperability at the expense of functionality. This approach only perpetuates the problems. A real solution requires: i) a common platform that can be shared by all and which is built on strong and proven integration models with well defined interfaces; ii) powerful data transformation capabilities; and iii) a base of unifying underlying technologies. To be successful, interoperability needs to be designed in and developed from the platform up to the application, not imposed top down from the proprietary application to a gateway or adapter.
What about standards organizations? Won't more and better standards lead to interoperability? Unfortunately, as experience over the last twenty years has shown, the inherent complexity of the healthcare domain and the dynamic nature of its logical record structures (with new information types being continually added or modified as medical practice and technology evolves and changes), make it very unlikely that this issue will ever be completely solved by standards efforts.
To be clear, no one is saying that standards are not worthwhile. The point is that EHR interoperability is far too complex to be solved by standards alone. Moreover, there are many cases where deeper levels of integration other than simply exchanging records are desired. In many instances, much more efficient and capable processes could be realized at lower cost if it was possible to integrate systems at the application logic level. This is the promise offered by service oriented architectures (SOA) which expose facilities as composable services grouped logically by function.
The Need for a Common Platform
The possibility of achieving a common ubiquitous platform will engender some natural skepticism. OHT's motivation for this goal comes from the shared history of its founders in the Eclipse Project. The Eclipse platform was designed to address the interoperability needs of the software development tools market. Before Eclipse, this market was populated by hundreds of different tools which interoperated (although not well) by sharing files and using a few actual and de facto standards. Microsoft had the most capable platform but its growth was stalled. No single competing vendor--not even big players like IBM, Borland, and Rational--could afford the investment required to build a broadly capable base product and then add all of the extensions, customizations, and specializations required to satisfy the breadth of customer requirements. The result was customer dissatisfaction and inefficiency, combined with a certain fatalism that this was the way the industry had always been, and nothing could be done about it. This is very reminiscent of attitudes seen in the healthcare industry today.
Eclipse offered a well-engineered shared infrastructure, shifting the focus for investment and innovation away from building (and re-building) the same base functionality. Instead, vendors could collaborate to build the platform and then compete on added value products. By sharing common infrastructure, they could concentrate their resources on climbing the value chain to build hundreds of differentiated products, all sharing the same base components. As an added bonus, since they shared the same platform, it was relatively inexpensive to build interoperating products. This economic change altered the business models and made interoperation a winning strategy in most cases.
We believe Eclipse succeeded because the infrastructure was designed from the ground up to support interoperability. Due to its rich set of high quality components and the economies of scale, migrating to Eclipse was the most cost-effective option long term for most vendors. In effect, the commercial value proposition was changed so that vendors could share a common infrastructure, but compete on value-added products built with "Eclipse inside". We are firmly convinced that Eclipse succeeded because it was freely available and not controlled by any single dominant industry player. For an interoperability platform to achieve its purpose, it must be (nearly) ubiquitous. Applications interoperate because they are all building upon the same base. An open source solution works well for the base; in fact, it may be the only viable solution. The platform, much like the national highway system, must become a shared resource, owned by no one, and enabling everyone to utilize the same level playing field. This creates economic value and addresses customer needs. OHT members believe it may be possible to achieve the same result in the healthcare market, and that OHT is the right vehicle to advance this agenda. Based on the experience that the OHT team has with Eclipse and with EHR implementations and standards, we see three key "grand challenges" as the prerequisites for success:
- OHT needs to develop a high quality modular OHT platform that is component-based and has built-in integration, extension, and customization mechanisms. In other words, interoperability needs to be designed in.
- OHT must build a development and user community that includes a representative cross-section of healthcare stakeholders. Participation by national health agencies, standards organizations and key vendors is critical.
- OHT must create a self-sustaining ecosystem that will allow the OHT platform to continue to grow and evolve as new needs become apparent. This is very much a culture-changing mission within the healthcare community.
Pursuing these goals presents a challenge. Moving beyond the current situation to a common shared platform will be a difficult, multi-year endeavour requiring more than just a superior technical solution. It will also involve a significant community building effort and the creation of a supportive socio-economic ecosystem which is designed to leverage commercial forces and not fight them. A tough challenge certainly, but previous experience with the Eclipse platform and the Eclipse Foundation shows that it is not impossible. And the stakes are high, since interoperability ultimately has the potential to lower costs, save lives, and improve care.
OHT Platform
The OHT platform is an enterprise service bus for services that implement healthcare applications; this is often called a "health services bus" or "health services spine". While the exact shape of the OHT platform is still a work in progress, OHT members are working to provide a more precise definition and implement parts of the system. The planned services to be implemented are:
Infrastructure services: include security and privacy, patient and provider registries, communications, medical device integration, and workflow and business rules.
Patient information services: include record location and management, entity identification, distributed data access (CRUD), indexing, and replication.
Interoperability services: include data interchange, legacy adapters, and data transformation.
Terminology services: include administration, search and query, authoring and maintenance, and concept/terminology mapping.
Analysis services: include reporting, analytics, and data warehouse.
Public health services: include outbreak management, detection and notification, geospatial mapping, and visualization.
The OHT platform will provide built-in extensibility mechanisms to enable users to create first class extensions. Potential applications that the OHT Platform is targeted to support include EHRs, personal health records (PHRs), pharmacare, laboratory, radiology/imaging, and viewers/portals for patients.
As a practical matter, no platform will be successful without a complementary set of supporting tools. OHT tools projects planned or under way include:
Modeling: healthcare artifacts, clinical content, and medical data.
HL7 messaging: message modeling and design, message instance editors, and message example generators.
Terminology: design, update, maintenance and deployment.
Conformance and test: profile management, test design, test generators, simulators, and test execution.
IHE profiles: implementations of profiles defined by Integrating the Healthcare Enterprise (IHE), an industry backed initiative to improve interoperability.
The OHT platform provides standard domain-aware interfaces and reusable software components that can be assembled into patient-centered services and applications. It provides component and programming models that enforce constraints on how application software is developed. The result is applications that interoperate seamlessly because they are running the same code. Interoperable applications are cheaper to build due to the use of free, high quality pre-existing code. Users find such applications easier to learn and use because they are based on similar concepts and interaction models. Operator skills acquired on one application are transferable to another.
Creating the OHT Community
As noted above, it is critical to create both a platform and a supporting community or ecosystem. These need to evolve in tandem as the platform and the ecosystem share a symbiotic relationship. In order to establish a community, there needs to be a common shared platform on which to build. Without a continuing research and commercial ecosystem, the platform ceases to innovate, becoming obsolete and losing relevance over time. Establishing the platform and the ecosystem requires a substantial initial investment which typically comes from public sources or from an entity which stands to gain in the long run from the existence of the platform and the community.
After an initial bootstrap period of three to five years, the ecosystem must generate sufficient ongoing economic and social benefits to become self-sustaining. The best way to ensure this is to encourage commercial activity around the platform early, so that vendors can realize a return on investment in the platform and the marketplace identifies which enhancements and value added products offer real value. There must also be a mechanism for continuing public investment to recognize and encourage innovations and applications that have social value--such as public health--even if there is no commercial return on investment (ROI).
Conclusion
The principle contributions of OHT will be:
- Open source software projects to produce the OHT platform and supporting software tools.
- A supporting commercial ecosystem built around the OHT open source code base that will create long term sustainability.
- An open forum and level playing field where providers, vendors, standards experts, caregivers, and software developers can collaborate and share assets and expertise.
The end result of deploying health IT systems based on OHT software will be improved care, better safety and lower costs. The immediate beneficiaries will be patients, public healthcare providers such as state operated national health agencies, and private payers such as insurance companies. Secondary beneficiaries include vendors who will create and exploit new markets and cut development costs, private providers who can adapt their business models to exploit lower cost open source solutions, and physicians who can deliver more patient-centered care. Brian Barry is CEO of Bedarra Research Labs and CTO of Open Health Tools. From 1991-2002 he served variously as Chief Scientist, CEO, President and CTO at Object Technology International, Inc. Under his leadership OTI developed the Eclipse Platform, and the IBM VisualAge family of products. Dr. Barry has published a number of research papers and articles on a wide variety of technical subjects. He has served on the Program Committees for software conferences such as OOPSLA, ECOOP, AOSD and Agile Development, was a co-author of the ANSI Smalltalk standard, and actively participates on a research review boards and committees.
Recommended Resources
Open Health Tools: Architectural Vision
Commission on Systemic Interoperability: Ending the Document Game