CDA4CDT H&P - HL7
CDAR2_II_BIMGRPTS_R1
[pic]
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.
|Editor/Co-Chair: |Fred M. Behlen, Ph.D. |
| |American College of Radiology |
| |fbehlen@ |
|Co-Chair: |Helmut Koenig, M.D. |
| |Siemens Medical Solutions |
| |helmut.koenig@ |
|Editor: |Rick Geimer |
| |Alschuler Associates, LLC |
| |rick@ |
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 |Note |
|0.3.14 |September 30, |Committee from Boca | |Draft |
| |2006 |Raton Meeting | | |
|0.3.15 |January 10, 2007|Committee from Boca | |Draft |
| | |Raton Meeting | | |
|0.4.17 |April 29, 2007 |Committee from Boca | |Draft |
| | |Raton Meeting | | |
|0.4.18 |July 8, 2007 |Committee from Boca | |Draft |
| | |Raton Meeting | | |
|0.4.19 |July 15, 2007 |Committee from Boca | |Draft |
| | |Raton Meeting | | |
|0.4.20 |August 28, 2007 |Committee from Boca | |Draft |
| | |Raton Meeting | | |
|0.4.21 |September 12, |Committee from Boca | |Draft |
| |2007 |Raton Meeting | | |
|0.4.22 |September 16, |Committee from Boca | |Draft |
| |2007 |Raton Meeting | | |
|0.x.00 |December xx, | | |First informative ballot |
| |2007 | | | |
Table of Contents
1 Introduction 10
1.1 Purpose 10
1.2 Audience 10
1.3 Approach 10
1.4 Organization of this Guide 10
1.5 Use of Templates 10
1.5.1 Originator Responsibilities 10
1.5.2 Recipient Responsibilities 11
1.6 Conventions Used in This Guide 11
1.6.1 Explanatory Statements 11
1.6.2 Conformance Requirements 11
1.6.3 XPath Notation 11
1.6.4 Keywords 11
1.6.5 XML Samples 12
1.6.6 DICOM Samples 12
1.6.7 Content of the Ballot Package 12
1.6.7.1 Sample DICOM SR Basic Diagnostic Imaging Report 13
1.6.7.2 Constrained CDA Diagnostic Imaging Report XML Schema 13
1.6.7.3 Sample XML 13
1.7 Scope 13
1.7.1 Levels of Constraint 13
2 CDA Header Constraints 15
2.1 Rendering Information from the CDA Header for Human Presentation 15
2.2 ClinicalDocument 15
2.3 Name, Address, Telephone Number, and Time Constraints 15
2.4 ClinicalDocument/realmCode 18
2.5 ClinicalDocument/typeId 18
2.6 ClinicalDocument/templateId 18
2.7 ClinicalDocument/id 18
2.8 ClinicalDocument/code 19
2.8.1 Use of Local Document Type Codes 20
2.8.2 Precoordinated Document Type Codes 20
2.9 ClinicalDocument/title 21
2.10 ClinicalDocument/effectiveTime 21
2.11 ClinicalDocument/confidentialityCode 22
2.12 ClinicalDocument/languageCode 22
2.13 ClinicalDocument/setId and ClinicalDocument/versionNumber 22
2.14 ClinicalDocument/copyTime 23
2.15 Participants 23
2.15.1 recordTarget 23
2.15.2 author 26
2.15.3 dataEnterer 27
2.15.4 informant 28
2.15.5 custodian 28
2.15.6 informationRecipient 29
2.15.7 legalAuthenticator 30
2.15.8 authenticator 31
2.15.9 participant 32
2.16 inFullfillmentOf 33
2.17 documentationOf 34
2.17.1 Physician Reading Study Performer 35
2.18 authorization 35
2.19 relatedDocument 35
2.20 componentOf 36
2.20.1 Physician of Record Participant 37
3 Body 38
3.1 Section Descriptions 38
3.1.1 Section Type Codes 38
3.2 Required Sections 39
3.2.1 DICOM Object Catalog – DCM 121181 39
3.2.2 Findings – LOINC 18782-3 42
3.3 Optional Sections 45
3.4 Clinical Statements 46
3.4.1 Study Act 47
3.4.2 Series Act 47
3.4.3 SopInstance Observation 48
3.4.4 Purpose of Reference Observation 51
3.4.5 Referenced Frames Observation 51
3.4.6 Boundary Observation 51
3.4.7 Text Observation 52
3.4.8 Code Observations 52
3.4.9 Numeric Measurement Observation 53
4 References 57
Appendix A — Validation 58
Introduction 58
Vocabulary 58
Administrative Gender 58
Extending the Vocabulary Tables for Local Use 58
Administrative Contact Role Type 58
Administrative Gender 58
Ethnicity 58
Marital Status 58
Null Flavors 58
Personal Relationship Role Type 59
Race 59
Participation Function 60
Appendix B — Termplate IDs Defined in this Guide 61
Appendix C — Section Cardinality 62
Appendix D — Sample Conforming CDA Document 63
Table of Figures
Figure 1: Use of the templateId element to indicate use of this guide 13
Figure 2: Various Uses of nullFlavor 15
Figure 3: Restricted URL grammar for telephone communications 16
Figure 4: Unknown telephone number example 16
Figure 5: ClinicalDocument/realmCode Example 17
Figure 6: ClinicalDocument/typeId example 17
Figure 7: ClinicalDocument/templateId example 17
Figure 8: ClinicalDocument/id example 18
Figure 9: ClinicalDocument/code Example 18
Figure 10: Use of the translation element to include local codes for document type. 19
Figure 11: ClinicalDocument/title example 20
Figure 12: CinicalDocument/effectiveTime example 21
Figure 13: ClinicalDocument/confidentialityCode example 21
Figure 14: ClinicalDocument/languageCode example with language only 21
Figure 15: ClinicalDocument/languageCode example with language and country 21
Figure 16: ClinicalDocument/setId and ClinicalDocument/versionNumber example 22
Figure 17: recordTarget example 25
Figure 18: author example 26
Figure 19: dataEnterer example 27
Figure 20: custodian example 28
Figure 21: informationRecipient example 29
Figure 22: legalAuthenticator example 30
Figure 23: authenticator example 31
Figure 24: participant Example 32
Figure 25: inFulfillmentOf Example 33
Figure 26: documentationOf Example 34
Figure 27: componentOf example 36
Figure 28: DICOM Object Catalog example 41
Figure 29: Findings example, including Level 3 content 44
Figure 30: Reason for study example 45
Figure 31: History example 45
Figure 32: Impressions example 45
Figure 33: SopInstance Observation as an entry 48
Figure 34: SopInstance Observation as a support for an inferred finding 50
Figure 35: Text Observation example 51
Figure 36: Code Element example 52
Figure 37: Numeric Measurement Report Observation example 55
Table of Tables
Table 1: Contents of the Ballot Package 11
Table 2: LOINC Document Type Codes 20
Table 3: Section Type Codes 38
Table 4: Purpose of Reference (DICOM CID 7003) 50
Table 5: Numeric Measurement Type Codes (value set XXX-1) 54
Table 6: Administrative Gender 57
Table 7: Null Flavor 58
Table 8: Participating Function Codes 59
Introduction
1 Purpose
The purpose of this document is to describe constraints on the CDA Header and Body elements for Diagnostic Imaging Reports. A Diagnostic Imaging Report contains a consulting specialist’s interpretation of image data. It is intended to convey the interpretation to the referring (ordering) physician, and becomes part of the patient’s medical record. It is intended for use in Radiology, Endoscopy, Cardiology, and other imaging specialties.
2 Audience
The audience for this document is software developers and consultants responsible for implementation of Radiology Information Systems, Radiology Reporting systems, Picture Archiving and Communications Systems (PACS), and other image and imaging management systems, that are expected to transmit results to of Electronic Health Record (EHR) systems or health information exchange networks as CDA documents created according to this Implementation Guide.
3 Approach
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).
4 Organization of this Guide
With subsections describing the organization …
5 Use 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.
6 Conventions Used in This Guide
This Implementation Guide is a conformance profile, as described in the Refinement and Localization section 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 Explanatory Statements
As an annotation profile, portions of this Implementation Guide summarize or explain the base standard.
Explanatory statements will appear in this style.
2 Conformance Requirements
Conformance requirements within this guide are sequentially numbered, and appear in the format illustrated below:
1: Here's an example of a conformance requirement for conformance to Level 1 requirements.
2: Here's another conformance statement. It might say that something shall include some specifically referenced thing.
3 XPath 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.
4 Keywords
The keywords shall, shall not, should, should not, may, and need not in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide.
5 XML Samples
XML Samples appear in various figures in this document in a fixed-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.
...
Figure XX-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.
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.
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.
7 Content of the Ballot Package
The ballot package contains the following files:
|Filename |Description |
|Diagnostic Imaging Report for CDA Release 2 Level|This Guide |
|1-3 v1.0.pdf | |
|DICOM SR “Basic Diagnostic Imaging Report” to HL7|The transformation guide specifying the mapping of constrained DICOM SR “Basic|
|CDA Release 2 “Diagnostic Imaging Report” |Diagnostic Imaging Reports” (DICOM PS 3.16-2007: Template 2000) to CDA Release|
|Transformation Guide |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 |Sample DICOM images referenced within the DICOM SR document EnhancedSR.dcm |
|SampleChestXR_Lat.dcm | |
Table 1: Contents of the Ballot Package
1 Sample DICOM SR Basic Diagnostic Imaging Report
The Sample DICOM SR report conforms to DICOM Template 2000 for a diagnostic imaging report including image annotation and references. This SR report is equivalent in content to the Sample CDA document, according to the mapping described on Appendix B.
The Report example is based on a chest radiography examination, the images from which are included in two DICOM Image files, SampleChestXR_PA.dcm and SampleChestXR_Lat.dcm. The report examples include references to these images.
2 Constrained CDA Diagnostic Imaging Report XML Schema
Also included in this ballot package is a CDA XML Schema constrained to the elements allowed in this Implementation Guide. This Schema is informative, and implementers should be cautioned that not all constraints in this guide are represented in the XML Schema.
3 Sample XML
A sample document is provided which conforms to the Level 1 and Level 2 constraints of this guide. This document is the source of many of the examples provided in this guide.
7 Scope
This specification defines additional constraints on CDA Header and Body elements used in a Diagnostic Imaging Report document 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 Levels of Constraint
This Implementation Guide specifies three levels of conformance requirements. Level 1 requirements specify constraints upon the CDA Header and the content of the document. Level 2 requirements specify constraints upon the structuredBody of the ClinicalDocument element of the CDA document. Level 3 requirements describe a limited set of structured entries for the purpose of referencing and annotating images from within the report.
This specification is intended for global use (universal realm). The specification of workflows, messages, or procedures used in performing imaging procedures is outside the scope of this specification.
CDA provides a mechanism to reference a template or implementation guide that has been assigned a unique identifier. The following example shows how to formally assert the use of this implementation guide. Use of the templateId indicates that the CDA instance not only conforms to the CDA specification, but in addition, conforms to the constraints specified in this Implementation Guide.
:
Figure 1: Use of the templateId element to indicate use of this guide
Within this guide, the required and optional content within the body are identified. This guide describes the information content of each section, but the information content cannot be verified by software.
CDA Header Constraints
1 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 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 ClinicalDocument
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.
1: The root of a History and Physical shall be a ClinicalDocument element from the urn:hl7-org:v3 namespace.
3 Name, 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.
2: All patient, guardianPerson, assignedPerson, maintainingPerson, relatedPerson, intendedRecipient/informationRecipient, associatedPerson, and relatedSubject/subject elements shall have a name.
3: All patientRole, assignedAuthor, assignedEntity[not(parent::dataEnterer)] and associatedEntity elements shall have an addr and telecom element.
4: All guardian, dataEnterer/assignedEntity, relatedEntity, intendedRecipient, relatedSubject and participantRole elements should have an addr and telecom element.
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.
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.
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.
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
8: Telephone numbers shall match the regular expression pattern
tel:\+?[-0-9().]+
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 e-mail 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.
10: If the telephone number is unknown it shall be represented using the appropriate flavor of null.
Figure 4: Unknown telephone number example
4 ClinicalDocument/realmCode
This value identifies the realm.
11: The ClinicalDocument/realmCode element may be present. If present, it shall use the fixed value UV.
Figure 5: ClinicalDocument/realmCode Example
5 ClinicalDocument/typeId
The clinical document type ID identifies the constraints imposed by CDA R2 on the content, essentially acting as a version identifier. The @root and @extension values of this element are specified as shown below.
Figure 6: ClinicalDocument/typeId example
12: The root attribute of the typeId element shall be 2.16.840.1.113883.1.3 and extension attribute shall be POCD_HD000040.
6 ClinicalDocument/templateId
The ClinicalDocument/templateId element identifies the template that defines constraints on the content. The clinicalDocument/templateID with the content shown below indicates conformance to this specification.
13: At least one ClinicalDocument/templateId element shall be present with the value DIR_ROOT_OID.
Figure 7: ClinicalDocument/templateId example
7 ClinicalDocument/id
The ClinicalDocument/id element is an instance identifier data type (see HL7 Version 3 Abstract Data Types). For compatibility with DICOM-SR, this specification constraints the root attribute to an OID, and UUIDs are prohibited. Since every UUID has an OID representation (need reference), this should not pose an exceptional burden on implementers. If an extension is present, the root uniquely identifies the scope of the extension. The root and extension attributes uniquely identify the document.
OIDs are limited by this specification to no more than 64 characters in length for compatibility with other standards and Implementation Guides.
14: CONF-HP-17: The ClinicalDocument/id element shall be present. The ClinicalDocument/id/@root attribute shall be a syntactically correct OID, and shall not be a UUID.
15: CONF-HP-19: OIDs SHALL be represented in dotted decimal notation, where each decimal number is either 0, or starts with a nonzero digit. More formally, an OID SHALL be in the form ([0-2])(.([1-9][0-9]*|0))+.
16: CONF-HP-20: OIDs SHALL be no more than 64 characters in length.
Figure 8: ClinicalDocument/id example
Organizations that wish to use OIDs should properly register their OID root and ensure uniqueness of the OID roots used in identifiers. A large number of mechanisms exist for obtaining OID roots for free or for a reasonable fee. HL7 maintains an OID registry page from which organizations may request an OID root under the HL7 OID root. This page can be accessed at:
Another useful resource lists the many ways to obtain a registered OID Root for free or a small fee anywhere in the world and is located at:
The manner in which the OID root is obtained is not constrained by this DSTU.
When a DICOM SR report is transformed to a CDA Diagnostic Imaging Report, a new ClinicalDocument/id is created by the transforming application, and DICOM Attribute (0008,0018) SOP Instance UID of the original document is used as a reference to the parent document (see section 2.19 relatedDocument).
8 ClinicalDocument/code
17: The ClinicalDocument/code element shall be present and specifies the type of the clinical document.
Given that reports generated according to this Guide may be transformed from established collections of imaging reports already stored with their own type codes, this Guide does not prescribe a closed set of Document Type Codes. Codes described here are recommended, but the set may be extended or replaced by local codes as needed.
18: The value for ClinicalDocument/code MAY be selected from Table 2: LOINC Document Type Codes and should be 18748-4 "Diagnostic Imaging Report" 2.16.840.1.113883.6.1 LOINC STATIC.
Figure 9: ClinicalDocument/code Example
1 Use of Local Document Type Codes
19: Implementations MAY use local codes in translation elements to further refine the document type.
An example of the use of local document type codes is shown below.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- h p before surgery guidelines
- surgery h p template
- general surgery h p template
- h p form for surgery
- medicare h p guidelines
- h p billing guidelines
- cms h p guidelines 2017
- medicare h p requirements for hospitals
- cms h p requirements 2018
- h p surgery definition
- preoperative h p template
- comprehensive h p requirements