| |
|
|
Interoperability Standards - the no-sales pitchPublication date: Jul 09, 2013
What interoperability standard should I use - and no sales pitch please.
Given that I have a particular workflow that I want to support, what interoperability standard should I use ? Standards organizations like HL7 will show you all of the features of all of its standards, but they rarely tell you which standard is a best fit with your workflow requirements. Ask any car sales guy about a particular model and they’ll tell you more details than you ever wanted to know … but, you’ll ask, can it be used to haul garbage? Yes. Can I safely take my kids to school in this? Yes. Does it do 200 kph? Yes. We all know that a particular model simply can’t be a perfect match with everyone’s requirements. Let’s cut the sales pitch and describe what the most widely used interoperability standards are really all about: A couple of interoperability standardsLet’s for example have a look at HL7 version 2: created to support hospital internal workflows, mostly of an administrative/logistical nature, and with the capacity to convey clinical data of relatively low complexity. A simple standard for a simple workflow problem. Of course one can tweak this standard and use it for interoperability between organizations, or for it to convey complex clinical data – but that wasn’t the original intent . HL7 version 2 has gained near universal acceptance when it comes to hospital internal workflows.The DICOM standard focuses on images, and image workflows (orders, status reports, radiology reports), originally within the radiology department but increasingly also in other “-ologies” that produce some form of image (or video/ waveform). The supported workflows are mainly those within the imaging department, between PACS, RIS systems, imaging modalities and viewing stations. The initial versions of HL7 version 2 and DICOM were developed in the late 80s – and there is memorandum of understanding dating back from those days that these standards shall not define any significant overlap in functionality. If your workflow is in any way related to the exchange of diagnostic images, then DICOM will be part of your solution. HL7 version 3 was created with the explicit aim to allow one to convey complex clinical data, e.g. to support the transfer of extracts of an EHR, or to convey data in support of clinical decision support systems. Given the installed base of HL7 version 2 deployment of HL7 v3 is nearly always in interoperability workflows involving multiple organizations – which in turn lead to the HL7 v3 standard being optimized for such a context. This is a complex standard for a complex problem. Apply HL7 v3 to solve a simple problem and you’ll have everybody (and especially the software implementers) scratching their heads as to why one needs such a complex solution (and: complex data structure) to convey a simple set of data. HL7 version 3 has been deployed at a large scale by a few large nationwide projects – mostly with the intent to cover both the simple as well as the complex workflow use-cases. Most of these projects have had to scale down their use of HL7 version 3 – and limit its usage to a few complex problems, and to the use of CDA. CDA, HL7’s e-Document standard, whilst nominally part of HL7 version3, is mostly regarded as a standard that’s separate from HL7 version 3 (i.e. HL7 version 3 messaging). CDA offers one a dual view of the world: it contains human readable textual sections, and may contain the very same data as present in the text in a software processable format . The software processable format is a HL7 version 3 format – allowing for complex constructs in theory, but in practice the HL7 v3 models as used in CDA documents tend to be well-scoped, smallish and implementable. CDA is currently mostly used for the medical summary (and related: referral, discharge letter) use-case. The FHIR standard (in beta testing) is essentially a RESTful openAPI for EMRs/EHRs. It’s ideally suited to open up data as contained in various data silos for reuse in things like Apps. One of its main distinguishing features is that it allows for a pull-mechanism to get hold of data, whereas other HL7 standards tend to be “push and duplicate” in nature. FHIR is explicitely aimed at the systems integration requirements of software/app developers. IHE aims to standardize all sorts of workflows, with widely different scopes and complexity, and to create implementation guides based on existing (other) interoperability standards (such as HL7 and DICOM) to support those workflows. If one looks at actual uptake of their specifications the IHE specifications are adopted to support two different kinds of workflows: a) imaging (e.g. radiology/cardiology) workflows, ordering/reporting, and b) the exchange of documents between organizations; the creation of a document based EHR – known as IHE XDS. IHE has created other specifications and workflow descriptions (e.g. identification of patient, consent, security, document formats), these effectively all serve to support the aforementioned two main workflow categories. If your workflow requirement isn’t one part of the two listed categories it is very likely IHE won’t have a lot to offer to your particular interoperability project. Others..Now how about other standards, such as DCM, OpenEHR, 13606, CDISC and terminologies? I’m aware that the above is not a complete list – maybe they’ll be subject of another post. I was in limbo as to whether publish this as a blogpost (=an “opinion”) or a whitepaper (=a “neutral overview”). Let’s publish it as a blogpost first – and depending on the level of comments I receive I’ll someday turn it into a whitepaper. -Rene
PermaLink to this page: http://www.ringholm.com/column/interoperability_standards_without_sales_pitch.htm
Index of columns:
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards. |
Rene is the Tutor-in-chief of Ringholm. [e-mail] |