Turning a CDR into an XDS Repository

So, if you have an HIE which houses a clinical data store fed by a collection of HL7 Version 2 messages, how do you use the HITSP specifications to make the information available in that store as a collection of clinical documents?  That's the question that came to me today from a few people participating in some of the US National program activities.  Because this same implementation works internationally using IHE profiles, I've also indicated which of those you would use if you aren't in the US.

The answer was too long to give on the call that had already run over 15 minutes, but I promised I would detail it here.

First of all, I'm going to make some assumptions about the system under consideration:

1.  Certain observations about the active problems, patient allergies et cetera,  are fed to the system using an ADT message on admission, or appear in OBX segments of other messages that are used to feed that information.
2.  Lab results are fed to the system using an ORU (unsolicited observation).
3.  Clinical documents that are generated by transcription are sent to the system using an MDM message (document management).
4.  Certain other diagnostic results (e.g., EKG results or Radiology reports) are sent using either an MDM or an ORU message.

These are fairly safe assumptions in many hospital and some ambulatory evironments.

I won't get into how providers maintain the problem, allergy or medications list (appropriately updating the lists to keep them current), but will simply assume that is somehow being managed.

The question basically boils down to how one would represent the content of a CDR as a collection of documents that may be available.

Each study report or lab result, either transcribed or sent as an ORU message is represented as one clinical document.  In this particular context, the clinical document can be identified making use of the message unique identifer as one component.  The date of the document is typically the date of the message, but in an ORU could also be taken as being the result date, or in an MDM the document dates.  You have to work out some business rules to deal with that, but you can use a concistent set that works for both MDM and ORU pretty well.  Mappinng PID information into the CDA is also straightforward and consistent, but given that you've got some sort of CDR, you could obtain that from the database.

Some lab and test results coming through as ORU's are not going to be well structured, simply a collection of text results associated with the test (e.g., pathology, radiology reports).  These are best converted to a HITSP C62 (or IHE XDS-SD), where the document type is a LOINC code indicating a laboratory result (11502-2 LABORATORY REPORT.TOTAL works pretty well, or 47045-0 Study Result for other diagnostic testing or imaging reports, but more details LOINC codes can be used to identify the type of test if you have them).  In these reports, the OBR (observation request) often identify indications, observations, diagnoses/assessments, et cetera, and can often be treated as section headings in the result.

Other lab results are going to be more structured (chemistry, hematology, et cetera).  For these, I would advise formatting the result using the HITSP C37 construct (or IHE XD-LAB).  Here the OBR segments identify different collections of results, and the OBX segments are often formatted in a tabular fashion.

Other reports, often operative notes, ED reports, and discharge summaries, are going to be coming from an MDM feed.  These can contain Word processing documents, PDF, richly formatted text (RTF), or plain text.  Most word processing documents and RTF can be used to generate PDF through a number of different open source and commercial technologies, or you can often extract the plain text.  These HL7 V2 messages will often contain a code identifying the type of document, which should be mapped to the appropriate LOINC document type code (see HITSP C80 Section 2.2.3.14.1 Document Class for a partial listing of LOINC codes you may want to map to).  Those documents can be formatted again as an HITSP C62 (or IHE XDS-SD). 

Now, what's the entry point for these documents?  Well, that's where the HITSP C32 document (or IHE XPHR) comes into play.  The important point here is that C32 and the underlying specifications (XPHR,  HL7 CCD and ASTM CCR) identify this as containing a summary of the most relevant information about the patient at a point in time.  The key word is summary; think of it as a face sheet..  It isn't meant to contain every last dot and twiddle about what happened to the patient.  It should be a summary so that the most relevant information needed by a provider is immediately accessible, and other details can be tracked down if need be.  Why?  Because if you put every last dot and twiddle in the C32/XPHR/CCD, you will overwhelm the recieving provider with TOO MUCH INFORMATION, and they won't be able to find the relevant details.

So, in the results section of the document, you can simply put an overview of what other reports are available. But how would you link these other documents into the C32 that you have produced?  The key here is to use the IHE Coded Results Section and include in that section external references to the report that has the complete detail.   An appropriately configured stylesheet on the consumer side can identify and highlight text in the C32 results section so that it appears and acts just like a hyperlink would, but goes through the appropriate steps to securely access the relevant document.

Now, you have a face sheet using the C32 (or XPHR) specifications, and links to lab results (using C37 or IHE XD-LAB) and other reports (using C62 or XDS-SD) so that providers can obtain the details.  You also have a collection of other documents (structured and unstructured) that can be searched for by the document class code.  This will allow some systems to access and display just the collection of documents available to the provider for quick review to locate (for example) a relevant study.  This also enables partitioning of some of the data if need be so that some information (e.g., regarding sensitive topics such as HIV/AIDS results, et cetera) can be made more private.  This requires some thought about how you generate the C32, because you may not want to include references to more sensitive documents in a less sensitive document.  This may mean that providers with different levels of access would get different face sheets (C32 documents) depending upon the level of access that they should have to sensitive information.

One other thing to realize is that the C32 we are talking about here is something that is dynamically generated at need.  As a result, there another commitment that you need to make.  That is when you generate this C32 face sheet dynamically, you need to be able to uniquely identify it, and be able to store it for retrieval on demand later, so that providers who use it for care can be assured that they get the same set of bits (content) in the future.  If you dynamically generate it each time without storing what you sent, there is a danger that a software change could result in a new set of bits, which would disrupt two important principles of using documents:  persitence and stewardship.   The benefit to you of storing what is exchanged is that you can simply log the identifier of the exchanged document in the audit trail, and if need be, go back and see exactly what the content of the exchange was.

The final issue to review here is whether a C32 document is allowed to contain information from a single visit or encounter or whether it can be used to aggregate information from multiple episodes of care.  Some people have asserted that the last isn't allowed.  However, when you consider the original purpose of the C32 specification, you'll realize that it must be allowed to aggregate information from multiple episodes of care.  That original use was expressed through the HITSP IS03 Consumer Empowerment specification.  The purposes of that use case was to support exchange of information between consumers and providers.  The consumer is the ultimate aggregator of healthcare information.  In the end, the accumulation of data that consumers will gather and put in their C32 (or XPHR) documents will come from all of their healthcare providers.