Diagnostic Imaging Report - dicom

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@laitek.com Co-Chair: Helmut Koenig, MD helmut.koenig@siemens.com (Committee Draft for) 1st Informative Ballot September 16, 2007 © 2007 Health Level Seven, Inc. Ann Arbor, MI All rights reserved. Revision History 0.3.14 0.3.15 0.4.17 0.4.18 0.4.19 0.4.20 0.4.21 0.4.22 September 30, 2006 January 10, 2007 April 29, 2007 July 8, 2007 July 15, 2007 August 28, 2007 September 12, 2007 September 16, 2007 Committee Committee Committee Committee Committee Committee Committee Committee draft from Boca Raton Meeting draft draft Draft Draft Draft Draft Draft 0.x.00 December xx, 2007 1st Informative Ballot Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 2 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Open Issues 1. Update Appendix B with current CDA ample 2. Update figures with snips from current CDA sample 3. Specify Detailed Level 3 description of measurements, annotation and image references. 4. Data enterer not in sample document 5. Information recipient not in sample document 6. ComponentOf/EncompassingEncounter not in sample document 7. Section 3.3.2 Rendering of Coded Observations into Section.text needs to be specified. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 3 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Table of Contents CDAR2_II_BIMGRPTS_R1 ........................................................................................... 1 IMPLEMENTATION GUIDE FOR CDA RELEASE 2 – DIAGNOSTIC IMAGING REPORT ........ 1 REVISION HISTORY ......................................................................................................... 2 OPEN ISSUES 3 TABLE OF CONTENTS ...................................................................................................... 4 FIGURES .............................................................................................................................. 6 FIGURES .............................................................................................................................. 6 TABLES................................................................................................................................ 6 1 1 2 DIAGNOSTIC IMAGING REPORT ................................................................................ 8 INTRODUCTION ............................................................................................................... 8 1.1 Purpose .......................................................................................................................... 8 1.2 Audience ........................................................................................................................ 8 1.3 Approach ....................................................................................................................... 8 1.4 Conventions Used in this Guide .................................................................................... 8 1.4.1 1.4.2 1.4.3 1.4.4 1.4.5 1.4.6 1.4.7 Explanatory Statements ................................................................................................ 8 Conformance Requirements .......................................................................................... 8 XPath Notation.............................................................................................................. 9 Key Words..................................................................................................................... 9 XML Samples ................................................................................................................ 9 DICOM Samples............................................................................................................ 9 Content of the Ballot Package........................................................................................ 9 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9 2.1.10 2.1.11 2.1.12 2.1.13 General Constraints .................................................................................................... 12 Rendering Information from the CDA Header for Human Presentation ......................... 12 ClinicalDocument/realmCode ..................................................................................... 12 ClinicalDocument/typeId ............................................................................................ 13 ClinicalDocument/templateId ..................................................................................... 13 ClinicalDocument/id ................................................................................................... 13 ClinicalDocument/code ............................................................................................... 14 ClinicalDocument/title ................................................................................................ 15 ClinicalDocument/effectiveTime ................................................................................. 15 ClinicalDocument/confidentialityCode ........................................................................ 16 ClinicalDocument/languageCode ................................................................................ 16 ClinicalDocument/setId and ClinicalDocument/versionNumber .................................. 16 ClinicalDocument/copyTime ....................................................................................... 16 1.5 Scope ........................................................................................................................... 10 CDA HEADER .............................................................................................................. 11 2.1 ClinicalDocument ......................................................................................................... 11 2.2 Participants ................................................................................................................. 17 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9 2.2.10 recordTarget............................................................................................................... 17 author ........................................................................................................................ 18 dataEnterer ................................................................................................................ 18 informant ................................................................................................................... 19 custodian .................................................................................................................... 19 informationRecipient .................................................................................................. 19 legalAuthenticator ...................................................................................................... 20 authenticator .............................................................................................................. 20 participant .................................................................................................................. 21 inFullfillmentOf ........................................................................................................... 21 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 4 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 2.2.11 2.2.12 2.2.13 2.2.14 3 BODY ......................................................................................................................... 25 3.1 Section Type Codes ..................................................................................................... 25 3.2 Sections ....................................................................................................................... 27 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 DICOM Object Catalog – DCM 121181 ........................................................................ 27 Findings – LOINC 18782-3 .......................................................................................... 28 Reason for Study – LOINC 18785-6 ............................................................................. 29 History of Present Illness – LOINC 10164-2 ................................................................. 30 Impressions – LOINC 19005-8 ..................................................................................... 30 3.3.1 3.3.2 3.3.3 Text Observations ....................................................................................................... 31 Code Observations ...................................................................................................... 32 Report Observations.................................................................................................... 32 3.3 4 documentationOf ........................................................................................................ 22 authorization .............................................................................................................. 23 relatedDocument ........................................................................................................ 23 componentOf .............................................................................................................. 24 Level 3 Content ............................................................................................................ 31 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 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 5 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Figures Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 1 Use of the templateId element to indicate use of this guide. ........................ 11 2 ClinicalDocument Example ..........................................................................12 3 ClinicalDocument/realmCode Example ........................................................ 12 4 ClinicalDocument/typeId Example .............................................................. 13 5 ClinicalDocument/templateId Example conforming to Level 1 only ..............13 6 ClinicalDocument/id Example ......................................................................13 7 ClinicalDocument/code Example .................................................................14 8 Use of the translation element to include local codes for document type. .....14 9 ClinicalDocument/title Example...................................................................15 10 CinicalDocument/effectiveTime Example ..................................................16 11 CinicalDocument/confidentialityCode Example .........................................16 12 ClinicalDocument/languageCode Example with language only ..................16 13 ClinicalDocument/languageCode Example with language and country. .....16 14 recordTarget Example ...............................................................................17 15 author Example ......................................................................................... 18 16 dataEnterer Example .................................................................................19 17 custodian Example ....................................................................................19 18 informationRecipient Example ...................................................................20 19 legalAuthenticator Example .......................................................................20 20 authenticator Example ..............................................................................21 21 participant Example ...................................................................................21 22 inFulfillmentOf Example.............................................................................22 23 documentationOf Example ........................................................................23 24 componentOf example ...............................................................................24 25 DICOM Object Catalog Example .................................................................28 26 Findings Example including Level 3 content ..............................................29 27 Reason for Study Example .........................................................................30 28 History Example ........................................................................................ 30 29 Impressions Example .................................................................................30 30 Text Element example ................................................................................32 31 Code Element example ...............................................................................32 32 Report Observation as an Entry .................................................................33 33 Report Observation as a support for an inferred finding ............................. 33 34 Image Reference Report Observation example ............................................34 35 Linear Measurement Report Observation example .....................................35 36 Linear Measurement Report Observation example .....................................35 37 Volume Measurement Report Observation example....................................35 38 Numeric Measurement Report Observation example ..................................36 Tables Table Table Table Table Table 1 2 3 4 5 Contents of the Ballot Package .....................................................................10 LOINC Document Type Codes ........................................................................15 Section Type Codes ....................................................................................... 25 Administrative Gender ...................................................................................38 Null Flavor ....................................................................................................39 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 6 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Table 6 Participating Function Codes.........................................................................40 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 7 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 1 Diagnostic Imaging Report 1 Introduction 1.1 Purpose The purpose of this document is to describe constraints on the CDA Header and Body elements for Diagnostic Imaging Reports. A Diagnostic Imaging Report contains a consulting specialist’s interpretation of image data. It is intended to convey the interpretation to the referring (ordering) physician, and becomes part of the patient’s medical record. It is intended for use in Radiology, Endoscopy, Cardiology, and other imaging specialties. 1.2 Audience The audience for this document is software developers and consultants responsible for implementation of Radiology Information Systems, Radiology Reporting systems, Picture Archiving and Communications Systems (PACS), and other image and imaging management systems, that are expected to transmit results to of Electronic Health Record (EHR) systems or health information exchange networks as CDA documents created according to this specification. 1.3 Approach The approach taken in the development of this specification was to review existing relevant DICOM Standards and IHE Implementation Profiles, and to review CDA Header and Body elements and attributes with domain experts, and on that basis, constrain the CDA Header and Body elements. 1.4 Conventions Used in this Guide This guide is a conformance profile, as described in the Refinement and Localization section of the HL7 Version 3 standards. As defined in that document, this guide is both an annotation profile and a constraint profile. The base standard for this guide is the HL7 Clinical Document Architecture, Release 2.0. The mapping profile for SR to CDA is based on DICOM Template 2000 Basic Diagnostic Imaging Report, NEMA PS3.16-2007. 1.4.1 Explanatory Statements As an annotation profile, portions of this guide summarize or explain the base standard. Explanatory statements will appear in this style. 1.4.2 Conformance Requirements Conformance requirements within this guide are sequentially numbered, and appear in the format illustrated below: Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 8 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. CONF-1: This is an example conformance requirement for conformance to level 1 requirements. 1.4.3 XPath Notation Instead of the traditional dotted notation used by HL7 to represent RIM classes, this guide uses XPath notation in conformance statements and elsewhere to identify the XML elements and attributes within the CDA document instance to which various constraints are applied. The implicit context of these expressions is the root of the document. The purpose of using this notation is to provide a mechanism which will be familiar to developers for identifying parts of an XML document. 1.4.4 Key Words The key words "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "NEED NOT" in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide. 1.4.5 XML Samples XML Samples appear in various figures in this document in a fixed font. Portions of the XML content may be suppressed for brevity. These are marked by a vertical ellipses, as shown in the example below. <ClinicalDocument xmlns='urn:hl7-org:v3'> : . </ClinicalDocument> Within the narrative, XML element and attribute names in the text will appear in this font. Literal attribute values will appear in this font. XPath expressions are used in the narrative and conformance requirements to identify elements. These were chosen because they are familiar to many XML implementers. 1.4.6 DICOM Samples DICOM Samples appear in the table format used in the DICOM Standard, listing each DICOM Attribute as a single line with columns denoting the Attribute Tag, Name, Value Representation and usage description. Examples of DICOM SR documents are presented in the notation used in Clunie, David, DICOM Structured Reporting, PixelMed Publishing, Bangor, PA, 2000. Available at: http://www.pixelmed.com (link checked ____,__, 2007). DICOM Images referenced in the samples may be presented herein a header in DICOM tabular form followed by a rendering of the pixel data into the publishing format of this document. The DICOM binary encoded form in included in the ballot package. 1.4.7 Content of the Ballot Package The ballot package contains the following files: Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 9 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Filename Description Diagnostic Imaging Report for CDA Release 2 Level 13 v1.0.pdf This guide DICOM SR “Basic Diagnostic Imaging Report” to HL7 CDA Release 2 “Diagnostic Imaging Report” Transformation Guide The transformation guide specifying the mapping of constrained DICOM SR “Basic Diagnostic Imaging Reports” (DICOM PS 3.16-2007: Template 2000) to CDA Release 2 “Diagnostic Imaging Reports” as described by this guide. EnhancedSR.xml The sample CDA document found in Appendix B. voc.xml A vocabulary data file used by both the Schematron schema and the display stylesheet. IMPL_CDAR2.xsl A stylesheet for displaying the content of the sample document in HTML. EnhancedSR.dcm The sample DICOM SR document found in Appendix C. SampleChestXR_PA.dcm SampleChestXR_Lat.dcm Sample DICOM images referenced within the DICOM SR document EnhancedSR…dcm Table 1 Contents of the Ballot Package 1.4.7.1 Sample DICOM SR Basic Diagnostic Imaging Report The Sample DICOM SR report conforms to DICOM Template 2000 for a diagnostic imaging report including image annotation and references. This SR report is equivalent in content to the Sample CDA document, according to the mapping described on Appendix B. The Report example is based on a chest radiography examination, the images from whick are included in two DICOM Image files, SampleChestXR_PA.dcm and SampleChestXR_Lat.dcm. The report examples include references to these images. 1.4.7.2 Constrained CDA Diagnostic Imaging Report XML Schema Also included in this ballot package is a CDA XML Schema constrained to the elements allowed in this Implementation Guide. This Schema is informative, and implementers should be cautioned that not all constraints in this guide are represented in the XML Schema. 1.4.7.3 Sample XML A sample document is provided which conforms to the level 1 and level 2 constraints of this guide. This document is the source of many of the examples provided in this guide. 1.5 Scope This specification defines additional constraints on CDA Header and Body elements used in a Diagnostic Imaging Report, and provides examples of conforming fragments in the body of the document and an example of a conforming XML instance as an appendix. This Guide specifies three levels of conformance requirements. Level 1 requirements specify constraints upon the CDA Header and the content of the document. Level 2 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 10 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. requirements specify constraints upon the structuredBody of the ClinicalDocument element of the CDA document. Level 3 requirements describe a limited set of structured entries for the purpose of referencing and annotating images from within the report. This specification is intended for global use (Universal Realm). The specification of workflows, messages, or procedures used in performing imaging procedures is outside the scope of this specification. CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that the CDA instance not only conforms to the CDA specification, but in addition, conforms to the constraints specified in this implementation guide. <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"> <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> <templateId root="2.16.840.1.113883.10" extension="CDAR2_II_BIMGRPTS_R1"/> : . : </ClinicalDocument> Figure 1 Use of the templateId element to indicate use of this guide. Within this guide, the required and optional content within the body are identified. This guide describes the information content of each section, but this cannot be verified by software. 2 CDA Header 2.1 ClinicalDocument The namespace for CDA Release 2.0 is urn:hl7-org:v3. Appropriate namespace declarations SHALL be used in the XML instance of the Clinical Document. In the examples in this specification, all elements are shown un-prefixed, assuming that the default namespace is declared to be urn:hl7-org:v3. This guide does not require use of any specific namespace prefix. Transmitted instances SHOULD NOT include the xsi:schemaLocation1 element. The root of a Diagnostic Imaging Report SHALL be a ClinicalDocument element from the urn:hl7org:v3 namespace. The xsi:schemaLocation element is not recommended by the XML ITS because of security risks. Receivers who choose to perform validation should use a locally cached schema. 1 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 11 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd"> <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> <templateId root="2.16.840.1.113883.10" extension="CDAR2_II_BIMGRPTS_R1"/> <id root="1.2.840.113619.2.62.994044785528.20060828170821659"/> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Diagnostic Imaging Report"/> <title>Chest X-Ray, PA and LAT View</title> <effectiveTime value="20060828170821"/> <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/> <languageCode code="en-US"/> : . : </ClinicalDocument> Figure 2 ClinicalDocument Example 2.1.1 General Constraints All telephone numbers SHALL be encoded using a restricted form of the tel: URL scheme, described in the section on Error! Reference source not found. below. 2.1.2 Rendering Information from the CDA Header for Human Presentation Rendering the information in the header for human presentation is optional. However, un-rendered information cannot be assumed to be authenticated information. Therefore, the judgment of whether to render or not render information in the header should recognize the business need to authenticate the information as well as other business needs. Recommendations for rendering information from the header include: 2.1.3  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 ClinicalDocument/realmCode This value identifies the realm2. The ClinicalDocument/realmCode element MAY be present. If present, it SHALL use the fixed value UV. <realmCode code='UV'/> Figure 3 ClinicalDocument/realmCode Example 2 This guide is for the Universal realm. A future guide may define national localizations. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 12 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 2.1.4 ClinicalDocument/typeId The ClinicalDocument/typeId element SHALL be present. It identifies the constraints imposed by CDA Release 2.0 on the content, essentially acting as a version identifier. The @root and @extension values of this element SHALL be specified as shown below in Figure 4. <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> Figure 4 ClinicalDocument/typeId Example CONF-1: The extension attribute of the typeId element SHALL be POCD_HD000040. 2.1.5 ClinicalDocument/templateId The ClinicalDocument/templateId elements identify the templates that impose constraints on the content. At least one ClinicalDocument/templateId of SHALL be present with the content shown below in Figure 5. This indicates conformance to the level one features of this guide. CONF-2: A ClinicalDocument/templateId element SHALL be present where the value of @extension is CDAR2_II_BIMGRPTS_R1 and the value of @root is 2.16.840.1.113883.10. <templateId root="2.16.840.1.113883.10" extension="CDAR2_II_BIMGRPTS_R1"/> Figure 5 ClinicalDocument/templateId Example conforming to Level 1 only 2.1.6 ClinicalDocument/id The ClinicalDocument/id element SHALL be present.. It SHALL be an II data type where the root is an OSI Object Identifier (OID). The root uniquely identifies the scope of the extension. The root and extension uniquely identifies the document. CONF-3: The ClinicalDocument/id/@root attribute SHALL be a syntactically correct OID. CONF-4: OIDs SHALL be represented in dotted decimal notation, where each decimal number is either 0, or starts with a non-zero digit. More formally, an OID SHALL be in the form ([0-2])(.([1-9][0-9]*|0))+. CONF-5: OIDs SHALL be no more than 64 characters in length. <id root="1.2.840.113619.2.62.994044785528.20060828170821659"/> Figure 6 ClinicalDocument/id 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: http://hl7.amg-hq.net/oid/frames.cfm Another useful resource lists the many ways to obtain a registered OID Root for free or a small fee, anywhere in the world, located at: http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 13 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. The manner in which the OID root is obtained is not constrained by this implementation guide. When a DICOM SR report is transformed to a CDA Diagnostic imaging Report, the ClinicalDocument/id/@root identifier is equivalent to the DICOM Attribute (0008,0018) SOP Instance UID and the ClinicalDocument/id/@extension identifier is not present. For compatibility with DICOM SR documents, ClinicalDocument/id/@extension SHALL NOT be present in Diagnostic Imaging Reports authored as CDA Documents. CONF-6: The ClinicalDocument/id/@extension attribute SHALL NOT be present. 2.1.7 ClinicalDocument/code The ClinicalDocument/code element SHALL be present and specifies the type of the clinical document. The LOINC Diagnostic Imaging Report document type (LOINC Document Code 18748-4) SHOULD be used as the value for ClinicalDocument/code in the CDA Header. <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Diagnostic Imaging Report"/> Figure 7 ClinicalDocument/code Example CDA Release 2.0 states that LOINC is the preferred vocabulary for document type specification. 2.1.7.1 Use of Local Document Type Codes Implementations MAY use local codes in translation elements to further refine the document type. An example of this is shown below in Figure 8. <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Diagnostic Imaging Report <translation code='XRPEDS' displayName='Pediatric Radiography Report' codeSystem='2.16.840.1.123456.78.9'/> </code> Figure 8 Use of the translation element to include local codes for document type. 2.1.7.2 Precoordinated Document Type Codes The LOINC document hierarchy listed in Table 2 is a list of document type codes supported under this specification. Some of these codes (those not marked in boldface type), are pre-coordinated with either the imaging modality, body part examined or specific imaging method such as the view. Use of these codes is not recommended, as this duplicates information potentially present with the CDA document header. When these codes are used, they SHALL NOT conflict with the other information present in the document. These codes are shown below in Table 2. LOINC Code Display Name Modality Diagnostic Imaging Report Any 18747-6 CT Report Cumputed Tomography 18755-9 MRI Report Magnetic Resonance Imaging 18748-4 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 14 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 18760-9 Ultrasound Report Ultrasoound 18757-5 Nuclear Medicine Report Nuclear Medicine 18758-3 PET Scan Report Positron Emission Tomography 18745-0 Cardiac Catheterization Report Cardiac Radiography/Fluoroscopy 11522-0 Echocardiography Report Cardiac Ultrasound 18782-3 X-ray Report 18752-6 Exercise stress test report 18754-2 Holter Study 18750-0 Cardiac Electrophysiology 11524-0 ECG Report 38269-7 Bone Mineral Densitometry Report Bone Densitometry 18748-4 Breast Imaging Report Mammography 18750-0 Cardiac Electrophysiology Report 11524-0 ECG Report 18752-6 Exercise Stress Test Report 18754-2 Holter Study Report Projection Radiography Table 2 LOINC Document Type Codes These codes are drawn from LOINC version 2.16, December 2005 and equal the subset of LOINC whose scale is DOC and which refer to reports for diagnostic imaging procedures. CONF-7: If pre-coordinated document type codes are used, values used in imaging procedure code ClinicalDocument/documentationOf/serviceEvent/code SHALL NOT conflict with ClinicalDocument/code. 2.1.8 ClinicalDocument/title The title element MAY be present and specifies the local name used for the document. Many provider organizations will desire to have document titles more specific than the generic Display Name of the Document Type Code. For example, instead of Diagnostic Imaging Report, one may wish to have the title be “Chest CT Report”. Implementers may generate this automatically from available information specifying procedure, modality, body part, etc. The method of such derivation is not specified in this specification. <title>Chest X-Ray, PA and LAT View</title> Figure 9 ClinicalDocument/title Example 2.1.9 ClinicalDocument/effectiveTime The ClinicalDocument/effectiveTime element SHALL be present and specifies the creation time of the content of the document. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 15 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. All Diagnostic Imaging Reports authored by direct input to a computer system SHOULD record an effectiveTime that is precise to the second. When authored in other ways, for example, by dictation and transcription, the precision of effectiveTime may be less. <effectiveTime value="20060828170821"/> Figure 10 CinicalDocument/effectiveTime Example 2.1.10 ClinicalDocument/confidentialityCode The ClinicalDocument/confidentialityCode SHALL be present. It specifies the confidentiality assigned to the document. This implementation guide provides no guidance on documents with respect to the vocabulary used for confidentialityCode, nor treatment or implementation of confidentiality. A Fixed Value of “N” (normal) is used when the CDA document is transformed from DICOM SR. A CDA Release 2.0 conforming example is shown below. <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/> Figure 11 CinicalDocument/confidentialityCode Example 2.1.11 ClinicalDocument/languageCode The ClinicalDocument/languageCode element SHALL be present. It specifies the language of the Diagnostic Imaging Report. The encoding of the language SHALL be present, and SHALL be in the form nn (see Figure 12) or nn-CC (see Figure 13), where nn is a two letter ISO-639-1 language code in lower case, and CC is a two letter ISO-3166 Country code in upper case. This is a subset of the values defined by RFC 3066. CONF-8: The languageCode element SHALL be present. CONF-9: The language code SHALL be in the form nn, or nn-CC. CONF-10: The nn portion SHALL be a legal ISO-639-1 language code in lower case. CONF-11: The CC portion, if present SHALL be an ISO-3166 country code in upper case. <languageCode code="en" Figure 12 ClinicalDocument/languageCode Example with language only <languageCode code="en-US" Figure 13 ClinicalDocument/languageCode Example with language and country. 2.1.12 ClinicalDocument/setId and ClinicalDocument/versionNumber The ClinicalDocument/setId and ClinicalDocument/versionElements, SHALL be absent. CONF-12: Both ClinicalDocument/setId and ClinicalDocument/versionNumber SHALL be absent. 2.1.13 ClinicalDocument/copyTime The ClinicalDocument/copyTime element has been deprecated in CDA Release 2, therefore it SHALL NOT be present in conforming instances of a Diagnostic Imaging Report. CONF-13: A ClinicalDocument/copyTime element SHALL NOT be present. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 16 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 2.2 Participants This section describes the constraints placed upon CDA Participants described in the CDA Header. In the HL7 Clinical Document Architecture, Release 2.0 specification, section 4.2.2.13 describes various Participant Scenarios, where a single person can participate in several roles. In these cases, the person SHOULD be listed for each role, as described in the CDA Release 2.0 specification. 2.2.1 recordTarget The recordTarget element SHALL be present. It SHALL be the patient in whose medical record the report is to be placed. CONF-14: At least one recordTarget/patientRole element SHALL be present. The birthTime and administrativeGenderCode SHALL be present as this information is needed by users of a Diagnostic Imaging Report. If unknown, it SHALL be represented using a flavor of null. Values for administrativeGenderCode SHOULD be drawn from the HL7 AdministrativeGender vocabulary. CONF-15: A patient/birthTime element SHALL be present. CONF-16: A patient/administrativeGenderCode element SHALL be present. The maritalStatusCode, religiousAffiliationCode, raceCode and ethnicGroupCode elements MAY be present. CONF-17: If maritalStatusCode, religiousAffiliationCode, raceCode and ethnicGroupCode elements are present, they SHOULD be encoded using appropriate HL7 vocabularies. CONF-18: The guardian element SHOULD be present when the patient is a minor child. The providerOrganization element MAY be present. <recordTarget> <patientRole> <id root="1.2.840.113619.2.62.994044785528.10" extension="0000680029"/>  <patient> <name> <given>John</given>  <family>Doe</family> </name> <administrativeGenderCode codeSystem="2.16.840.1.113883.5.1" code="M"/>  <birthTime value="19641128"/>  </patient> </patientRole> </recordTarget> Figure 14 recordTarget Example Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 17 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 2.2.2 author The author element SHALL be present. It represents the creator of the document. If the role of the actor is the entry of information from his or her own knowledge or application of skills, that actor SHOULD be represented as the author. If one actor provides information to another actor, who filters, reasons, or algorithmically creates new information, then that second actor is also an author, having created information from his or her own knowledge or skills. However, that determination is independent from the determination of the first actor's authorship. <author> <time value="20060823224352"/> <assignedAuthor> <id extension="121008" root="2.16.840.1.113883.19.5"/> <assignedPerson> <name> <given>Richard</given> <family>Blitz</family> <suffix>MD</suffix> </name> </assignedPerson> </assignedAuthor> </author> Figure 15 author Example The time element SHALL be present. It SHALL be the starting time of the author's participation in the creation of the document. CONF-19: The author/time element SHALL be present. The assignedAuthor/id element SHALL be present. CONF-20: The assignedAuthor/id element SHALL be present. An assignedAuthor/assignedPerson or assignedAuthor/assignedAuthoringDevice element SHALL be present. This is the person or device authoring the document. CONF-21: An assignedAuthor element SHALL contain at least one assignedPerson or assignedAuthoringDevice elements. 2.2.3 dataEnterer This element MAY be present. It represents the person, usually a transcriptionist, who transferred the information from other sources into the Diagnostic Report. A person can participate as both author and dataEnterer. If the role of the actor is to transfer information from one source to another (e.g., transcription, or transfer from paper form to electronic system), that actor SHOULD be recorded as dataEnterer. CONF-22: When dataEnterer is present, an assignedEntity/assignedPerson element SHALL be present. The time element MAY be present. If present, it represents the starting time of entry of the data. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 18 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. <dataEnterer> <time value='20050329222451+0500'/> <assignedEntity> <id extension='2' root='1.3.6.4.1.4.1.2835.2'/> <assignedPerson> <name> <prefix>Mrs.</prefix> <given>Bernice</given> <family>Wiseman</family> </name> </assignedPerson> </assignedEntity> </dataEnterer> Figure 16 dataEnterer Example 2.2.4 informant The informant element SHALL NOT be present. 2.2.5 custodian The custodian element SHALL be present. This SHALL be the custodian of the Diagnostic Imaging Report document. The Custodian is optional in DICOM SR documents. When transforming from SR to CDA and Custodian is not present in the source document, it shall be set according to organizational policies. <custodian> <assignedCustodian> <representedCustodianOrganization> <id root="1.2.840.113619.2.62.994044785528"/> <name>World University Hospital</name> </representedCustodianOrganization> </assignedCustodian> </custodian> Figure 17 custodian Example 2.2.6 informationRecipient The ClinicalDocument/informationRecipient element MAY be present3. This element records the intended recipient of the information at the time the document is created. The Referring Physician, if present, SHALL be recorded as an informationRecipient. When no referring physician is preesnt, as in the case of self-referred screening examinations allowed by law, the intendedRecipient may be null with a nullFlavor of “OTH”. The intended recipient MAY also be the health chart of the patient, in which case the receivedOrganization SHALL be the scoping organization of that chart. CONF-23: When informationRecipient is used, at least one informationRecipient/intendedRecipient/informationRecipient or informationRecipient/intendedRecipient/recievedOrganization SHOULD be present. Note that there are two elements in the CDA Release 2.0 schema that are named informationRecipient. The outermost of these elements is what is being discussed here. The second element with the same name may appear as a descendent of this one. 3 Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 19 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. <informationRecipient> <intendedRecipient> <id extension='4' root='1.3.6.4.1.4.1.2835.2'/> <addr> <streetAddressLine>21 North Ave</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>01803</postalCode> <country>USA</country> </addr> <telecom value='tel:(999)555-1212' use='WP'/> <informationRecipient> <name> <prefix>Dr.</prefix> <given>Phil</given> <family>Green</family> </name> </informationRecipient> <receivedOrganization> <name>Good Health Clinic</name> </receivedOrganization> </intendedRecipient> </informationRecipient> Figure 18 informationRecipient Example 2.2.7 legalAuthenticator The legalAuthenticator element SHALL be present if the document has been legally authenticated. It SHALL identify the legal authenticator of the document. Diagnostic Imaging Reports MAY be released before legal authentication, based on local practice. This implies that a Diagnostic Imaging Report that does not contain this element has not been legally authenticated. CDA Release 2 allows only one Legal Authenticator. In the case of diagnostic reports that are double read by physicians with authenticating privilege, one of the physicians is recorded as the legalAuthenticator, and the other is recorded as an Authenticator. Institutional policy may dictate which physician is the legalAuthenticator. CONF-24: The assignedEntity/assignedPerson element SHALL be present in legalAuthenticator. <legalAuthenticator> <time value="20060827141500"/> <signatureCode code="S"/> <assignedEntity> <id extension="08150000" root="1.2.840.113619.2.62.994044785528.33"/> <assignedPerson> <name> <given>Richard</given> <family>Blitz</family> <suffix>MD</suffix> </name> </assignedPerson> </assignedEntity> </legalAuthenticator> Figure 19 legalAuthenticator Example 2.2.8 authenticator An authenticator MAY be present. The authenticator SHALL identify a participant who verified the accuracy of the information in the document. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 20 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. In radiology reporting environments, the authenticator would typically be a resident who dictated the initial report and reviewed and approved the transcribed version, but the report would still need to be legally authenticated by an attending radiologist. CONF-25: The assignedEntity/assignedPerson element SHALL be present in an authenticator element. <legalAuthenticator> <time value="20060827134500"/> <signatureCode code="S"/> <assignedEntity> <id extension="1234567" root="1.2.840.113619.2.62.994044785528.33"/> <assignedPerson> <name> <given>Robert</given> <family>Resident</family> <suffix>MD</suffix> </name> </assignedPerson> </assignedEntity> </legalAuthenticator> Figure 20 authenticator Example participant 2.2.9 The participant element MAY be present. The participant SHALL identify the physician requesting the imaging procedure (the referring physician). CONF-26: The assignedEntity/assignedPerson element SHALL be present in an participant element. <participant typeCode="REF"> <associatedEntity classCode="PROV"> <id nullFlavor="UNK"/> <associatedPerson> <name> <given>John</given> <family>Smith</family> <suffix>MD</suffix> </name> </associatedPerson> </associatedEntity> </participant> Figure 21 participant Example . 2.2.10 inFullfillmentOf The inFullfillmentOf elements MAY be present. They represent the Placer Order that was fulfilled in by the imaging procedure(s) covered by this report document. The Placer Order is either a group of of order (modeled as PlacerGroup in the Placer Order RMIM of the Orders & Observations domain) or a single order item (modeled as ObservationRequest in the same RMIM). This optionality reflects two major approaches to the grouping of procedures as implemented in the installed base of imaging information systems. These approaches differ in their handling of grouped procedures and how they are mapped to identifiers in the DICOM image and structured reporting data. The example of a CT examination covering chest, abdomen and pelvis will be used in the discussion below: Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 21 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved.  In the IHE Scheduled Workflow model, the Chest CT, Abdomen CT and Pelvis CT each represent a Requested Procedure, and all three procedures are grouped under a single Filler Order. The Filler Order number maps directly to the DICOM Accession Number in the DICOM imaging and report data.  A widely deployed alternative approach maps the requested procedure identifiers directly to the DICOM Accession Number. The Requested Procedure ID in such implementations may or may not be different from the Accession Number but is of little identifying importance because there is only one Requested Procedure per Accession Number. There is no identifier that formally connects the requested procedures ordered in this group. In both cases, inFullfillmentOf/order/id is mapped to the DICOM Accession Number in the imaging data. <inFulfillmentOf> <order> <id extension="10523475" root="1.2.840.113619.2.62.994044785528.27"/>  </order> </inFulfillmentOf> Figure 22 inFulfillmentOf Example 2.2.11 documentationOf One or more documentationOf elements SHALL be present. Each documentationOf/ServiceEvent SHALL indicate an imaging procedure that the provider describes and interprets in the content of the Diagnostic Imaging Report. The main activity being described by this document is the interpretation of the imaging procedure. This is shown by setting the value of the @classCode attribute of the serviceEvent element to ACT, and indicating the duration over which care was provided in the effectiveTime element. Within the documentationOf element, there is one serviceEvent element. This event is the unit imaging procedure corresponding to a billable item. The type of imaging procedure MAY be further described in the serviceEvent/code element. This guide makes no specific recommendations about the vocabulary to use for describing this event. CONF-27: One or more ClinicalDocument/documentationOf elements SHALL be present. CONF-28: The value of the serviceEvent/@classCode attribute SHALL be ACT (a Healthcare Service). CONF-29: One or more serviceEvent/id elements SHALL be present. In IHE Scheduled Workflow environments, one serviceEvent/id element contains the DICOM Study Instance UID from the Modality Worklist, and the second serviceEvent/id element contains the DICOM Requested Procedure ID from the from the Modality Worklist, CONF-30: If present, the value of serviceEvent/code SHALL NOT conflict with the ClininicalDocument/code. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 22 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. The effectiveTime for the serviceEvent covers the duration of the imaging procedure being reported. This event SHOULD have one or more performers, which MAY participate at the same or different periods of time. Service events map to DICOM Requested Procedures. That is documentationOf/ServiceEvent/id is ID of the Requested Procedure. CONF-31: The effectiveTime element of the serviceEvent element SHOULD be present. CONF-32: The effectiveTime element SHOULD contain both a low and a high element. CONF-33: A serviceEvent SHOULD have at least one performer. There are cases where no performers might be listed, for example, in cases where the information is not available. CONF-34: The performer elements SHOULD list the persons performing the procedure(s) being reported. This would normally be the technologist performing the imaging procedure. The specific type of performer MAY be described in performer/assignedEntity/code. CONF-35: If present, the values for performer/assignedEntity/code SHALL be drawn from SNOMED CT, using concepts that descend from the healthcare professional subtype hierarchy (SNOMED CT Concept ID: 223366009). CONF-36: The performer/assignedEntity/code if present SHALL have a value drawn from the SNOMED CT healthcare professional subtype hierarchy. CONF-37: Every performer/assignedEntity element SHALL have at least one assignedPerson or representedOrganization. The time element of the performer element MAY be present. If present, it indicates the time span over which healthcare services are provided, if different from that of the service event. <documentationOf> <serviceEvent classCode="ACT"> <id root="1.2.840.113619.2.62.994044785528.114289542805"/>  <id extension="123453" root="1.2.840.113619.2.62.994044785528.26"/>  </serviceEvent> </documentationOf> Figure 23 documentationOf Example 2.2.12 authorization The authorization elements MAY be present. This document provides no guidance on the encoding of authorization elements. 2.2.13 relatedDocument relatedDocument elements MAY be present. A Diagnostic Imaging Report may have three types of parent document:  A superseded version that the present document wholly replaces (typeCode = RPLC). Diagnostic Imaging Reports may go through stages of revision prior to being legally authenticated. Such early stages may be drafts from transcription, or those created by residents, Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 23 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. or other pleliminary versions. Policies not covered by this specification may govern requirements for retention of such earlier versions, but except for forensic purposes, the latest version in a chain of revisions represents the complete and current report.  An original version that the present document appends (typeCode = APND). When a Diagnostic Imaging Report is legally authenticated, it cannot thereafter be replaced, but is only amended by a separate addendum document that references the original.  A source document from which the present document is transformed (typeCode = XFRM). A Diagnostic Imaging Report may be created by transformation from a DICOM SR document or from another Diagnostic Imaging Report. An example of the latter case is the creation of a derived document for use in a claims attachment. When the parent document legally authenticated, it SHALL NOT be replaced. It may only be appended or transformed. 2.2.14 componentOf When the Diagnostic imaging procedure is performed in the context of a hospital stay or and outpatient visit for which there is an Encounter Number, that number SHOULD be is present in as the id of the encompassingEncounter. EncompassingEncounter.id is not available from DICOM SR documents, if Physian’s Reading Studies shall be mapped as Encounter participant (Performer), the null flavor UNK (unknown) shall be used The id element of the encompassingEncounter SHALL be present and represents the identifier for the encounter. CONF-38: The encompassingEncounter element SHALL have an id element. The effectiveTime MAY be present, and represents the time interval or point in time in which the encounter took place. The encompassing encounter might be that of the office visit in which the Diagnostic Imaging procedure was ordered. CONF-39: The encompassingEncounter element MAY have an effectiveTime element. The responsibleParty element MAY be present. If present, it represents only the party responsible for the encounter, not necessarily the entire episode of care. CONF-40: The responsibleParty/assignedEntity element SHALL have at least one assignedPerson or representedOrganization element present. <componentOf> <encompassingEncounter> <id extension='9937012' root='1.3.6.4.1.4.1.2835.12'/> <effectiveTime> <low value='20050329'/> <high value='20050329'/> </effectiveTime> </encompassingEncounter> </componentOf> Figure 24 componentOf example Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 24 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 3 Body A Diagnostic Imaging Report SHALL have a structuredBody element. The content of this element makes up the human readable text of the document. This information SHALL be organized into sections and MAY have sub-sections. CONF-41: A nonXMLBody/text SHOULD not contain both a reference element and character data. 3.1 Section Type Codes The Section Type codes used in this guide are described below in Table 3. All section codes shown in this table describe narrative document sections4. The column headings of this table are described below: DCM Code: DCM Code Meaning: LOINC Code: LOINC Component Name: Use: DCM Code The code of the section in DICOM (Context Group CID 7001). The display name of the section in DICOM (Context Group CID 7001).. The code of the section in LOINC. The display name of the section in LOINC. The use column indicates that a section in a Diagnostic Imaging Report is: R – required C – conditionally required O – optional DCM Code meaning LOINC Code 121181 DICOM Object Catalog 121060 History 121062 Request 121064 Current Procedure Descriptions 121066 Prior Procedure Descriptions 121068 Previous Findings 121070 Findings 121072 Impressions 121074 Recommendations LOINC Component Name Use C O O O O 18834-2 RADIOLOGY COMPARISON STUDY OBSERVATION O 18782-3 RADIOLOGY STUDY OBSERVATION R 19005-8 RADIOLOGY - IMPRESSION O 18783-1 RADIOLOGY STUDY RECOMMENDATION O 121076 Conclusions 121078 Addendum O O 121109 Indications for Procedure 121110 Patient Presentation 121113 Complications 121111 Summary 121180 Key Images 18785-6 RADIOLOGY REASON FOR STUDY O O O O O Table 3 Section Type Codes The DICOM Object Catalog section (see § 3.3.1), if present, SHALL be the first section in the document body. 4 SCALE_TYP = 'NAR' in the LOINC tables. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 25 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Subsequent sections SHOULD appear in the order shown above. Sections within the Diagnostic Imaging Report content SHOULD have a title. A section element in a level 2 conforming Diagnostic Imaging Report SHOULD have a non-empty title element. The remainder of the examples in this section all show sample content that would appear in the structuredBody element. For level 2 conformance, all section elements that are present in the body of the document SHALL have a code and some non-blank text or one or more subsections, even if the purpose of the text is only to indicate that information is unknown. CONF-42: A section element SHALL have a code element. CONF-43: A section SHALL contain at least one text element or one or more component elements. CONF-44: All text or component elements SHALL contain content. For compatibility with DICOM SR reports, which do not have section titles apart from the Code Meaning of the section container’s Concept Name code, the CDA Section title SHALL be identical to the displayName of the Section Code. CONF-45: A Section/title element SHALL be present and SHALL have content equal to the content of Section/code@displayName. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 26 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 3.2 Sections Required and optional sections are described below. The sections “Reason for Study”, “History of Present Illness” and “Impressions”, detailed below, are three examples of optional sections. Others, as set forth in Table 2, may also be present. 3.2.1 DICOM Object Catalog – DCM 121181 A DICOM Object Catalog SHALL be present if the document contains references to DICOM Images, and if present SHALL be the first section in the CDA document body, Structured Reports or other DICOM composite objects. The DICOM Object Catalog lists all referenced objects and their parent Series and Studies, plus other DICOM attriburtes required for retrieving the objects. DICOM Object Catalog sections are not intended for viewing, and contain empty section text. CONF-46: A DICOM Object Catalog SHALL be present if the document contains references to DICOM Images. CONF-47: If present, the DICOM Object Catalog section SHALL be the first section in the CDA document body, CONF-48: A DICOM Object Catalog section SHALL have an empty or absent section/text element. Error! Reference source not found. Figure 26, below, shows a sample of an Object Catalog section. <component> <section classCode="DOCSECT" moodCode="EVN"> <code code="121181" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="DICOM Object Catalog"/> <text/> <entry>  <act classCode="ACT" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.114289542805"/> <code code="113014" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Study"/>  <entryRelationship typeCode="COMP"> <act classCode="ACT" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823223142485051"/> <code code="113015" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Series"> <qualifier> <name code="121139" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Modality"> </name> <value code="CR" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Computed Radiography"> </value> </qualifier> </code>   <entryRelationship typeCode="COMP"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/> <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage"> <originalText> <reference value="#finding3"/> </originalText> Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 27 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.9940 44785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051 &objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentTyp e=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entryRelationship> <entryRelationship typeCode="COMP"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232231422.3"/> <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage"> <originalText> <reference value="#finding4"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.99404478552 8.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&ob jectUID=1.2.840.113619.2.62.994044785528.20060823.200608232231422.3&contentType=appli cation/DICOM"/>  </text> <effectiveTime value="20060823223142"/> </observation> </entryRelationship> </act> </entryRelationship> </act> </entry> </section> </component> Figure 25 DICOM Object Catalog Example 3.2.2 Findings – LOINC 18782-3 A Findings Section SHALL be present. The Findings section contains the main narrative body of the report. This section SHOULD contain only the direct observations in the report, with topics such as Reason for Study, History, and Impression placed in separate sections. However, in cases where the source of report content provides a single blob of text not separated into these sections, that text SHALL be placed in the Findings section. <component> <section> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"/> <text> <content ID="finding1">The cardiomediastinum is within normal limits. The trachea is midline. The previously described opacity at the medial right lung base has cleared. There are no new infiltrates. There is a new round density at the left hilus, superiorly (diameter about 45mm). A CT scan is recommended for further evaluation. The pleural spaces are clear. The visualized musculoskeletal structures and the upper abdomen are stable and unremarkable.</content> <content ID="finding2"> 45 mm diameter</content> <content ID="finding3"> Image</content> Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 28 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. <linkHtml href="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.99404 4785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051& amp;objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType =application/DICOM" name="Computed Radiography Image Storage"/> </text> <entry> <observation classCode="OBS" moodCode="EVN"> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"> </code> <text> <reference value="#finding1"/> </text>  <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship>  <entryRelationship typeCode="SUBJ"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>  <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">  <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.9940 44785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051 &objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentTyp e=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entryRelationship> </observation> </entry> </section> </component> Figure 26 Findings Example including Level 3 content 3.2.3 Reason for Study – LOINC 18785-6 The indication for the imaging procedure SHOULD be present as a separate section. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 29 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. <component> <section> <code code="18785-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Reason for study"/> <text>Suspected lung tumor</text> </section> </component> Figure 27 Reason for Study Example 3.2.4 History of Present Illness – LOINC 10164-2 Relevant patient history MAY be present as a separate section. <component> <section> <code code="10164-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="History of present illness"/> <text>Sore throat.</text> </section> </component> Figure 28 History Example 3.2.5 Impressions – LOINC 19005-8 Radiologist’s impression SHALL be present unless the Impression content is embedded in the FINDINGS section. <component> <section> <code code="19005-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="X-ray impression"/> <text>No acute cardiopulmonary process. Round density in left superior hilus, further evaluation with CT is recommended as underlying malignancy is not excluded.</text> </section> </component> Figure 29 Impressions Example Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 30 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 3.3 Level 3 Content A Diagnostic Imaging Report MAY contain CDA Entries that represent in coded form findings, image references, annotation and numeric measurements, equivalent to the body content in DICOM Structured Reporting documents as constrained in the IHE Simple Image and Numeric report (SINR) profile). IHE SINR is based on DICOM Basic Diagnostic Imaging Report (Template 2000), with the additional constraint that only the Enhanced SR Information Object Definition may be used. DICOM Template 2000 defines imaging report documents comprising a number of optional sections, including those defined above under “Level 2 Content”. Each section contains,  Text Observations [Text Elements in DICOM SR], optionally inferred from “Report Observations” (as defined below)  Code Observations [Code Elements in DICOM SR], optionally inferred from Report Observations  Report Observations Template 2000 does not constrain the number or order of the Observations. Each Report Observation is ONE of the following:  An Image reference (purpose of reference is Baseline, Best Illustration of Finding, Source of Measurement, or user extension),  A Linear Measurement, optionally inferred from a RegionOFInterest [Spatial Coordinates (SCOORD) in DICOM SR] referencing an image,  An Area Measurement, optionally inferred from a RegionOFInterest [Spatial Coordinates (SCOORD) in DICOM SR] referencing an image,  A Volume Measurement, optionally inferred from a RegionOFInterest [Spatial Coordinates (SCOORD) in DICOM SR] referencing an image, or  A Numeric measurement with a coded measurement type optionally inferred from either o an Image Reference, or o a RegionOFInterest [Spatial Coordinates (SCOORD) in DICOM SR] referencing an image In all cases, the Level 3 content take the place of <entry> elements immediately following the Section/text closing bracket as illustrated in Figure 25. 3.3.1 Text Observations Text entries MAY be present, and if present, shall contain the same text content as the Section.text. A Text entry is required if the findings in the section text are represented Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 31 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. as inferred from Report Observations. This is required in CDA because if an observation is to be the source of an SPRT entryRelationship (equivalent to INFERRED FROM in DICOM SR), the source Observation must be an entry. That is, a whole section cannot be inferred from an Observation entry. If Text Entries are present the Section.text must represent faithfully the concatenation of the all such text entries. The entry’s observation.text element SHOULD avoid replication of the text content by including it as a <reference> to tagged <content> in the Section.text. <entry> <observation classCode="OBS" moodCode="EVN"> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"> </code> <text> <reference value="#finding1"/> </text> <!— zero or more <entryRelationship> observations may appear here --> </observation> </entry> </section> </component> Figure 30 Text Element example 3.3.2 Code Observations Code Observations may be present, and may obtionally be inferred from Report Observations, and if present, shall contain the same text content as the Section.text. Code Observations shall be rendered into Section.text in separate paragraphs. <entry> <observation classCode="OBS" moodCode="EVN"> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"> </code> <statusCode code='completed'/> <value xsi:type="CD" code="248649006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Hilar mass"/> <!— zero or more <entryRelationship> observations may appear here --> </observation> </entry> </section> </component> Figure 31 Code Element example 3.3.3 Report Observations Report Observations may be present as Entries, enclosed in <entry> … </entry> or as supporting observations in Text or Code entries, enclosed in <entryRelationship typeCode="SPRT"> … </entryRelationship>. Figures 25 and 25, below, illustrate these two placements, respectively. <entry> Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 32 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>  <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">  <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.9940 44785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051 &objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentTyp e=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entry> </section> </component> Figure 32 Report Observation as an Entry <entry> <observation classCode="OBS" moodCode="EVN"> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"> </code> <text> <reference value="#finding1"/> </text>  <entryRelationship typeCode="SUBJ"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>  <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">  <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.9940 44785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051 &objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentTyp e=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entryRelationship> </observation> </entry> </section> </component> Figure 33 Report Observation as a support for an inferred finding Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 33 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 3.3.3.1 Report Observation – Image Reference Image References indicate the image from which an observation was inferred or which a finding mentions.  <entryRelationship typeCode="SUBJ"> <observation classCode="DGIMG" moodCode="EVN"> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.3"/>  <code code="1.2.840.10008.5.1.4.1.1.1" codeSystem="1.2.840.10008.2.6.1" codeSystemName="DCMUID" displayName="Computed Radiography Image Storage">  <originalText> <reference value="#finding3"/> </originalText> </code> <text xsi:type="ED" mediaType="application/DICOM"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.9940 44785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051 &objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentTyp e=application/DICOM"/>  </text> <effectiveTime value="20060823223232"/> </observation> </entryRelationship> Figure 34 Image Reference Report Observation example 3.3.3.2 Report Observation – Linear Measurement Linear Measurements represent distance between two points in the image.  <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship> Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 34 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Figure 35 Linear Measurement Report Observation example 3.3.3.3 Report Observation – Area Measurement Area Measurements represent area within a region of interest in a image.  <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship> Figure 36 Linear Measurement Report Observation example 3.3.3.4 Report Observation – Volume Measurement Volume Measurements represent physical volumes within anatomical structures, as inferred from measurement s on the image or groups of images.  <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship> Figure 37 Volume Measurement Report Observation example 3.3.3.5 Report Observation – Numeric Measurement Numeric Measurements may be derived from image characteristics, other than spatial measurements. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 35 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved.  <entryRelationship typeCode="SPRT"> <observation classCode="OBS" moodCode="EVN"> <code code="M-02550" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter"> <originalText> <reference value="#finding2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> <translation code="mm" codeSystem="2.16.840.1.113883.6.8" codeSystemName="UCUM" codeSystemVersion="1.5"/> </value> </observation> </entryRelationship> Figure 38 Numeric Measurement Report Observation example Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 36 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. 4 References CDA Release 2.0 Clinical Document Architecture, Release 2.0, 2005, Health Level Seven, Inc. ISO-3166-1 Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes, 1997, International Organization for Standardization ISO-639-1 Codes for the representation of names of languages--Part 1: Alpha-2 code, 2002, International Organization for Standardization LOINC® Logical Observation Identifiers Names and Codes, Regenstrief Institute RFC 2806 URLs for Telephone Calls, 2000, A. Vaha-Sipila, The Internet Society RFC 2119 Key words for use in RFCs to Indicate Requirement Levels RFC 3066 Tags for the Identification of Languages, 2001, H. Alvestrand, The Internet Society Schematron The Schematron Assertion Language 1.5, 2002, Rick Jelliffe, Academia Sinica Computing Centre SNOMED CT SNOMED Clinical Terms, 2002, SNOMED International Organization Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 37 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Appendix A — Validation Introduction This appendix describes the vocabularies used or defined by this specification, and the Schematron schema that may be used to validate the content of the CDA Header for Diagnostic Imaging Report documents. Administrative Gender Administrative Gender codes used to describe the gender of the patient SHOULD come from the HL7 AdministrativeGender vocabulary. The OID for this vocabulary domain is 2.16.840.1.113883.5.1. Code Display Name Description F Female Female M Male Male UN Undifferentiated The gender of a person could not be uniquely defined as male or female, such as hermaphrodite. Table 4 Administrative Gender Ethnicity & Race Ethnicity codes used to describe the ethnicity of the patient SHOULD come from the HL7 Ethnicity vocabulary. The OID for this vocabulary domain is 2.16.840.1.113883.5.50. This vocabulary is listed below. DICOM’s Patient Sex attribute is mapped to Administrative Gender. Race codes used to describe the race of the patient SHOULD come from the HL7 Race vocabulary. This vocabulary is too extensive to list in this document. The OID for this vocabulary domain is 2.16.840.1.113883.5.104. In the diagnostic reporting context, Race or Ethnicity as a CDA header component is a confirming demographic attribute usually inherited from information systems providing orders or ADT information. In any circumstance where race or ethnicity is clinically relevant to report content, Race or Ethnicity SHALL be explicitly mentioned in the report narrative. Null Flavor Null Flavors are used to indicate why a required data element does not contain any information. Only the UNK null flavor is used in the Diagnostic Imaging Report. The complete list is shown below for reference. Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 38 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Code Display Name Description NI NoInformation No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value. OTH other The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system). NINF negative infinity Negative infinity of numbers. PINF positive infinity Positive infinity of numbers. UNK unknown A proper value is applicable, but not known. ASKU asked but unknown Information was sought but not found (e.g., patient was asked but didn't know) NAV temporarily unavailable Information is not available at this time but it is expected that it will be available later. NASK not asked This information has not been sought (e.g., patient was not asked) TRC trace The content is greater than zero, but too small to be quantified. MSK masked There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information. Note: using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail. NA not applicable No proper value is applicable in this context (e.g., last menstrual period for a male). NP not present Value is not present in a message. This is only defined in messages, never in application data! All values not present in the message must be replaced by the applicable default, or no-information (NI) as the default of all defaults. Table 5 Null Flavor Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 39 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Participation Function Participating function codes used to describe the exact function of a healthcare providers SHOULD come from the HL7 ParticipatingFunction vocabulary. This vocabulary is listed below. The OID for this vocabulary domain is 2.16.840.1.113883.5.88. Code Display Name Description ADMPHYS admitting physician A physician who admitted a patient to a hospital or other care unit that is the context of this service. ANRS anesthesia nurse In a typical anesthesia setting the nurse principally assisting the anesthesiologist during the critical periods. ANEST anesthesist In a typical anesthesia setting an anesthesiologist or anesthesia resident in charge of the anesthesia and life support, but only a witness to the surgical procedure itself. To clarify responsibilities anesthesia should always be represented as a separate service related to the surgery. ATTPHYS attending physician A physician who is primarily responsible for a patient during the hospitalization, which is the context of the service. DISPHYS discharging physician A physician who discharged a patient from a hospital or other care unit that is the context of this service. FASST first assistant surgeon In a typical surgery setting the assistant facing the primary surgeon. The first assistant performs parts of the operation and assists in others (e.g., incision, approach, electrocoutering, ligatures, sutures). MDWF midwife A person (usually female) helping a woman deliver a baby. Responsibilities vary locally, ranging from a mere optional assistant to a full required participant, responsible for (normal) births and pre- and post-natal care for both mother and baby. NASST nurse assistant In a typical surgery setting the non-sterile nurse handles material supply from the stock, forwards specimen to pathology, and helps with other non-sterile tasks (e.g., phone calls, etc.). PCP primary care physician The healthcare provider that holds primary responsibility for the overall care of a patient. PRISURG primary surgeon In a typical surgery setting the primary performing surgeon. RNDPHYS rounding physician A physician who made rounds on a patient in a hospital or other care center. SNRS scrub nurse In a typical surgery setting the nurse in charge of the instrumentation. SASST second assistant surgeon In a typical surgery setting the assistant who primarily holds the hooks. TASST third assistant In a typical surgery setting there is rarely a third assistant (e.g., in some Hip operations the third assistant postures the affected leg). Table 6 Participating Function Codes Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 40 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved. Appendix B — Sample Conforming CDA Document The document below is a non-normative example of a Diagnostic Imaging Report that conforms to this specification. The file sampleDiagnosticImagingReport.xml included in this distribution is equivalent in content to this appendix. [paste sample document, as pretty-printed by XML Spy, in final text] Implementation Guide for CDA Release 2 – Level 1 & 2 – Diagnostic Imaging Report Page 41 Committee Draft 0.4 September 16, 2007 © 2007 Health Level Seven, Inc. All rights reserved.

Diagnostic Imaging Report - dicom

Related documents

Products

Support

Diagnostic Imaging Report - dicom

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib