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.
