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.

Google Online Preview   Download