Healthcare Integration – 4 Core Principles to Do It Right – Part I
For years the healthcare industry has been hyping interoperability, or another favorite “Plug & Play.” Whatever it’s called, Healthcare Integration will never be achieved unless we change our ideas on how we can get there. So let’s get real.
Those of us in the trenches know that “Plug & Play” faces huge obstacles and is likely to never be a robust reality. There is simply too much variability in systems, data formats, and communications protocols. Too much customization and too much extending of standards are being done in real-time to ever make direct data sharing possible on any kind of grand scale.
Software Architecture for Data Exchange Holds the Key to Interoperability
In “A Robust Health Data Infrastructure”, JASON, The MITRE Corporation (an independent group of scientists advising the U.S. government on science and technology), proposes a possible software architecture for the exchange of health information. What has us so excited about this recent report published by the Government’s Agency for Healthcare Research and Quality is that the recommendations so very closely align with our product’s own architecture and design, started over a decade ago.
Over two blogs, we would like to discuss four of the eight core principles on which the architecture proposed by JASON is based:
- Be agnostic as to the type, scale, platform, and storage location of the data
- Use public APIs and open standards, interfaces, and protocols
- Include with the data the corresponding metadata, context, and provenance information
- Represent the data as atomic data with associated metadata
When PilotFish started out as a services organization, we ruefully joked that standards are anything but standard and that state of affairs has not changed over time. In response to this hard reality, we developed our products to deal with the myriad of different data formats and protocols that come into and out of systems, applications, equipment, and databases – anything to anything. As technology is always changing, any architecture must offer easy and flexible configuration and Open APIs.
It is important, too, that an integration engine be agnostic as to the type, scale, platform, and storage location of the data. Being agnostic in healthcare gets us much closer to an interoperable world. Clearly, processing logic and data handling should be platform independent.
For example, if an organization decides to focus on the dominant Microsoft Windows operating systems, they exclude the likes of Apple or Linux. Both of these are strong, stable, and widely used platforms. Apple shows great promise for innovation in healthcare. Look at the growing use of Apple’s iPad in the hospital environment and its new cloud-based information platform known as “HealthKit.” The announcements of new partnerships with Epic Systems and Mayo Clinic, along with a number of other dominant players make it clear that in the Windows-dominated world of Healthcare, there needs to be support and inclusion of other platforms.
As important as it is to be platform agnostic, the same approach applies to standards. HL7 2.x is a legacy standard by all measures. With that status comes many limitations. Take for example HL7 3.x which is based on XML. It is more of a “true standard” and less of a “framework for negotiation” than HL7 2.x. The reality is any new software architecture must also be open to easily incorporate new standards.
As JASON puts it, “In short, the architecture must be flexible enough to incorporate any particular technology, but specific enough to ensure adherence to system-wide principles for the exchange of health information.” (Page 26)
When you’ve been out doing implementations as long as we have, hard reality teaches how essential flexibility and extensibility are to software architecture. You never know what you are going to run into.
Watch for Part II where we get real about open APIs, metadata, data representation, and migration. See you next time.