X.3 Transcribed Diagnostic Imaging CDA Instance Content
Prev | X Dictation-based Reporting With Image References (Informative) | Next

## X.3 Transcribed Diagnostic Imaging CDA Instance Content

This section describes the use of transcribed dictation and Key Object Selection (KO) documents to produce an HL7 Clinical Document Architecture (CDA) Release 2 document.

### Note

While this section describes encoding as CDA Release 2, notes are provided about encoding issues for CDA Release 1.

### X.3.1 CDA Header Content

The header of the CDA instance includes:

- Identity of the patient ("recordTarget" participation)

- Identity of the requested procedure ("documentationOf" act relationship)

- Identity of the dictating physician ("author" participation)

- Identity of the transcriptionist ("dataEnterer" participation)

- Identity of the report signing physician ("legalAuthenticator" participation)

- Identity of the institution owning the report ("custodian" participation)

- Identity of the request/order ("inFulfillmentOf" act relationship)

### Note

The markup components in CDA Release 1 use different names.

### X.3.2 Transcribed Text Content

Each transcription section can be encoded in a Section in the CDA document. The Section.Code and/or Section.Title can be derived from the corresponding transcription section title, if any. Although the transcription text can be encoded in the Section.Text without further markup, it is recommended that it be enclosed in <paragraph> tags.

### X.3.3 Image References

Images are referenced using hypertext links in the narrative text. These links in CDA are not considered part of the attested content.

### Note

1. The primary use case for this Annex is the dictation/transcription reporting model. In the historical context of that model, the images (film sheets) are usually not considered part of the attested content of the report, although they are part of the complete exam record. I.e., the report is clinically complete without the images, and the referenced images are not formally part of the report. Therefore, this Annex discusses only the use of image references, not images embedded in the report.

2. Being part of the attested content would require the images to be displayed every time the report is displayed - i.e., they are integral to understanding the report. If the images are attested, they must also be encapsulated with the CDA package. I.e., the CDA document itself is only one part of the interchanged package; the referenced images must also always be sent with the CDA document. If the images are for reference only and not attested, the Image Content Item may be transformed to a simple hypertext link; it is then the responsibility of CDA document receiver to follow or not follow the hyperlink. Moreover, as the industry moves toward ubiquitous network access to a distributed electronic healthcare record, there will be less need to prepackage the referenced images with the report.

In the current use case, there will be one or more KO instances with image references. Each KO instance can be transformed to a Section in the CDA document with a Section.Title "Key Images", and a Section.Code of 121180 from the DICOM Controlled Terminology (see PS3.16). If the KO includes a TEXT content item, it can be transformed to <paragraph> data in that Section.Text of the CDA document. Each IMAGE content item can be transformed to a link item using the <linkHtml> markup.

Within the <linkHtml> markup, the value of the href attribute is the DICOM object reference as a Web Access to Persistent DICOM Objects (WADO) specified URI (see Table X.3-1).

### Note

1. When a DICOM object reference is included in an HL7 CDA document, it is presumed the recipient would not be a DICOM application; it would have access only to general Internet network protocols (and not the DICOM upper layer protocol), and would not be configured with the means to display a native DICOM image. Therefore, the recommended encoding of a DICOM Object Reference in the CDA narrative block <linkHtml> uses WADO for access by the HTTP/HTTPS network protocol (see PS3.18), using one of the formats broadly supported in Web browsers (image/jpeg or video/mpeg) as the requested content type.

2. In CDA Release 1, the markup tag for hyperlinks is <link_html> within the scope of a <link> tag.

Table X.3-1. WADO Reference in an HL7 CDA <linkHtml>

WADO Component | Source
--- | ---
<scheme>:// <authority> / <path> | Configuration setting, used by the conversion process, identifying the WADO server
?requestType=WADO | Fixed
&studyUID =<uid> | Study Instance UID for referenced image obtained from the Current Requested Procedure Evidence Sequence or the Pertinent Other Evidence Sequence in the KO Instance
&seriesUID= <uid> | Series Instance UID for referenced image obtained from the Current Requested Procedure Evidence Sequence or the Pertinent Other Evidence Sequence in the KO Instance
&objectUID= <uid> | Referenced SOP Instance UID from IMAGE content item
&frameNumber= <list> | Referenced Frame Number from IMAGE content item (if present)
&presentationUID= <uid> | Referenced SOP Instance UID from Referenced SOP Sequence within IMAGE content item
&presentationSeriesUID= <uid> | Series Instance UID for referenced presentation state obtained from the Current Requested Procedure Evidence Sequence or the Pertinent Other Evidence Sequence in the KO Instance
&contentType=video/mpeg | Present if Referenced SOP Class UID from IMAGE content item is for a multi-frame image IOD

### Note

1. Literal strings are in normal typeface, while <italic typeface within angle brackets> indicates values to be copied from the identified source.

2. The default contentType for single frame images is image/jpeg, which does not need to be specified as a WADO component. However, the default contentType for multiple frame images is application/dicom, which needs to be overridden with the specific request for video/mpeg.

3. There is not yet a standard mechanism for minimizing the potential for staleness of the <scheme>://<authority>/<path>component.

### X.3.4 Icons

If the IMAGE content item includes an Icon Image Sequence, the report creation process may embed the icon in the Section.Text narrative. The Icon Image Sequence Pixel Data is converted into an image file, e.g., in JPEG or GIF format, and base64 encoded. The file is encoded in an ObservationMedia entry in the CDA instance, and a <renderMultimedia> tag reference to the entry is encoded in the Section.Text adjacent to the <linkHtml> of the image reference.

### X.3.5 Structured Entries

The Current Requested Procedure Evidence Sequence (0040,A375) of the KO instance lists all the SOP Instances referenced in the IMAGE content items in their hierarchical Study/Series/Instance context. It is recommended that this list be transcoded to CDA Entries in a Section with Section.Title "DICOM Object Catalog" and a Section.Code of 121181 from the DICOM Controlled Terminology (see PS3.16).

### Note

1. Structured Entries are not defined in CDA Release 1.

2. Since the image hypertext links in the Section narrative may refer to both an image and a softcopy presentation state, as well as possibly being constrained to specific frame numbers, in general there is not a simple mapping from the <linkHtml> to an entry. Therefore it is not expected that there would be ID reference links between the <linkHtml> and related entries.

The purpose of the Structured Entries is to allow DICOM-aware applications to access the referenced images in their hierarchical context.

The encoding of the DICOM Object References in CDA Entries is shown in Figure X.3-1 and Tables X.3-2 through X.3-6. All of the mandatory data elements for the Entries are available in the Current Requested Procedure Evidence Sequence; optional elements (e.g., instance DateTimes) may also be included if known by the encoding application.

Figure X.3-1. CDA Section with DICOM Object References

### Note

The format of Figure X.3-1 follows the conventions of HL7 v3 Reference Information Model diagrams.

Table X.3-2. DICOM Study Reference in an HL7 V3 Act (CDA Act Entry)

Attribute | Data Type | Multiplicity | Value
--- | --- | --- | ---
classCode | CS | 1..1 | ACT
moodCode | CS | 1..1 | EVN
id | II | 1..1 | <Study Instance UID (0020,000D) as root property with no extension property >
code | CD | 1..1 | <113014 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, "DICOM Study" as displayName property>
text | ST | 0..1 | <Study Description (0008,1030) >
effectiveTime | TS | 0..1 | < Study Date (0008,0020) and Study Time (0008,0030) >

Table X.3-3. DICOM Series Reference in an HL7 V3 Act (CDA Act Entry)

Attribute | Data Type | Multiplicity | Value
--- | --- | --- | ---
classCode | CS | 1..1 | ACT
moodCode | CS | 1..1 | EVN
id | II | 1..1 | <Series Instance UID (0020,000E) as root property with no extension property >
code | CD | 0..1 | <113015 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, "DICOM Series" as displayName property, Modality as qualifier property (see text and Table X.3-4) >
text | ST | 0..1 | < Series Description (0008,103E) >
effectiveTime | TS | 0..1 | < Series Date (0008,0021) and Series Time (0008,0031) >

The code for the Act representing a Series uses a qualifier property to indicate the modality. The qualifier property is a list of coded name/value pairs. For this use, only a single list entry is used, as described in Table X.3-4.

Table X.3-4. Modality Qualifier for The Series Act.Code

Property | Data Type | Value
--- | --- | ---
name | CV | <121139 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, "Modality" as displayName property>
value | CD | < Modality (0008,0060) as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, Modality code meaning (from PS3.16) as displayName property>

Table X.3-5. DICOM Composite Object Reference in an HL7 V3 Act (CDA Observation Entry)

Attribute | Data Type | Multiplicity | Value
--- | --- | --- | ---
classCode | CS | 1..1 | DGIMG
moodCode | CS | 1..1 | EVN
id | II | 1..1 | < SOP Instance UID (0008,0018) as root property with no extension property>
code | CD | 1..1 | < SOP Class UID (0008,0016) as code property, 1.2.840.10008.2.6.1 as codeSystem property, DCMUID as codeSystemName property, SOP Class UID Name (from PS3.6) as displayName property>
text | ED | 0..1 | <application/DICOM as mediaType property, WADO reference (see Table X.3-6) as reference property>
effectiveTime | TS | 0..1 | < Content Date (0008,0023) and Content Time (0008,0033) >

### Note

1. The DGIMG class is used to reference all DICOM Composite Instances, not just diagnostic images.

2. The Observation.Text reference property may alternatively use a DICOM protocol based URI, rather than WADO, should such a URI be defined.

Table X.3-6. WADO Reference in an HL7 DGIMG Observation.Text

WADO Component | Source
--- | ---
<scheme>:// <authority> / <path> | Configuration setting, used by the conversion process, identifying the WADO server
?requestType=WADO | Fixed
&studyUID =<uid> | Study Instance UID for referenced instance
&seriesUID= <uid> | Series Instance UID for referenced instance
&objectUID= <uid> | SOP Instance UID for referenced instance
&contentType=application/DICOM | Fixed

### X.4.3 Using The WADO Reference For DICOM Network Protocol Retrievals

An application that receives a CDA with image references, and is capable of using the full services of DICOM upper layer protocol directly, can use the WADO parameters in either the linkHtml or in the DGIMG Observation.Text to retrieve the object using the DICOM network services. Such an application would need to be pre-configured with the hostname/IP address, TCP port, and AE Title of the DICOM object server (C-MOVE or C-GET SCP); this network address is not part of the WADO string. (Note that pre-configuration of this network address is typical for DICOM applications, and is facilitated by the LDAP-based DICOM Application Configuration Management Profile; see PS3.15.)

The application would open a Query/Retrieve Service Association with the configured server, and send a C-MOVE or C-GET command using the study, series, and object instance UIDs identified in the WADO query parameters. Such an application might also reasonably query the server for related objects, such as Grayscale Softcopy Presentation State.

### Note

When using the C-GET service, the retrieving application needs to specify and negotiate the SOP Class of the retrieved objects when it opens the Association. This information is not available in the linkHtml WADO reference; however, it is available in the DGIMG Observation.Code. It may also be obtained from the configured server using a C-FIND query on a prior Association.

Prev | Up | Next
X.2 Transcribed Diagnostic Imaging SR Instance Content | Home | X.4 Simultaneous SR and CDA Instance Creation