CDA4CDT H&P
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
January 22, 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@ |
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 11
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
1.7.2 Future Work 14
2 CDA Header – General Constraints 15
2.1 Constraints on Header Elements 16
2.1.1 ClinicalDocument 16
2.1.2 General Constraints 17
2.1.3 Rendering Information from the CDA Header for Human Presentation 17
2.1.4 ClinicalDocument/realmCode 17
2.1.5 ClinicalDocument/typeId 18
2.1.6 ClinicalDocument/templateId 18
2.1.7 ClinicalDocument/id 18
2.1.8 ClinicalDocument/code 19
2.1.8.1 Use of Local Document Type Codes 19
2.1.8.2 Precoordinated Document Type Codes 19
2.1.9 ClinicalDocument/title 20
2.1.10 ClinicalDocument/effectiveTime 21
2.1.11 ClinicalDocument/confidentialityCode 21
2.1.12 ClinicalDocument/languageCode 21
2.1.13 ClinicalDocument/setId and ClinicalDocument/versionNumber 22
2.1.14 ClinicalDocument/copyTime 22
2.1.15 Participants 22
2.1.15.1 recordTarget 22
2.1.15.2 author 23
2.1.15.3 dataEnterer 24
2.1.15.4 informant 24
2.1.15.5 Assigned Healthcare Providers 24
2.1.15.6 Personal Relations 24
2.1.15.7 Healthcare Providers 24
2.1.15.8 custodian 24
2.1.15.9 informationRecipient 25
2.1.15.10 legalAuthenticator 25
2.1.15.11 authenticator 26
2.1.15.12 participant 26
2.1.15.13 inFullfillmentOf 27
2.1.15.14 documentationOf 27
2.1.15.15 authorization 29
2.1.15.16 relatedDocument 29
2.1.15.17 componentOf 29
2.2 Rendering Header Information for Human Presentation 30
3 CDA Header – Diagnostic Imaging Report-specific Constraints 31
3.1 ClinicalDocument/templateId 31
3.2 ClinicalDocument/code 31
3.2.1 Use of Local Document Type Codes 31
3.2.2 Pre-coordinated Document Type Codes 31
3.3 Participants 31
3.3.1 participant 31
3.3.2 Supporting Person or Organization 31
3.3.3 inFulfillmentOf 31
3.3.4 authorization 31
3.3.5 componentOf 31
4 Body 32
4.1 Section Descriptions 32
4.1.1 Section Type Codes 32
4.1.2 Sections 33
4.2 Required Sections 33
4.2.1 DICOM Object Catalog – DCM 121181 33
4.2.2 Findings – LOINC 18782-3 35
4.3 Optional Sections 36
4.3.1 Reason for Study – LOINC 18785-6 36
4.3.2 History of Present Illness – LOINC 10164-2 36
4.3.3 Impressions – LOINC 19005-8 37
4.4 Level 3 Content 37
4.4.1 Text Observations 38
4.4.2 Code Observations 38
4.4.3 Report Observations 39
5 References 43
Appendix A — Validation 44
Introduction 44
Vocabulary 44
Administrative Gender 44
Extending the Vocabulary Tables for Local Use 44
Administrative Contact Role Type 44
Administrative Gender 44
Ethnicity 44
Marital Status 44
Null Flavors 44
Personal Relationship Role Type 45
Race 45
Participation Function 46
Appendix B — External Constraints 47
Introduction 47
XXX Constraints 47
Medications (Template ID 9.99.999.9 ….) 47
Social History (Template ID 9.99.999.9 ….) 47
YYY Constraints 47
Appendix C — Termplate IDs Defined in this Guide 48
Appendix D — List of Additional Optional Subsections 49
Appendix E — Section Cardinality 50
Appendix F — Sample Conforming CDA Document 51
Table of Figures
Figure 1: Use of the templateId element to indicate use of this guide 13
Figure 2: ClinicalDocument example 16
Figure 3: ClinicalDocument/realmCode example 16
Figure 4: ClinicalDocument/typeId example 17
Figure 5: ClinicalDocument/templateId example 17
Figure 6: ClinicalDocument/id example 17
Figure 7: ClinicalDocument/code example 18
Figure 8: Use of the translation element to include local codes for document type 18
Figure 9: ClinicalDocument/title example 20
Figure 10: CinicalDocument/effectiveTime example 20
Figure 11: CinicalDocument/confidentialityCode example 20
Figure 12: ClinicalDocument/languageCode example with language only 20
Figure 13: ClinicalDocument/languageCode example with language and country 21
Figure 14: recordTarget example 22
Figure 15: author example 22
Figure 16: dataEnterer example 23
Figure 17: custodian example 23
Figure 18: informationRecipient example 24
Figure 19: legalAuthenticator example 25
Figure 20: authenticator example 25
Figure 21: participant example 26
Figure 22: inFulfillmentOf example 26
Figure 23: documentationOf example 28
Figure 24: componentOf example 29
Figure 25: DICOM Object Catalog example 34
Figure 26: Findings example, including Level 3 content 35
Figure 27: Reason for study example 35
Figure 28: History example 36
Figure 29: Impressions example 36
Figure 30: Text Element example 37
Figure 31: Code Element example 38
Figure 32: Report Observation as an entry 40
Figure 33: Report Observation as a support for an inferred finding 41
Figure 34: Numeric Measurement Report Observation example 41
Table of Tables
Table 1: Contents of the Ballot Package 11
Table 2: LOINC Document Type Codes 19
Table 3: Section Type Codes 32
Table 4: Numeric Measurement Type Codes 40
Table 4: Administrative Gender 43
Table 5: Null Flavor 44
Table 6: Participating Function Codes 45
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.
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.
1 Originator Responsibilities
TBD
2 Recipient Responsibilities
TBD
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 of Figure 7: 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 XXXXX)
8 ClinicalDocument/code
17: The ClinicalDocument/code element shall be present and specifies the type of the clinical document.
18: The value for ClinicalDocument/code should be 18748-4 "Diagnostic Imaging Report" 2.16.840.1.113883.6.1 LOINC STATIC ???DATE???.
Figure 9: ClinicalDocument/code Example
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.
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 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