CDA Document Exchange

Editing tips and notes

Return to master table of contents

1 CDA Overview

(content on separate page)

2 Introduction to CDA Technical Artifacts

(content on separate page)

3 CDA Document Exchange

NOTE: The exact method by which a CDA instance is packaged and exchanged is outside the scope of this standard. While the MIME packaging method described here is not normative, it does illustrate one mechanism that meets the document exchange requirements described below.

Any CDA exchange strategy must accommodate the following requirements:

• All components of a CDA document that are integral to its state of wholeness (such as attested multimedia) are able to be included in a single exchange package.
• Content needing to be rendered if exchanging across a firewall where the links won't be traversable, must be able to be included in a single exchange package.
• Additional files associated with a CDA document to provide the recipient with the sender's rendering suggestions (such as one or more style sheets) are able to be included in a single exchange package.
• There is no need to change any of the references (e.g., a reference to attested multimedia in a separate file) within the base CDA document when creating the exchange package.
• There is no need to change any of the references (e.g., a reference to attested multimedia in a separate file) within the base CDA document when extracting the contents of an exchange package.
• There is no need to change any values of attributes of type XML ID when creating the exchange package.
• There are no restrictions on the directory structure used by receivers. Receivers can place the components of the CDA document into directories of their choosing.
• Critical metadata about the CDA instance needed for document management (e.g. document state, document archival status) must be included in the exchange package. (For a complete discussion of clinical document metadata, document management, and HL7 V3 document states and state transitions, refer to the HL7 V3 Medical Records specification).

From the perspective of a V2.x, V3 message and FHIR, a CDA document can be thought of as a multimedia object that can be exchanged as a Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type (ED). The current MIME recommendation is to follow the approach described in the Internet standard RFC 2557 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", which is the approach for the MIME encapsulations of aggregate documents used by ebXML and DICOM.

3.1 Using HL7 V2.x messages

In V2.x, CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents (such as MDM). Within the OBX segment, the MIME package is placed in OBX.5 (Field 00573 Observation value), encoded as a V2.x encapsulated data type. The value of OBX.2 (Field 00570 Value Type) should be set to "ED". The value of OBX.3 should be the same as ClinicalDocument.code.

Many fields in the message will overlap in meaning with fields in the CDA document. The following table shows the correspondence between the HL7 V2 MDM message's TXA segment and components of CDA.

Table X: HL7 V2 TXA Segment :: CDA Mapping

TXA Field	CDA Component
TXA-2 Document type	ClinicalDocument.code
TXA-4 Activity date/time	ServiceEvent.effectiveTime
TXA-5 Primary activity provider code/name	ServiceEvent performer
TXA-6 Origination date/time	ClinicalDocument.effectiveTime
TXA-7 Transcription date/time	dataEnterer.time
TXA-9 Originator code/name	author
TXA-11 Transcriptionist code/name	dataEnterer
TXA-12 Unique document number	ClinicalDocument.id
TXA-13 Parent document number	ParentDocument.id
TXA-14 Placer order number	Order.id
TXA-18 Document confidentiality status	ClinicalDocument.confidentialityCode
TXA-22 Authentication person, time stamp	authenticator, legalAuthenticator
TXA-23 Distributed copies	informationRecipient

The following example shows a non-normative, valid use of RFC 2557 in a V2 message. Several other valid representations are possible.

Example X

 MSH|...
 EVN|...
 PID|...
 PV1|... 
 TXA|...
 OBX|1|ED|11492-6^History and Physical^LN||
   ^multipart^related^A^
   MIME-Version: 1.0\X13\
   Content-Type: multipart/related; boundary="HL7-CDA-boundary";
   type="text/xml"; start="10.12.45567.43"\X13\
   Content-Transfer-Encoding: BASE64\X13\

   --HL7-CDA-boundary\X13\
   Content-Type: text/xml; charset="US-ASCII"\X13\
   Content-ID: <10.12.45567.43>\X13\

   ... Base 64 of base CDA document, which contains 
      ...
      <observationMedia classCode="OBS" moodCode="EVN">
         <id root="10.23.4567.345"/> 
         <value mediaType="image/jpeg">
            <reference value="left_hand_image.jpeg"/>
         </value>
      </observationMedia>
      ...

   --HL7-CDA-boundary
   Content-ID: <10.23.4567.345>\X13\
   Content-Location: canned_left_hand_image.jpeg\X13\
   Content-Type: image/JPEG\X13\

   ... Base64 image ...

   --HL7-CDA-boundary--

   ...

3.2 Using HL7 V3 Messages

In V3, CDA documents can be exchanged in any message that can exchange documents (such as the HL7 V3 Medical Records messages). The Act.text RIM attribute contains the MIME package, encoded as an encapsulated data type.

As is the case with V2, many fields in the V3 message will overlap in meaning with fields in the CDA document. Since CDA and V3 Medical Records messages derive from a common model, the correspondence is clear, as shown in the following table.

Table X: HL7 V3 Medical Records :: CDA Mapping

HL7 V3 Medical Records Component	CDA Component	Comments
ClinicalDocument	ClinicalDocument	Medical Records includes attributes not present in CDA (text, statusCode, availabilityTime, reasonCode, completioncode, storageCode, copyTime); CDA includes attributes not present in Medical Records (title).
authenticator	authenticator
legalAuthenticator	legalAuthenticator
dataEnterer	dataEnterer
EncounterEvent / encounterPerformer	encompassingEncounter / encounterParticipant; serviceEvent / performer	The Medical Records encounterPerformer is split into two CDA participants.
responsibleParty	responsibleParty
custodian	custodian
participant	participant
informationRecipient	informationRecipient
recordTarget	recordTarget
author	author
subject	subject	The Medical Records subject is a directory of all subjects listed in the document.
relatedDocument / ParentDocument	relatedDocument / parentDocument
documentationOf / Event	documentationOf / serviceEvent
inFulfillmentOf / Order	inFulfillmentOf / order
componentOf / EncounterEvent	componentOf / encompassingEncounter

The following example shows a non-normative, valid use of RFC 2557 in a V3 message. Several other valid representations are possible.

Example X

<someMessage>
  <Act.Code code="11488-4" 
    codeSystem="2.16.840.1.113883.6.1" 
    displayName="Consultation note"/>
  <Act.text type="multipart/related">
  MIME-Version: 1.0
  Content-Type: multipart/related; boundary="HL7-CDA-boundary";
  type="text/xml"; start="10.12.45567.43"
  Content-Transfer-Encoding: BASE64

  --HL7-CDA-boundary
  Content-Type: text/xml; charset="US-ASCII"
  Content-ID: <10.12.45567.43>

    ... Base 64 of base CDA document, which contains 
    ...
  <observationMedia classCode="OBS" moodcode="EVN">
    <id root="10.23.4567.345"/> 
    <value mediaType="image/jpeg">
      <reference value="left_hand_image.jpeg"/>
    </value>
  </observationMedia>
   ...

  --HL7-CDA-boundary
  Content-ID: <10.23.4567.345>
  Content-Location: canned_left_hand_image.jpeg
  Content-Type: image/JPEG

  ... Base64 image ...

  --HL7-CDA-boundary--

  </Act.text>
</someMessage>

3.3 Using HL7 FHIR Services

In FHIR, CDA documents are to be exchanged using the FHIR DocumentReference resource. A DocumentReference resource is used to describe a document that is made available to a healthcare system. A document is some sequence of bytes that is identifiable, establishes its own context (e.g., what subject, author, etc. can be displayed to the user), and has defined update management. The DocumentReference resource can be used with any document format that has a recognized mime type and that conforms to this definition.

A client can ask a server to generate a document reference from a document. The server reads the existing document and generates a matching DocumentReference resource, or returns one it has previously generated. Servers may be able to return or generate document references for the following types of documents, FHIR Documents, CDA Documents, or Other Documents.

For CDA documents, the uri returned is a reference to a FHIR Binary end-point that returns either a CDA document, or some kind of CDA Package that the server knows how to process (e.g., an IHE .zip, Multipart Mime package)

The operation is initiated by a named query, using _query=generate on the /DocumentReference end-point:

 GET [service-url]/DocumentReference/?_query=generate&uri=:url&...

The "uri" parameter is a relative or absolute reference to one of the document types described above. Other parameters may be supplied:

Name	Meaning
persist	Whether to store the document at the document end-point (/Document) or not, once it is generated. Value = true or false (default is for the server to decide).

4 CDA Templating

(content on separate page)

5 CDA R-MIM

(content on separate page)

6 CDA Hierarchical Description

(content on separate page)

7 CDA XML Implementation

(content on separate page)

8 Appendix

(content on separate page)