PS3.20

DICOM PS3.20 2017b - Imaging Reports using HL7 Clinical Document Architecture

DICOM Standards Committee


Table of Contents

Notice and Disclaimer
Foreword
1. Scope and Field of Application
2. Normative and Informative References
Bibliography
3. Definitions
3.1. Codes and Controlled Terminology Definitions:
3.2. Vocabulary Model Definitions:
3.3. Template Definitions
3.4. Imaging Report Definitions
4. Symbols and Abbreviations
5. Conventions
5.1. Template Metadata
5.1.1. Template IDs and Version
5.1.2. Context
5.1.3. Open and Closed Templates
5.2. Template Table Structure
5.2.1. Business Name
5.2.1.1. Multiple Instantiations
5.2.1.2. Implicit Element Structure For Business Name
5.2.2. Nesting Level
5.2.3. Element/Attribute Names and XPath Notation
5.2.4. Cardinality
5.2.5. Element/Attribute Conformance
5.2.6. Data Type
5.2.7. Value Conformance
5.2.8. Value Specification
5.2.8.1. Coded Simple Value
5.2.8.2. Concept Descriptor and Coded With Equivalents
5.2.8.3. Value Set
5.2.8.4. Concept Domains
5.2.8.5. Mapping From DICOM SOP Instances and HL7v2 Messages
5.2.9. Subsidiary Templates
5.2.9.1. Vocabulary Binding and Constraints
5.2.10. Additional Requirements
5.3. Encoding
5.3.1. Translation Code Element
5.3.2. Null Flavor
5.3.3. Unknown Information
5.3.4. XML ID
5.4. Extension and Namespace
5.5. Serialization Order of Elements
6. Conformance
7. Document-level Templates
7.1. Imaging Report
7.1.1. clinicalDocument/code
7.1.2. Addendum
7.2. Imaging Addendum Report
8. Header Content Templates
8.1. General Header
8.1.1. templateId - contentTemplate
8.1.2. title
8.1.3. effectiveTime
8.1.4. setID and versionNumber
8.1.5. recordTarget/patientRole
8.1.6. legalAuthenticator
8.1.7. recordTarget/patientRole/Patient/birthTime
8.1.8. author/assignedAuthor
8.1.9. InformationRecipient/intendedRecipient
8.2. Imaging Header
8.2.1. componentOf/encompassingEncounter
8.2.2. Physician of Record Participant
8.2.3. inFulfillmentOf/Order and @ID
8.2.4. documentationOf/serviceEvent
8.2.4.1. code and translation
8.2.4.2. Performer
8.3. Parent Document
8.3.1. relatedDocument
8.3.2. parentDocument/setId and versionNumber
9. Section-level Templates
9.1. General Requirements For Sections
9.1.1. Section Text
9.1.1.1. <content> Markup and Links From Entries
9.1.1.2. <linkHtml> Markup and Internal References
9.1.1.3. <renderMultiMedia> Markup and Graphical Content
9.1.1.4. <linkHtml> Markup and External References
9.1.1.5. <linkHtml> Markup and Image References
9.1.1.6. list
9.1.1.7. table
9.1.2. General Section Entries
9.1.2.1. templateId
9.1.2.2. author
9.1.2.3. section/entry
9.1.2.4. regionOfInterest
9.2. Clinical Information
9.3. Imaging Procedure Description
9.3.1. component/section Radiation Exposure and Protection Information
9.4. Comparison Study
9.5. Findings
9.5.1. text
9.6. Impression
9.7. Addendum
9.7.1. author
9.7.2. component/section - Communication of Actionable Findings
9.8. Sub-sections
9.8.1. Request
9.8.1.1. text/content and @ID – CDS Record
9.8.2. Procedure Indications
9.8.2.1. entry/observation
9.8.3. Medical (General) History
9.8.3.1. section/text
9.8.4. Complications
9.8.5. Radiation Exposure and Protection Information
9.8.5.1. text
9.8.5.2. entry/procedure Patient Exposure
9.8.5.3. entry/observation SOP Instance
9.8.5.4. entry/observation Pregnancy
9.8.5.5. entry/observation Indication
9.8.5.6. entry/observation Dose Measurements
9.8.6. Key Images
9.8.6.1. Section/text
9.8.6.2. SOP Instance Observation
9.8.6.3. observationMedia
9.8.7. DICOM Object Catalog
9.8.8. Fetus Findings
9.8.8.1. name - FetusID
9.8.9. Labeled Subsection
9.8.9.1. title
9.8.9.2. component/section Labeled Subsection
9.8.10. Communication of Actionable Findings
9.8.10.1. section/text/content - narrative
9.8.10.2. entry/act
9.8.10.3. entry/act/effectiveTime
9.8.10.4. entry/act/participant
9.8.11. Recommendation
9.8.11.1. text/content
9.8.11.2. entry/procedure
9.8.11.3. entry/procedure/code
9.8.11.4. entry/procedure/effectiveTime
9.8.11.5. entry/procedure/text/reference
10. Entry-level Templates
10.1. Coded Observation
10.1.1. code and @negationInd
10.1.2. text/reference and Related Narrative Block Markup
10.1.3. interpretationCode and translation For Actionable Findings
10.1.4. targetSiteCode
10.1.5. entryRelationship/@typeCode=SUBJ/observation - Coded
10.2. Procedural Medication
10.2.1. Business Name Alias
10.2.2. text/reference and Related Narrative Block Markup
10.2.3. doseQuantity
10.3. observationMedia
10.3.1. observationMedia/@ID and Related Narrative Block Markup
10.3.2. value and Reference
10.4. Procedure Technique
10.4.1. id
10.4.2. code
10.4.3. text/reference and Related Narrative Block Markup
10.4.4. methodCode - Modality
10.4.5. methodCode - Other Parameters
10.4.6. targetSiteCode and Laterality
10.4.7. participation - Location
10.5. Quantity Measurement
10.5.1. text/reference and Related Narrative Block Markup
10.5.2. interpretationCode and Translation For Actionable Findings
10.5.3. targetSiteCode
10.6. Study Act
10.6.1. entryRelationship/act - Series
10.7. Series Act
10.8. SOP Instance Observation
10.8.1. entryRelationship
10.8.1.1. entryRelationship/@typeCode=SUBJ (SOP Instance)
10.8.1.2. entryRelationship/@typeCode=RSON (Purpose of Reference)
10.8.1.3. entryRelationship/@typeCode=COMP (Referenced Frames)
10.9. Image Quality
10.9.1. text/reference and Related Narrative Block Markup
A. SR Diagnostic Imaging Report Transformation Guide
B. SR Diagnostic Imaging Report Transformation Guide
C. SR to CDA Imaging Report Transformation Guide
C.1. Constraints
C.2. Conventions
C.3. Header Transformation
C.4. Body Transformation
C.4.1. Section Mapping
C.4.1.1. Section Observer Context
C.4.1.2. Comparison Study Procedure Context
C.4.1.3. Fetus Subject Context
C.4.2. Section/text
C.4.3. Content Item Mapping
C.4.3.1. Coded Observations
C.4.3.2. Text Observations
C.4.3.3. Image Observations
C.4.3.4. Numeric Observations
C.4.3.5. Inferred From Image Observations
C.4.3.6. Inferred From Numeric Observations
C.4.3.7. Inferred From Spatial Coordinates Observations
C.4.4. Specific Section Content Mapping
C.4.4.1. Procedure Indications
C.4.4.2. Current Procedure Descriptions
C.4.4.3. Radiation Exposure and Protection Information
C.4.4.4. Key Images
C.5. Example
C.5.1. DICOM SR "Basic Diagnostic Imaging Report" (TID 2000)
C.5.2. Transcoded HL7 CDA Release 2 Imaging Report

List of Figures

C-1. TID 2000 Structure Summarized from PS3.16, and mapping to CDA

List of Tables

5.1-1. Template metadata table format
5.2-1. Template table format
5.2.3-1. Template element and attribute example
5.2.9.1-1. Vocabulary Binding Table Format
Cardiac Measurements
Current Lesion Sizes with Comparison to Exam on 2014/11/16
C.3-1. CDA Header content from SR
C.4-1. SR Section mapping to CDA
C.4-2. CDA Section mapping from SR
C.4-3. CDA Section author mapping from SR
C.4-4. Comparison Study mapping from SR
C.4-5. CDA Fetus subject mapping from SR
C.4-6. CDA Coded Observation mapping from SR CODE
C.4-7. CDA Coded Observation mapping from SR TEXT
C.4-8. CDA SOP Instance Observation mapping from SR IMAGE
C.4-9. CDA Quantity Measurement mapping from SR NUM
C.4-10. Clinical Information Procedure Indications mapping from SR
C.4-11. Current Procedure Description mapping from SR
C.4-12. CDA Radiation Exposure and Protection Information mapping from SR
C.4-13. Key Image mapping from SR
C.5-1. Sample document encoding

List of Examples

5.2.1.1-1. Example Business Name based production logic with discriminators for two measurements
5.2.3-1. XML document example
5.3.1-1. Translation code example
5.3.2-1. nullFlavor example
5.3.2-2. XML example of allowed nullFlavors when element is required
5.3.3-1. Unknown medication example
5.3.3-2. Unknown medication use of anticoagulant drug example
5.3.3-3. No known medications example
7.1.1-1. clinicalDocument/code example with translation element for local code
8.1.5-1. Header example
8.1.6-1. legalAuthenticator example
8.1.7-1. recordTarget example
8.1.8-1. Person author example
8.1.9-1. informationRecipient example
8.2.1-1. componentOf example
8.2.2-1. Physician of record participant example
8.2.3-1. inFulfillmentOf example
8.2.4.1-1. documentationOf example
8.2.4.2-1. Physician reading study performer example
8.2.4.2-2. participant example
8.2.4.2-3. dataEnterer example
8.3.2-1. relatedDocument example
9.1.1.4-1. Example - linkHtml references at point of use for RadLex
9.1.1.4-2. Example- linkHtml references at end of narrative block for RadLex
9.1.1.5-1. Example linkHtml reference for WADO image access
9.1.1.7-1. Measurements Table Example 1
9.1.1.7-2. Measurements Table Example 2
9.1.2.2-1. Author example
9.2-1. Clinical Information section example
9.3-1. Current Imaging Procedure description section example
9.4-1. Comparison study section example
9.5.1-1. Findings section example
9.6-1. Impression section example
9.7.2-1. Addendum section example
9.8.1.1-1. Request section example
9.8.2.1-1. Procedure indications section example
9.8.3.1-1. Medical (General) History section example
9.8.4-1. Complications section example
9.8.5.6-1. Radiation Exposure and Protection section example
9.8.6-1. Key Images section example
9.8.7-1. DICOM object catalog section example
9.8.8-1. Fetus Findings section example
9.8.9.2-1. Labeled sub-section example
9.8.10-1. Communication of Actionable Results section example
9.8.11-1. Radiology recommendation section example
10.1-1. Coded observation example
10.2-1. Procedural Medication activity example
10.3-1. Observation Media activity example
10.4-1. Procedure Technique template example
10.5-1. Quantity measurement observation example 1
10.5-2. Quantity measurement observation example 2
10.6-1. Study act example
10.7-1. Series act example
10.8-1. SOP instance observation example with purpose of reference
10.9-1. Image Quality example

Notice and Disclaimer

The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.

NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.

NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.

In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.

NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.

Foreword

This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.

The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].

DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information, all rights reserved.

HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.

SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology Standards Development Organisation (IHTSDO), all rights reserved.

LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.

1 Scope and Field of Application

This part of the DICOM Standard specifies templates for the encoding of imaging reports using the HL7 Clinical Document Architecture Release 2 (CDA R2, or simply CDA) Standard. Within this scope are clinical procedure reports for specialties that use imaging for screening, diagnostic, or therapeutic purposes.

This Part constitutes an implementation guide for CDA, and is harmonized with the approach to standardized templates for CDA implementation guides developed by HL7. It also provides Business Names for data elements that link data in user terminology, e.g., collected by a report authoring application, to specific CDA encoded elements.

As an implementation guide for imaging reports, particular attention is given to the use and reference of data collected in imaging procedures as explicit evidence within reports. This data includes images, waveforms, measurements, annotations, and other analytic results managed as DICOM SOP Instances. Specifically, this Part includes a specification for transformation into CDA documents of DICOM Structured Report instances that represent imaging reports.

2 Normative and Informative References

The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.

[ISO/IEC Directives, Part 2] ISO/IEC. 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .

ANSI/HL7 CDA®, R2-2005 HL7 Version 3 Standard: Clinical Document Architecture (CDA) Release 2, 2005 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7)

CDA® is a registered trademark of HL7 International.

ANSI/HL7 V3 CPPV3MODELS, R1-2012 HL7 Version 3 Standard: Core Principles and Properties of Version 3 Models, Release 1 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=58)

ANSI/HL7 V3 CMET, R2-2009 Health Level Seven Version 3 Standard: Common Message Element Types, Release 2, 2009.

ANSI/HL7 V3 DT, R1-2004 HL7 Version 3 Data Types Abstract Specification, Release 1 - November 2004. [Note: this specific release version is required by CDA R2]

ANSI/HL7 V3 XMLITSDT, R1-2004 HL7 Version 3 XML Implementation Technology Specification - Data Types, Release 1 - April 2004. [Note: this specific release version is required by CDA R2]

HL7 CDA R2 DIR IG, R1-2009 Health Level Seven Implementation Guide for CDA Release 2: Imaging Integration, Basic Imaging Reports in CDA and DICOM, Diagnostic Imaging Reports (DIR) Release 1.0 - Informative, 2009 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=13)

HL7 CDAR2_IG_IHE_CONSOL HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1.1 - US Realm, Draft Standard for Trial Use, July 2012 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258)

HL7 CDAR2_IG_CCDA_CLINNOTES_R2 HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes, Release 2 - US Realm, Draft Standard for Trial Use, November 2014 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=379)

HL7 CDAR2_IG_GREENMOD4CCD HL7 Implementation Guides for CDA® R2: greenCDA Modules for CCD®, Release 1 - Informative, April 2011(http://www.hl7.org/implement/standards/product_brief.cfm?product_id=136)

HL7 Templates HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 - DSTU, October 2014 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377)

HL7 CDA Digital Signatures HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1 - DSTU, October 2014 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=375)

HL7 v3-2014 HL7 Version 3 Interoperability Standards, Normative Edition 2014 (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=362]

IHE Card Sup CIRC IHE Cardiology Technical Framework Supplement, Cardiac Imaging Report Content, Trial Implementation, July 2011 (http://www.ihe.net/Technical_Frameworks/#cardiology)

IHE ITI TF IHE IT Infrastructure Technical Framework, Revision 11.0, September 2014 (http://www.ihe.net/Technical_Frameworks/#IT)

IHE PCC TF IHE Patient Care Coordination Technical Framework, Revision 10.0, November 2014 (http://www.ihe.net/Technical_Frameworks/#pcc)

IHE RAD TF IHE Radiology Technical Framework, Revision 13.0, July 2014 (http://www.ihe.net/Technical_Frameworks/#radiology)

LOINC Logical Observation Identifier Names and Codes, Regenstrief Institute, Indianapolis 2013.

This product includes all or a portion of the LOINC® table, LOINC panels and forms file, LOINC document ontology file, and/or LOINC hierarchies file, or is derived from one or more of the foregoing, subject to a license from Regenstrief Institute, Inc. Your use of the LOINC table, LOINC codes, LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file also is subject to this license, a copy of which is available at http://loinc.org/terms-of-use. The current complete LOINC table, LOINC Users' Guide, LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file are available for download at http://loinc.org. The LOINC table and LOINC codes are copyright © 1995-2013, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee. The LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file are copyright © 1995-2013, Regenstrief Institute, Inc. All rights reserved.

THE LOINC TABLE (IN ALL FORMATS), LOINC PANELS AND FORMS FILE, LOINC DOCUMENT ONTOLOGY FILE, AND LOINC HIERARCHIES ARE PROVIDED "AS IS." ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

LOINC® is a registered United States trademark of Regenstrief Institute, Inc. A small portion of the LOINC table may include content (e.g., survey instruments) that is subject to copyrights owned by third parties. Such content has been mapped to LOINC terms under applicable copyright and terms of use. Notice of such third party copyright and license terms would need to be included if such content is included.

RFC4646 Tags for Identifying Languages, The Internet Society, 2005

SNOMED CT® Systematized Nomenclature of Medicine - Clinical Terms, International Release, International Health Terminology Standards Development Organisation (IHTSDO), January 2015

SNOMED CT is a registered trademark of the International Health Terminology Standard Development Organisation (IHTSDO).

UCUM Unified Code for Units of Measure, Regenstrief Institute, Indianapolis 2013.

This product includes all or a portion of the UCUM table, UCUM codes, and UCUM definitions or is derived from it, subject to a license from Regenstrief Institute, Inc. and The UCUM Organization. Your use of the UCUM table, UCUM codes, UCUM definitions also is subject to this license, a copy of which is available at http://unitsofmeasure.org. The current complete UCUM table, UCUM Specification are available for download at http://unitsofmeasure.org. The UCUM table and UCUM codes are copyright © 1995-2013, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved.

THE UCUM TABLE (IN ALL FORMATS), UCUM DEFINITIONS, AND SPECIFICATION ARE PROVIDED "AS IS." ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

XML Extensible Markup Language (XML) 1.0 (Fifth Edition), World Wide Web Consortium, 2008 (http://www.w3.org/TR/REC-xml/)

XML Schema Datatypes XML Schema Part 2: Datatypes Second Edition, World Wide Web Consortium, 2004 (http://www.w3.org/TR/xmlschema-2/)

xml:id xml:id Version 1.0, World Wide Web Consortium, 2005 (http://www.w3.org/TR/xml-id)

XPath XML Path Language (XPath), Version 1.0, World Wide Web Consortium, 1999 (http://www.w3.org/TR/xpath/)

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 Codes and Controlled Terminology Definitions:

The following definitions are commonly used in this Part of the DICOM Standard:

Context Group

A set of coded concepts defined by a Mapping Resource forming a set appropriate to use in a particular context.

Context ID (CID)

Identifier of a Context Group.

Template

A pattern that describes the Content Items, Value Types, Relationship Types and Value Sets that may be used in part of a Structured Report content tree, or in other Content Item constructs, such as Acquisition Context or Protocol Context. Analogous to a Module of an Information Object Definition.

Template ID (TID)

Identifier of a Template.

Coding Schemes

Dictionaries (lexicons) of concepts (terms) with assigned codes and well defined meanings.

3.2 Vocabulary Model Definitions:

The following terms used in this Part of the DICOM Standard are defined in HL7 Core Principles and Properties of Version 3 Models:

Concept Domain

A named category of like concepts (a semantic type) that is specified in the vocabulary declaration of an attribute in an information model. It constrains the intent of the coded element while deferring the binding of the element to a specific set of codes until later in the specification process.

Value Set

A uniquely identifiable set of valid concept identifiers. Value sets constrain the permissible content for a coded element in an information model or data type specification.

Vocabulary Binding

The mechanism of identifying specific codes to be used to express the semantics of coded model elements in information models or coded data type properties. Vocabulary Binding may bind the coded element or data type property to a single fixed value code, or may bind it to a Value Set Assertion.

3.3 Template Definitions

The following term used in this Part of the DICOM Standard is defined in the HL7 Templates Standard, and applies to CDA template specifications:

Template

A set of conformance statements which further constrain an existing information model.

3.4 Imaging Report Definitions

The following definitions apply to terms used in this Part of the Standard:

Business Name

Identifier for a CDA Data Element, Attribute, or structure of Data Elements that corresponds to a business requirement for information exchange.

4 Symbols and Abbreviations

The following symbols and abbreviations are used in this Part of the Standard.

ANSI

American National Standards Institute

CDA

Clinical Document Architecture (HL7)

DICOM

Digital Imaging and Communications in Medicine

HL7

Health Level 7

HMD

Hierarchical Message Description (HL7)

IE

Information Entity

IHE

Integrating the Healthcare Enterprise

IOD

Information Object Definition

ISO

International Standards Organization

LOINC

Logical Observation Identifiers Names and Codes

MRRT

IHE Management of Radiology Report Templates Profile

NEMA

National Electrical Manufacturers Association

OID

Object Identifier (ISO 8824)

RSNA

Radiological Society of North America

SNOMED

Systematized Nomenclature of Medicine

SR

Structured Reporting

UCUM

Unified Code for Units of Measure

UID

Unique Identifier

XML

Extensible Markup Language

The following symbols and abbreviations for HL7 v3 Data Types are used in this Part of the Standard.

AD

Postal Address

CE

Coded With Equivalents

CD

Concept Descriptor

CS

Coded Simple Value

ED

Encapsulated Data

EN

Entity Name

II

Instance Identifier

INT

Integer Number

IVL<>

Interval

LIST<>

List

OID

ISO Object Identifier

ON

Organization Name

PN

Person Name

PQ

Physical Quantity

REAL

Real Number

ST

Character String

TEL

Telecommunication Address

TS

Point in Time

UID

Unique Identifier String

URL

Universal Resource Identifier

5 Conventions

5.1 Template Metadata

Each template has a set of metadata, as specified in the HL7 Templates Specification. The metadata is presented as a table, as shown in Table 5.1-1.

Table 5.1-1. Template metadata table format

Template ID

OID (see Section 5.1.1)

Name

Effective Date

Version Label

(see Section 5.1.1)

Status

"draft", "active", "review" or "retired"

Description

Classification

type of the template, e.g., CDA Section Level

Relationships

relationships to other templates or model artifacts

Context

"parent node", "sibling node" (see Section 5.1.2)

Open/Closed

"open", "closed"(see Section 5.1.3)

Revision History


5.1.1 Template IDs and Version

Template identifiers (templateId) are assigned for each document, section, and entry level template. When valued in an instance, the template identifier signals the imposition of a set of template-defined constraints. The value of this attribute (e.g., @root="2.16.840.1.113883.10.20.22.4.8") provides a unique identifier for the template in question.

A template may be further qualified by a version label. This label may be used as the extension attribute of the templateID (e.g., @extension="20150309"). All versions of a template, regardless of the version label, must be compatible; i.e., they may vary only by optional content conformance requirements. Thus the version label is typically not used as a conformance constraint.

Within this Standard, template versions are identified by the string "DICOM" and the date of adoption (represented as YYYYMMDD), separated by a hyphen (e.g., DICOM-20150523).

5.1.2 Context

As described in the HL7 Template specification section 2.9.9.4, the context identifies whether the template applies to the parent node in which the templateID is an element, or applies to its sibling nodes in the template table. These typically are applied respectively to templates with a single parent element with child element structure, and to templates with flat list of sibling elements (see Section 5.2.8).

5.1.3 Open and Closed Templates

Each template is defined as being either "open" or "closed". In "open" templates, all of the features of the CDA Specification are allowed except as constrained by the templates. By contrast, a "closed" template specifies everything that is allowed and nothing further may be included.

5.2 Template Table Structure

Each template is specified in tabular form, as shown in Table 5.2-1.

Table 5.2-1. Template table format

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Scoping​Business​Name

Element​Business​Name

Referenced​Business​Name


5.2.1 Business Name

This Part uses Business Names to identify and map common data elements from clinical imaging reports into the proper context-specific CDA/XML structure.

A Business Name is assigned to each element or attribute that may have a user-specified value assigned in the production of the clinical document instance. Business Names are specified to facilitate the implementation of production logic for clinical report authoring applications. The benefit is that developers of clinical report authoring applications are not required to have an in depth knowledge of CDA, the HL7 v3 R-MIM data model, or the XML structures. The use of readable and intuitive Business Names provides a method of direct access to insert data that is specific to each clinical report instance.

Note

Business Names are also described in the HL7 greenCDAModules for CCD specification, but that specification implies the use of a specific XML structure for production logic that is not required by this Part. The specification of production logic using Business Names is outside the scope of this Part.

Business Names are not specified for elements that are expected to receive an automatically generated value, e.g., the id element for each document, section, and entry.

As a convention, Business Names are represented in CamelCase (alternating upper and lower case, no spaces, initial letter in upper case) in the Business Name column of the template tables.

Business Names are hierarchically organized, and contextually scoped by higher level Business Names.

  • Data element/attribute level Business Names are shown in normal font

  • Business Names that provide scoping for subsidiary Business Names are shown in bold font.

  • Referenced Business Names from included templates are shown in italic (see Section 5.2.9)

  • As a convention, hierarchical relationship between Business Names is shown with the : character.

Scoping Business Names scope all attributes and elements subsidiary to the element to which the name is assigned.

Examples:

  • The top level scoping Business Name for an Imaging Report is "ImagingReport", and it scopes all attributes and elements in the document, i.e., including and subsidiary to the <ClinicalDocument> XML element

  • The Business Name for the 9.2 Clinical Information report section is "ImagingReport:ClinicalInformation", and it scopes all attributes and elements including and subsidiary to the <section> XML element in template 1.2.840.10008.9.2

  • The Business Name for the text element of the 9.2 Clinical Information report section is "ImagingReport:ClinicalInformation:Text"

  • The Business Name for the text element of the 9.6 Impression section is "ImagingReport:Impression:Text"

Note that both 9.2 Clinical Information and 9.6 Impression define a Business Name "Text", but these are distinguished by their hierarchical location under the scoping Business Names of their respective sections.

5.2.1.1 Multiple Instantiations

Some templates may be invoked multiple times in a document instance; for example, the 10.5 Quantity Measurement template is instantiated for each numeric measurement in a report. Each instantiation shall have an identifying string, unique within the document, used as a discriminator between those multiple instantiations. The Business Name for each element that may have multiple instantiations has a suffix [*], indicating the use of a discriminator string. This allows Business Name based production logic for authoring applications to identify specific instances of an element.

Example 5.2.1.1-1. Example Business Name based production logic with discriminators for two measurements

-- "Q21a" is the discriminator for the first measurement
-- "Q21b" is the discriminator for the second measurement
ImagingReport:Findings:QuantityMeasurement[Q21a]:MeasurementName = ("112058", "DCM", "Calcium score")
ImagingReport:Findings:QuantityMeasurement[Q21a]:MeasurementValue = "8"
ImagingReport:Findings:QuantityMeasurement[Q21a]:MeasurementUnits = "[arb'U]"
ImagingReport:Findings:QuantityMeasurement[Q21b]:MeasurementName = ("408716009", "SNOMED", "Stenotic lesion length")
ImagingReport:Findings:QuantityMeasurement[Q21b]:MeasurementValue = "14"
ImagingReport:Findings:QuantityMeasurement[Q21b]:MeasurementUnits = "mm"

The discriminator string shall be conformant to XML Name production requirements, as used for the XML ID attribute (see Section 5.3.4 on the use of XML ID).

Some CDA elements may include an XML ID attribute. This attribute is identified by '*' (asterisk) as its Business Name, and its value shall be the discriminator string.

5.2.1.2 Implicit Element Structure For Business Name

A Business Name may be associated with an element subsidiary to another element that does not have an associated Business Name. In such a case, when the element with the Business Name is instantiated in a document, its entire parent element hierarchy must be instantiated, even if those elements are identified as optional.

Note

For example, in the 8.1 General Header template, if Recipient:Name is instantiated, the entire hierarchical structure of informationRecipient/intendedRecipient/informationRecipient/name must be instantiated to hold the name element content.

5.2.2 Nesting Level

CDA documents are encoded using the Extensible Markup Language (XML), and are marked up through hierarchically nested XML elements (tags). The Nesting Level column of the template tables identifies the hierarchical level of each element relative to the other elements in the table using the character right angle bracket '>'. Multiple levels of nesting are identified by multiple > characters.

XML elements may have attributes, encoded as "<name>=<value>" pairs within the element tag. Such attributes are identified using the character at sign '@'.

5.2.3 Element/Attribute Names and XPath Notation

The name of each XML element and attribute used in a CDA document for which specific constraints are applied is shown in the Element/Attribute column of the template tables. Optional elements whose use is not specified nor constrained are not shown.

Elements and attributes that use the default value specified in CDA Specification are not shown. For example, the Section element has default attributes classCode='DOCSECT' and moodCode='EVN'; these are not listed in the templates. In accordance with the HL7 v3 specification, attributes with default values need not be included in instances, and their absence implies the default value.

XML Path Language (XPath) notation is used 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 node of the document, and traversing the path to the root node of the relevant template. This notation provides a mechanism that will be familiar to developers for identifying parts of an XML document.

XPath syntax selects nodes from an XML document using a path containing the context of the node(s). The path is constructed from node names and attribute names (prefixed by a '@') and concatenated with a '/' symbol.

Example 5.2.3-1 is an example of a fragment of a CDA document.

Example 5.2.3-1. XML document example

<author>
    <assignedAuthor>
        ...
        <code codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'
                code='17561000' displayName='Cardiologist' />
            ...
        </assignedAuthor>
    </author>

Table 5.2.3-1 is an example of a fragment of a template specification table.

Table 5.2.3-1. Template element and attribute example

Nest Level

Element/​Attribute

author

>

assigned​Author

>>

code

>>@

@codeSystem

>>@

@codeSystemName

>>@

@code

>>@

@displayName


In Table 5.2.3-1, the code attribute of the code element could be selected with the XPath expressionauthor/assignedAuthor/code/@code.

5.2.4 Cardinality

Each element/attribute has a cardinality indicator that specifies the number of allowable occurrences within a template instance. The cardinality indicators are interpreted with the following format "m…n" where m represents the least and n the most:

  • 0..1 zero or one

  • 1..1 exactly one

  • 1..* at least one

  • 0..* zero or more

  • 1..n at least one and not more than n

  • 0..0 none [SHALL NOT]

5.2.5 Element/Attribute Conformance

Each element/attribute has a conformance verb (keyword) in addition to the cardinality constraint.

The keywords SHALL, SHOULD, MAY, SHOULD NOT, SHALL NOT, and NEED NOT in this document are to be interpreted as described in ISO/IEC Directives, Part 2, Annex H "Verbal forms for the expression of provisions":

  • SHALL: an absolute requirement

  • SHALL NOT: an absolute prohibition against inclusion

  • SHOULD/SHOULD NOT: a best practice or recommendation. There may be valid reasons to ignore a recommendation, but the full implications must be understood and carefully weighed before choosing to not adhere to the best practice.

  • MAY/NEED NOT: truly optional; can be included or omitted at the discretion of the content creator with no conformance implications

The keyword SHALL is associated with a minimum cardinality of at least 1; other keywords have a minimum cardinality of 0. If an element is required by SHALL, but is not known (and would otherwise be omitted without the SHALL requirement), it must be represented by a nullFlavor. SHALL allows the use of nullFlavor unless the requirement is on an attribute (nullFlavor does not apply to attributes), or the use of nullFlavor is explicitly precluded (see Section 5.2.7 Value Conformance and Section 5.3.2 Null Flavor).

Within the template, the keyword COND (conditional) may be present. In this case, the specification of the condition, and the conformance verbs associated with the condition being true or false, are described below the table in a paragraph flagged with the COND keyword.

In an open template, additional elements and attributes allowed by the CDA Specification are not precluded by template constraints, unless there are applicable SHALL NOT template specifications.

5.2.6 Data Type

The data type associated with each element/attribute is specified, as described in the CDA Specification and its referenced HL7v3 Data Types Release 1. Elements that are simply tags with subsidiary content only of nested elements, e.g., RIM class clone names, have the Data Type column empty.

Many data types are non-primitive, and may include constituent component elements and/or attributes. Such subsidiary components are not specified in the templates unless specific constraints are to be applied to them.

5.2.7 Value Conformance

The template table may constrain values or vocabularies to be used with an element or attribute. Value constraints include a conformance verb (SHALL, SHOULD, MAY, etc.) as defined in Section 5.2.5, and specified in the Value Conformance column of the template tables.

Elements for which nullFlavor is forbidden are indicated with an additional constraint keyword noNull.

Additionally, constraints specifying Value Sets include a coding strength conformance CWE (Coded With Extensibility) or CNE (Coded with No Extensibility), as defined in Core Principles and Properties of HL7 Version 3 Models, Release 1.

Further, Value Set constraints can be static, meaning that they are bound to a specified version of a Value Set, or dynamic, meaning that they are bound to the most current version of the Value Set. By default, Value Sets have dynamic binding, unless explicitly specified with an additional constraint keyword static.

5.2.8 Value Specification

The template table may constrain values to a single fixed value, to a Value Set from which the value is to be drawn, or to a named Concept Domain. It may non-normatively reference a mapping from a DICOM SOP Instance or an HL7 message.

The template table may contain elements without a value specification, and without a Business Name. These are typically id elements. The application creating the document instance shall fill these elements with appropriate values.

5.2.8.1 Coded Simple Value

Values of Data Type CS (Coded Simple Value) have a fixed code system defined in the CDA Specification, and are simple strings. The template tables identify only the constraint on the code value, and do not specify the fixed code system nor the code meaning (display name), which are not encoded in the CDA instance.

5.2.8.2 Concept Descriptor and Coded With Equivalents

Single values of Data Type CD (Concept Descriptor) or CE (Coded With Equivalents) are specified in the template tables with the triplet notation specified in PS3.16:

  • (CodeValue, Coding Scheme Designator, "Code Meaning")

The Coding Scheme Designator is a simple human readable identifier of the code system, and corresponds to the optional codeSystemName attribute of the CD or CE element. The CDA Specification requires the Code System OID to be encoded in the codeSystem attribute of the CD or CE element. The corresponding OID for each Coding Scheme Designator is provided in Annex 8 “Coding Schemes” in PS3.16. The Code Meaning is encoded in the displayName attribute of the CD or CE element.

5.2.8.3 Value Set

Elements whose value may be drawn from a Value Set will have that Value Set identified in the Value column introduced by the keyword ValueSet.

5.2.8.4 Concept Domains

Concept Domains (see definition in Section 3.2) are used to provide a named category in a structural template that can be bound to a specific value or value set by an invoking template, thus specializing the structural template for a particular use case. Concept Domain names are introduced by the keyword ConceptDomain in the Value column. For example, the 10.5 Quantity Measurement template Concept Domain "observationType" might be bound to a value set of fetal ultrasound measurements in one invoking template, or to a value set of cardiac CT measurements in another invoking template.

Concept Domain names are similar to element Business Names in that they provide a public interface that is bound to specific values later in the document specification and production process. Concept Domains do not have a Value Conformance verb; the conformance verb is specified when the Concept Domain is bound to a specific value or value set (see Section 5.2.9.1).

5.2.8.5 Mapping From DICOM SOP Instances and HL7v2 Messages

Elements whose value may be mapped from a DICOM SOP Instance or from an HL7v2 message have the source attribute name and tag identified in the Value column in italic font. Note that many of these values have their origin in IT systems outside the imaging department, and there may be alternate routes for these values to be accessed by the reporting application, e.g., from an HL7 FHIR web service.

Note

Due to differences in use of HL7v2 data elements, mappings should not be considered normative.

Data mapped from a specific Attribute in the interpreted DICOM image(s) is identified by the Attribute Name and Tag, represented in the mapping as:

  • Attribute Name (gggg,eeee)

Data mapped from Attributes within sequences is identified with the > character:

  • Sequence Attribute Name (ggg0,eee0) > Item Attribute Name (ggg1,eee1)

Data mapped from an HL7v2 field in the order for the study is identified by the Element Name and Segment Field identifier:

  • Element Name seg-n

The mapping of the value typically requires a transformation from the DICOM Value Representation or the HL7v2 Data Type representation to the CDA Data Type encoding. For example, transforming a DICOM Code Sequence attribute or an HL7v2 CWE field to a CD or CE Data Type requires a look up of the Coding Scheme OID.

5.2.9 Subsidiary Templates

A template may include subsidiary templates. Templates typically have one of two styles, a single parent element with child element structure, or a flat list of sibling elements.

The single parent element style is typical for the top level Document, Section, and Entry templates, and the parent element is of the HL7 v3 RIM act class. Inclusion of such a template therefore involves an actRelationship element; that actRelationship element is specified in the invoking template.

The sibling elements style is typical for sets of elements and attributes aggregated for editorial convenience.

Inclusion of a subsidiary template includes the name of included template and its templateID, specified in the Subsidiary Template column of the invoking template table.

For an included template of the single parent element style, the scoping business name and top level element are provided in italics in the invoking template table. This indicates this is data copied from the specification in the included template for the reader's convenience.

5.2.9.1 Vocabulary Binding and Constraints

A template inclusion may provide Concept Domain Vocabulary Binding or other vocabulary constraints, e.g., limiting an element in the included template to a specific value from its defined Value Set. These vocabulary constraints are specified in tabular form, as shown in Table 5.2.9.1-1. The table is included in the additional requirements for the template, with a reference in the Value column of the template entry invoking the subsidiary template. The Value Conformance and Value specification columns are interpreted as in the templates tables.

Table 5.2.9.1-1. Vocabulary Binding Table Format

Concept Domain or Element

Value Conf

Value

...

...

...


5.2.10 Additional Requirements

Each template may be accompanied by additional requirements and usage explanations in narrative specification language.

5.3 Encoding

A full discussion of the representation of data types and vocabulary is outside the scope of this document; for more information, see the HL7 V3 specifications on Abstract Data Types R1 and XML Data Types R1 referenced in the CDA Specification.

Note

  1. Many Data Types encode their values in attributes, rather than character data. For example, the URL Data Type encodes its value in the value attribute within the element tag, e.g., <reference value="http://xyz.org">. Within this specification, the attribute(s) that hold the value are not identified, except where specific constraints apply.

  2. The Consolidated CDA specification includes extensive examples of valid and invalid encodings, which may be useful for implementers.

  3. The specification of a representation of Data Types for use in Business Name-based report production logic is outside the scope of this Standard.

5.3.1 Translation Code Element

HL7 Data Types CD (Concept Descriptor) and CE (Coded With Equivalents) allow a translation code element, which allows the encoding of the same concept in an alternate coding system. This supports the encoding of both an originally entered (local) code, and a code specified for cross-system interoperability.

This Part follows the convention used in the Consolidated CDA Implementation Guide specification, which specifies the standard interoperable code in the root, whether it is original or a translation. The HL7v3 Data Types R1 standard included by CDA formally specifies the original code (as initially entered in an information system application) to be placed in the root.

Note

This discrepancy is resolved in HL7v3 Data Types R2 to follow the convention used here, and the HL7 Structured Documents Working Group has approved the "pre-adoption" of the Data Types R2 approach in CDA implementations.

Example 5.3.1-1. Translation code example

<code code='206525008'
      displayName='neonatal necrotizing enterocolitis 'codeSystem='2.16.840.1.113883.6.96'
      codeSystemName='SNOMED CT'>
    <translation code='NEC-1'
      displayName='necrotizing enterocolitis'
      codeSystem='2.16.840.1.113883.19'/>
</code>

5.3.2 Null Flavor

Information technology solutions store and manage data, but sometimes data are not available: an item may be unknown, not relevant, or not computable or measurable. In HL7 v3, a flavor of null, or nullFlavor, describes the reason for missing data.

For example, if a patient arrives at an Emergency Department unconscious and with no identification, a null flavor is used to represent the lack of information. The patient's birth date could be represented with a null flavor of "NAV", which is the code for "temporarily unavailable". When the patient regains consciousness or a relative arrives, we expect to be able to obtain the patient's birth date.

Example 5.3.2-1. nullFlavor example

<birthTime nullFlavor="NAV"/> <!--coding an unknown birthdate-->

Use null flavors for unknown, required, or optional attributes:

NI

No information. This is the most general and default null flavor.

NA

Not applicable. Known to have no proper value (e.g., last menstrual period for a male).

UNK

Unknown. A proper value is applicable, but is not known.

ASKU

Asked, but not known. Information was sought, but not found (e.g., the patient was asked but did not know).

NAV

Temporarily unavailable. The information is not available, but is expected to be available later.

NASK

Not asked. The patient was not asked.

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.

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).

The above null flavors are commonly used in clinical documents. For the full list and descriptions, see the nullFlavor vocabulary domain in the HL7 v3 Vocabulary referenced by the CDA specification.

Any SHALL conformance requirement on an element may use nullFlavor, unless nullFlavor is explicitly disallowed (as indicated by noNull, see Section 5.2.7 Value Conformance). SHOULD and MAY conformance requirements may also use nullFlavor. nullFlavor does not apply to conformance requirements on attributes.

The encoding of nullFlavor as an attribute of the data type element is not shown in the templates, hence there is no business name associated with the attribute.

Note

Production logic based on Business Names needs to provide a mechanism for assignment of a value to the nullFlavor attribute as an alternative for a value for the element. Specification of such production logic is outside the scope of this Standard.

Example 5.3.2-2. XML example of allowed nullFlavors when element is required

<entry>
    <observation classCode="OBS" moodCode="EVN">
        <id nullFlavor="NI"/>
        <code nullFlavor="OTH">
            <originalText>New Grading system</originalText>
        </code>
        <statusCode code="completed"/>
        <effectiveTime nullFlavor="UNK"/>
        <value xsi:type="CD" nullFlavor="NAV">
            <originalText>Spiculated mass grade 5</originalText>
        </value>
    </observation>
</entry>

5.3.3 Unknown Information

If a document creator wants to state that a piece of information is unknown, the following principles apply:

  1. If the creator doesn't know an attribute of an act, that attribute can be null.

    Example 5.3.3-1. Unknown medication example

    <text>patient was given a medication but I do not know what it was</text>
    <entry>
        <substanceAdministration moodCode="EVN" classCode="SBADM">
            <consumable>
                <manufacturedProduct>
                    <manufacturedLabeledDrug>
                        <code nullFlavor="NI"/>
                    </manufacturedLabeledDrug>
                </manufacturedProduct>
            </consumable>
        </substanceAdministration>
    </entry>

  2. If the creator doesn't know if an act occurred, the nullFlavor is on the act (detail could include specific allergy, drug, etc.).

    Example 5.3.3-2. Unknown medication use of anticoagulant drug example

    <text>I do not know whether or not patient received an anticoagulant drug</text>
    <entry></para>
        <substanceAdministration moodCode="EVN" classCode="SBADM" nullFlavor="NI">
            <consumable>
                <manufacturedProduct>
                    <manufacturedLabeledDrug>
                        <code code="81839001" displayName="anticoagulant drug"
                            codeSystem="2.16.840.1.113883.6.96"
                            codeSystemName="SNOMED CT"/>
                    </manufacturedLabeledDrug>
                </manufacturedProduct>
            </consumable>
        </substanceAdministration>
    </entry>

  3. If the sender wants to state 'no known', a negationInd can be used on the corresponding act (substanceAdministration, Procedure, etc.)

    Example 5.3.3-3. No known medications example

    <text>No known medications</text>
    <entry>
        <substanceAdministration moodCode="EVN" classCode="SBADM" negationInd="true">
            <consumable>
                <manufacturedProduct>
                    <manufacturedLabeledDrug>
                        <code code="410942007" displayName="drug or medication"
                            codeSystem="2.16.840.1.113883.6.96"
                            codeSystemName="SNOMED CT"/>
                    </manufacturedLabeledDrug>
                </manufacturedProduct>
            </consumable>
        </substanceAdministration>
    </entry>

Other CDA implementation guides recommended using specific codes to assert no known content, for example SNOMED CT 160244002 "No known allergies" or 160245001 "No current problems or disability". Specific codes are still allowed; however, use of negationInd is an alternative, and the specific approach for each use will be specified in the associated template.

5.3.4 XML ID

The XML Specification allows a markup tag to have an attribute of type ID, whose value is unique within the document, that allows reference to that markup. The CDA schema defines such attributes with attribute name ID.

Note

  1. Thus the attribute named ID is of XML attribute type ID. This must further be distinguished from the element named id of HL7v3 Data Type UID that is part of most RIM classes. The attribute name is always upper case, the element name is always lower case.

  2. The actual CDA schema specification uses the XML Schema Datatypes definition of XML ID (xs:ID). Readers may also be familiar with the xml:id specification, which is not formally used by CDA as it was published after the CDA specification.

In the CDA R2 Specification, the XML ID attribute capability is applied to the Section and observationMedia elements, and to various types of narrative block markup, and is used to provide linkage between structured entries and the corresponding narrative text (see Section 9.1.1 Section Text).

5.4 Extension and Namespace

In accordance with CDA R2 (and HL7 v3 XML) extensibility rules, as described in CDA R2 Section 1.4, "locally-defined" XML markup may be specified where there is a need to communicate information for which there is no suitable representation in CDA R2. These extensions are described in the context of the templates where they are used. All such extensions use HL7 v3 Data Types used by CDA R2.

Note

The HL7 Structured Documents Working Group coordinates markup extensions that have been defined for implementation guides published by HL7, IHE, DICOM, and other organizations. See http://wiki.hl7.org/index.php?title=CDA_R2_Extensions

The namespace for extensions defined in this standard is "urn:dicom-org:ps3-20", which is aliased in this standard as "ps3-20". Extensions defined in this standard are:

  • ps3-20:accessionNumber - The accessionNumber extension allows for the clear identification of the imaging department identifier for a service request (order). While this identifier could be conveyed as another id for the inFulfillmentOf/Order element, there is no reliable way in that context to distinguish it from the Placer Order Number. As this is a primary management identifier in departmental workflows, a distinct local markup is defined. This extension uses the II Data Type.

The namespace for extensions defined by HL7 is "urn:hl7-org:sdtc". which is aliased in this standard as "sdtc". HL7 defined extensions used in this standard are:

  • sdtc:signatureText - Provides a location for a textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act as specified in the Participation.typeCode. Details of the element content are described in the HL7 CDA Digital Signature Standard. This extension uses the ED Data Type.

5.5 Serialization Order of Elements

The CDA schema requires elements to be encoded in a specified order, which may be different than the order in which they are described in the templates. The serialization of elements shall be in accordance with the HL7 CDA Hierarchical Description. In particular, attention must be paid to the serialization order of elements defined in sibling templates (see Section 5.1.2).

Note

For example, the various header templates are siblings, specifying sets of elements at the same hierarchical level. These elements of different templates must be encoded in their appropriate serialized order in the object instance - all templateID elements from the document template and all header templates first, followed by the elements of the clinicalDocument class in their prescribed order, followed by the participations in their prescribed order, followed by act relationships in their prescribed order.

6 Conformance

The CDA specification section 1.3 provides conformance requirements for Document Originators and Document Recipients.

Note

  1. Consolidated CDA Implementation Guide Section 2.8 includes recommended best practices for Document Recipients displaying CDA documents.

  2. There may be other CDA-related standards to which an application may claim conformance. For example, IHE Patient Care Coordination Technical Framework specifies a Document Consumer actor with four options for conformance.

A CDA document instance in accordance with this Standard asserts its conformance to a template by inclusion of the specified templateID elements in the document, sections, and entries.

7 Document-level Templates

Document-level templates describe the purpose and rules for constructing a conforming CDA document. Document templates include constraints on the CDA header and sections by referring to templates, and constraints on the vocabulary used in those templates.

7.1 Imaging Report

Template ID

1.2.840.10008.9.1

Name

Imaging Report

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

This CDA Imaging Report document template defines the report content and technical constraints for top level elements, attributes, sections, and entries to be used in imaging report instances. This template may apply to screening, diagnostic, or therapeutic radiology, cardiology, or other imaging reports.

The body of an Imaging Report may contain five main imaging report sections:

  • Clinical information (optionally);

  • Current imaging procedure description;

  • Comparison studies (optionally);

  • Findings (optionally);

  • Impression;

  • plus potentially an Addendum(s)

The report templates sponsored by the RSNA Radiology Reporting Initiative (http://www.radreport.org) adhere to this general section outline.

Classification

CDA Document Level

Relationships

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Imaging​Report

Clinical​Document

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.1

Doc​Type

>

code

1..1

SHALL

CD

SHALL CWE noNull

ValueSet LOINC Imaging Document Codes 1.3.6.1.4.1.12009.10.2.5

>

1..1

SHALL

8.1 General Header 1.2.840.10008.9.20

>

1..1

SHALL

8.2 Imaging Header 1.2.840.10008.9.21

>

0..1

MAY

8.3 Parent Document 1.2.840.10008.9.22

>

component

1..1

SHALL

>>

structured​Body

1..1

SHALL

>>>

component

0..1

MAY

Clinical​Information

>>>>

section

9.2 Clinical Information 1.2.840.10008.9.2

>>>

component

1..1

SHALL

Procedure​Description

>>>>

section

9.3 Imaging Procedure Description 1.2.840.10008.9.3

>>>

component

0..1

MAY

Comparison​Study

>>>>

section

9.4 Comparison Study 1.2.840.10008.9.4

>>>

component

0..1

MAY

Findings

>>>>

section

9.5 Findings 2.16.840.1.113883.​10.20.6.1.2

>>>

component

1..1

SHALL

Impression

>>>>

section

9.6 Impression 1.2.840.10008.9.5

>>>

component

0..*

COND

Addendum[*]

>>>>

section

9.7 Addendum 1.2.840.10008.9.6

7.1.1 clinicalDocument/code

Most of the codes in Value Set LOINC Imaging Document Codes are pre-coordinated with the imaging modality, body part examined, and/or specific imaging method. When pre-coordinated codes are used, any coded values elsewhere in the document describing the modality, body part, etc., must be consistent with the document type code. Local codes used for report types may be included as a translation element in the code.

Note

Use of Value Set LOINC Imaging Document Codes is harmonized with HL7 Consolidated CDA Templates for Clinical Notes, Release 2. DICOM CID 7001 “Diagnostic Imaging Report Headings”, used in TID 2000 “Basic Diagnostic Imaging Report”, is a subset of the LOINC Imaging Document Codes.

Example 7.1.1-1. clinicalDocument/code example with translation element for local code

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

7.1.2 Addendum

COND: If the header includes a relatedDocument element with typeCode RPLC, and the replaced document had a legalAuthenticator element (i.e., was signed), the component/structuredBody SHALL contain at least one 9.7 Addendum.

7.2 Imaging Addendum Report

Template ID

1.2.840.10008.​9.24

Name

Imaging Addendum Report

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

Document structure for an Imaging Addendum Report, i.e., an appendage to an existing report document that contains supplemental information. The parent document content remains unaltered. The Addendum Report must be read together with its parent document for full context. Some institutions may have policies that forbid the use of Addendum Reports, and require revised reports with a complete restatement of the original documentation.

Classification

CDA Document Level

Relationships

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Imaging​Addendum

Clinical​Document

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.1

Doc​Type

>

code

1..1

SHALL

CD

SHALL CWE noNull

ValueSet LOINC Imaging Document Codes 1.3.6.1.4.1.12009.10.2.5

>

1..1

SHALL

8.1 General Header 1.2.840.10008.9.20

>

1..1

SHALL

8.2 Imaging Header 1.2.840.10008.9.21

>

related​Document

1..1

SHALL

>@

@typecode

1.1

SHALL

CS

SHALL

APND

>>

parent​Document

1..1

SHALL

Amended​Document​ID

>>>

id

1..1

SHALL

II

>

component

1..1

SHALL

>>

structured​Body

1..1

SHALL

>>>

component

1..*

SHALL

Addendum[*]

>>>>

section

9.7 Addendum 1.2.840.10008.9.6

8 Header Content Templates

8.1 General Header

Template ID

1.2.840.10008.9.20

Name

General Header Elements

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

CDA Header Elements for all documents, including primary participations

Classification

CDA Header Elements

Relationships

Included in all document level templates

Context

sibling node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

template​Id

1..1

SHALL

II

@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.20

Content​Template

template​Id

0..*

MAY

II

type​Id

1..1

SHALL

II

@

@root

1..1

SHALL

UID

SHALL

2.16.840.1.113883.​1.3

@

@extension

1..1

SHALL

ST

SHALL

POCD_HD000040

id

1..1

SHALL

II

Title

title

1..1

SHALL

ST

Creation​Time

effective​Time

1..1

SHALL

TS

Confidentiality

confidentiality​Code

1..1

SHALL

CE

SHALL CWE

ValueSet x_BasicConfidentialityKind Value Set 2.16.840.1.113883.11.16926

Language​Code

language​Code

1..1

SHALL

CS

SHALL CNE

ValueSet CID 5000 “Languages”

Set​Id

set​Id

0..1

MAY

II

Version​Number

version​Number

1..1

COND

INT

Patient[*]

record​Target

1..*

SHALL

>

patient​Role

1..1

SHALL

>>

id

1..*

SHALL

II

IDIssuer

>>@

root

1..1

SHALL

UID

Issuer of Patient ID Qualifiers Sequence (0010,0024) > Universal Entity ID (0040,0032)

Patient ID List PID-3.4.2

ID

>>@

extension

1..1

SHALL

ST

Patient ID (0010,0020)

Patient ID List PID-3.1

Addr

>>

addr

1..*

SHALL

AD

Tele

>>

telecom

1..*

SHALL

TEL

>>

patient

1..1

SHALL

Name

>>>

name

1..1

SHALL

PN

Patient's Name (0010,0010)

Patient Name PID-5

Gender

>>>

administrative​Gender​Code

1..1

SHALL

CE

SHALL CNE

ValueSet AdministrativeGender Value Set 2.16.840.1.113883.11.1

Patient's Sex (0010,0040); [Map value "O" to nullFlavor UNK]

Administrative Sex PID-3.8

Birth​Time

>>>

birth​Time

1..1

SHALL

TS

Patient's Birth Date (0010,0030) + Patient's Birth Time (0010,0032)

Date/Time of Birth PID-7

>>

provider​Organization

0..1

MAY

Provider​Org​Name

>>>

name

1..*

SHALL

ON

Issuer of Patient ID (0010,0021)

Provider​Org​Tel

>>>

telecom

0..*

SHOULD

TEL

Provider​Org​Addr

>>>

addr

0..*

SHOULD

AD

legal​Authenticator

0..1

MAY

Signing​Time

>

time

1..1

SHALL

TS

>

signature​Code

1..1

SHALL

CS

SHALL

S

>

assigned​Entity

1..1

SHALL

Signer​ID

>>

id

1.*

SHALL

II

Signer​Addr

>>

addr

1.*

SHALL

AD

Signer​Tel

>>

telecom

1..*

SHALL

TEL

>>

assigned​Person

1..1

SHALL

Signer​Name

>>>

name

1..1

SHALL

PN

Signature​Block

>

sdtc:signatureText

0..1

MAY

ED

Author[*]

author

1..*

SHALL

Authoring​Time

>

time

1..1

SHALL

TS

>

assigned​Author

1..1

SHALL

>>

id

1.*

SHALL

II

Addr

>>

addr

1.*

SHALL

AD

Tel

>>

telecom

1..*

SHALL

TEL

>>

assigned​Person

1..1

SHALL

Name

>>>

name

1..1

SHALL

PN

Recipient[*]

information​Recipient

0..*

MAY

>

intended​Recipient

1..1

SHALL

>@

@classCode

1..1

SHALL

CS

SHALL

ASSIGNED

Addr

>>

addr

0.*

MAY

AD

Tel

>>

telecom

0..*

MAY

TEL

>>

information​Recipient

0..1

MAY

Name

>>>

name

1..1

SHALL

PN

>>

received​Organization

0..1

MAY

Org

>>>

name

1..1

SHALL

ON

custodian

1..1

SHALL

>

assigned​Custodian

1..1

SHALL

>>

represented​Custodian​Organization

1..1

SHALL

Custodian​Org​ID

>>>

id

1.*

SHALL

II

Custodian​Org​Name

>>>

name

1..1

SHALL

ON

Custodian​Org​Addr

>>>

addr

1..1

SHALL

AD

Custodian​Org​Tel

>>>

telecom

1..1

SHALL

TEL

Note that there is no business name associated with this template. Rather, this template is an editorial convenience for template specification, and the Business Names for the elements of this template are logically part of the business name scope of the invoking template.

8.1.1 templateId - contentTemplate

This templateId may be used to identify the template(s) used to generate/constrain the content of the report. This element is in addition to the templateId of the document level template, and typically represents clinical sub-specialty requirements. See Section 5.1.1 on the structure and use of the templateId.

Note

The IHE MRRT profile defines a "dcterms.identifier" that may be used for this templateId.

8.1.2 title

The title may include the title of the report template used.

Note

The IHE MRRT profile defines a "dcterms.title" that may be used in this element.

8.1.3 effectiveTime

The effectiveTime signifies the document creation time, when the document first came into being. Where the CDA document is a transform from an original document in some other format, the ClinicalDocument.effectiveTime is the time the original document is created. The time when the transform occurred is not represented in CDA.

8.1.4 setID and versionNumber

The setID and versionNumber elements may be used by the document creation system to manage document revisions, in accordance with the CDA specification sections 4.2.1.7 and 4.2.1.8.

COND: If and only if the setID element is present, the versionNumber element SHALL be present.

8.1.5 recordTarget/patientRole

The recordTarget records the patient whose health information is described by the clinical document; it must contain at least one patientRole element.

Multiple recordTarget elements should be used only in the case of conjoined twins/triplets who are the subject of a single imaging procedure, or for special cases (e.g., pre-natal surgery, where a medical record has been established for the fetus).

Example 8.1.5-1. Header example

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- DICOM Imaging Report Template -->
<templateId root="1.2.840.10008.9.1"/>
<!-- General Header Template -->
<templateId root="1.2.840.10008.9.20"/>
<id extension="999021" root="2.16.840.1.113883.19"/>
<code codeSystem="2.16.840.1.113883.6.1"
    codeSystemName="LOINC" code="18748-4"
    displayName="Diagnostic Imaging Report"/>
<title>Radiology Report</title>
<effectiveTime value="20150329171504+0500"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-US" codeSystem="2.16.840.1.113883.6.121"/>
<setId extension="111199021" root="2.16.840.1.113883.19"/>
<versionNumber value="1"/>

8.1.6 legalAuthenticator

The legalAuthenticator identifies the single person legally responsible for the correctness of the content of the document and SHALL be present if the document has been legally authenticated. In the context of an imaging report, this means the radiologist, cardiologist, or other professional who signed or validated the report.

Note

Per the CDA Standard, the legal authenticator, if present, must be a person, and the authentication applies to the human-readable narrative in section/text and any renderMultiMedia referenced content. Structured entries and external images referenced through linkHtml are not attested by the legal authentication.

Based on local practice, clinical documents may be released before legal authentication. This implies that a clinical document that does not contain this element has not been legally authenticated.

The legalAuthenticator SHALL contain exactly one [1..1] time representing the time of signature.

The legalAuthenticator MAY contain zero or one [0..1] sdtc:signatureText extension element. This provides a textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act. The element is described in the HL7 CDA Digital Signature Standard.

Example 8.1.6-1. legalAuthenticator example

<legalAuthenticator>
    <time value="20050329224411+0500"/>
    <signatureCode code="S"/>
    <assignedEntity>
        <id extension="KP00017" root="2.16.840.1.113883.19"/>
        <addr>
            <streetAddressLine>21 North Ave.</streetAddressLine>
            <city>Burlington</city>
            <state>MA</state>
            <postalCode>02368</postalCode>
            <country>US</country>
        </addr>
        <telecom use="WP" value="tel:(555) 555-1003"/>
        <assignedPerson>
            <name>
                <given>Henry</given>
                <family>Seven</family>
            </name>
        </assignedPerson>
    </assignedEntity>
</legalAuthenticator>

8.1.7 recordTarget/patientRole/Patient/birthTime

Patient birthTime SHALL be precise to year, SHOULD be precise to day.

Example 8.1.7-1. recordTarget example

<recordTarget>
    <patientRole>
        <id extension="12345" root="2.16.840.1.113883.19"/>
        <!-Example ID using fake assigning authority OID. ->
        <id extension="111-00-1234" root="2.16.840.1.118975.4.1"/>
        <!-Fake Social Security Number using the actual SSN OID. ->
        <addr use="HP">
            <!-HP is "primary home" from codeSystem 2.16.840.1.113883.5.1119 ->
            <streetAddressLine>17 Daws Rd.</streetAddressLine>
            <city>Blue Bell</city>
            <state>MA</state>
            <postalCode>02368</postalCode>
            <country>US</country>
            <!-US is "United States" from ISO 3166-1 Country Codes: 1.0.3166.1 ->
        </addr>
        <telecom value="tel:(781) 555-1212" use="HP"/>
        <!-HP is "primary home" from AddressUse 2.16.840.1.113883.5.1119 ->
        <patient>
            <name use="L">
                <!-L is "Legal" from EntityNameUse 2.16.840.1.113883.5.45 ->
                <prefix>Mr.</prefix>
                <given>Adam</given>
                <given qualifier="CL">Frankie</given>
                <!-CL is "Call me" from EntityNamePartQualifier 2.16.840.1.113883.5.43 ->
                <family>Everyman</family>
            </name>
            <administrativeGenderCode code="M"
                codeSystem="2.16.840.1.113883.5.1" displayName="Male"/>
            <birthTime value="19541125"/>
        </patient>
        <providerOrganization>
            <id root="2.16.840.1.113883.19"/>
            <name>Good Health Clinic</name>
            <telecom use="WP" value="tel:(781) 555-1212"/>
            <addr>
                <streetAddressLine>21 North Ave</streetAddressLine>
                <city>Burlington</city>
                <state>MA</state>
                <postalCode>02368</postalCode>
                <country>US</country>
            </addr>
        </providerOrganization>
    </patientRole>
</recordTarget>

8.1.8 author/assignedAuthor

The author element represents the creator of the clinical document. This template restricts the author to be a person.

Such author SHALL contain exactly one [1..1] time representing the start time of the author's participation in the creation of the content of the clinical document.

Example 8.1.8-1. Person author example

<author>
    <time value="20050329224411+0500"/>
    <assignedAuthor>
        <id extension="KP00017" root="2.16.840.1.113883.19.5"/>
        <addr>
            <streetAddressLine>21 North Ave.</streetAddressLine>
            <city>Burlington</city>
            <state>MA</state>
            <postalCode>02368</postalCode>
            <country>US</country>
        </addr>
        <telecom use="WP" value="tel:(555) 555-1003"/>
        <assignedPerson>
            <name>
                <given>Henry</given>
                <family>Seven</family>
            </name>
        </assignedPerson>
    </assignedAuthor>
</author>

8.1.9 InformationRecipient/intendedRecipient

The informationRecipient participation elements record the intended recipients of the information at the time the document is created. An intended recipient may be a person (an informationRecipient entity), with or without an organization affiliation (receivedOrganization scoping entity), or simply an organization. If an organization, the document is expected to be incorporated into an information system of that organization (e.g., the electronic medical record for the patient).

Example 8.1.9-1. informationRecipient example

<informationRecipient>
    <intendedRecipient classCode="ASSIGNED">
        <informationRecipient>
            <name>
                <given>Henry</given>
                <family>Seven</family>
            </name>
        </informationRecipient>
        <receivedOrganization>
            <name>Good Health Clinic</name>
        </receivedOrganization>
    </intendedRecipient>
</informationRecipient>

8.2 Imaging Header

Template ID

1.2.840.10008.9.21

Name

Imaging Header Elements

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

CDA Header Elements for imaging reports, including encounter, order, and study context

Classification

CDA Header Elements

Relationships

Included in 7.1 Imaging Report

Context

sibling node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

template​Id

1..1

SHALL

II

@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.21

component​Of

1..1

SHALL

>

encompassing​Encounter

1..1

SHALL

>>

id

0..1

SHOULD

II

Encounter​IDIssuer

>>@

@root

1..1

SHALL

UID

Issuer of Admission ID Sequence (0038;0014) > Universal Entity ID (0040,0032)

Visit Number PV1-19.4.2

Encounter​ID

>>@

@extension

1..1

SHALL

ST

Admission Id (0038,0010)

Visit Number PV1-19.1

Encounter​Time

>>

effective​Time

1..1

SHALL

>>

location

0..1

MAY

>>>

health​Care​Facility

1..1

SHALL

>>>>

location

0..1

SHOULD

Healthcare​Facility​Name

>>>>>

name

1..1

SHALL

EN

Healthcare​Facility​Address

>>>>>

addr

1..1

SHALL

AD

>>>>

service​Provider​Organization

0..1

SHOULD

Healthcare​Provider​Organization​Name

>>>>>

name

1..1

SHALL

ON

>>

encounter​Participant

0..*

MAY

>>@

@typeCode

1..1

SHALL

ATND

>>>

assigned​Entity

1..1

SHALL

>>>>

assigned​Person

1..1

SHALL

Attending​Physician​Name

>>>>>

name

1..1

SHALL

EN

in​Fulfillment​Of

1..*

SHALL

Order[*]

>

order

1..1

SHALL

>>

id

1..1

SHALL

II

Order​Assigning​Authority

>>@

@root

1..1

SHALL

UID

Order Placer Identifier Sequence (0040,0026) > Universal Entity ID (0040,0032)

Placer Order Number OBR-2.3

Order​Placer​Number

>>@

@extension

1..1

SHALL

ST

Placer Order Number/Imaging Service Request (0040,2016)

Placer Order Number OBR-2.1

>>

ps3-20:accessionNumber

1..1

SHALL

II

Accession​Assigning​Authority

>>@

@root

1..1

SHALL

UID

Issuer of Accession Number Sequence (0008,0051) > Universal Entity ID (0040,0032)

Filler Order Number OBR-2.3

Accession​Number

>>@

@extension

1..1

SHALL

ST

Accession Number (0008,0050)

Filler Order Number OBR-2.1

Ordered​Procedure​Code

>>

code

0..1

SHOULD

CE

Requested Procedure Code Sequence (0032,1064)

Universal Service ID OBR-4

Order​Priority

>>

priority​Code

0..1

SHOULD

CE

ValueSet ActPriority Value Set 2.16.840.1.113883.11.16866

documentation​Of

1..*

SHALL

Study[*]

>

service​Event

1..1

SHALL

Study​UID

>>

id

1..1

SHALL

II

Study Instance UID (0020,000D)

Study Instance UID IPC-3

Procedure​Code

>>

code

1..1

SHALL

CE

Procedure Code Sequence (0008,1032)

Modality

>>>

translation

1..*

SHALL

CD

SHALL CNE

Modality (0008,0060)

Anatomic​Region​Code

>>>

translation

0..1

SHOULD

CD

Concept​Domain AnatomicRegion

>>

effective​Time

1..1

SHALL

IVL <TS>

Study​Time

>>>

low

1..1

SHALL

TS

Study Date (0008,0020) + Study Time (0008,0030) + Timezone Offset From UTC (0008,0201)

Observation Date/Time OBR-7

Performer[*]

>>

performer

0..*

MAY

Type

>>@

@typeCode

1..1

SHALL

CS

SHALL

ValueSet x_serviceEventPerformer Value Set 2.16.840.1.113883.11.19601

>>>

assigned​Entity

1..1

SHALL

ID

>>>>

id

1..1

SHALL

II

>>>>

assigned​Person

1..1

SHALL

Name

>>>>>

name

1..1

SHALL

PN

participant

1..1

SHALL

@

@typeCode

1..1

SHALL

CS

SHALL

REF

>

associated​Entity

1..1

SHALL

>@

@classCode

1..1

SHALL

CS

SHALL

PROV

Referrer​ID

>>

id

0..1

SHOULD

II

Ordering Provider ORC-12.1 + ORC-12.9.2

Referrer​Addr

>>

addr

0.*

SHOULD

AD

Ordering Provider Address ORC-24

Referrer​Tel

>>

telecom

0..*

SHOULD

TEL

Call Back Phone Number ORC-14

>>

associated​Person

1..1

SHALL

Referrer​Name

>>>

name

1..1

SHALL

PN

Referring Physician's Name (0008,0090)

Ordering Provider ORC-12

data​Enterer

0..1

MAY

@

@typeCode

1..1

SHALL

CS

SHALL

ENT

>

assigned​Entity

1..1

SHALL

Transcriptionist​ID

>>

id

0..1

SHOULD

II

Transcriptionist OBR-35.1.1

>>

assigned​Person

0..1

SHOULD

Transcriptionist​Name

>>>

name

1..1

SHALL

PN

Transcriptionist OBR-35.1

Note that there is no business name associated with this template. Rather, this template is an editorial convenience for template specification, and the Business Names for the elements of this template are logically part of the Business Name scope of the invoking template.

8.2.1 componentOf/encompassingEncounter

The id element of the encompassingEncounter represents the identifier for the encounter. When the diagnostic imaging procedure is performed in the context of a hospital stay or an outpatient visit for which there is an Encounter Number, Visit Number, or Admission ID, equivalent to DICOM attribute (0038,0010), that number should be present as the ID of the encompassingEncounter.

The effectiveTime of the encompassingEncounter represents the time interval or point in time in which the encounter took place. The encompassing encounter might be that of the hospital or office visit in which the imaging procedure was performed. If the effective time is unknown, a nullFlavor attribute can be used.

Example 8.2.1-1. componentOf example

<componentOf>
    <encompassingEncounter>
        <id extension="9937012" root="1.3.6.4.1.4.1.2835.12"/>
        <effectiveTime value="20060828170821"/>
        <encounterParticipant typeCode="ATND">
            <assignedEntity>
                <id extension="4" root="2.16.840.1.113883.19"/>
                <code code="208M00000X"
                    codeSystem="2.16.840.1.113883.6.101"
                    codeSystemName="NUCC"
                    displayName="Hospitalist"/>
                <addr nullFlavor="NI"/>
                <telecom nullFlavor="NI"/>
                <assignedPerson>
                    <name>
                        <prefix>Dr.</prefix>
                        <given>Fay </given>
                        <family>Family</family>
                    </name>
                </assignedPerson>
            </assignedEntity>
        </encounterParticipant>
    </encompassingEncounter>
</componentOf>

8.2.2 Physician of Record Participant

This encounterParticipant with typeCode="ATND" (Attender) is the attending physician and is usually different from the Physician Reading Study Performer defined in documentationOf/serviceEvent.

Example 8.2.2-1. Physician of record participant example

<encounterParticipant typeCode="ATND">
    <assignedEntity>
        <id extension="44444444" root="2.16.840.1.113883.4.6"/>
        <code code="208M00000X"
            codeSystem="2.16.840.1.113883.6.101"
            codeSystemName="NUCC"
            displayName="Hospitalist"/>
        <addr nullFlavor="NI"/>
        <telecom nullFlavor="NI"/>
        <assignedPerson>
            <name>
                <prefix>Dr.</prefix>
                <given>Fay</given>
                <family>Family</family>
            </name>
        </assignedPerson>
    </assignedEntity>
</encounterParticipant>

8.2.3 inFulfillmentOf/Order and @ID

An inFulfillmentOf element represents the Placer Order. There may be more than one inFulfillmentOf element in the case where a single report is fulfilling multiple orders. There SHALL be one inFulfillmentOf/order for each distinct Order associated with the report.

In each inFulfillmentOf/order there SHALL be one order/id for the Placer Order Number (0040,2016). There SHALL be one order/ps3-20:accessionNumber for the DICOM Accession Number (0008,0050) associated with the order. The ps3-20:accessionNumber SHALL be Data Type II; it SHALL have a UID root attribute identifying its assigning authority, and the DICOM Accession Number SHALL be in the extension attribute.

Example 8.2.3-1. inFulfillmentOf example

<xs:schema ...
    xmlns:ps3-20="urn:dicom-org:ps3-20"
    ...
</xs:schema>
<inFulfillmentOf>
    <order>
        <id extension="089-927851" root="2.16.840.1.113883.19.4.33"/>
        <!-- {extension} =
          Placer Order Number/Imaging Service Request (0040,2016) {root} =
          Order Placer Identifier Sequence (0040,0026) > Universal Entity ID (0040,0032) -->
        <ps3-20:accessionNumber extension="10523475" root="2.16.840.1.113883.19.4.27" />
        <!-- {extension}=
          Accession Number (0008,0050) {root} =
          Issuer of Accession Number Sequence (0008,0051) > Universal Entity ID (0040,0032) -->
        <code code="RPID24"
            displayName="CT HEAD WITH IV CONTRAST"
            codeSystem="2.16.840.1.113883.6.256"
            codeSystemName="RadLex Playbook">
        <!-- Ordered Procedure Code is
          Requested Procedure Code Sequence (0032,1064) -->
    </order>
</inFulfillmentOf>

8.2.4 documentationOf/serviceEvent

Each documentationOf/serviceEvent indicates an imaging procedure that the provider describes and interprets in the content of the report. The main activity being described by this document is both the performance of the imaging procedure and the interpretation of the imaging procedure.

There may be more than one documentationOf/serviceEvent element if the report is interpreting multiple DICOM Studies. There may also be multiple reports for a single DICOM Study.

The serviceEvent/id element contains the DICOM Study Instance UID.

The date and time of the imaging procedure is indicated in the serviceEvent/effectiveTime element; the date and time of the interpretation is in the clinicalDocument/effectiveTime.

Note

The serviceEvent/effectiveTime uses the IVL_TS data type with the low element required, for harmonization with Consolidated CDA release 1.1.

8.2.4.1 code and translation

Within each documentationOf element, there is one serviceEvent element. The type of imaging procedure may be further described in the serviceEvent/code element. This guide makes no specific recommendations about the primary vocabulary to use for describing this event, identified as Procedure Code.

The serviceEvent/code/translation elements include codes representing the primary image acquisition modality using DICOM (DCM) terminology, and target anatomic region (for which SNOMED terminology is recommended).

Note

  1. These codes may be used as health information exchange search metadata in accordance with the IHE Radiology Technical Framework Cross-Enterprise Document Sharing for Imaging (XDS-I) Profile.

  2. Binding of the Concept Domains ProcedureCode and AnatomicRegion to specific Value Sets may be done in a further profiling of the use of this Template.

Example 8.2.4.1-1. documentationOf example

<documentationOf>
    <serviceEvent classCode="ACT" moodCode="EVN">
        <!-- study instance UID (0020,000D) -->
        <id root="1.2.840.113619.2.62.994044785528.114289542805"/>
        <!-- code is DICOM (Performed) Procedure Code Seq (0008,1032) -->
        <code code="71020"
            displayName="Radiologic examination, chest, two views, frontal and lateral"
            codeSystem="2.16.840.1.113883.6.12"
            codeSystemName="CPT4">
            <translation code="XR"
                displayName="XR"
                codeSystem="1.2.840.10008.2.16.4"
                codeSystemName="DCM"/>
        </code>
        <!-- translation code is Modality (0008,0060) -->
        <effectiveTime value="20060823222400+0800"/>
    </serviceEvent>
</documentationOf>

8.2.4.2 Performer

The documentationOf/serviceEvent may include as a participant the physician reading the study, equivalent to DICOM attribute (0008,1060), and other healthcare professional participants in the procedure (e.g., the surgical performer in an interventional procedure).

Note

In simple procedures, the physician reading the study is identified in the Author or LegalAuthenticator participation on the ClinicalDocument, and does not need to be re-identified in this element. The technologist performing the imaging may be identified in this element as a secondary performer, since the interpreting physician is the principal performer responsible for the service event.

Example 8.2.4.2-1. Physician reading study performer example

<performer typeCode="PRF">
    <assignedEntity>
        <id extension="111111111" root="2.16.840.1.113883.4.6"/>
        <code code="2085R0202X"
            codeSystem="2.16.840.1.113883.6.101"
            codeSystemName="NUCC"
            displayName="Diagnostic Radiology"/>
        <addr nullFlavor="NI"/>
        <telecom nullFlavor="NI"/>
        <assignedPerson>
            <name><given>Christine</given><family>Cure</family><suffix>MD</suffix></name>
        </assignedPerson>
    </assignedEntity>
</performer>

Example 8.2.4.2-2. participant example

<participant typeCode="REF">
    <associatedEntity classCode="PROV">
        <id nullFlavor="NI"/>
        <addr nullFlavor="NI"/>
        <telecom nullFlavor="NI"/>
        <associatedPerson>
            <name><given>Amanda</given><family>Assigned</family><suffix>MD</suffix></name>
        </associatedPerson>
    </associatedEntity>
</participant>

Example 8.2.4.2-3. dataEnterer example

<dataEnterer>
    <assignedEntity typeCode="ENT">
        <id root="2.16.840.1.113883.19.5" extension="43252"/>
        <addr>
            <streetAddressLine>21 North Ave.</streetAddressLine>
            <city>Burlington</city>
            <state>MA</state>
            <postalCode>02368</postalCode>
            <country>US</country>
        </addr>
        <telecom use="WP" value="tel:(555) 555-1003"/>
        <assignedPerson>
            <name><given>Henry</given><family>Seven</family></name>
        </assignedPerson>
    </assignedEntity>
</dataEnterer>

8.3 Parent Document

Template ID

1.2.840.10008.9.22

Name

Parent Document Header Elements

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

CDA Header Elements describing relationship to prior/parent documents

Classification

CDA Header Elements

Relationships

Included in all document level templates

Context

sibling node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

related​Document

0..1

MAY

@

@typecode

1.1

SHALL

CS

SHALL

RPLC

>

parent​Document

1..1

SHALL

Replaced​Document​ID

>>

id

1..1

SHALL

II

Replaced​Document​Set​ID

>>

set​Id

0..1

MAY

II

Replaced​Document​Version

>>

version​Number

1..1

COND

INT

related​Document

0..1

MAY

@

@typecode

1.1

SHALL

CS

SHALL

XFRM

>

parent​Document

1..1

SHALL

Transformed​Document​ID

>>

id

1..1

SHALL

II

8.3.1 relatedDocument

A document may have two types of parent document:

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

  • A source document from which the present document is transformed (typeCode = XFRM). A document may be created by transformation from a DICOM Structured Report (SR) document (see Annex C).

The CDA document management vocabulary includes a typeCode APND (append) relationship to a parent document. This relationship type is not supported in this specification; rather, append is effected by creating a replacement document with an 9.7 Addendum.

8.3.2 parentDocument/setId and versionNumber

COND: If and only if the setID element is present, the versionNumber element SHALL be present.

Example 8.3.2-1. relatedDocument example

<!-- transformation of a DICOM SR -->
<relatedDocument typeCode="XFRM">
    <parentDocument>
        <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.9"/>
        <!-- SOP Instance UID (0008,0018) of SR sample document -->
    </parentDocument>
</relatedDocument>

9 Section-level Templates

9.1 General Requirements For Sections

9.1.1 Section Text

Template ID

1.2.840.10008.9.19

Name

Section Text

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

This template specifies the common set of narrative block markup that may be included in a CDA imaging report section.

Classification

CDA Element Set

Relationships

Included in all sections

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Text

text

1..1

COND

ED

Content[*]

>

content

0..*

MAY

ST

*

>@

@ID

1..1

SHALL

XML ID

[See 5.3.4 XML ID]

Style

>@

@styleCode

0..1

MAY

XML NMTOKENS

Int​Ref[*]

>

link​Html

0..*

MAY

ST

>@

@href

1..1

SHALL

ST (URL - XML IDREF)

Graphic​Ref[*]

>

render​Multi​Media

0..*

MAY

>@

@referencedObject

1..1

SHALL

XML IDREF

Caption

>>

caption

0..1

MAY

ST

Ext​Ref[*]

>

link​Html

0..*

MAY

ST

URL

>@

@href

1..1

SHALL

ST (URL)

Paragraph(*)

>

paragraph

0..*

MAY

ST

Caption

>>

caption

0..1

MAY

ST

List(*)

>

list

0..*

MAY

ST

*

>@

@ID

1..1

SHALL

XML ID

[See 5.3.4 XML ID]

Ordered

>@

@listType

0..1

MAY

XML NMTOKENS

SHALL

ordered

Caption

>>

caption

0..1

MAY

ST

Item(*)

>>

item

1..*

SHALL

ST

*

>>@

@ID

1..1

SHALL

XML ID

[See 5.3.4 XML ID]

Table(*)

>

table

1..1

SHALL

*

>@

@ID

1..1

SHALL

XML ID

[See 5.3.4 XML ID]

Caption

>>

caption

0..1

MAY

ST

>>

Tr

1..1

SHALL

>>@

@styleCode

1..1

SHALL

CS

SHALL

Bold

Column​Head(*)

>>>

Th

1..*

SHALL

ST

Row[*]

>>

Tr

1..*

SHALL

*

>>@

@ID

1..1

SHALL

XML ID

Cell(*)

>>>

Td

1..1

SHALL

ST

The text element within the section stores the narrative to be rendered, as described in the CDA R2 specification, and is referred to as the CDA narrative block.

COND: The text element SHALL be present if the section content is not completely represented by subsections.

As noted in the CDA R2 specification, the document originator is responsible for ensuring that the narrative block contains the complete, human readable, attested content of the section. Structured entries support computer processing and computation, and are not a replacement for the attestable, human-readable content of the CDA narrative block.

Additional specification information for the CDA narrative block can be found in the CDA R2 specification in sections 1.2.1, 1.2.3, 1.3, 1.3.1, 1.3.2, 4.3.4.2, and 6.

The narrative block allows a variety of markup. The markup that implements various types of internal and external linkage is shown in the table, and is included in the conformance specifications for each section narrative block that invokes this template. The markup elements may occur in any order and at any point within the narrative block text as allowed by the CDA R2 specification.

9.1.1.1 <content> Markup and Links From Entries

The CDA narrative block may contain the <content> markup element to wrap a block of text so that it can be explicitly identified using its XML ID attribute, and referenced from elsewhere in the document. Specifically, structured entries may link to their equivalent narrative rendering in a content block using the XML ID (see CDA R2 Specification, section 4.3.5.1).

Additionally, a content block may include a styleCode attribute to suggest rendering (see CDA R2 Specification, section 4.3.5.11). For example, Bold could also be used to highlight actionable findings in the text of the 9.5 Findings and/or 9.6 Impression sections.

9.1.1.2 <linkHtml> Markup and Internal References

The CDA narrative block MAY contain the <linkHtml> markup to provide a link between narrative text in one section and a content block in another section (see CDA R2 specification section 4.3.5.2). The XML ID of the target content block is used in the linkHtml href attribute, with a prefixed '#' to indicate the reference is in the current document.

For example, a linkHtml reference could be used to link an actionable finding in the 9.6 Impression section to the specific, detailed measurement evidencing a problem that was identified in the text of the 9.5 Findings section.

9.1.1.3 <renderMultiMedia> Markup and Graphical Content

The CDA narrative block MAY contain the <renderMultiMedia> markup element to include graphical content, e.g., a coronary tree diagram or myocardial wall motion "bulls-eye chart". The renderMultiMedia element SHALL link to an observationMedia structured entry using the XML ID of that entry (see CDA R2 Specification, section 4.3.5.6).

9.1.1.4 <linkHtml> Markup and External References

The CDA narrative block MAY contain the <linkHtml> markup to provide a link between narrative text and an external (non-attested) resource (see CDA R2 specification section 4.3.5.2).

Note

For radiology reports, this capability may be used to tag concepts in the narrative block to concepts defined in the RadLex terminology (http://www.radlex.org), developed by the Radiological Society of North America. The RadLex coded vocabulary is a useful tool for indexing report content for data mining purposes. It is not intended to be a complete grammar for expression of clinical statements, but rather a lexicon for tagging concepts of interest.

Within the report section narrative blocks, RadLex codes may be included using the <linkHtml> element and a URI pointing to the RadLex resource. <linkHtml> elements may be embedded in the text at the location of the concept (within the scope of a content tag), or may be provided in a list at the end of the narrative block.

Example 9.1.1.4-1. Example - linkHtml references at point of use for RadLex

<section>
    ...
    <text>
        ...
        <content ID="find1">There is focal opacity
            <linkHtml href="http://www.radlex.org/RID/RID28530"/>
            at the right lung
            <linkHtml href="http://www.radlex.org/RID/RID1302"/>
            base most likely representing right lower lobe atelectasis
            <linkHtml href="http://www.radlex.org/RID/RID28493"/>.
        </content>
        <content ID="find2">The mediastinum ...</content>
    </text>
    ...
</section>

Example 9.1.1.4-2. Example- linkHtml references at end of narrative block for RadLex

<section>
    <title>Findings</title>
    <text>
        <content ID="find1">Pleura normal... </content>
        <linkHtml href="http://www.radlex.org/RID/RID1362"/>
    </text>
</section>

9.1.1.5 <linkHtml> Markup and Image References

The text elements (and their children) MAY contain Web Access to DICOM Persistent Object (WADO) references to DICOM objects by including a linkHtml element where @href is a valid WADO URL. The text content of linkHtml MAY be either the visible text of the hyperlink, or a descriptor or identifier of the image.

The linkHtml may be associated with a <renderMultiMedia> markup element to specify a (limited resolution) copy of the image to be rendered in the narrative (e.g., a thumbnail); the renderMultiMedia element SHALL link to an observationMedia structured entry using the XML ID of that entry. As CDA does not allow use of an image as the linkHtml displayable hyper-linked content, the linkHtml should immediately follow the renderMultiMedia for the thumbnail.

Example 9.1.1.5-1. Example linkHtml reference for WADO image access

<text>
    ...
    <paragraph>
        <caption>Source of Measurement</caption>
        <renderMultiMedia referencedObject="#thumb1"/>
        <linkHtml href="http://www.example.org/wado?requestType=WADO
            &amp;studyUID=1.2.840.113619.2.62.994044785528.114289542805
            &amp;seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051
            &amp;objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3
            &amp;contentType=application/dicom">Chest_PA</linkHtml>
    </paragraph>
    ...
</text>

9.1.1.6 list

This template specifies a structure and Business Names for list markup in the narrative text, as described in the CDA Specification section 4.3.5.8. Inclusion of the listType="ordered" attribute specifies a numbered list of items.

Each list is identified by an XML ID attribute, and each list item also is identified by an XML ID attribute.

The list items contain human readable displayable text using any of the narrative text structures permitted in section/text, including internal, external, or image references, or graphics. Processable structured data may be encoded in 10.1 Coded Observation or 10.5 Quantity Measurement entries in the section. Such observation entries SHOULD be linked to the corresponding item through the ID attribute of the item (see Section 10.1.2 and Section 10.5.1).

9.1.1.7 table

This template specifies a structure and Business Names for table markup in the narrative text, as described in the CDA Specification section 4.3.5.9, typically used for a table of measurements. The table may be of arbitrary size.

Note

See Travis, A., et al., "Preferences for Structured Reporting of Measurement Data", JAcadRadiology 21:6 DOI:10.1016/j.acra.2014.02.008

Each table is identified by an XML ID attribute, and each table row also is identified by an XML ID attribute.

The table cells contain human readable displayable text using any of the narrative text structures permitted in section/text, including internal, external, or image references, or graphics. Processable structured data may be encoded in 10.1 Coded Observation or 10.5 Quantity Measurement entries in the section. Such observation entries SHOULD be linked to the corresponding row through the ID attribute of the row (see Section 10.1.2 and Section 10.5.1).

Example 9.1.1.7-1. Measurements Table Example 1

As displayed

Table . Cardiac Measurements

Measurement name

Value

Flag

Left ventricular ejection fraction

40 %

LOW

Left ventricle end diastolic volume

120 ml

Left ventricle end systolic volume

72 ml


As encoded in CDA instance

<text>
	<table ID="T-C">
		<caption>Cardiac Measurements</caption>
		<tr styleCode="Bold">
			<th>Measurement name</th>
			<th>Value</th>
			<th>Flag</th>
		</tr>
		<tr ID="Q1">
			<td>Left ventricular ejection fraction</td>
			<td>40 %</td>
			<td styleCode="Bold">LOW</td>
		</tr>
		<tr ID="Q2">
			<td>Left ventricle end diastolic volume</td>
			<td>120 ml</td>
		</tr>
		<tr ID="Q3">
			<td>Left ventricle end systolic volume</td>
			<td>72 ml</td>
		</tr>
	</table>
</text>
<entry>
	<observation classCode="OBS" moodCode="EVN">
		<templateId root="2.16.840.1.113883.10.20.6.2.14"/>
		<id root="1.2.840.10213.2.62.7044234.11652014"/>
		<code code="10230-1" codeSystem="2.16.840.1.113883.6.1"
		    codeSystemName="LOINC" displayName="LVEF" />
		<text><reference value="#Q1"/></text>
		<statusCode code="completed"/>
		<effectiveTime value="20140913223912"/>
		<value xsi:type="PQ" unit="%" value="40" />
		<interpretationCode code="L" codeSystem="2.16.840.1.113883.6.83"
		    codeSystemName="ObservationInterpretation" displayName="Low" />
	</observation>
</entry>
<entry>
	<observation classCode="OBS" moodCode="EVN">
		<templateId root="2.16.840.1.113883.10.20.6.2.14"/>
		<id root="1.2.840.10213.2.62.7044234.11652014"/>
		<code code="8821-1" codeSystem="2.16.840.1.113883.6.1"
		    codeSystemName="LOINC" displayName="LVEDV" />
		<text><reference value="#Q2"/></text>
		<statusCode code="completed"/>
		<effectiveTime value="20140913223912"/>
		<value xsi:type="PQ" unit="ml" value="120" />
	</observation>
</entry>
<entry>
	<observation classCode="OBS" moodCode="EVN">
		<templateId root="2.16.840.1.113883.10.20.6.2.14"/>
		<id root="1.2.840.10213.2.62.7044234.11652014"/>
		<code code="8823-7" codeSystem="2.16.840.1.113883.6.1"
		    codeSystemName="LOINC" displayName="LVESV" />
		<text><reference value="#Q3"/></text>
		<statusCode code="completed"/>
		<effectiveTime value="20140913223912"/>
		<value xsi:type="PQ" unit="ml" value="72" />
	</observation>
</entry>

Example 9.1.1.7-2. Measurements Table Example 2

As displayed

Table . Current Lesion Sizes with Comparison to Exam on 2014/11/16

Ref

Measurement name

Current Value

Prior Value

Image Reference

L1

Left periaortic lymph node size (mm)

12 x 8

15 x 10

Ser:3, Img:67

L2

Segment 2 left lobe lesion size (mm)

6 x 8

10 x 9

Ser:3, Img:79

L3

Left common iliac lymph node size (mm)

12 x 3

16 x 5

Ser:3, Img:139


As encoded in CDA instance

<text>
	<table ID="Table2">
		<caption>Current Lesion Sizes with Comparison to Exam on 2014/11/16</caption>
		<tr styleCode="Bold">
			<td>Ref</td>
			<td>Measurement name</td>
			<td>Current Value</td>
			<td>Prior Value</td>
			<td>Image Reference</td>
		</tr>
		<tr ID="lesRow1">
			<td>L1</td>
			<td>Left periaortic lymph node size (mm) </td>
			<td>12 x 8</td>
			<td>15 x 10</td>
			<td><linkHtml href="http://wado.pacs.guh.org/..." >Ser:3, Img:67</linkHtml></td>
		</tr>
		...
	</table>
</text>

9.1.2 General Section Entries

Template ID

1.2.840.10008.9.23

Name

General Section Entries

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

This template specifies the common set of structured entries that may be included in a CDA imaging report section, and an author participation for the section.

Classification

CDA Element Set

Relationships

Included in 9.5 Findings section and its sub-sections, 9.2 Clinical Information and other sections

Context

sibling node

Open/Closed

open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Content​Template

template​Id

0..1

MAY

II

author

0..*

MAY

Authoring​Time

>

time

1..1

SHALL

TS

>

assigned​Author

1..1

SHALL

Author​ID

>>

id

1.*

SHALL

II

>>

assigned​Person

1..1

COND

Author​Name

>>>

name

1..1

SHALL

PN

>>

assigned​Authoring​Device

1..1

COND

Author​Device​Model

>>>

manufacturer​Model​Name

0..1

SHOULD

ST

Author​Software

>>>

software​Name

0..1

SHOULD

ST

>>

represented​Organization

0..1

MAY

Author​Organization

>>>

name

0..1

SHOULD

ON

entry

0..*

MAY

Coded​Observation[*]

>

observation

1..1

SHALL

10.1 Coded Observation 2.16.840.1.113883.​10.20.6.2.13

entry

0..*

MAY

Quantity​Measurement[*]

>

observation

1..1

SHALL

10.5 Quantity Measurement 2.16.840.1.113883.​10.20.6.2.14

entry

0..*

MAY

Graphic[*]

>

observation​Media

1..1

SHALL

10.3 observationMedia 1.3.6.1.4.1.19376.​1.4.1.4.7

entry

0..*

MAY

SOPInstance[*]

>

observation

1..1

SHALL

10.8 SOP Instance Observation 1.2.840.10008.9.18

entry

0..*

MAY

>

region​Of​Interest

0..0

SHALL NOT

Note that there is no business name associated with this template. Rather, this template is an editorial convenience for template specification, and the Business Names for the elements of this template are logically part of the Business Name scope of the invoking template.

Also, the ID of this template is not represented in a templateID element. Rather, the templateID of the invoking template implicitly includes the elements specified by this template.

9.1.2.1 templateId

This templateId may be used to identify the template(s) used to generate/constrain the content of the section. This is in addition to the templateId of the section level template, and typically represents clinical sub-specialty requirements. See Section 5.1.1 on the structure and use of the templateId.

9.1.2.2 author

The author participation allows the recording of an author for a section, equivalent to the TID 1002 “Observer Context”. Either a person or a device may be identified as the author for a section or subsection.

COND: Either the assignedPerson or assignedAuthoringDevice element SHALL be present.

Example 9.1.2.2-1. Author example

<author>
    <assignedAuthor>
        <id extension="121008" root="2.16.840.1.113883.19.5"/>
        <assignedPerson>
            <name>
                <given>John</given>
                <family>Blitz</family>
                <suffix>MD</suffix>
            </name>
        </assignedPerson>
    </assignedAuthor>
</author>

9.1.2.3 section/entry

A section may contain CDA entries that represent clinical statements in coded form (using the 10.1 Coded Observation template), numeric measurements (using the 10.5 Quantity Measurement template), images to be displayed in the narrative block (using the 10.3 observationMedia template, and invoked from a renderMultiMedia element), or references to external images or annotated images (using the 10.8 SOP Instance Observation template).

These entries may appear in any order.

9.1.2.4 regionOfInterest

Section templates defined in this Implementation guide SHALL NOT use the CDA Region of Interest Overlay entry (classCode="ROIOVL"). If it is desired to show images with graphical annotations, the annotations SHOULD be encoded in DICOM Presentation State objects that reference the image. Report applications that display referenced images and annotation may retrieve a rendered image using a WADO reference in accordance with PS3.18, including the image and Presentation State, or other DICOM retrieval and rendering methods. This approach avoids the risks of errors in registering a CDA region of interest annotation with DICOM images, and places all image rendering within the scope of the DICOM Standard, including the full range of 2D and 3D presentations defined in DICOM.

9.2 Clinical Information

Template ID

1.2.840.10008.9.2

Name

Clinical Information

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

Clinical details about the case such as presenting signs and symptoms, past clinical history, the overall condition of the patient, etc.

Classification

CDA Section Level

Relationships

Included in 7.1 Imaging Report

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Clinical​Information

section

1..1

SHALL

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.2

>

id

1..1

SHALL

II

>

code

1..1

SHALL

CD

SHALL

(55752-0, LOINC, "Clinical Information")

Title

>

title

1..1

SHALL

ST

Text

>

text

1..1

COND

ED

9.1.1 Section Text 1.2.840.10008.9.19

>

component

0..1

MAY

Request

>>

section

1..1

SHALL

9.8.1 Request 1.2.840.10008.9.7

>

component

0..1

MAY

Procedure​Indications

>>

section

1..1

SHALL

9.8.2 Procedure Indications 1.2.840.10008.9.22

>

component

0..1

MAY

History

>>

section

1..1

SHALL

9.8.3 Medical (General) History 2.16.840.1.113883.​10.20.22.2.39

>

0..1

MAY

9.1.2 General Section Entries 1.2.840.10008.9.23

Example 9.2-1. Clinical Information section example

<section classCode="DOCSECT" moodCode="EVN">
    <templateId root="1.2.840.10008.9.2"/>
    <id root="1.2.840.10213.2.62.994044785528.114289542805"/>
    <code code="55752-0" codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC" displayName="Clinical Information"/>
    <title>Clinical Information</title>
    <text>The patient was referred for evaluation of suspected pulmonary embolism.</text>
    <!---see examples for other sections/entries -->
</section>

9.3 Imaging Procedure Description

Template ID

1.2.840.10008.9.3

Name

Imaging Procedure Description

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

The Imaging Procedure Description section records the technical details of the procedure and may include information about protocol, imaging device, contrast, radiation dose, medications administered (sedation, stress agents), etc.

Classification

CDA Section Level

Relationships

Included in 7.1 Imaging Report

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Procedure​Description

section

1..1

SHALL

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.3

>

id

1..1

SHALL

II

>

code

1..1

SHALL

CD

SHALL

(55111-9, LOINC, "Current Imaging Procedure Description")

Title

>

title

1..1

SHALL

ST

Text

>

text

1..1

COND

ED

9.1.1 Section Text 1.2.840.10008.9.19

>

entry

1..1

SHALL

Procedure​Technique

>>

procedure

1..1

SHALL

10.4 Procedure Technique 1.2.840.10008.9.14

>

entry

0..*

MAY

Procedural​Medication[*]

>>

substance​Administration

1..1

SHALL

10.2 Procedural Medication 1.2.840.10008.9.13

>

component

0..1

MAY

Complications

>>

section

1..1

SHALL

9.8.4 Complications 2.16.840.1.113883.​10.20.22.2.37

>

component

0..1

COND

Radiation​Exposure

>>

section

1..1

SHALL

9.8.5 Radiation Exposure and Protection Information 1.2.840.10008.9.8

>

component

1..1

SHALL

DICOMObject​Catalog

>>

section

1..1

SHALL

9.8.7 DICOM Object Catalog 2.16.840.1.113883.​10.20.6.1.1

>

entry

0..1

MAY

Image​Quality

>>

observation

1..1

SHALL

10.9 Image Quality 1.2.840.10008.9.15

Example 9.3-1. Current Imaging Procedure description section example

<section classCode="DOCSECT" moodCode="EVN">
    <templateId root="1.2.840.10008.9.3"/>
    <id root="1.2.840.10213.2.62.9940434234785528.11428954534542805"/>
    <code code="55111-9" codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC" displayName="Current Imaging Procedure Description"/>
    <title>Imaging Procedure Description</title>
    <text>A CT study was acquired with 2.5 mm images of the abdomen and pelvis with 140 ml of... </text>
    <!-- See Procedure Technique template example - required here -->
    <!-- See DICOM Imaging Catalog template example - required here -->
    <!---see examples for other sections/entries -->
</section>

9.3.1 component/section Radiation Exposure and Protection Information

COND: If the documented service utilizes ionizing radiation, a 9.8.5 Radiation Exposure and Protection Information section MAY be present.

9.4 Comparison Study

Template​ID

1.2.840.10008.9.4

Name

Comparison Study

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

Documentation of a prior Imaging Procedure to which the current images were compared

Classification

CDA Section Level

Relationships

Included in 7.1 Imaging Report

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Comparison​Study

section

1..1

SHALL

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.4

>

id

1..*

SHALL

II

>

code

1..1

SHALL

CD

SHALL

(18834-2, LOINC, "Radiology Comparison study")

Title

>

title

1..1

SHALL

ST

Text

>

text

1..1

COND

ED

9.1.1 Section Text 1.2.840.10008.9.19

>

entry

0..*

MAY

Procedure​Technique

>>

procedure

1..1

SHALL

10.4 Procedure Technique 1.2.840.10008.9.14

>

entry

0..*

MAY

Study[*]

>>

act

1..1

SHALL

10.6 Study Act 1.2.840.10008.9.16

>

0..1

MAY

9.1.2 General Section Entries 1.2.840.10008.9.23

Example 9.4-1. Comparison study section example

<section classCode="DOCSECT" moodCode="EVN">
    <templateId root="1.2.840.10008.9.4"/>
    <id root="1.2.840.10213.2.62.994056444785528.1142893564536542805"/>
    <code code="18834-2" codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC" displayName="Radiology Comparison Study"/>
    <title>Comparison Study</title>
    <text>A prior CT with contrast performed on May 7, 2012, showed that ...</text>
    <! ---see examples for other sections/entries />
</section>

9.5 Findings

Template ID

2.16.840.1.113883.​10.20.6.1.2

Name

Findings

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

Records clinically significant observations confirmed or discovered during the procedure.

Classification

CDA Section Level

Relationships

Included in 7.1 Imaging Report

Context

parent node

Open/Closed

Open

Revision History

From Consolidated CDA r1.1

DICOM-20150324: Added optional subsections and entries

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Findings

section

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

2.16.840.1.113883.​10.20.6.1.2

>

id

1..*

SHALL

II

>

code

1..1

SHALL

CD

SHALL

(59776-5, LOINC, "Procedure Findings")

Title

>

title

1..1

SHALL

ST

Text

>

text

1..1

COND

ED

9.1.1 Section Text 1.2.840.10008.9.19

>

component

0..*

MAY

Fetus​Findings[*]

>>

section

1..1

SHALL

9.8.8 Fetus Findings 1.2.840.10008.9.9

>

component

0..*

MAY

Subsection[*]

>>

section

1..1

SHALL

9.8.9 Labeled Subsection 1.2.840.10008.9.10

>

0..1

MAY

9.1.2 General Section Entries 1.2.840.10008.9.23

9.5.1 text

If entries are present, the section/text SHALL represent faithfully all such statements and MAY contain additional text.

The narrative text associated with an actionable finding SHOULD be highlighted using styleCode Bold. See Section 9.1.1.1.

Actionable findings that require a specific follow-up action or procedure SHOULD be referenced from a recommendation in the 9.8.11 Recommendation section.

Communication of actionable findings SHOULD be documented in the 9.8.10 Communication of Actionable Findings section.

Example 9.5.1-1. Findings section example

<section classCode="DOCSECT" moodCode="EVN">
    <templateId root="2.16.840.1.113883.10.20.6.1.2"/>
    <id root="1.2.840.10213.2.62.941494044785528.114289542452452805"/>
    <code code="59776-5" codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC" displayName="Procedure Findings"/>
    <title>Findings</title>
    <text>
        <paragraph>
            <caption>Finding</caption>
            <content ID="Fndng2">The cardiomediastinum is... </content>
        </paragraph>
        <paragraph>
            <caption>Diameter</caption>
            <content ID="Diam2">45mm</content>
        </paragraph>
        ...
    </text>
    <entry>
        <templateId root="2.16.840.1.113883.10.20.6.2.12"/>
        ...
    </entry>
    <!-- see examples for other sections/entries -->
</section>

9.6 Impression

Template ID

1.2.840.10008.9.5

Name

Impression

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

The most important diagnoses or other clinical conclusions that can be made from the imaging observations and other clinical information are recorded here. This section may include recommendations for additional imaging tests or other actions, as well as global assessments, such as BI-RADS Categories or the equivalent.

Classification

CDA Section Level

Relationships

Included in 7.1 Imaging Report

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Impression

section

1..1

SHALL

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.5

>

id

1..*

SHALL

II

>

code

1..1

SHALL

CD

SHALL

(19005-8, LOINC, "Impressions")

Title

>

title

1..1

SHALL

ST

Text

>

text

1..1

COND

ED

9.1.1 Section Text 1.2.840.10008.9.19

>

component

0..1

MAY

Communication​Of​Actionable​Findings

>>

section

1..1

SHALL

9.8.10 Communication of Actionable Findings 1.2.840.10008.9.11

>

component

0..1

MAY

Key​Images

>>

section

1..1

SHALL

9.8.6 Key Images 1.3.6.1.4.1.19376.​1.4.1.2.14

>

component

0..*

MAY

Recommendation

>>

section

1..1

SHALL

9.8.11 Recommendation 1.2.840.10008.9.12

>

entry

0..*

MAY

Coded​Observation

>>

observation

1..1

SHALL

CD

10.1 Coded Observation 2.16.840.1.113883.​10.20.6.2.13

Example 9.6-1. Impression section example

<section classCode="DOCSECT" moodCode="EVN">
    <templateId root="2.16.840.1.113883.10.20.22.2.27"/>
    <id root="1.2.840.10213.2.62.994948294044785528.11422458954285205"/>
    <code code="19005-8"
        codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC"
        displayName="Impressions"/>
    <title>Impression</title>
    <text>This exam identified ...</text>
    <!-- other sections and entries here -->
</section>

9.7 Addendum

Template ID

1.2.840.10008.9.6

Name

Addendum

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

Addendum section for imaging report includes supplemental information added to the original document contents..

Classification

CDA Section Level

Relationships

Included in 7.1 Imaging Report

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Addendum[*]

section

1..1

SHALL

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.6

>

id

1..*

SHALL

II

>

code

1..1

SHALL

CD

SHALL

(55107-7, LOINC, "Addendum")

Title

>

title

1..1

SHALL

ST

Text

>

text

1..1

COND

ED

9.1.1 Section Text 1.2.840.10008.9.19

>

author

1..1

SHALL

Time

>>

time

1..1

SHALL

TS

>>

assigned​Author

1..1

SHALL

Author​ID

>>>

id

1..*

SHALL

II

>>>>

assigned​Person

1..1

SHALL

Author​Name

>>>>>

name

1..1

SHALL

PN

>

component

0..1

MAY

Communication​Of​Actionable​Findings

>>

section

1..1

SHALL

9.8.10 Communication of Actionable Findings 1.2.840.10008.9.11

>

0..1

MAY

9.1.2 General Section Entries 1.2.840.10008.9.23

9.7.1 author

Note that the Author identified in the document header is the author of the original report, as that participation sets the default authoring context for the report. The Author participation in this section shall be present, and identifies the author of the addendum, even if the same as the author of the original report.

9.7.2 component/section - Communication of Actionable Findings

It is possible for an imaging report to be legally signed (authenticated) prior to the Actionable Findings being properly communicated. In this event, an addendum to the imaging report is often created to document the communication of the actionable findings. This can be included in the section/text of the 9.7 Addendum, or using the 9.8.10 Communication of Actionable Findings subsection.

Example 9.7.2-1. Addendum section example

<section classCode="DOCSECT" moodCode="EVN" ID="Adndm">
    <templateId root="1.2.840.10008.9.6"/>
    <id root="1.2.840.10213.2.62.7906994044785528.1142895428068506"/>
    <code code="55107-7" codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC" displayName=" Addendum"/>
    <title>Addendum</title>
    <text>The supplemental information added to the original document...</text>
    <author>
        <time value="20140605143000+0500"/>
        <assignedAuthor>
            <id extension="23454345" root="2.16.840.1.113883.19.5"/>
            <assignedPerson>
            <name><given>Henry</given> <family>Radiologist</family></name>
            </assignedPerson>
        </assignedAuthor>
    </author>
</section>

9.8 Sub-sections

9.8.1 Request

Template ID

1.2.840.10008.9.7

Name

Request

Effective Date

2015/03/24

Version Label

DICOM-20150324

Status

Active

Description

Information about the requested imaging studies and associated tests. It may include information on the reason for the request, and on any validation of the request by clinical decision support against relevant appropriateness criteria.

Classification

CDA Section Level

Relationships

Included in 9.2 Clinical Information

Context

parent node

Open/Closed

Open

Revision History

DICOM-20150324: Initial version

Business Name

Nest Level

Element/​Attribute

Card

Elem/Attr Conf

Data Type

Value Conf

Value

Subsidiary Template

Request

section

1..1

SHALL

>

template​Id

1..1

SHALL

II

>@

@root

1..1

SHALL

UID

SHALL

1.2.840.10008.9.7

>

id

1..*

SHALL

II

>

code

1..1

SHALL

CD

SHALL

(55115-0, LOINC, "Request")

Title

>

title

1..1

SHALL

ST

Text

>

text

1..1

COND

ED

9.1.1 Section Text 1.2.840.10008.9.19

CDSRecord​Text[*]

>>

content

0..*

MAY

ST

*

>>@

@ID

1..1

SHALL

XML ID

>

0..1

MAY

9.1.2 General Section Entries 1.2.840.10008.9.23

9.8.1.1 text/content and @ID – CDS Record

The Request section narrative text block MAY include content blocks recording clinical decision support assessments of the request with respect to the indications, patient characteristics, and relevant guidelines. Each such text/content SHALL include an XML ID attribute that serves as the business name discriminator associated with an instantiation of the element. Even if only one content block is instantiated, the ID attribute shall be present.

Example 9.8.1.1-1. Request section example

<section classCode="DOCSECT" moodCode="EVN">
    <templateId root="1.2.840.10008.9.7" />
    <id root="1.2.840.10213.2.62.7906994785528.114289506"/>
    <code code="55115-0"
        codeSystem="2.16.840.1.113883.6.1"
        codeSystemName="LOINC"
        displayName="Request" />
    <title>Request</title>
    <text>PTA (Iliac Angioplasty) for treatment of symptomatic
        atherosclerotic disease in both iliac arteries.
        <content ID="CDS001">Procedure ordered by Pat Smith, MD, NPI:8740944987.
        Classified APPROPRIATE by RadCDS based on ACR Select criteria
        at 2015-07-21 10:52:31 CDT</content>
    </text>
</section>

9.8.2 Procedure Indications