Transforming CDA Documents to Care Record Messages
Appendix F - Transforming CDA Documents to Care Record Messages
The HL7 Clinical Document Architecture (CDA) provides a mechanism to record an XML document that can be used as a persistent record of care acts documented during a clinical encounter. Many profiles developed by the IHE Patient Care Coordination Technical committee are based upon the CDA and are used in that fashion. However, there are other exchanges that may not need the overhead of a clinical document, and which would be better expressed in a clinical message. The HL7 Care Record standard describes one such message that has already been used in several IHE PCC profiles, including the QED and CM profiles, and now the Query for Clinical Guidance (QCG) profile.
One example of the case where the content of a clinical document could be used in a message is in the use of clinical decision support for forecasting immunizations. The Query for Clinical Guidance profile describes a pair of messages that can be exchanged to integrate a healthcare application with a clinical decision support service. The content needed for an immunization forecasting service is already defined in the IHE PCC Immunization Content (IC) profile. This profile provides all the information needed for an immunization forecasting system, but does so as a clinical document. What is needed to support immunization forecasting as a service is a way to translate that document content into an HL7 Version 3 Care Record message.
This appendix describes how a CDA document can be transformed into a message conforming to the same guidelines as the CDA document.
The intent of the HL7 Version 3 standard is to provide semantic interoperability. An application that is aware of the HL7 Reference Information Model, and the datatypes and underlying vocabulary should readily be able to interpret the meaning of an activity regardless of the particular HL7 V3 standard used to describe it. In practice, this requires a great deal of HL7 specific knowledge regarding modelling and semantics.
A Clinical Document provides documentation of (see the documentationOf class in the CDA R-MIM) one or more service events (see ServiceEvent) performed by a healthcare service provider (see the performer connected to the ServiceEvent). The HL7 Version 3 Care Record message describes a service event that is the "provision of care" (see CareProvisionEvent in the Care Record DSTU) by a service provider (see performer attached to CareProvisionEvent). These two standards greatly overlap in their content.
The Author, DataEnter, and RecordTarget classes of the CareProvisionEvent are mapped to the Author, DataEnter, RecordTarget classes of the CDA (and visa-versa). Many other classes map one-for-one from one to the other, or nearly so.
Mapping the CDA Header to the Care Record Message
The following table shows the mapping from the classes found in the CDA Header found in this diagram to the Care Record classes found here. The tables use XPath expressions to identify the classes in each component.
| CDA | Care Record | Notes |
|---|---|---|
| /ClinicalDocument/documentationOf/serviceEvent | /CareProvisionEvent | The CareProvisionEvent must have the classCode PCPR. A CDA document can describe service events other than those with a classCode of PCPR. Note: The Continutity of Care Document service event uses the classCode of PCPR in the CDA Service event |
| /ClinicalDocument/documentationOf/serviceEvent/performer | /CareProvisionEvent/performer | Technically this is already addressed in the mapping above, however, we wanted to be clear that the performer of the Care Provision Event would also appear as the performer of the serviceEvent in the CDA document |
| /ClinicalDocument/recordTarget | /CareProvisionEvent/recordTarget | The Care Record allows for the record target to be the patient or any other entity maintained by the organization (e.g., a piece of equiment or a service location). CDA only allows patients to be record targets. Please note that CDA also does not support subject on the ClinicalDocument act, but it may be used inside entries in the clinical document. |
| /ClinicalDocument/author/assignedAuthor | /CareProvisionEvent/author/assignedPart | CDA Authors are persons or devices. Care Record allows persons and organizations to be recorded as an author, but not devices. There are other fine details as to what is allowed in the content, but the essential information (id, code, addr, telecom, and person name) are all recorded using the same XML |
| /ClinicalDocument/dataEnterer/assignedEntity | /CareProvisionEvent/dataEnterer/assignedPerson | These two are nearly the same, the CDA uses a more tightly constrained form. |
| /ClinicalDocument/authenticator{ | }/ClinicalDocument/legalAuthenticator | Care Record supports recording of a verifier (classCode=VRF), authenticator (AUTHEN), or legal authenticator (LA) in one class. CDA uses different classes to distinguish between the authenticator and legal authenticator. Strictly speaking, a CareRecord verifier with classCode VRF must be represented in CDA using the /ClinicalDocument/participant with a classCode set to VRF, but the other two cases map directly into more specific CDA classes |
| /ClinicalDocument/informationRecipient | /CareProvisionEvent/PrimaryInformationRecipient | The Care Record class is more restricted. It only holds primary information recipients, whereas the CDA class can hold primary and secondary information recipients |
| /ClinicalDocument/inFulfillmentOf/order | /CareRecord/inFulfillmentOf/careProvisionRequestOrPromise | A CDA can fulfill a wider variety of orders than are allowed for in a CareProvisionRequest, and so allows for code and and priorityCode to be sent in addition to the order identifier. |
Mapping the CDA Body to the Care Record Message
The CDA Body requires just a little bit of explanation. The body of a CDA document is composed of one or more sections, each of which may be composed of additional sections or entries as clinical statements. A section is a special kind of organizer used within documents. It need not be preserved in the Care Record Message unless the use case requires similar information to be carried together. However, many implementors will want to do so in order to preserve the structure of the CDA document. A simple expedient resolves this issue, as each section in the CDA document can be represented as an organizer in the Care Record message using the same classCode DOCSECT. The only determination that needs to be made is whether this section should be related through the pertinentInformation1, pertinentInformation2, pertinentInformation3, or component act relationships of the CareProvisionEvent. Since the CDA document does not distinguish between informative vs. pertinent relationships, we can rule out pertinentInformation1 and pertinentInformation2, requiring that we only need to decide whether to place the information in the component or pertinentInformation3 relationship. We can easily determine which information should appear in the care plan by inspection of section.code. If section.code uses the LOINC code 18776-5 TREATMENT PLAN then the information belongs in component, otherwise, it belongs in pertinentInformation3.
What happens to section.text
Since the purpose of this transformation is to put the machine readable information into a message so that clinical decision support algorithms can be applied, the text associated with the section will not be transformed. If you really wanted to maintain the text in the message, you could incorporate it into an act that was a component of the organizer, using a special code to identify the act containing the text.
Mapping CDA Entries to clinical statements in the Care Record
The following table shows the mapping from the classes found in the CDA clinical statement model to clinical statements in the Care Record DSTU. As you can see, almost all classes use identical names in the two models. The tables use XPath expressions to identify the classes in each component. Note that since the section.text is no longer present, references to text in acts, or originalText in codes that point to text in the section of the CDA can no longer be pointed to, and must be copied.
| CDA | Care Record | Notes |
|---|---|---|
| observation | observation | |
| observation/referenceRange | observation/referenceRange | |
| any clinicalStatement/precondition | any CareEntry'/conditions | Care Record supports more than just precondition (PRCN) in the conditions relationship. |
| substanceAdministration | substanceAdministration | |
| substanceAdministration/consumable | substanceAdministration/consumable | |
| supply | supply | |
| supply/product | supply/product | |
| procedure | procedure | |
| encounter | encounter | |
| act | act | |
| organizer | organizer | |
| any clinicalStatement/entryRelationship | any CareEntry/targetOf | Care Record supports a wider model than CDA. |
This mapping can be used in the other direction to take information from a Care Record message (e.g., as a result of a QED query) and turn it into a CDA document.