There has been much wailing and gnashing of teeth about the lack of interoperability of our electronic medical and health records (EMRs and EHRs). Some of this frustration can be directed toward a fundamental flaw of the American Healthcare System; lack of a national patient identifier. There is, however, another culprit whose head struggles to rise above the noise, hype and politics of interoperability: lack of a payload for interoperability.
As a radiologist and imaging informaticist versed in imaging interoperability based primarily on the Health Level 7 (HL7) and Digital Imaging and Communication in Medicine (DICOM) standards and the Integrating the Healthcare Enterprise (IHE) integration profile choreography of those two standards, I am flummoxed that the rest of health care does not have the interoperability that we enjoy in Imaging. We have a patient centered “export all” button and the rest of healthcare does not.
This functionality has three important repercussions for health care. You can go to any digital medical imaging department in the world, and with patient consent ask for all the imaging studies of that patient. In the worst case scenario, you will be given a set of CDs; in the best case, you will be directed to an on-line service provider. Not only will those CDs contain, most often, an end user image viewer with a standardized user interface but after appropriate cross-institution, patient identity management, you can import these studies into a subsequent picture archive and communication system (PACS) for use as comparison studies in the clinical setting.
Of interest is the fact that radiology reports fall somewhere in between medical images and EMR results. Radiology reports are, in fact, often included, on CDs when image studies are exported. They are, however, less well formally defined, there is some variability in both their presence and the ability to import them into electronic medical record systems in a computable fashion.
The second repercussion of having all this data available in a standard format is that it is available for image processing and machine learning. All of the major image processing environments, proprietary or open, are able to process these medical images in any number of ways.
The third repercussion of this function of DICOM and IHE is that you can migrate imaging data, in bulk, from one PACS to another and this happens routinely. PACS systems are still evolving functionality and after 7 or 10 years of service (since PACS have been in service now for almost 25 years!) it is not uncommon for an institution to choose a new PACS and migrate all of the image data from the previous system to the new one. It is not a perfect or painless process due, typically, to a bit of data uncleanliness that builds up over the years, but it is insightful, straight forward, vendor supported and achievable. It happens, without much fuss every day.
None of this is the case for EMR data. The unit of exchange in what we call EMR interoperability (or the lack thereof) is not patient data but rather abstraction of patient data into Clinical Document Architecture (CDA) documents. The name, itself, positions it as nothing more than paving the cow path of the old three ring patient information binder and its paper documents. The aggregation of all of a patient’s CDA documents from all of a patient’s providers by no means represents all of the medical information about the patient.
CDAs are designed, from the get go, to be ‘human readable’ yet they are, for the most part, illegible. HL7 and the Office of the National Coordinator for Health Information Technology (ONCHIT) had to sponsor a challenge last year, to improve rendering of these documents. From a technology perspective, HL7 erred in blending the human readable and machine computable in one document. Much of modern computing is based on the model, view, controller (MVC) paradigm wherein data, delivery and display are separate not the least of why is so that each may be optimized.
Note that HL7’s Fast Healthcare Interoperability Resources (FHIR) specification does not solve this problem. FHIR defines modular resources that represent components of the patient’s record. There is a mechanism for bundling resources and for getting all available resources from a single system. Modular resources have not yet, however, been defined to cover the complete breadth of patient data. They will continue to be developed and released for years to come (as will CDAs). Moreover, vendors are not required to implement any given set of modular resources and, so, availability is and will be haphazard.So, neither the patient’s complete collection of CDAs nor all their FHIR modular resources can be used to develop a complete clinical picture of the patient. Nor can they be used to develop a complete computable data structure of the patient. This hampers the development of new computer applications in health care at a time when the technology for doing so is burgeoning.
Equally important, these collections also cannot be used to migrate patient data from one EMR to the next. This lack of migration stifles innovation and competition amongst EMR vendors. We want vendors to compete on novel ways of capturing, creating and making use of patient data not on the basis of possession of patient data. The lack of a clear, vendor neutral, affordable migration pathway traps the customer steward of patient data in an untenable, expensive situation. We, in Imaging, learned this important lesson decades ago; can you imagine, today, having to purchase a proprietary interface from each imaging modality vendor?!
So, how do we fix this interoperability problem once and for all? I suggest that HL7 International pause and take a breath. They are perfectly suited to develop a single, new extensible markup language (XML) artifact, perhaps based on the Reference Information Model (RIM), which can be used to instantiate all of a patient’s EMR content at a given point of time. Let’s call this the XMR for ‘exportable medical record’. This XMR artifact, though geek readable, does not have to be human readable (and I say that in the nicest way possible). Let the systems that receive, aggregate and process these new artifacts compete on how best to do so.
The problem of the lack of interoperability in health care information systems can be solved as has been done for decades in subdomains like Imaging. This new XMR payload artifact could be transported by any number of proprietary, IHE or FHIR transport mechanisms for any number of purposes. At any point in time, a patient could go to their provider and ask for their XMR (perhaps delivered on a thumb drive). More importantly, using existing exchange and patient record locator services EMRs could query their peers for a patient’s XMRs and these could be aggregated and incorporated, as structured data, into the local EMR. The collection of XMRs could be used to present more complete clinical information, drive the development of novel computer processing of patient data and liberate patient data from proprietary silos where it is now trapped. The ONCHIT could then live up to its name and mandate the use of this XMR artifact and the ‘export all’ button.