Diagnostic Imaging Report - HL7 International



CDAR2_II_BIMGRPTS_R1

Implementation Guide for CDA Release 2 – Diagnostic Imaging Report

|Editor/Co-Chair: |Fred M. Behlen, PhD |

| |American College of Radiology |

| |fbehlen@ |

|Co-Chair: |Helmut Koenig, MD |

| |helmut.koenig@ |

(Committee Draft for) 1st Informative Ballot

September 1216, 2007

© 2007 Health Level Seven, Inc.

Ann Arbor, MI

All rights reserved.

Revision History

0.3.14 September 30, 2006 Committee draft from Boca Raton Meeting

0.3.15 January 10, 2007 Committee draft

0.4.17 April 29, 2007 Committee draft

0.4.18 July 8, 2007 Committee Draft

0.4.19 July 15, 2007 Committee Draft

0.4.20 August 28, 2007 Committee Draft

0.4.21 September 12, 2007 Committee Draft

0.4.22 September 16, 2007 Committee Draft

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

Open Issues

1. Update Appendix B with current CDA ample

2. Update figures with snips from current CDA sample

3. Others TBD in Committee Review (July 11 Conference Call)

4. Specify Level 2 constraints

5. Specify Detailed Level 3 description with of measurements, annotation and image references.

6. Level 1-2 example (Appendix B, C)

7. Level 3 example (Appendix D)

8. Describe transformation of SR to CDA (Appendix E)

9. Data enterer not in sample document

10. Information recipient not in sample document

11. ComponentOf/EncompassingEncounter not in sample document

12. Section 3.3.2 Rendering of Coded Observations into Section.text needs to be specified.

Table of Contents

1 Diagnostic Imaging Report 3

1 Introduction 3

1.1 Purpose 3

1.2 Audience 3

1.3 Approach 3

1.4 Conventions Used in this Guide 3

1.4.1 Explanatory Statements 3

1.4.2 Conformance Requirements 3

1.4.3 XPath Notation 3

1.4.4 Key Words 3

1.4.5 XML Samples 3

1.4.6 DICOM Samples 3

1.4.7 Content of the Ballot Package 3

1.5 Scope 3

2 CDA Header 3

2.1 ClinicalDocument 3

2.1.1 General Constraints 3

2.1.2 Rendering Information from the CDA Header for Human Presentation 3

2.1.3 ClinicalDocument/realmCode 3

2.1.4 ClinicalDocument/typeId 3

2.1.5 ClinicalDocument/templateId 3

2.1.6 ClinicalDocument/id 3

2.1.7 ClinicalDocument/code 3

2.1.8 ClinicalDocument/title 3

2.1.9 ClinicalDocument/effectiveTime 3

2.1.10 ClinicalDocument/confidentialityCode 3

2.1.11 ClinicalDocument/languageCode 3

2.1.12 ClinicalDocument/setId and ClinicalDocument/versionNumber 3

2.1.13 ClinicalDocument/copyTime 3

2.2 Participants 3

2.2.1 recordTarget 3

2.2.2 author 3

2.2.3 dataEnterer 3

2.2.4 informant 3

2.2.5 custodian 3

2.2.6 informationRecipient 3

2.2.7 legalAuthenticator 3

2.2.8 authenticator 3

2.2.9 participant 3

2.2.10 inFullfillmentOf 3

2.2.11 documentationOf 3

2.2.12 authorization 3

2.2.13 relatedDocument 3

2.2.14 componentOf 3

3 Body 3

3.1 Section Type Codes 3

3.2 Sections 3

3.2.1 DICOM Object Catalog – DCM 121181 3

3.2.2 Findings – LOINC 18782-3 3

3.2.3 Reason for Study – LOINC 18785-6 3

3.2.4 History of Present Illness – LOINC 10164-2 3

3.2.5 Impressions – LOINC 19005-8 3

3.3 Level 3 Content 3

3.3.1 Text Observations 3

3.3.2 Code Observations 3

3.3.3 Report Observations 3

4 References 3

Appendix A — Validation 3

Introduction 3

Administrative Gender 3

Ethnicity & Race 3

Null Flavor 3

Participation Function 3

Appendix B — Sample Conforming CDA Document 3

1 Diagnostic Imaging Report 7

1 Introduction 7

1.1 Purpose 7

1.2 Audience 7

1.3 Approach 7

1.4 Conventions Used in this Guide 7

1.4.1 Explanatory Statements 7

1.4.2 Conformance Requirements 7

1.4.3 XPath Notation 8

1.4.4 Key Words 8

1.4.5 XML Samples 8

1.4.6 DICOM Samples 8

1.4.7 Content of the Ballot Package 8

1.5 Scope 9

2 CDA Header 10

2.1 ClinicalDocument 10

2.1.1 General Constraints 11

2.1.2 Rendering Information from the CDA Header for Human Presentation 11

2.1.3 ClinicalDocument/realmCode 11

2.1.4 ClinicalDocument/typeId 12

2.1.5 ClinicalDocument/templateId 12

2.1.6 ClinicalDocument/id 12

2.1.7 ClinicalDocument/code 13

2.1.8 ClinicalDocument/title 14

2.1.9 ClinicalDocument/effectiveTime 14

2.1.10 ClinicalDocument/confidentialityCode 15

2.1.11 ClinicalDocument/languageCode 15

2.1.12 ClinicalDocument/setId and ClinicalDocument/versionNumber 15

2.1.13 ClinicalDocument/copyTime 15

2.2 Participants 15

2.2.1 recordTarget 16

2.2.2 author 16

2.2.3 dataEnterer 17

2.2.4 informant 18

2.2.5 custodian 18

2.2.6 informationRecipient 18

2.2.7 legalAuthenticator 19

2.2.8 authenticator 19

2.2.9 participant 20

2.2.10 inFullfillmentOf 20

2.2.11 documentationOf 21

2.2.12 authorization 22

2.2.13 relatedDocument 22

2.2.14 componentOf 23

3 Body 24

3.1 LOINC Section Type Codes 24

3.2 Required Sections 26

3.2.1 Findings – LOINC 18782-3 26

3.3 Conditionally-Required Sections 28

3.3.1 DICOM Object Catalog – DCM 121181 28

3.4 Optional Sections 30

3.4.1 Reason for Study – LOINC 18785-6 30

3.4.2 History of Present Illness – LOINC 10164-2 30

3.4.3 Impressions – LOINC 19005-8 30

3.5 Level 3 Content 31

3.5.1 Text Elements 31

3.5.2 Code Elements 32

3.5.3 Report Observations 32

4 References 37

Appendix A — Validation 38

Introduction 38

Administrative Gender 38

Ethnicity & Race 38

Null Flavor 38

Participation Function 40

Appendix B — Sample Conforming CDA Document 41

Figures

Figure 1 Use of the templateId element to indicate use of this guide. 3

Figure 2 ClinicalDocument Example 3

Figure 3 ClinicalDocument/realmCode Example 3

Figure 4 ClinicalDocument/typeId Example 3

Figure 5 ClinicalDocument/templateId Example conforming to Level 1 only 3

Figure 6 ClinicalDocument/id Example 3

Figure 7 ClinicalDocument/code Example 3

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

Figure 9 ClinicalDocument/title Example 3

Figure 10 CinicalDocument/effectiveTime Example 3

Figure 11 CinicalDocument/confidentialityCode Example 3

Figure 12 ClinicalDocument/languageCode Example with language only 3

Figure 13 ClinicalDocument/languageCode Example with language and country. 3

Figure 14 recordTarget Example 3

Figure 15 author Example 3

Figure 16 dataEnterer Example 3

Figure 17 custodian Example 3

Figure 18 informationRecipient Example 3

Figure 19 legalAuthenticator Example 3

Figure 20 authenticator Example 3

Figure 21 participant Example 3

Figure 22 inFulfillmentOf Example 3

Figure 23 documentationOf Example 3

Figure 24 componentOf example 3

Figure 25 DICOM Object Catalog Example 3

Figure 26 Findings Example including Level 3 content 3

Figure 27 Reason for Study Example 3

Figure 28 History Example 3

Figure 29 Impressions Example 3

Figure 30 Text Element example 3

Figure 31 Code Element example 3

Figure 32 Report Observation as an Entry 3

Figure 33 Report Observation as a support for an inferred finding 3

Figure 34 Image Reference Report Observation example 3

Figure 35 Linear Measurement Report Observation example 3

Figure 36 Linear Measurement Report Observation example 3

Figure 37 Volume Measurement Report Observation example 3

Figure 38 Numeric Measurement Report Observation example 3

Figure 1 Use of the templateId element to indicate use of this guide. 11

Figure 2 ClinicalDocument Example 12

Figure 3 ClinicalDocument/realmCode Example 12

Figure 4 ClinicalDocument/typeId Example 13

Figure 5 ClinicalDocument/templateId Example conforming to Level 1 only 13

Figure 6 ClinicalDocument/id Example 13

Figure 7 ClinicalDocument/code Example 14

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

Figure 9 ClinicalDocument/title Example 15

Figure 10 CinicalDocument/effectiveTime Example 15

Figure 11 CinicalDocument/confidentialityCode Example 16

Figure 12 ClinicalDocument/languageCode Example with language only 16

Figure 13 ClinicalDocument/languageCode Example with language and country. 16

Figure 14 recordTarget Example 17

Figure 15 author Example 18

Figure 16 dataEnterer Example 18

Figure 17 custodian Example 19

Figure 18 informationRecipient Example 20

Figure 19 legalAuthenticator Example 20

Figure 20 authenticator Example 21

Figure 21 participant Example 21

Figure 22 inFulfillmentOf Example 22

Figure 23 documentationOf Example 23

Figure 24 componentOf example 24

Figure 25 Findings Example including Level 3 content 28

Figure 26 DICOM Object Catalog Example 30

Figure 27 Reason for Study Example 31

Figure 28 History Example 31

Figure 29 Impressions Example 31

Figure 30 Text Element example 33

Figure 31 Code Element example 33

Figure 32 Report Observation as an Entry 34

Figure 33 Report Observation as a support for an inferred finding 34

Figure 34 Image Reference Report Observation example 35

Figure 34 Linear Measurement Report Observation example 35

Figure 34 Linear Measurement Report Observation example 36

Figure 34 Volume Measurement Report Observation example 36

Figure 34 Numeric Measurement Report Observation example 37

Tables

Table 1 Contents of the Ballot Package 3

Table 2 LOINC Document Type Codes 3

Table 3 Section Type Codes 3

Table 4 Administrative Gender 3

Table 5 Null Flavor 3

Table 6 Participating Function Codes 3

Table 1 Contents of the Ballot Package 10

Table 2 LOINC Document Type Codes 15

Table 3 LOINC Section Type Codes 25

Table 4 Administrative Gender 39

Table 5 Null Flavor 40

Table 6 Participating Function Codes 41

Diagnostic Imaging Report

1 Introduction

1 Purpose

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

2 Audience

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

3 Approach

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

4 Conventions Used in this Guide

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

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

1 Explanatory Statements

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

Explanatory statements will appear in this style.

2 Conformance Requirements

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

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

3 XPath Notation

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

4 Key Words

The key words "shall", "shall not", "should", "should not", "may", and "need not" in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide.

5 XML Samples

XML Samples appear in various figures in this document in a fixed font. Portions of the XML content may be suppressed for brevity. These are marked by a vertical ellipses, as shown in the example below.

:

.

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

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

6 DICOM Samples

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

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

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

7 Content of the Ballot Package

The ballot package contains the following files:

|Filename |Description |

|Diagnostic Imaging Report for CDA |This guide |

|Release 2 Level 1-3 v1.0.pdf | |

|DICOM SR “Basic Diagnostic Imaging |The transformation guide specifying the mapping of constrained DICOM SR “Basic Diagnostic |

|Report” to HL7 CDA Release 2 |Imaging Reports” (DICOM PS 3.16-2007: Template 2000) to CDA Release 2 “Diagnostic Imaging |

|“Diagnostic Imaging Report” |Reports” as described by this guide. |

|Transformation Guide | |

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

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

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

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

|SampleChestXR_PA.dcm |Sample DICOM images referenced within the DICOM SR document EnhancedSR…dcm |

|SampleChestXR_Lat.dcm | |

Table 1 Contents of the Ballot Package

1 Sample DICOM SR Basic Diagnostic Imaging Report

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

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

2 Constrained CDA Diagnostic Imaging Report XML Schema

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

3 Sample XML

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

5 Scope

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

This Guide specifies three levels of conformance requirements. Level 1 requirements specify constraints upon the CDA Header and the content of the document. Level 2 requirements specify constraints upon the structuredBody of the ClinicalDocument element of the CDA document. Level 3 requirements describe a limited set of structured entries for the purpose of referencing and annotating images from within the report.

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

CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that the CDA instance not only conforms to the CDA specification, but in addition, conforms to the constraints specified in this implementation guide.

:

.

:

Figure 1 Use of the templateId element to indicate use of this guide.

Within this guide, the required and optional content within the body are identified. This guide describes the information content of each section, but this cannot be verified by software.

2 CDA Header

1 ClinicalDocument

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

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

Chest X-Ray, PA and LAT View

:

.

:

Figure 2 ClinicalDocument Example

1 General Constraints

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

2 Rendering Information from the CDA Header for Human Presentation

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

Recommendations for rendering information from the header include:

• Document title and document dates

• Service and encounter types and date ranges as appropriate

• All persons named along with their roles, participations, participation date ranges, identifiers, address and telecom information

• Selected organizations named along with roles, participations, identifiers or names,

• Record Target(s) date-of-birth

• Any other minimal context information that is available

3 ClinicalDocument/realmCode

This value identifies the realm[2].

The ClinicalDocument/realmCode element MAY be present. If present, it shall use the fixed value UV.

Figure 3 ClinicalDocument/realmCode Example

4 ClinicalDocument/typeId

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

Figure 4 ClinicalDocument/typeId Example

1: The extension attribute of the typeId element shall be POCD_HD000040.

5 ClinicalDocument/templateId

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

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

1: A ClinicalDocument/templateId element shall be present where the value of @extension is CDAR2_II_BIMGRPTS_R1 and the value of @root is 2.16.840.1.113883.10.

Figure 5 ClinicalDocument/templateId Example conforming to Level 1 only

6 ClinicalDocument/id

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

2: The ClinicalDocument/id/@root attribute shall be a syntactically correct OID.

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

4: OIDs shall be no more than 64 characters in length.

Figure 6 ClinicalDocument/id Example

Organizations that use OIDs shall properly register their OID root, and ensure uniqueness of the OID roots used in identifiers. There are a large number of mechanisms to obtain OID roots for free, or for a reasonable fee. HL7 Maintains an OID registry page, from which organizations may request an OID root under the HL7 OID root. This page can be accessed at:

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



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

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

5: The ClinicalDocument/id/@extension attribute shall not be present.

7 ClinicalDocument/code

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

The LOINC Diagnostic Imaging Report document type (LOINC Document Code 18748-4) should be used as the value for ClinicalDocument/code in the CDA Header.

Figure 7 ClinicalDocument/code Example

CDA Release 2.0 states that LOINC is the preferred vocabulary for document type specification.

1 Use of Local Document Type Codes

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

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download