diagnostic imaging report - health level seven international€¦ · web viewfilename description...

CDAR2_II_BIMGRPTS_R1

Implementation Guide for CDA Release 2 – Diagnostic Imaging Report

Editor/Co-Chair: Fred M. Behlen, PhDAmerican College of [email protected]

Co-Chair: Helmut Koenig, MDhelmut. [email protected]

(Committee Draft for) 1st Informative BallotAugust 28September 12, 2007

© 2007 Health Level Seven, Inc.Ann Arbor, MIAll rights reserved.

mailto:[email protected]

mailto:[email protected]

Revision History

0.3.14 September 30, 2006 Committee draft from Boca Raton Meeting0.3.15 January 10, 2007 Committee draft0.4.17 April 29, 2007 Committee draft0.4.18 July 8, 2007 Committee Draft 0.4.19 July 15, 2007 Committee Draft0.4.20 August 28, 2007 Committee Draft0.4.21 September 12, 2007 Committee Draft

0.x.00 December xx, 2007 1st Informative Ballot

Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Committee DraftCommittee Draft 0.40.4 September 12August xx, 2007

© 2006 2007 Health Level Seven, Inc. All rights reserved.

Open Issues

1. Update Appendix B with current CDA ample2. Update figures with snips from current CDA sample3. Others TBD in Committee Review (July 11 Conference Call)4. Specify Level 2 constraints5. Specify Level 3 description with measurements, annotation and image

references.6. Level 1-2 example (Appendix B, C)7. Level 3 example (Appendix D)8. Describe transformation of SR to CDA (Appendix E)



Table of Contents

1 DIAGNOSTIC IMAGING REPORT ......................................................................71 INTRODUCTION .................................................................................................................. 7

1.1 Purpose ..................................................................................................................71.2 Audience ................................................................................................................71.3 Approach ................................................................................................................71.4 Conventions Used in this Guide ..............................................................................7

1.4.1 Explanatory Statements ................................................................................................71.4.2 Conformance Requirements ..........................................................................................71.4.3 XPath Notation ...............................................................................................................81.4.4 Key Words ......................................................................................................................81.4.5 XML Samples .................................................................................................................81.4.6 DICOM Samples .............................................................................................................81.4.7 Content of the Ballot Package .......................................................................................8

1.5 Scope .....................................................................................................................92 CDA HEADER ................................................................................................................. 10

2.1 ClinicalDocument .................................................................................................102.1.1 General Constraints .....................................................................................................112.1.2 Rendering Information from the CDA Header for Human Presentation .......................112.1.3 ClinicalDocument/realmCode ......................................................................................112.1.4 ClinicalDocument/typeId ..............................................................................................122.1.5 ClinicalDocument/templateId .......................................................................................122.1.6 ClinicalDocument/id .....................................................................................................122.1.7 ClinicalDocument/code ................................................................................................132.1.8 ClinicalDocument/title ..................................................................................................142.1.9 ClinicalDocument/effectiveTime ..................................................................................142.1.10 ClinicalDocument/confidentialityCode .........................................................................152.1.11 ClinicalDocument/languageCode .................................................................................152.1.12 ClinicalDocument/setId and ClinicalDocument/versionNumber ...................................152.1.13 ClinicalDocument/copyTime ........................................................................................15

2.2 Participants ..........................................................................................................152.2.1 recordTarget ................................................................................................................162.2.2 author ..........................................................................................................................162.2.3 dataEnterer ..................................................................................................................172.2.4 informant .....................................................................................................................182.2.5 custodian .....................................................................................................................182.2.6 informationRecipient ...................................................................................................182.2.7 legalAuthenticator .......................................................................................................192.2.8 authenticator ...............................................................................................................192.2.9 participant ...................................................................................................................202.2.10 inFullfillmentOf ............................................................................................................202.2.11 documentationOf .........................................................................................................212.2.12 authorization ................................................................................................................222.2.13 relatedDocument .........................................................................................................222.2.14 componentOf ...............................................................................................................23

3 BODY ............................................................................................................................ 24 3.1 LOINC Section Type Codes ...................................................................................243.2 Required Sections ................................................................................................26

3.2.1 Findings – LOINC 18782-3 ............................................................................................263.3 Conditionally-Required Sections ...........................................................................28

3.3.1 DICOM Object Catalog – DCM 121181 .........................................................................283.4 Optional Sections .................................................................................................30



3.4.1 Reason for Study – LOINC 18785-6 ..............................................................................303.4.2 History of Present Illness – LOINC 10164-2 ..................................................................303.4.3 Impressions – LOINC 19005-8 ......................................................................................30

3.5 Level 3 Content ....................................................................................................313.5.1 Text Elements ..............................................................................................................313.5.2 Code Elements .............................................................................................................323.5.3 Report Observations ....................................................................................................32

4 REFERENCES .................................................................................................................. 37 APPENDIX A — VALIDATION .............................................................................38

INTRODUCTION ....................................................................................................................... 38 Administrative Gender ...................................................................................................38Ethnicity & Race .............................................................................................................38Null Flavor ......................................................................................................................38Participation Function .....................................................................................................40

APPENDIX B — SAMPLE CONFORMING CDA DOCUMENT .....................................41

1 DIAGNOSTIC IMAGING REPORT ......................................................................71 INTRODUCTION .................................................................................................................. 7

1.1 Purpose ..................................................................................................................71.2 Audience ................................................................................................................71.3 Approach ................................................................................................................71.4 Conventions Used in this Guide ..............................................................................7

1.4.1 Explanatory Statements ................................................................................................71.4.2 Conformance Requirements ..........................................................................................71.4.3 XPath Notation ...............................................................................................................81.4.4 Key Words ......................................................................................................................81.4.5 XML Samples .................................................................................................................81.4.6 DICOM Samples .............................................................................................................81.4.7 Content of the Ballot Package .......................................................................................8

1.5 Scope .....................................................................................................................92 CDA HEADER ................................................................................................................. 10

2.1 ClinicalDocument .................................................................................................102.1.1 General Constraints .....................................................................................................112.1.2 Rendering Information from the CDA Header for Human Presentation .......................112.1.3 ClinicalDocument/realmCode ......................................................................................112.1.4 ClinicalDocument/typeId ..............................................................................................122.1.5 ClinicalDocument/templateId .......................................................................................122.1.6 ClinicalDocument/id .....................................................................................................122.1.7 ClinicalDocument/code ................................................................................................132.1.8 ClinicalDocument/title ..................................................................................................142.1.9 ClinicalDocument/effectiveTime ..................................................................................142.1.10 ClinicalDocument/confidentialityCode .........................................................................152.1.11 ClinicalDocument/languageCode .................................................................................152.1.12 ClinicalDocument/setId and ClinicalDocument/versionNumber ...................................152.1.13 ClinicalDocument/copyTime ........................................................................................15

2.2 Participants ..........................................................................................................152.2.1 recordTarget ................................................................................................................162.2.2 author ..........................................................................................................................162.2.3 dataEnterer ..................................................................................................................172.2.4 informant .....................................................................................................................182.2.5 custodian .....................................................................................................................182.2.6 informationRecipient ...................................................................................................182.2.7 legalAuthenticator .......................................................................................................192.2.8 authenticator ...............................................................................................................192.2.9 participant ...................................................................................................................20



2.2.10 inFullfillmentOf ............................................................................................................202.2.11 documentationOf .........................................................................................................212.2.12 authorization ................................................................................................................222.2.13 relatedDocument .........................................................................................................222.2.14 componentOf ...............................................................................................................23

3 BODY ............................................................................................................................ 24 3.1 LOINC Section Type Codes ...................................................................................243.2 Required Sections ................................................................................................26

3.2.1 Findings – LOINC 18782-3 ............................................................................................263.3 Optional Sections .................................................................................................293.3.1 Reason for Study – LOINC 18785-6 .......................................................................293.3.2 History of Present Illness – LOINC 10164-2 ...........................................................293.3.3 Impressions – LOINC 19005-8 ...............................................................................293.3.4 DICOM Object Catalog – DCM 121181 ..................................................................293.4 Level 3 Content ....................................................................................................334 References ...........................................................................................................34Appendix A — ............................................................................................................Validation 35Introduction ....................................................................................................................35Administrative Gender ...................................................................................................35Ethnicity & Race .............................................................................................................35Null Flavor ......................................................................................................................35Participation Function .....................................................................................................37Appendix B — .................................................................Sample Conforming CDA Document 38



FiguresFigure 1 Use of the templateId element to indicate use of this guide. .....................11Figure 2 ClinicalDocument Example .........................................................................12Figure 3 ClinicalDocument/realmCode Example .......................................................12Figure 4 ClinicalDocument/typeId Example ..............................................................13Figure 5 ClinicalDocument/templateId Example conforming to Level 1 only ............13Figure 6 ClinicalDocument/id Example .....................................................................13Figure 7 ClinicalDocument/code Example ................................................................14Figure 8 Use of the translation element to include local codes for document type. .14Figure 9 ClinicalDocument/title Example ..................................................................15Figure 10 CinicalDocument/effectiveTime Example .................................................15Figure 11 CinicalDocument/confidentialityCode Example ........................................16Figure 12 ClinicalDocument/languageCode Example with language only ................16Figure 13 ClinicalDocument/languageCode Example with language and country. ...16Figure 14 recordTarget Example ..............................................................................17Figure 15 author Example ........................................................................................18Figure 16 dataEnterer Example ................................................................................18Figure 17 custodian Example ...................................................................................19Figure 18 informationRecipient Example ..................................................................20Figure 19 legalAuthenticator Example .....................................................................20Figure 20 authenticator Example .............................................................................21Figure 21 participant Example .................................................................................21Figure 22 inFulfillmentOf Example ...........................................................................22Figure 23 documentationOf Example .......................................................................23Figure 24 componentOf example .............................................................................24Figure 25 Findings Example including Level 3 content .............................................28Figure 26 DICOM Object Catalog Example ................................................................30Figure 27 Reason for Study Example ........................................................................31Figure 28 History Example .......................................................................................31Figure 29 Impressions Example ................................................................................31Figure 30 Text Element example ..............................................................................33Figure 31 Code Element example .............................................................................33Figure 32 Report Observation as an Entry ................................................................34Figure 33 Report Observation as a support for an inferred finding ..........................34Figure 34 Image Reference Report Observation example ........................................35Figure 34 Linear Measurement Report Observation example ..................................35Figure 34 Linear Measurement Report Observation example ..................................36Figure 34 Volume Measurement Report Observation example ................................36Figure 34 Numeric Measurement Report Observation example ...............................37Figure 1 Use of the templateId element to indicate use of this guide. .....................10Figure 2 ClinicalDocument Example .........................................................................11Figure 3 ClinicalDocument/realmCode Example .......................................................11Figure 4 ClinicalDocument/typeId Example ..............................................................12Figure 5 ClinicalDocument/templateId Example conforming to Level 1 only ............12Figure 6 ClinicalDocument/id Example .....................................................................12Figure 7 ClinicalDocument/code Example ................................................................13Figure 8 Use of the translation element to include local codes for document type. .13Figure 9 ClinicalDocument/title Example ..................................................................14Figure 10 CinicalDocument/effectiveTime Example .................................................14Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Committee DraftCommittee Draft 0.40.4 September 12August xx, 2007


Figure 11 CinicalDocument/confidentialityCode Example ........................................15Figure 12 ClinicalDocument/languageCode Example with language only ................15Figure 13 ClinicalDocument/languageCode Example with language and country. ...15Figure 14 recordTarget Example ..............................................................................16Figure 15 author Example ........................................................................................17Figure 16 dataEnterer Example ................................................................................17Figure 17 custodian Example ...................................................................................18Figure 18 informationRecipient Example ..................................................................19Figure 19 legalAuthenticator Example .....................................................................19Figure 20 authenticator Example .............................................................................20Figure 21 participant Example .................................................................................20Figure 22 inFulfillmentOf Example ...........................................................................21Figure 23 documentationOf Example .......................................................................22Figure 24 componentOf example .............................................................................23Figure 25 Findings Example .....................................................................................28Figure 26 Reason for Study Example ........................................................................29Figure 27 History Example .......................................................................................29Figure 28 Impressions Example ................................................................................29Figure 29 DICOM Object Catalog Example ................................................................32TablesTable 1 Contents of the Ballot Package ...................................................................10Table 2 LOINC Document Type Codes ......................................................................15Table 3 LOINC Section Type Codes ...........................................................................25Table 4 Administrative Gender .................................................................................39Table 5 Null Flavor ....................................................................................................40Table 6 Participating Function Codes .......................................................................41Table 1 Contents of the Ballot Package .....................................................................9Table 2 LOINC Document Type Codes ......................................................................14Table 3 LOINC Section Type Codes ...........................................................................24Table 4 Administrative Gender .................................................................................35Table 5 Null Flavor ....................................................................................................36Table 6 Participating Function Codes .......................................................................37



1 Diagnostic Imaging Report

1 Introduction

1.1 Purpose

The purpose of this document is to describe constraints on the CDA Header and Body elements for Diagnostic Imaging Reports. A Diagnostic Imaging Report contains a consulting specialist’s interpretation of image data. It is intended to convey the interpretation to the referring (ordering) physician, and becomes part of the patient’s medical record. It is intended for use in Radiology, Endoscopy, Cardiology, and other imaging specialties.

1.2 Audience

The audience for this document is software developers and consultants responsible for implementation of Radiology Information Systems, Radiology Reporting systems, Picture Archiving and Communications Systems (PACS), and other image and imaging management systems, that are expected to transmit results to of Electronic Health Record (EHR) systems or health information exchange networks as CDA documents created according to this specification.

1.3 Approach

The approach taken in the development of this specification was to review existing relevant DICOM Standards and IHE Implementation Profiles, and to review CDA Header and Body elements and attributes with domain experts, and on that basis, constrain the CDA Header and Body elements.

1.4 Conventions Used in this Guide

This guide is a conformance profile, as described in the Refinement and Localization section of the HL7 Version 3 standards. As defined in that document, this guide is both an annotation profile and a constraint profile. The base standard for this guide is the HL7 Clinical Document Architecture, Release 2.0.

The mapping profile for SR to CDA is based on DICOM Template 2000 Basic Diagnostic Imaging Report, NEMA PS3.16-2007.

1.4.1 Explanatory Statements

As an annotation profile, portions of this guide summarize or explain the base standard.

Explanatory statements will appear in this style.

1.4.2 Conformance Requirements

Conformance requirements within this guide are sequentially numbered, and appear in the format illustrated below:



http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm

http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm

CONF-1: This is an example conformance requirement for conformance to level 1 requirements.

1.4.3 XPath Notation

Instead of the traditional dotted notation used by HL7 to represent RIM classes, this guide uses XPath notation in conformance statements and elsewhere to identify the XML elements and attributes within the CDA document instance to which various constraints are applied. The implicit context of these expressions is the root of the document. The purpose of using this notation is to provide a mechanism which will be familiar to developers for identifying parts of an XML document.

1.4.4 Key Words

The key words "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "NEED NOT" in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide.

1.4.5 XML Samples

XML Samples appear in various figures in this document in a fixed font. Portions of the XML content may be suppressed for brevity. These are marked by a vertical ellipses, as shown in the example below. <ClinicalDocument xmlns='urn:hl7-org:v3'>

:.

</ClinicalDocument>

Within the narrative, XML element and attribute names in the text will appear in this font. Literal attribute values will appear in this font.

XPath expressions are used in the narrative and conformance requirements to identify elements. These were chosen because they are familiar to many XML implementers.

1.4.6 DICOM Samples

DICOM Samples appear in the table format used in the DICOM Standard, listing each DICOM Attribute as a single line with columns denoting the Attribute Tag, Name, Value Representation and usage description.

Examples of DICOM SR documents are presented in the notation used in Clunie, David, DICOM Structured Reporting, PixelMed Publishing, Bangor, PA, 2000. Available at: http://www.pixelmed.com (link checked ____,__, 2007).

DICOM Images referenced in the samples may be presented herein a header in DICOM tabular form followed by a rendering of the pixel data into the publishing format of this document. The DICOM binary encoded form in included in the ballot package.

1.4.7 Content of the Ballot Package

The ballot package contains the following files:



http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm

http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm

Filename Description

Diagnostic Imaging Report for CDA Release 2 Level 1-3 v1.0.pdf

This guide

DICOM SR “Basic Diagnostic Imaging Report” to HL7 CDA Release 2 “Diagnostic Imaging Report” Transformation Guide

The transformation guide specifying the mapping of constrained DICOM SR “Basic Diagnostic Imaging Reports” (DICOM PS 3.16-2007: Template 2000) to CDA Release 2 “Diagnostic Imaging Reports” as described by this guide.

EnhancedSR.xml The sample CDA document found in Appendix B.

voc.xml A vocabulary data file used by both the Schematron schema and the display stylesheet.

IMPL_CDAR2.xsl A stylesheet for displaying the content of the sample document in HTML.

EnhancedSR.dcm The sample DICOM SR document found in Appendix C.

SampleChestXR_PA.dcmSampleChestXR_Lat.dcm

Sample DICOM images referenced within the DICOM SR document EnhancedSR…dcm

Table 1 Contents of the Ballot Package

1.4.7.1 Sample DICOM SR Basic Diagnostic Imaging Report

The Sample DICOM SR report conforms to DICOM Template 2000 for a diagnostic imaging report including image annotation and references. This SR report is equivalent in content to the Sample CDA document, according to the mapping described on Appendix B.

The Report example is based on a chest radiography examination, the images from whick are included in two DICOM Image files, SampleChestXR_PA.dcm and SampleChestXR_Lat.dcm. The report examples include references to these images.

1.4.7.2 Constrained CDA Diagnostic Imaging Report XML Schema

Also included in this ballot package is a CDA XML Schema constrained to the elements allowed in this Implementation Guide. This Schema is informative, and implementers should be cautioned that not all constraints in this guide are represented in the XML Schema.

1.4.7.3 Sample XML

A sample document is provided which conforms to the level 1 and level 2 constraints of this guide. This document is the source of many of the examples provided in this guide.

1.5 Scope

This specification defines additional constraints on CDA Header and Body elements used in a Diagnostic Imaging Report, and provides examples of conforming fragments in the body of the document and an example of a conforming XML instance as an appendix.

This Guide specifies three levels of conformance requirements. Level 1 requirements specify constraints upon the CDA Header and the content of the document. Level 2



requirements specify constraints upon the structuredBody of the ClinicalDocument element of the CDA document. Level 3 requirements describe a limited set of structured entries for the purpose of referencing and annotating images from within the report.

This specification is intended for global use (Universal Realm). The specification of workflows, messages, or procedures used in performing imaging procedures is outside the scope of this specification.

CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that the CDA instance not only conforms to the CDA specification, but in addition, conforms to the constraints specified in this implementation guide.<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"><typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/><templateId root="2.16.840.1.113883.10" extension="CDAR2_II_BIMGRPTS_R1"/>:.:

</ClinicalDocument>

Figure 1 Use of the templateId element to indicate use of this guide.Within this guide, the required and optional content within the body are identified. This guide describes the information content of each section, but this cannot be verified by software.

2 CDA Header

2.1 ClinicalDocument The namespace for CDA Release 2.0 is urn:hl7-org:v3. Appropriate namespace declarations SHALL be used in the XML instance of the Clinical Document. In the examples in this specification, all elements are shown un-prefixed, assuming that the default namespace is declared to be urn:hl7-org:v3. This guide does not require use of any specific namespace prefix. Transmitted instances SHOULD NOT include the xsi:schemaLocation1 element.

The root of a Diagnostic Imaging Report SHALL be a ClinicalDocument element from the urn:hl7-org:v3 namespace.

1 The xsi:schemaLocation element is not recommended by the XML ITS because of security risks. Receivers who choose to perform validation should use a locally cached schema.Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Committee DraftCommittee Draft 0.40.4 September 12August xx, 2007


<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"><typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/><templateId root="2.16.840.1.113883.10" extension="CDAR2_II_BIMGRPTS_R1"/><id root="1.2.840.113619.2.62.994044785528.20060828170821659"/><code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Diagnostic Imaging Report"/><title>Chest X-Ray, PA and LAT View</title><effectiveTime value="20060828170821"/><confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code="en-US"/>:.:

</ClinicalDocument>

Figure 2 ClinicalDocument Example

2.1.1 General Constraints

All telephone numbers SHALL be encoded using a restricted form of the tel: URL scheme, described in the section on Error: Reference source not found below.

2.1.2 Rendering Information from the CDA Header for Human Presentation

Rendering the information in the header for human presentation is optional. However, un-rendered information cannot be assumed to be authenticated information. Therefore, the judgment of whether to render or not render information in the header should recognize the business need to authenticate the information as well as other business needs.

Recommendations for rendering information from the header include: Document title and document dates Service and encounter types and date ranges as appropriate All persons named along with their roles, participations, participation date

ranges, identifiers, address and telecom information Selected organizations named along with roles, participations, identifiers or

names, Record Target(s) date-of-birth Any other minimal context information that is available

2.1.3 ClinicalDocument/realmCode

This value identifies the realm2.

The ClinicalDocument/realmCode element MAY be present. If present, it SHALL use the fixed value UV. <realmCode code='UV'/>

Figure 3 ClinicalDocument/realmCode Example

2 This guide is for the Universal realm. A future guide may define national localizations. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Committee DraftCommittee Draft 0.40.4 September 12August xx, 2007


Fred Behlen, 08/28/07,

Remove all this?


Add to example

2.1.4 ClinicalDocument/typeId

The ClinicalDocument/typeId element SHALL be present. It identifies the constraints imposed by CDA Release 2.0 on the content, essentially acting as a version identifier. The @root and @extension values of this element SHALL be specified as shown below in Figure 4.

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

Figure 4 ClinicalDocument/typeId Example

CONF-1: The extension attribute of the typeId element SHALL be POCD_HD000040.

2.1.5 ClinicalDocument/templateId

The ClinicalDocument/templateId elements identify the templates that impose constraints on the content.

At least one ClinicalDocument/templateId of SHALL be present with the content shown below in Figure 5. This indicates conformance to the level one features of this guide.

CONF-2: A ClinicalDocument/templateId element SHALL be present where the value of @extension is CDAR2_II_BIMGRPTS_R1 and the value of @root is 2.16.840.1.113883.10.

<templateId root="2.16.840.1.113883.10" extension="CDAR2_II_BIMGRPTS_R1"/>

Figure 5 ClinicalDocument/templateId Example conforming to Level 1 only

2.1.6 ClinicalDocument/id

The ClinicalDocument/id element SHALL be present.. It SHALL be an II data type where the root is an OSI Object Identifier (OID). The root uniquely identifies the scope of the extension. The root and extension uniquely identifies the document.

CONF-3: The ClinicalDocument/id/@root attribute SHALL be a syntactically correct OID.

CONF-4: OIDs SHALL be represented in dotted decimal notation, where each decimal number is either 0, or starts with a non-zero digit. More formally, an OID SHALL be in the form ([0-2])(.([1-9][0-9]*|0))+.

CONF-5: OIDs SHALL be no more than 64 characters in length.

<id root="1.2.840.113619.2.62.994044785528.20060828170821659"/>

Figure 6 ClinicalDocument/id ExampleOrganizations that use OIDs SHALL properly register their OID root, and ensure uniqueness of the OID roots used in identifiers. There are a large number of mechanisms to obtain OID roots for free, or for a reasonable fee. HL7 Maintains an OID registry page, from which organizations may request an OID root under the HL7 OID root. This page can be accessed at: http://hl7.amg-hq.net/oid/frames.cfm

Another useful resource lists the many ways to obtain a registered OID Root for free or a small fee, anywhere in the world, located at:

http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration



The manner in which the OID root is obtained is not constrained by this implementation guide.

When a DICOM SR report is transformed to a CDA Diagnostic imaging Report, the ClinicalDocument/id/@root identifier is equivalent to the DICOM Attribute (0008,0018) SOP Instance UID and the ClinicalDocument/id/@extension identifier is not present. For compatibility with DICOM SR documents, ClinicalDocument/id/@extension SHALL NOT be present in Diagnostic Imaging Reports authored as CDA Documents.

CONF-6: The ClinicalDocument/id/@extension attribute SHALL NOT be present.

2.1.7 ClinicalDocument/code

The ClinicalDocument/code element SHALL be present and specifies the type of the clinical document.

The LOINC Diagnostic Imaging Report document type (LOINC Document Code 18748-4) SHOULD be used as the value for ClinicalDocument/code in the CDA Header. <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Diagnostic Imaging Report"/>

Figure 7 ClinicalDocument/code ExampleCDA Release 2.0 states that LOINC is the preferred vocabulary for document type specification.

2.1.7.1 Use of Local Document Type Codes

Implementations MAY use local codes in translation elements to further refine the document type. An example of this is shown below in Figure 8.

<code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Diagnostic Imaging Report<translation code='XRPEDS' displayName='Pediatric Radiography Report'codeSystem='2.16.840.1.123456.78.9'/>

</code>

Figure 8 Use of the translation element to include local codes for document type.

2.1.7.2 Precoordinated Document Type Codes

The LOINC document hierarchy listed in Error: Reference source not found is a list of document type codes supported under this specification. Some of these codes (those not marked in boldface type), are pre-coordinated with either the imaging modality, body part examined or specific imaging method such as the view. Use of these codes is not recommended, as this duplicates information potentially present with the CDA document header. When these codes are used, they SHALL NOT conflict with the other information present in the document. These codes are shown below in Error: Reference source not found.

LOINC Code Display Name Modality

18748-4 Diagnostic Imaging Report Any

18747-6 CT Report Cumputed Tomography




Add to example

18755-9 MRI Report Magnetic Resonance Imaging

18760-9 Ultrasound Report Ultrasoound

18757-5 Nuclear Medicine Report Nuclear Medicine

18758-3 PET Scan Report Positron Emission Tomography

18745-0 Cardiac Catheterization Report Cardiac Radiography/Fluoroscopy

11522-0 Echocardiography Report Cardiac Ultrasound

18782-3 X-ray StudyProjection Radiography

18752-6 Exercise stress test report

18754-2 Holter Study

18750-0 Cardiac Electrophysiology

11524-0 ECG Report

38269-7 Bone Mineral Densitometry Report Bone Densitometry

18748-4 Breast Imaging Report Mammography

Table 2 LOINC Document Type Codes These codes are drawn from LOINC version 2.16, December 2005 and equal the subset of LOINC whose scale is DOC and which refer to reports for diagnostic imaging procedures.

CONF-7: If pre-coordinated document type codes are used, values used in imaging procedure code ClinicalDocument/documentationOf/serviceEvent/code SHALL NOT conflict with ClinicalDocument/code.

2.1.8 ClinicalDocument/title

The title element MAY be present and specifies the local name used for the document. Many provider organizations will desire to have document titles more specific than the generic Display Name of the Document Type Code. For example, instead of Diagnostic Imaging Report, one may wish to have the title be “Chest CT Report”. Implementers may generate this automatically from available information specifying procedure, modality, body part, etc. The method of such derivation is not specified in this specification.

<title>Chest X-Ray, PA and LAT View</title>

Figure 9 ClinicalDocument/title Example

2.1.9 ClinicalDocument/effectiveTime

The ClinicalDocument/effectiveTime element SHALL be present and specifies the creation time of the content of the document.

All Diagnostic Imaging Reports authored by direct input to a computer system SHOULD record an effectiveTime that is precise to the second. When authored in other ways, for example, by dictation and transcription, the precision of effectiveTime may be less.<effectiveTime value="20060828170821"/>

Figure 10 CinicalDocument/effectiveTime Example



2.1.10 ClinicalDocument/confidentialityCode

The ClinicalDocument/confidentialityCode SHALL be present. It specifies the confidentiality assigned to the document. This implementation guide provides no guidance on documents with respect to the vocabulary used for confidentialityCode, nor treatment or implementation of confidentiality. A Fixed Value of “N” (normal) is used when the CDA document is transformed from DICOM SR. A CDA Release 2.0 conforming example is shown below.

<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>

Figure 11 CinicalDocument/confidentialityCode Example

2.1.11 ClinicalDocument/languageCode

The ClinicalDocument/languageCode element SHALL be present. It specifies the language of the Diagnostic Imaging Report. The encoding of the language SHALL be present, and SHALL be in the form nn (see Figure 12) or nn-CC (see Figure 13), where nn is a two letter ISO-639-1 language code in lower case, and CC is a two letter ISO-3166 Country code in upper case. This is a subset of the values defined by RFC 3066.

CONF-8: The languageCode element SHALL be present.CONF-9: The language code SHALL be in the form nn, or nn-CC.CONF-10: The nn portion SHALL be a legal ISO-639-1 language code in lower case.CONF-11: The CC portion, if present SHALL be an ISO-3166 country code in upper

case.<languageCode code="en"

Figure 12 ClinicalDocument/languageCode Example with language only

<languageCode code="en-US"

Figure 13 ClinicalDocument/languageCode Example with language and country.

2.1.12 ClinicalDocument/setId and ClinicalDocument/versionNumber

The ClinicalDocument/setId and ClinicalDocument/versionElements, SHALL be absent. CONF-12: Both ClinicalDocument/setId and ClinicalDocument/versionNumber

SHALL be absent.

2.1.13 ClinicalDocument/copyTime

The ClinicalDocument/copyTime element has been deprecated in CDA Release 2, therefore it SHALL NOT be present in conforming instances of a Diagnostic Imaging Report.

CONF-13: A ClinicalDocument/copyTime element SHALL NOT be present.

2.2 Participants

This section describes the constraints placed upon CDA Participants described in the CDA Header.



http://www.faqs.org/rfcs/rfc3066.html


http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html


http://www.loc.gov/standards/iso639-2/langcodes.html

In the HL7 Clinical Document Architecture, Release 2.0 specification, section 4.2.2.13 describes various Participant Scenarios, where a single person can participate in several roles. In these cases, the person SHOULD be listed for each role, as described in the CDA Release 2.0 specification.

2.2.1 recordTarget

The recordTarget element SHALL be present. It SHALL be the patient in whose medical record the report is to be placed.

CONF-14: At least one recordTarget/patientRole element SHALL be present.

The birthTime and administrativeGenderCode SHALL be present as this information is needed by users of a Diagnostic Imaging Report. If unknown, it SHALL be represented using a flavor of null. Values for administrativeGenderCode SHOULD be drawn from the HL7 AdministrativeGender vocabulary.

CONF-15: A patient/birthTime element SHALL be present. CONF-16: A patient/administrativeGenderCode element SHALL be present.

The maritalStatusCode, religiousAffiliationCode, raceCode and ethnicGroupCode elements MAY be present.

CONF-17: If maritalStatusCode, religiousAffiliationCode, raceCode and ethnicGroupCode elements are present, they SHOULD be encoded using appropriate HL7 vocabularies.

CONF-18: The guardian element SHOULD be present when the patient is a minor child.

The providerOrganization element MAY be present.

<recordTarget><patientRole><id root="1.2.840.113619.2.62.994044785528.10" extension="0000680029"/><patient><name><given>John</given><family>Doe</family>

</name><administrativeGenderCode codeSystem="2.16.840.1.113883.5.1" code="M"/><birthTime value="19641128"/>

</patient></patientRole>

</recordTarget>

Figure 14 recordTarget Example

2.2.2 author

The author element SHALL be present. It represents the creator of the document. If the role of the actor is the entry of information from his or her own knowledge or application of skills, that actor SHOULD be represented as the author. If one actor provides information to another actor, who filters, reasons, or algorithmically creates new information, then that second actor is also an author, having created information from his or her own knowledge or skills. However, that determination is independent from the determination of the first actor's authorship.



http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/AdministrativeGender.htm

http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm#participation_scenarios

<author><time value="20060823224352"/><assignedAuthor><id extension="121008" root="2.16.840.1.113883.19.5"/><assignedPerson><name><given>Richard</given><family>Blitz</family><suffix>MD</suffix>

</name></assignedPerson>

</assignedAuthor></author>

Figure 15 author ExampleThe time element SHALL be present. It SHALL be the starting time of the author's participation in the creation of the document.

CONF-19: The author/time element SHALL be present.

The assignedAuthor/id element SHALL be present.

CONF-20: The assignedAuthor/id element SHALL be present.

An assignedAuthor/assignedPerson or assignedAuthor/assignedAuthoringDevice element SHALL be present. This is the person or device authoring the document.

CONF-21: An assignedAuthor element SHALL contain at least one assignedPerson or assignedAuthoringDevice elements.

2.2.3 dataEnterer

This element MAY be present. It represents the person, usually a transcriptionist, who transferred the information from other sources into the Diagnostic Report. A person can participate as both author and dataEnterer.

If the role of the actor is to transfer information from one source to another (e.g., transcription, or transfer from paper form to electronic system), that actor SHOULD be recorded as dataEnterer.

CONF-22: When dataEnterer is present, an assignedEntity/assignedPerson element SHALL be present.

The time element MAY be present. If present, it represents the starting time of entry of the data.

<dataEnterer><time value='20050329222451+0500'/><assignedEntity><id extension='2' root='1.3.6.4.1.4.1.2835.2'/><assignedPerson><name><prefix>Mrs.</prefix><given>Bernice</given><family>Wiseman</family>


</assignedEntity></dataEnterer>

Figure 16 dataEnterer Example

2.2.4 informant

The informant element SHALL NOT be present.




Data Enterer should be added to the sample document.

2.2.5 custodian

The custodian element SHALL be present. This SHALL be the custodian of the Diagnostic Imaging Report document. The Custodian is optional in DICOM SR documents. When transforming from SR to CDA and Custodian is not present in the source document, it shall be set according to organizational policies.

<custodian><assignedCustodian><representedCustodianOrganization><id root="1.2.840.113619.2.62.994044785528"/><name>World University Hospital</name>

</representedCustodianOrganization></assignedCustodian>

</custodian>

Figure 17 custodian Example

2.2.6 informationRecipient

The ClinicalDocument/informationRecipient element MAY be present3. This element records the intended recipient of the information at the time the document is created. The Referring Physician, if present, SHALL be recorded as an informationRecipient. When no referring physician is preesnt, as in the case of self-referred screening examinations allowed by law, the intendedRecipient may be null with a nullFlavor of “OTH”. The intended recipient MAY also be the health chart of the patient, in which case the receivedOrganization SHALL be the scoping organization of that chart.

CONF-23: When informationRecipient is used, at least one informationRecipient/intendedRecipient/informationRecipient or informationRecipient/intendedRecipient/recievedOrganization SHOULD be present.

<informationRecipient><intendedRecipient><id extension='4' root='1.3.6.4.1.4.1.2835.2'/><addr><streetAddressLine>21 North Ave</streetAddressLine><city>Burlington</city><state>MA</state><postalCode>01803</postalCode><country>USA</country>

</addr><telecom value='tel:(999)555-1212' use='WP'/><informationRecipient><name><prefix>Dr.</prefix><given>Phil</given><family>Green</family>

</name></informationRecipient><receivedOrganization><name>Good Health Clinic</name>

</receivedOrganization></intendedRecipient>

</informationRecipient>

Figure 18 informationRecipient Example

3 Note that there are two elements in the CDA Release 2.0 schema that are named informationRecipient. The outermost of these elements is what is being discussed here. The second element with the same name may appear as a descendent of this one.Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Committee DraftCommittee Draft 0.40.4 September 12August xx, 2007



Add to example

2.2.7 legalAuthenticator

The legalAuthenticator element SHALL be present if the document has been legally authenticated. It SHALL identify the legal authenticator of the document. Diagnostic Imaging Reports MAY be released before legal authentication, based on local practice. This implies that a Diagnostic Imaging Report that does not contain this element has not been legally authenticated.

CDA Release 2 allows only one Legal Authenticator. In the case of diagnostic reports that are double read by physicians with authenticating privilege, one of the physicians is recorded as the legalAuthenticator, and the other is recorded as an Authenticator. Institutional policy may dictate which physician is the legalAuthenticator.

CONF-24: The assignedEntity/assignedPerson element SHALL be present in legalAuthenticator.

<legalAuthenticator><time value="20060827141500"/><signatureCode code="S"/><assignedEntity><id extension="08150000" root="1.2.840.113619.2.62.994044785528.33"/><assignedPerson><name><given>Richard</given><family>Blitz</family><suffix>MD</suffix>


</assignedEntity></legalAuthenticator>

Figure 19 legalAuthenticator Example

2.2.8 authenticator

An authenticator MAY be present. The authenticator SHALL identify a participant who verified the accuracy of the information in the document.

CONF-25: The assignedEntity/assignedPerson element SHALL be present in an authenticator element.

<legalAuthenticator><time value="20060827134500"/><signatureCode code="S"/><assignedEntity><id extension="1234567" root="1.2.840.113619.2.62.994044785528.33"/><assignedPerson><name><given>Robert</given><family>Resident</family><suffix>MD</suffix>


</assignedEntity></legalAuthenticator>

Figure 20 authenticator Example

2.2.9 participant

The participant element MAY be present. The participant SHALL identify the physician requesting the imaging procedure (the referring physician).




Need to clarify an example of an Authenticator.

CONF-26: The assignedEntity/assignedPerson element SHALL be present in an participant element.

<participant typeCode="REF"><associatedEntity classCode="PROV"><id nullFlavor="UNK"/><associatedPerson><name><given>John</given><family>Smith</family><suffix>MD</suffix>

</name></associatedPerson>

</associatedEntity></participant>

Figure 21 participant Example

.

2.2.10 inFullfillmentOf

The inFullfillmentOf elements MAY be present. They represent the Placer Order that was fulfilled in by the imaging procedure(s) covered by this report document.

The Placer Order is either a group of of order (modeled as PlacerGroup in the Placer Order RMIM of the Orders & Observations domain) or a single order item (modeled as ObservationRequest in the same RMIM). This optionality reflects two major approaches to the grouping of procedures as implemented in the installed base of imaging information systems. These approaches differ in their handling of grouped procedures and how they are mapped to identifiers in the DICOM image and structured reporting data. The example of a CT examination covering chest, abdomen and pelvis will be used in the discussion below:

In the IHE Scheduled Workflow model, the Chest CT, Abdomen CT and Pelvis CT each represent a Requested Procedure, and all three procedures are grouped under a single Filler Order. The Filler Order number maps directly to the DICOM Accession Number in the DICOM imaging and report data.

A widely deployed alternative approach maps the requested procedure identifiers directly to the DICOM Accession Number. The Requested Procedure ID in such implementations may or may not be different from the Accession Number but is of little identifying importance because there is only one Requested Procedure per Accession Number. There is no identifier that formally connects the requested procedures ordered in this group.

In both cases, inFullfillmentOf/order/id is mapped to the DICOM Accession Number in the imaging data.

<inFulfillmentOf><order><id extension="10523475" root="1.2.840.113619.2.62.994044785528.27"/>

</order></inFulfillmentOf>

Figure 22 inFulfillmentOf Example

2.2.11 documentationOf

One or more documentationOf elements SHALL be present. Each documentationOf/ServiceEvent SHALL indicate an imaging procedure that the provider describes and interprets in the content of the Diagnostic Imaging Report. The main activity being described by this document is the interpretation of the imaging procedure. This is shown by setting the value of the @classCode attribute of the serviceEvent element to ACT, and indicating the duration over which care was provided in the effectiveTime element. Within the documentationOf element, there is one serviceEvent element. This event is the unit imaging procedure corresponding to a billable item. The type of imaging procedure MAY be further described in the serviceEvent/code element. This guide makes no specific recommendations about the vocabulary to use for describing this event.

CONF-27: One or more ClinicalDocument/documentationOf elements SHALL be present.

CONF-28: The value of the serviceEvent/@classCode attribute SHALL be ACT.CONF-29: One or more serviceEvent/id elements SHALL be present. In IHE

Scheduled Workflow environments, one serviceEvent/id element contains the DICOM Study Instance UID from the Modality Worklist, and the second serviceEvent/id element contains the DICOM Requested Procedure ID from the from the Modality Worklist,

CONF-30: If present, the value of serviceEvent/code SHALL NOT conflict with the ClininicalDocument/code.

The effectiveTime for the serviceEvent covers the duration of the imaging procedure being reported. This event SHOULD have one or more performers, which MAY participate at the same or different periods of time.

Service events map to DICOM Requested Procedures. That is documentationOf/ServiceEvent/id is ID of the Requested Procedure.

CONF-31: The effectiveTime element of the serviceEvent element SHOULD be present.

CONF-32: The effectiveTime element SHOULD contain both a low and a high element.

CONF-33: A serviceEvent SHOULD have at least one performer. There are cases where no performers might be listed, for example, in cases where the information is not available.

CONF-34: The performer elements SHOULD list the persons performing the procedure(s) being reported. This would normally be the technologist performing the imaging procedure.

The specific type of performer MAY be described in performer/assignedEntity/code. CONF-35: If present, the values for performer/assignedEntity/code SHALL be drawn

from SNOMED CT, using concepts that descend from the healthcare professional subtype hierarchy (SNOMED CT Concept ID: 223366009).

CONF-36: The performer/assignedEntity/code if present SHALL have a value drawn from the SNOMED CT healthcare professional subtype hierarchy.




HK: replace by Healthcare Service

CONF-37: Every performer/assignedEntity element SHALL have at least one assignedPerson or representedOrganization.

The time element of the performer element MAY be present. If present, it indicates the time span over which healthcare services are provided, if different from that of the service event.<documentationOf><serviceEvent classCode="ACT"><id root="1.2.840.113619.2.62.994044785528.114289542805"/><id extension="123453" root="1.2.840.113619.2.62.994044785528.26"/>

</serviceEvent></documentationOf>

Figure 23 documentationOf Example

2.2.12 authorization

The authorization elements MAY be present. This document provides no guidance on the encoding of authorization elements.

2.2.13 relatedDocument

relatedDocument elements MAY be present. A Diagnostic Imaging Report may have three types of parent document:

A superseded version that the present document wholly replaces (typeCode = RPLC). Diagnostic Imaging Reports may go through stages of revision prior to being legally authenticated. Such early stages may be drafts from transcription, or those created by residents, or other pleliminary versions. Policies not covered by this specification may govern requirements for retention of such earlier versions, but except for forensic purposes, the latest version in a chain of revisions represents the complete and current report.

An original version that the present document appends (typeCode = APND). When a Diagnostic Imaging Report is legally authenticated, it cannot thereafter be replaced, but is only amended by a separate addendum document that references the original.

A source document from which the present document is transformed (typeCode = XFRM). A Diagnostic Imaging Report may be created by transformation from a DICOM SR document or from another Diagnostic Imaging Report. An example of the latter case is the creation of a derived document for use in a claims attachment.

When the parent document legally authenticated, it SHALL NOT be replaced. It may only be appended or transformed.

2.2.14 componentOf

When the Diagnostic imaging procedure is performed in the context of a hospital stay or and outpatient visit for which there is an Encounter Number, that number SHOULD be is present in as the id of the encompassingEncounter.

EncompassingEncounter.id is not available from DICOM SR documents, if Physian’s Reading Studies shall be mapped as Encounter participant (Performer), the null flavor UNK (unknown) shall be used

The id element of the encompassingEncounter SHALL be present and represents the identifier for the encounter.

CONF-38: The encompassingEncounter element SHALL have an id element.

The effectiveTime MAY be present, and represents the time interval or point in time in which the encounter took place. The encompassing encounter might be that of the office visit in which the Diagnostic Imaging procedure was ordered.

CONF-39: The encompassingEncounter element MAY have an effectiveTime element.

The responsibleParty element MAY be present. If present, it represents only the party responsible for the encounter, not necessarily the entire episode of care.

CONF-40: The responsibleParty/assignedEntity element SHALL have at least one assignedPerson or representedOrganization element present.

<componentOf><encompassingEncounter><id extension='9937012' root='1.3.6.4.1.4.1.2835.12'/><effectiveTime><low value='20050329'/><high value='20050329'/>

</effectiveTime></encompassingEncounter>

</componentOf>

Figure 24 componentOf example




Add to Example

3 BodyA Diagnostic Imaging Report SHALL have a structuredBody element. The content of this element makes up the human readable text of the document. This information SHALL be organized into sections and MAY have sub-sections.

CONF-41: A nonXMLBody/text SHOULD not contain both a reference element and character data.

3.1 LOINC Section Type Codes

The LOINC Section Type codes used in this guide are described below in Table 3. All section codes shown in this table describe narrative document sections4.

NOTE TO BALLOTERS: Where no applicable LOINC code was found, a local extension code has been de-fined beginning with the letter X. These codes will be submitted to LOINC after close of the ballot, and will be incorporated into the final release of this document.

The column headings of this table are described below: DCM Code: The code of the section in DICOM (Context Group CID 7001).DCM Code Meaning: The display name of the section in DICOM (Context Group CID 7001).. LOINC Code: The code of the section in LOINC.LOINC Component Name: The display name of the section in LOINC.Use: The use column indicates that a section in a Diagnostic Imaging Report is:

R – requiredC – conditionally requiredO – optional

DCM Code

DCM Code meaning LOINC Code LOINC Component Name Use

121181 DICOM Object Catalog C

121060 History O

121062 Request O

121064 Current Procedure Descriptions O

121066 Prior Procedure Descriptions O

121068 Previous Findings 18834-2 RADIOLOGY COMPARISON STUDY - OBSERVATION

O

121070 Findings 18782-3 RADIOLOGY STUDY OBSERVATION O

121072 Impressions 19005-8 RADIOLOGY - IMPRESSION O

121074 Recommendations 18783-1 RADIOLOGY STUDY - RECOMMENDATION

O

121076 Conclusions O

121078 Addendum O

121109 Indications for Procedure 18785-6 RADIOLOGY REASON FOR STUDY O

121110 Patient Presentation O121113 Complications O

121111 Summary O

121180 Key Images O

Table 3 LOINC Section Type Codes

4 SCALE_TYP = 'NAR' in the LOINC tables.Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Committee DraftCommittee Draft 0.40.4 September 12August xx, 2007



Do we intend to create LOINC codes for all Sections?

The DICOM Object Catalog section (see § 3.3.1), if present, SHALL be the first section in the document body.

Subsequent sections SHOULD appear in the order shown above, and MAY be nested under other sections. Sections and sub-sections within the Diagnostic Imaging Report content SHOULD have a title. A section element in a level 2 conforming Diagnostic Imaging Report SHOULD have a non-empty title element.

The remainder of the examples in this section all show sample content that would appear in the structuredBody element.

For level 2 conformance, all section elements that are present in the body of the document SHALL have a code and some non-blank text or one or more subsections, even if the purpose of the text is only to indicate that information is unknown.

CONF-42: A section element SHALL have a code element.CONF-43: A section SHALL contain at least one text element or one or more

component elements. CONF-44: All text or component elements SHALL contain content.



3.2 Required Sections

A Diagnostic Imaging Report SHALL contain sections that provide the following information:

3.2.1 Findings – LOINC 18782-3

The main narrative body of the report. This section SHOULD contain only the direct observations in the report, with topics such as Reason for Study, History, and Impression placed in separate sections. However, in cases where the source of report content provides a single blob of text not separated into these sections, that text SHALL shall be placed in the Findings section.

<component><section><code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Study observation"/><text><content ID="finding1">The cardiomediastinum is within normal limits. The trachea

is midline. The previously described opacity at the medial right lung base has cleared. There are no new infiltrates. There is a new round density at the left hilus, superiorly (diameter about 45mm). A CT scan is recommended for further evaluation. The pleural spaces are clear. The visualized musculoskeletal structures and the upper abdomen are stable and unremarkable.</content>

<content ID="finding2"> 45 mm diameter</content><content ID="finding3"> Image</content><linkHtml href="http://www.example.org/wado?

requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM" name="Computed Radiography Image Storage"/>

</text><entry><observation classCode="OBS" moodCode="EVN"><code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Study observation"></code><text><reference value="#finding1"/>

</text><entryRelationship typeCode="SPRT"><observation classCode="OBS" moodCode="EVN"><code code="M-02550" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNM3" displayName="Diameter"><originalText><reference value="#finding2"/>

</originalText></code><statusCode code="completed"/><effectiveTime value="20060823223912"/><value xsi:type="PQ" value="45" unit="mm"><translation code="mm" codeSystem="2.16.840.1.113883.6.8"

codeSystemName="UCUM" codeSystemVersion="1.5"/></value>

</observation></entryRelationship><entryRelationship typeCode="SUBJ"><observation classCode="DGIMG" moodCode="EVN"><id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/><code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1"

codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">

<originalText><reference value="#finding3"/>

</originalText></code><text xsi:type="ED" mediaType="application/DICOM"><reference value="http://www.example.org/wado?

requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM"/>

</text><effectiveTime value="20060823223232"/>

</observation></entryRelationship>

</observation></entry>

</section></component>

Figure 25 Findings Example including Level 3 content

3.3 Conditionally-Required Sections

A Diagnostic Imaging Report SHALL contain the following sections if their respective requirement conditions are met:

3.3.1 DICOM Object Catalog – DCM 121181

A DICOM Object Catalog SHALL be present if the document contains references to DICOM Images, Structured Reports or other DICOM composite objects. The DICOM Object Catalog lists all referenced objects and their parent Series and Studies, plus other DICOM attriburtes required for retrieving the objects.

DICOM Object Catalog sections are not intended for viewing, and contain empty section text.

CONF-45: A DICOM Object Catalog section SHALL have an empty or absent section/text element.

Figure 30 below shows a sample of an Object Catalog section. <component> <section classCode="DOCSECT" moodCode="EVN"> <code code="121181" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="DICOM Object Catalog"/> <text/> <entry>  <act classCode="ACT" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.114289542805"/> <code code="113014" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Study"/>  <entryRelationship typeCode="COMP"> <act classCode="ACT" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823223142485051"/> <code code="113015" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Series"> <qualifier> <name code="121139" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Modality"> </name> <value code="CR" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Computed Radiography"> </value> </qualifier> </code>   <entryRelationship typeCode="COMP"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/> <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage"> <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation>

</entryRelationship> <entryRelationship typeCode="COMP"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232231422.3"/> <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage"> <originalText> <reference value="#finding4"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232231422.3&contentType=application/DICOM"/>  </text> <effectiveTime value="20060823223142"/> </observation> </entryRelationship> </act> </entryRelationship> </act> </entry> </section> </component>

Figure 26 DICOM Object Catalog Example

3.4 Optional Sections

A Diagnostic Imaging Report MAY contain additional sections that provide additional information, such as prior procedure descriptions, prior findings , etc. When present these sections SHOULD be readily identifiable by the title.

3.4.1 Reason for Study – LOINC 18785-6

The indication for the imaging procedure SHOULD be present as a separate section.


displayName="Reason for study"/><text>Suspected lung tumor</text>


Figure 27 Reason for Study Example

3.4.2 History of Present Illness – LOINC 10164-2

Relevant patient history MAY be present as a separate section.


displayName="History of present illness"/><text>Sore throat.</text>


Figure 28 History Example

3.4.3 Impressions – LOINC 19005-8

Radiologist’s impression SHALL be present unless the Impression content is embedded in the FINDINGS section.


displayName="X-ray impression"/><text>No acute cardiopulmonary process. Round density in left superior hilus,

further evaluation with CT is recommended as underlying malignancy is not excluded.</text></section>

</component>

Figure 29 Impressions Example

3.4.4 DICOM Object Catalog – DCM 121181

A DICOM Object Catalog SHALL be present if the document contains references to DICOM Images, Structured Reports or other DICOM composite objects. The DICOM Object Catalog lists all referenced objects and their parent Series and Studies, plus other DICOM attriburtes required for retrieving the objects.

DICOM Object Catalog sections are not intended for viewing, and contain empty section text.



CONF-46: A DICOM Object Catalog section SHALL have an empty or absent section/text element.

Figure 30 below shows a sample of an Object Catalog section.



</component>

Figure 30 DICOM Object Catalog Example



3.5 Level 3 Content

A Diagnostic Imaging Report MAY contain CDA Entries that represent in coded form findings, image references, annotation and numeric measurements, equivalent to the body content in DICOM Structured Reporting documents as constrained in the IHE Simple Image and Numeric report (SINR) profile). IHE SINR is based on DICOM Basic Diagnostic Imaging Report (Template 2000), with the additional constraint that only the Enhanced SR Information Object Definition may be used.

DICOM Template 2000 defines imaging report documents comprising a number of optional sections, including those defined above under “Level 2 Content”. Each section contains,

Text Elements, optionally inferred from Report Observations

Code Elements, optionally inferred from Report Observations

Report observations

Template 2000 does not constrain the number or order of the elements and observations.

Each Report Observation is ONE of the following:

An Image reference (purpose of reference is Baseline, Best Illustration of Finding, Source of Measurement, or user extension),

A Linear Measurement, optionally inferred from an SCOORD referencing an image,

An Area Measurement, optionally inferred from an SCOORD referencing an image,

A Volume Measurement, optionally inferred from an SCOORD referencing an image, or

A Numeric measurement with a coded measurement type optionally inferred from an Image, or an SCOORD referencing an image

In all cases, the Level 3 content take the place of <entry> elements immediately following the Section/text closing bracket as illustrated in Figure 25.

3.5.1 Text Elements

Text entries MAY be present, and if present, shall contain the same text content as the Section.text. A Text entry is required if the findings in the the section text are represented as inferred from report observations. If a text entry is present, the entry SHALL have the same text content as the Section.text. The entry’s observation.text element SHOULD avoid replication of the text content by including it as a <reference> to tagged <content> in the Section.text.

<entry> <observation classCode="OBS" moodCode="EVN">



<code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"> </code> <text> <reference value="#finding1"/> </text>

<!— zero or more <entryRelationship> observations may appear here -->

</observation> </entry> </section> </component>

Figure 31 Text Element example

3.5.2 Code Elements

Text entries may be present, and if present, shall contain the same text content as the Section.text. A Text entry is required if the findings in the the section text are represented as inferred from report observations. If a text entry is present, the entry SHALL have the same text content as the Section.text. The entry’s observation.text element SHOULD avoid replication of the text content by including it as a <reference> to tagged <content> in the Section.text.

<entry> <observation classCode="OBS" moodCode="EVN"> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"> </code> <statusCode code='completed'/> <value xsi:type="CD" code="248649006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Hilar mass"/>

<!— zero or more <entryRelationship> observations may appear here -->

</observation> </entry> </section> </component>

Figure 32 Code Element example

3.5.3 Report Observations

Report Observations may be present as Entries, enclosed in <entry> … </entry> or as supporting observations in Text or Code entries, enclosed in <entryRelationship typeCode="SPRT"> … </entryRelationship>. Figures 25 and 25, below, illustrate these two placements, respectively.

<entry> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>  <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">  <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM">

<reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entry> </section> </component>

Figure 33 Report Observation as an Entry

<entry> <observation classCode="OBS" moodCode="EVN"> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"> </code> <text> <reference value="#finding1"/> </text>  <entryRelationship typeCode="SUBJ"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>  <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">  <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entryRelationship> </observation> </entry> </section> </component>

Figure 34 Report Observation as a support for an inferred finding

3.5.3.1 Report Observation – Image Reference

Image References indicate the image from which an observation was inferred or which a finding mentions.

<entryRelationship typeCode="SUBJ"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>  <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">  <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entryRelationship>

Figure 35 Image Reference Report Observation example

3.5.3.2 Report Observation – Linear Measurement

Linear Measurements represent distance between two points in the image.

 <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship>

Figure 36 Linear Measurement Report Observation example

3.5.3.3 Report Observation – Area Measurement

Area Measurements represent area within a region of interest in a image.

 <entryRelationship typeCode="SPRT">

<observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship>

Figure 37 Linear Measurement Report Observation example

3.5.3.4 Report Observation – Volume Measurement

Volume Measurements represent physical volumes within anatomical structures, as inferred from measurement s on the image or groups of images.

 <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship>

Figure 38 Volume Measurement Report Observation example

3.5.3.5 Report Observation – Numeric Measurement

Numeric Measurements may be derived from image characteristics, other than spatial measurements.

 <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText>

</code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship>

Figure 39 Numeric Measurement Report Observation example



4 ReferencesCDA Release 2.0 Clinical Document Architecture, Release 2.0, 2005, Health Level

Seven, Inc.

ISO-3166-1 Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes, 1997, International Organization for Standardization

ISO-639-1 Codes for the representation of names of languages--Part 1: Alpha-2 code, 2002, International Organization for Standardization

LOINC® Logical Observation Identifiers Names and Codes, Regenstrief Institute

RFC 2806 URLs for Telephone Calls, 2000, A. Vaha-Sipila, The Internet Society

RFC 2119 Key words for use in RFCs to Indicate Requirement Levels

RFC 3066 Tags for the Identification of Languages, 2001, H. Alvestrand, The Internet Society

Schematron The Schematron Assertion Language 1.5, 2002, Rick Jelliffe, Academia Sinica Computing Centre

SNOMED CT SNOMED Clinical Terms, 2002, SNOMED International Organization



http://www.snomed.org/snomedct/index.html

http://xml.ascc.net/resource/schematron/Schematron2000.html


http://www.ietf.org/rfc/rfc2119.txt


http://www.regenstrief.org/loinc

http://www.loc.gov/standards/iso639-2/langcodes.html


http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm

Appendix A — Validation

IntroductionThis appendix describes the vocabularies used or defined by this specification, and the Schematron schema that may be used to validate the content of the CDA Header for Diagnostic Imaging Report documents.

Administrative Gender

Administrative Gender codes used to describe the gender of the patient SHOULD come from the HL7 AdministrativeGender vocabulary. The OID for this vocabulary domain is 2.16.840.1.113883.5.1.

Code Display Name Description

F Female Female

M Male Male

UN Undifferentiated The gender of a person could not be uniquely defined as male or female, such as hermaphrodite.

Table 4 Administrative Gender

Ethnicity & Race

Ethnicity codes used to describe the ethnicity of the patient SHOULD come from the HL7 Ethnicity vocabulary. The OID for this vocabulary domain is 2.16.840.1.113883.5.50. This vocabulary is listed below. DICOM’s Patient Sex attribute is mapped to Administrative Gender.

Race codes used to describe the race of the patient SHOULD come from the HL7 Race vocabulary. This vocabulary is too extensive to list in this document. The OID for this vocabulary domain is 2.16.840.1.113883.5.104.

In the diagnostic reporting context, Race or Ethnicity as a CDA header component is a confirming demographic attribute usually inherited from information systems providing orders or ADT information. In any circumstance where race or ethnicity is clinically relevant to report content, Race or Ethnicity SHALL be explicitly mentioned in the report narrative.

Null Flavor

Null Flavors are used to indicate why a required data element does not contain any information.




HK: the use of the UNK null flavor is explained, others are not used

http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/Race.htm

http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/Ethnicity.htm

http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/AdministrativeGender.htm


NI NoInformation No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value.

OTH other The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).

NINF negative infinity Negative infinity of numbers.

PINF positive infinity Positive infinity of numbers.

UNK unknown A proper value is applicable, but not known.

ASKU asked but unknown Information was sought but not found (e.g., patient was asked but didn't know)

NAV temporarily unavailable Information is not available at this time but it is expected that it will be available later.

NASK not asked This information has not been sought (e.g., patient was not asked)

TRC trace The content is greater than zero, but too small to be quantified.

MSK masked There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.

Note: using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.

NA not applicable No proper value is applicable in this context (e.g., last menstrual period for a male).

NP not present Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults.

Table 5 Null Flavor



Participation Function

Participating function codes used to describe the exact function of a healthcare providers SHOULD come from the HL7 ParticipatingFunction vocabulary. This vocabulary is listed below. The OID for this vocabulary domain is 2.16.840.1.113883.5.88.


ADMPHYS admitting physician A physician who admitted a patient to a hospital or other care unit that is the context of this service.

ANRS anesthesia nurse In a typical anesthesia setting the nurse principally assisting the anesthesiologist during the critical periods.

ANEST anesthesist In a typical anesthesia setting an anesthesiologist or anesthesia resident in charge of the anesthesia and life support, but only a witness to the surgical procedure itself. To clarify responsibilities anesthesia should always be represented as a separate service related to the surgery.

ATTPHYS attending physician A physician who is primarily responsible for a patient during the hospitalization, which is the context of the service.

DISPHYS discharging physician A physician who discharged a patient from a hospital or other care unit that is the context of this service.

FASST first assistant surgeon In a typical surgery setting the assistant facing the primary surgeon. The first assistant performs parts of the operation and assists in others (e.g., incision, approach, electrocoutering, ligatures, sutures).

MDWF midwife A person (usually female) helping a woman deliver a baby. Responsibilities vary locally, ranging from a mere optional assistant to a full required participant, responsible for (normal) births and pre- and post-natal care for both mother and baby.

NASST nurse assistant In a typical surgery setting the non-sterile nurse handles material supply from the stock, forwards specimen to pathology, and helps with other non-sterile tasks (e.g., phone calls, etc.).

PCP primary care physician The healthcare provider that holds primary responsibility for the overall care of a patient.

PRISURG primary surgeon In a typical surgery setting the primary performing surgeon.

RNDPHYS rounding physician A physician who made rounds on a patient in a hospital or other care center.

SNRS scrub nurse In a typical surgery setting the nurse in charge of the instrumentation.

SASST second assistant surgeon In a typical surgery setting the assistant who primarily holds the hooks.

TASST third assistant In a typical surgery setting there is rarely a third assistant (e.g., in some Hip operations the third assistant postures the affected leg).

Table 6 Participating Function Codes



http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/ParticipatingFunction.htm

Appendix B — Sample Conforming CDA Document

The document below is a non-normative example of a Diagnostic Imaging Report that conforms to this specification. The file sampleDiagnosticImagingReport.xml included in this distribution is equivalent in content to this appendix.

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="CDASINR4.xsl"?><ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/><templateId root="2.16.840.1.113883.10" extension="CDAR2_II_BIMGRPTS_R1"/><id root="1.2.840.113619.2.62.994044785528.20060828170821659"/><code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Diagnostic Imaging Report"/><title>Chest X-Ray, PA and LAT View</title><effectiveTime value="20060828170821"/><confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code="en-US"/><recordTarget>

<patientRole><id root="1.2.840.113619.2.62.994044785528.10" extension="0000680029"/><patient>

<name><given>John</given><family>Doe</family>

</name><administrativeGenderCode codeSystem="2.16.840.1.113883.5.1" code="M"/><birthTime value="19641128"/>

</patient></patientRole>

</recordTarget><author>

<time value="20060823224352"/><assignedAuthor>

<id extension="121008" root="2.16.840.1.113883.19.5"/><assignedPerson>

<name><given>Richard</given>

<family>Blitz</family><suffix>MD</suffix>


</assignedAuthor></author><custodian>

<assignedCustodian>

<representedCustodianOrganization><id root="1.2.840.113619.2.62.994044785528"/><name>World University Hospital</name>

</representedCustodianOrganization></assignedCustodian>

</custodian><legalAuthenticator>

<time value="20060827141500"/><signatureCode code="S"/><assignedEntity>

<id extension="08150000" root="1.2.840.113619.2.62.994044785528.33"/><assignedPerson>

<name><given>Richard</given><family>Blitz</family><suffix>MD</suffix>


</assignedEntity></legalAuthenticator><participant typeCode="REF">

<associatedEntity classCode="PROV"><id nullFlavor="UNK"/><associatedPerson>

<name><given>John</given><family>Smith</family><suffix>MD</suffix>

</name></associatedPerson>

</associatedEntity></participant><inFulfillmentOf>

<order><id extension="10523475" root="1.2.840.113619.2.62.994044785528.27"/>

</order></inFulfillmentOf><documentationOf>

<serviceEvent classCode="ACT"><id root="1.2.840.113619.2.62.994044785528.114289542805"/>

<id extension="123453" root="1.2.840.113619.2.62.994044785528.26"/>

</serviceEvent></documentationOf><component>

<structuredBody><component>

<section>

<code code="18785-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Reason for study"/>

<text>Suspected lung tumor</text></section></component><component>

<section>

<code code="10164-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="History of present illness"/>

<text>Sore throat.</text></section><section>

<code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"/>

<text><content ID="finding1">The cardiomediastinum is within normal limits. The trachea is

midline. The previously described opacity at the medial right lung base has cleared. There are no new infiltrates. There is a new round density at the left hilus, superiorly (diameter about 45mm). A CT scan is

recommended for further evaluation. The pleural spaces are clear. The visualized musculoskeletal structures and the upper abdomen are stable and unremarkable.</content>

<content ID="finding2"> 45 mm diameter</content><content ID="finding3"> Image</content><linkHtml href="http://www.example.org/wado?

requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM" name="Computed Radiography Image Storage"/>

</text><entry>

<observation classCode="OBS" moodCode="EVN"><code code="18782-3" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC" displayName="Study observation"></code><text>

<reference value="#finding1"/></text><entryRelationship typeCode="SPRT">

<observation classCode="OBS" moodCode="EVN"><code code="M-02550" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNM3" displayName="Diameter"><originalText>

<reference value="#finding2"/></originalText>

</code><statusCode code="completed"/><effectiveTime value="20060823223912"/><value xsi:type="PQ" value="45" unit="mm">

<translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/>

</value></observation>

</entryRelationship><entryRelationship typeCode="SUBJ">

<observation classCode="DGIMG" moodCode="EVN"><id

root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/><code code="1.2.840.10008.5.1.4.1.1.1"

codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">

<originalText>

<reference value="#finding3"/></originalText>

</code><text xsi:type="ED" mediaType="application/DICOM">

<reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM"/>

</text><effectiveTime value="20060823223232"/>


</observation></entry>

</section><section>

<code code="19005-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="X-ray impression"/>

<text>No acute cardiopulmonary process. Round density in left superior hilus, further evaluation with CT is recommended as underlying malignancy is not excluded.</text>

</section><section classCode="DOCSECT" moodCode="EVN">

<code code="121181" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="DICOM Object Catalog"/>

<text/><entry>

<act classCode="ACT" moodCode="EVN">

<id root="1.2.840.113619.2.62.994044785528.114289542805"/><code code="113014" codeSystem="1.2.840.10008.2.16.4"

codeSystemName="DCM" displayName="Study"/><!--

*****************************************************************

Series ***************************************************************** -->

<entryRelationship typeCode="COMP"><act classCode="ACT" moodCode="EVN">

<id root="1.2.840.113619.2.62.994044785528.20060823223142485051"/><code code="113015" codeSystem="1.2.840.10008.2.16.4"

codeSystemName="DCM" displayName="Series"><qualifier>

<name code="121139" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Modality"> </name>

<value code="CR" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Computed Radiography"> </value>

</qualifier></code>

<entryRelationship typeCode="COMP">


root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/><code code="1.2.840.10008.5.1.4.1.1.1"


<originalText><reference value="#finding3"/>

</originalText></code><text xsi:type="ED" mediaType="application/DICOM">

<reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/DICOM"/>

</text><effectiveTime value="20060823223232"/>

</observation></entryRelationship><entryRelationship typeCode="COMP">


root="1.2.840.113619.2.62.994044785528.20060823.200608232231422.3"/><code code="1.2.840.10008.5.1.4.1.1.1"


<originalText><reference value="#finding4"/>

</originalText></code><text xsi:type="ED" mediaType="application/DICOM">