CDAR2_II_BIMGRPTS_R1
Implementation Guide for CDA Release 2.0
Levels 1, 2, and 3
Diagnostic Imaging Report– Universal Realm
Based on HL7 CDA Release 2.0
Draft Standard for Trial Use
First Ballot
March 20, 2008
© 2008 Health Level Seven, Inc.
Ann Arbor, MI
All rights reserved.
American College of Radiology
Co-Chair: / Helmut Koenig, M.D.
Siemens Medical Solutions
Editor: / Rick Geimer
Alschuler Associates, LLC
Acknowledgments
This Guide was produced and developed through the efforts of a project …
Revision History (to be removed prior to putting up for ballot)
Rev / Date / By Whom / Changes / Note0.3.14 / September 30, 2006 / Committee from Boca Raton Meeting / Draft
0.3.15 / January 10, 2007 / Committee from Boca Raton Meeting / Draft
0.4.17 / April 29, 2007 / Committee from Boca Raton Meeting / Draft
0.4.18 / July 8, 2007 / Committee from Boca Raton Meeting / Draft
0.4.19 / July 15, 2007 / Committee from Boca Raton Meeting / Draft
0.4.20 / August 28, 2007 / Committee from Boca Raton Meeting / Draft
0.4.21 / September 12, 2007 / Committee from Boca Raton Meeting / Draft
0.4.22 / September 16, 2007 / Committee from Boca Raton Meeting / Draft
0.x.00 / December xx, 2007 / First informative ballot
Table of Contents
1Introduction......
1.1Purpose......
1.2Audience......
1.3Approach......
1.4Organization of this Guide......
1.5Use of Templates......
1.5.1Originator Responsibilities......
1.5.2Recipient Responsibilities......
1.6Conventions Used in This Guide......
1.6.1Explanatory Statements......
1.6.2Conformance Requirements......
1.6.3XPath Notation......
1.6.4Keywords......
1.6.5XML Samples......
1.6.6DICOM Samples......
1.6.7Content of the Ballot Package......
1.6.7.1Sample DICOM SR Basic Diagnostic Imaging Report......
1.6.7.2Constrained CDA Diagnostic Imaging Report XML Schema......
1.6.7.3Sample XML......
1.7Scope......
1.7.1Levels of Constraint......
2CDA Header Constraints......
2.1Rendering Information from the CDA Header for Human Presentation......
2.2ClinicalDocument......
2.3Name, Address, Telephone Number, and Time Constraints......
2.4ClinicalDocument/realmCode......
2.5ClinicalDocument/typeId......
2.6ClinicalDocument/templateId......
2.7ClinicalDocument/id......
2.8ClinicalDocument/code......
2.8.1Use of Local Document Type Codes......
2.8.2Precoordinated Document Type Codes......
2.9ClinicalDocument/title......
2.10ClinicalDocument/effectiveTime......
2.11ClinicalDocument/confidentialityCode......
2.12ClinicalDocument/languageCode......
2.13ClinicalDocument/setId and ClinicalDocument/versionNumber......
2.14ClinicalDocument/copyTime......
2.15Participants......
2.15.1recordTarget......
2.15.2author......
2.15.3dataEnterer......
2.15.4informant......
2.15.5custodian......
2.15.6informationRecipient......
2.15.7legalAuthenticator......
2.15.8authenticator......
2.15.9participant......
2.16inFullfillmentOf......
2.17documentationOf......
2.17.1Physician Reading Study Performer......
2.18authorization......
2.19relatedDocument......
2.20componentOf......
2.20.1Physician of Record Participant......
3Body......
3.1Section Descriptions......
3.1.1Section Type Codes......
3.2Required Sections......
3.2.1DICOM Object Catalog – DCM 121181......
3.2.2Findings – LOINC 18782-3......
3.3Optional Sections......
3.4Clinical Statements......
3.4.1Study Act......
3.4.2Series Act......
3.4.3SopInstance Observation......
3.4.4Purpose of Reference Observation......
3.4.5Referenced Frames Observation......
3.4.6Boundary Observation......
3.4.7Text Observation......
3.4.8Code Observations......
3.4.9Numeric Measurement Observation......
4References......
Appendix A —Validation......
Introduction......
Vocabulary......
Administrative Gender
Extending the Vocabulary Tables for Local Use
Administrative Contact Role Type
Administrative Gender
Ethnicity
Marital Status
Null Flavors......
Personal Relationship Role Type
Race
Participation Function
Appendix B —Termplate IDs Defined in this Guide......
Appendix C —Section Cardinality......
Appendix D —Sample Conforming CDA Document......
Table of Figures
Figure 1: Use of the templateId element to indicate use of this guide......
Figure 2: Various Uses of nullFlavor......
Figure 3: Restricted URL grammar for telephone communications......
Figure 4: Unknown telephone number example......
Figure 5: ClinicalDocument/realmCode Example......
Figure 6: ClinicalDocument/typeId example......
Figure 7: ClinicalDocument/templateId example......
Figure 8: ClinicalDocument/id example......
Figure 9: ClinicalDocument/code Example......
Figure 10: Use of the translation element to include local codes for document type......
Figure 11: ClinicalDocument/title example......
Figure 12: CinicalDocument/effectiveTime example......
Figure 13: ClinicalDocument/confidentialityCode example......
Figure 14: ClinicalDocument/languageCode example with language only......
Figure 15: ClinicalDocument/languageCode example with language and country......
Figure 16: ClinicalDocument/setId and ClinicalDocument/versionNumber example......
Figure 17: recordTarget example......
Figure 18: author example......
Figure 19: dataEnterer example......
Figure 20: custodian example......
Figure 21: informationRecipient example......
Figure 22: legalAuthenticator example......
Figure 23: authenticator example......
Figure 24: participant Example......
Figure 25: inFulfillmentOf Example......
Figure 26: documentationOf Example......
Figure 27: componentOf example......
Figure 28: DICOM Object Catalog example......
Figure 29: Findings example, including Level 3 content......
Figure 30: Reason for study example......
Figure 31: History example......
Figure 32: Impressions example......
Figure 33: SopInstance Observation as an entry......
Figure 34: SopInstance Observation as a support for an inferred finding......
Figure 35: Text Observation example......
Figure 36: Code Element example......
Figure 37: Numeric Measurement Report Observation example......
Table of Tables
Table 1: Contents of the Ballot Package......
Table 2: LOINC Document Type Codes......
Table 3: Section Type Codes
Table 4: Purpose of Reference (DICOM CID 7003)......
Table 5: Numeric Measurement Type Codes (value set XXX-1)......
Table 6: Administrative Gender......
Table 7: Null Flavor......
Table 8: Participating Function Codes......
1Introduction
1.1Purpose
The purpose of this document is to describe constraints on the CDA Header and Body elements for Diagnostic Imaging Reports. A Diagnostic Imaging Report contains a consulting specialist’s interpretation of image data. It is intended to convey the interpretation to the referring (ordering) physician, and becomes part of the patient’s medical record. It is intended for use in Radiology, Endoscopy, Cardiology, and other imaging specialties.
1.2Audience
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 Implementation Guide.
1.3Approach
The approach taken in the development of this Implementation Guide 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.
Most of the constrains in this implementation guide have been inherited from the DICOM SR “Basic Diagnostic Imaging Report” to HL7 CDA Release 2 “Diagnostic Imaging Report” Transformation Guide (by Helmut Koenig).
1.4Organization of this Guide
With subsections describing the organization …
1.5Use of Templates
Templates are collections of constraints that specify and validate agreed-to requirements for exchange. Collecting individual constraints and assigning a unique template identifier to the collection establishes a shorthand mechanism for the instance creator to assert conformance to those constraints. The template identifier itself carries no semantics. Validation errors against a template must not be construed as anything other than failure to meet the exact requirements of the template, and absence of a template identifier need not be construed as failure to meet the constraints required by the template.
1.6Conventions Used in This Guide
This Implementation Guide is a conformance profile, as described in theRefinement and Localizationsection of the HL7 Version 3 standards. The base standard for this Implementation Guide is the HL7 Clinical Document Architecture, Release 2.0. As defined in that document, this Implementation Guide is both an annotation profile and a localization profile. Every aspect of the CDA R2 may not be described in this guide.
The mapping profile for SR to CDA is based on DICOM Template 2000 Basic Diagnostic Imaging Report, NEMA PS3.16-2007.
1.6.1Explanatory Statements
As an annotation profile, portions of this Implementation Guide summarize or explain the base standard.
Explanatory statements will appear in this style.
1.6.2Conformance Requirements
Conformance requirements within this guide are sequentially numbered, and appear in the format illustrated below:
CONF-XX-1:Here's an example of a conformance requirement for conformance to Level1 requirements.
CONF-XX-2:Here's another conformance statement. It might say that something shall include some specifically referenced thing.
1.6.3XPath Notation
Instead of the traditional dotted notation used by HL7 to represent RIM classes, this document uses XPath notation in conformance statements and elsewhere to identify the XML elements and attributes within the CDA document instance to which various constraints are applied. The implicit context of these expressions is the root of the document. The purpose of using this notation is to provide a mechanism which will be familiar to developers for identifying parts of an XML document.
1.6.4Keywords
The keywords shall, shall not, should, shouldnot, may, and neednot in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide.
1.6.5XML Samples
XML Samples appear in various figures in this document in a fixed-width font. Portions of the XML content may be omitted from the content for brevity, marked by an ellipsis (…) as shown in the example below.
<ClinicalDocument xmins='urn:h17-org:v3'>
...
</ClinicalDocument>
FigureXX-1: ClinicalDocument example
Within the narrative, XML element and attribute names will appear in this fixed character font (ElementName). Literal attribute values will appear in this italic character font (AttributeValue).
XPath expressions are used in the narrative and conformance requirements to identify elements because they are familiar to many XML implementers.
1.6.6DICOM 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.
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 is included in the ballot package.
1.6.7Content of the Ballot Package
The ballot package contains the following files:
Filename / DescriptionDiagnostic Imaging Report for CDA Release 2 Level 1-3 v1.0.pdf / This Guide
DICOM SR “Basic Diagnostic Imaging Report” to HL7 CDA Release 2 “Diagnostic Imaging Report” Transformation Guide / The transformation guide specifying the mapping of constrained DICOM SR “Basic Diagnostic Imaging Reports” (DICOM PS 3.16-2007: Template 2000) to CDA Release 2 “Diagnostic Imaging Reports” as described by this Guide.
EnhancedSR.xml / The sample CDA document found in Appendix B.
voc.xml / A vocabulary data file used by both the Schematron schema and the display stylesheet.
CDA.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
SampleChestXR_Lat.dcm / Sample DICOM images referenced within the DICOM SR document EnhancedSR.dcm
Table 1: Contents of the Ballot Package
1.6.7.1Sample 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 which are included in two DICOM Image files, SampleChestXR_PA.dcm and SampleChestXR_Lat.dcm. The report examples include references to these images.
1.6.7.2Constrained CDA Diagnostic Imaging Report XML Schema
Also included in this ballot package is a CDA XML Schema constrained to the elements allowed in this Implementation Guide. This Schema is informative, and implementers should be cautioned that not all constraints in this guide are represented in the XML Schema.
1.6.7.3Sample XML
A sample document is provided which conforms to the Level1 and Level2 constraints of this guide. This document is the source of many of the examples provided in this guide.
1.7Scope
This specification defines additional constraints on CDA Header and Body elements used in a Diagnostic Imaging Reportdocument in the universal realm, and provides examples of conforming fragments in the body of the document and an example of a conforming XML instance as an appendix.
1.7.1Levels of Constraint
This Implementation Guide specifiesthree levels of conformance requirements. Level 1 requirements specify constraints upon the CDA Header and the content of the document. Level 2 requirements specify constraints upon the structuredBody of the ClinicalDocument element of the CDA document. Level 3 requirements describe a limited set of structured entries for the purpose of referencing and annotating images from within the report.
This specification is intended for global use (universal realm). The specification of workflows, messages, or procedures used in performing imaging procedures is outside the scope of this specification.
CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that the CDA instance not only conforms to the CDA specification, but in addition, conforms to the constraints specified in this Implementation Guide.
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi=" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="DIR_ROOT_OID"/>
:
</ClinicalDocument>
Figure 1: Use of the templateId element to indicate use of this guide
Within this guide, the required and optional content within the body are identified. This guide describes the information content of each section, but the information content cannot be verified by software.
2CDA HeaderConstraints
2.1Rendering 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 deemed to have been signed by an Authenticator. 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.
It is recommended that at least the following information from the header is rendered:
- Document title and document date
- Service and encounter types and date ranges as appropriate
- All persons named along with their roles and participations..
- Selected organizations named along with roles and participations.
- Record Target name, identifier and date of birth
2.2ClinicalDocument
The namespace for CDA R2 is urn:hl7-org:v3. The appropriate namespace must be used in the XML instance of the Clinical Document. In the examples in this specification, all elements are shown unprefixed, assuming that the default namespace is declared to be urn:hl7-org:v3. This specification does not require use of any specific namespace prefix. Instances should not include the xsi:schemaLocation[1]element.
CONF-DIR-1:The root of a History and Physical shall be a ClinicalDocument element from the urn:hl7-org:v3 namespace.
2.3Name, Address, Telephone Number, and Time Constraints
To support communication between the receiver of the document and the patient or any other person or organization mentioned within it, the elements representing them will be named.
CONF-DIR-2:All patient, guardianPerson, assignedPerson, maintainingPerson, relatedPerson, intendedRecipient/informationRecipient, associatedPerson, and relatedSubject/subject elements shall have a name.
CONF-DIR-3:All patientRole, assignedAuthor, assignedEntity[not(parent::dataEnterer)] and associatedEntity elements shall have an addr and telecom element.
CONF-DIR-4:All guardian, dataEnterer/assignedEntity, relatedEntity, intendedRecipient, relatedSubject and participantRole elements should have an addr and telecom element.
CONF-DIR-5:All guardianOrganization, providerOrganization, wholeOrganization, representedOrganization, representedCustodianOrganization, receivedOrganization, scopingOrganization and serviceProviderOrganization elements shall have name, addr and telecom elements.
When name, address, or telecom information is unknown and where these elements are required to be present, as with CDA conformance if the information is unknown, these elements will be represented using an appropriate value for the nullFlavor attribute on the element. Legal values according to this specification come from the HL7 NullFlavor vocabulary.
<assignedEntity>
<id extension='3' root='2.16.840.1.113883.19'/>
<addr nullFlavor='UNK'/>
<telecom nullFlavor='ASKU' use='WP'/>
<assignedPerson>
<name nullFlavor='NAV'/>
</assignedPerson>
</assignedEntity>
Figure 2: Various Uses of nullFlavor
Events occurring at a single point in time that are represented in the Clinical Document header will in general be precise to the day. These point-in-time events are the time of creation of the document; the starting time of a participation by an author, data enterer, authenticator, or legal authenticator; or the starting and ending time of an encounter.
CONF-DIR-6:Times or time intervals found in the ClinicalDocument/effectiveTime, author/time, dataEnterer/time, legalAuthenticator/time, authenticator/time and encompassingEncounter/effectiveTime elements shall be precise to the day, shall include a time zone if more precise than to the day[2], and should be precise to the second.
CONF-DIR-7:Times or time intervals found in the asOrganizationPartOf/effectiveTime, asMaintainedEntity/effectiveTime, relatedEntity/effectiveTime, serviceEvent/effectiveTime, ClinicalDocument/participant/time, serviceEvent/performer/time and encounterParticipant/time shall be precise at least to the year, should be precise to the day, and may omit time zone.
In CDA-conformant documents, all telephone numbers are to be encoded using a restricted form of the tel: URL [scheme as described below.
The telecom element is used to provide a contact telephone number for the various participants that requireit. The value attribute ofthis elements is a URL that specifies the telephone number, as indicated by the TEL data type
Within the specification, all telephone numbers are to be encoded using the grammar shown in Figure 3: Restricted URL grammar for telephone communications, which is a restriction on the TEL data type and RFC 2806[3]. It simplifies interchange between applications as it removes optional URL components found in RFC 2806 that applications typically do not know how to process, such as ISDN sub-address, phone context, or other dialing parameters.
A telephone number used for voice calls begins with the URL scheme tel:. If the number is a global phone number, it starts with a plus (+) sign. The remaining number is made up of the dialing digits and an optional extension and may also contain visual separators.
telephone-url= telephone-scheme ':' telephone-subscriber
telephone-scheme= 'tel'
telephone-subscriber = global-phone-number [ extension ]
global-phone-number= '+' phone-number
phone-number= digits
digits = phonedigit | digits phonedigit
phonedigit= DIGIT | visual-separator
extension = ';ext=' digits
visual-separator= '-' | '.' | '(' | ')'
Figure 3: Restricted URL grammar for telephone communications
CONF-DIR-8:Telephone numbers shall match the regular expression pattern
tel:\+?[-0-9().]+
CONF-DIR-9:At least one dialing digit shall be present in the phone number after visual separators are removed.
There is no way to distinguish between an unknown phone number and an unknown email or other telecommunications address. Therefore, the following convention will be used: Any telecom element that uses a flavor of null (has a nullFlavor attribute) is assumed to be a telephone number, which is the only required telecommunications address element within this DSTU.
CONF-DIR-10:If the telephone number is unknown it shall be represented using the appropriate flavor of null.