Context issues with the IHE QED profilePublication date: Dec 15, 2010
The 'trial use' IHE QED profile (query for details) profile describes how one can use one generic mechanism to query for certain categories clinical data. The profile suggests that the response could be based on the shredded contents of CDA documents - taking information out of its context is however a dangerous process.
This post is all about the context of medical data. Allow me to elaborate: when one sends a data set for patient Smith it is not sufficient to know that 'diagnosis = asthma', one has to be aware of its context: is the context of this diagnosis a discharge letter (and is the diagnosis therefore perhaps a discharge diagnosis), a procedure note (a reason for the procedure?), or a prescription (reason for prescription, or allergy perhaps?), is the diagnosis actually related to patient Smith or to a family member of patient Smith? Have any procedures been performed (documented elsewhere in the document) which are the cause of the diagnosis? When interpreting the diagnosis one has to be aware of its context. Persisting data in a 'clinically safe' way (amongst other things: within its proper context) is a tricky issue.
Recently I was asked to present an overview of a number of IHE profiles (see next blog post about the increasing demand for IHE training courses). Amongst other things they requested that certain 'trial for use' profiles be discussed. That has the advantage that I get to actually study them in detail.. One of the profiles that I was requested to provide an overview of was QED (Query for Existing Data). QED (which was created in 2008/2009 by the IHE PCC committee) describes a workflow for the retrieval of one or more categories of medical data from a source application. It is based on a HL7 version 3 query and response message. The use case is understandable, and the messages are being used in a proper manner.
The surprise came when it discusses what kind of application is envisioned to be the source of the data. QED envisions a document repository (a document management system) to be the source of information. Such a document repository persists CDA documents received from all sorts of data sources. CDA documents contain medical data which one could query using the query as described in QED.
And that's where the issue of context raises its ugly head again. Shredding the data from CDA documents into a database (and thereby yanking them out of their original context) and subsequently using the data to populate a part of a v3 message - that's using the data in a different context. Imagine the laboratory results one would include in a lab-to-lab report (i.e. exhaustively detailed) versus the lab results one would include in a referral (almost none, only those that are relevant in the context of that particular referral). The result of the query would result in wildly different sets of data - taken out of their context.
To a certain extent one can get away with such an approach if the CDA is very tightly templated, in which case most of the context semantics are implied by the template. If one works in an environment where CDA documents aren't strongly templated, there is IMHO no way one could reasonably shred a CDA document without losing contextual information. If QED wishes to argue that document repositories should be able to respond to this query, it should at least document the limitations and serious risks associated with such an approach.
In my opinion the QED profile mistakenly identifies a document repository as the one that should respond to the query for existing data. The only applications that are properly aware of the context are the data sources themselves (i.e. those applications that created the documents that have been stored in the document archive).
(update) Keith Boone, one of the editors of the QED profile, read this column and sent me an e-mail to address my comments. He invited me to author a 'safety analysis' section for inclusion in the QED profile. If one has comments about an open standard, one also volunteers to help improve it.
(update, the analysis which I submitted) If the Clinical Data Source actor doesn't have awareness of the full context of the data being requested there may be issues with Patient Safety. This issue is particularly present when the Clinical Data Source actor is grouped with a Cross Enterprise Document Repository actor. In such a grouping the Clinical Data Source actor won't be aware of the clinical context of individual sections in a document.
A document may have been specifically created for a specific purpose, consciously limiting its content to those aspects (and level of detail) as appropriate for that specific purpose. Extracting data from such a document and using it within another context has Patient Safety issues associated with it. For example: one may interpret the contents of a medication section as being a full list of medications being taken by a patient; whereas the original document limited the contents of that section to the medications relevant to a particular disease.
This risk is mitigated to some degree by the QED requirement to include a reference to the entire document when re-using a document section outside of its context.
There are known implementations of QED that perform post-processing on duplicate information as present in sections of one and the same kind extracted from multiple documents from different sources. This further increases the risk of wrongful interpretation of data out of their original context. The use of the ITI "On-Demand Documents" profile should be considered instead - the source of the document in this profile is fully aware of the context of the data.
Note that QED will probably work just fine if all one has in terms of documents is a stack of CCDs. A CCD is essentially a database dump of a set of clinical data - it doesn't provide any context other than selecting a particular maximum subset of all clinical data to be included. There's a lot more to CDA than CCD. An implementer of QED pointed out to me that the profile has hardly been implemented up to now - and for once I hope this is an IHE profile which won't be embraced by software developers.
PermaLink to this page: http://www.ringholm.com/column/Context_issues_with_IHE_QED.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.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.
Rene is the Tutor-in-chief of Ringholm.