diagnostic imaging report - dicom...

Digital Imaging and Communications in Medicine (DICOM)

Supplement 155:

Imaging Reports using HL7 Clinical Document Architecture

Prepared by:DICOM Standards Committee, Working Group 8: Structured Reportingin cooperation with Working Group 20: Integration of Imaging and Information Systems1300 N. 17th Street, Suite 1752Rosslyn, Virginia 22209 USA

VERSION: Draft 2014-02-28Developed in accordance with: DICOM Workitem 2010-04-D

Open issues1. Use of Accession Numbers and Order Placer Numbers in inFulfillmentOf2. For WG-6 – How should this be published within the Parts of DICOM? Should

this be a new Part, so that might be jointly balloted with HL7 (like Part 18 was with ISO)? Or should Part 20 be recast to be combined with this (since it has transformation of SR imaging reports directly to CDA, and includes templates for header elements and sections)?

3. Do we need specific Conformance Statements (probably different than current Part 2)

4. For RSNA and IHE – Should the MRRT specification be standardized within DICOM? Might that be a later step after trial use of MRRT (in a different Supplement)?

5. Style of specification for template Public Interface – template name, attribute names and data types (is template name just an attribute name in a higher level template?)

6. Do we need an Implementation Technology Specification for the data types used in the template public interfaces?

7. Style of specification for template – tabular, or conformance statements, or both?

Closed issuesArbitrary block of measurements from measurement app put into a CDA section. (D. Rubin) Resolution: just put into Findings, or into user-labeled subsection

Table of ContentsSCOPE AND FIELD OF APPLICATION.......................................................................................12

CDA and Implementation Guides.......................................................................................12Templates..........................................................................................................................13Imaging Report Templates for CDA....................................................................................13Use with RSNA RadReport and IHE MRRT...........................................................................14Structures provided by this Supplement............................................................................14Relationship to DICOM SR..................................................................................................15

1 GENERAL REQUIREMENTS AND CONVENTIONS................................................................161.1 Use of Templates.......................................................................................................16

1.1.1 Originator Responsibilities: General Case............................................................161.1.2 Recipient Responsibilities: General Case.............................................................16

1.2 Levels of Constraint...................................................................................................161.3 Conformance Conventions Used in This Guide..........................................................17

1.3.1 Open and Closed Templates................................................................................171.3.2 Conformance Verbs (Keywords)..........................................................................171.3.3 Cardinality...........................................................................................................181.3.4 Optional and Required with Cardinality...............................................................191.3.5 Vocabulary Conformance....................................................................................191.3.6 Containment Relationships..................................................................................201.3.7 Null Flavor...........................................................................................................211.3.8 Unknown Information..........................................................................................221.3.9 Data Types..........................................................................................................24

1.4 XML Conventions Used in This Guide.........................................................................241.4.1 XPath Notation....................................................................................................241.4.2 XML Examples and Sample Documents...............................................................25

2 DOCUMENT-LEVEL TEMPLATES........................................................................................262.1 Diagnostic Imaging Report Release 2........................................................................26

2.1.1 DIR Header Constraints.......................................................................................272.1.2 DIR Body Constraints...........................................................................................29

2.2 Interventional Radiology Report (reserved)...............................................................302.3 Anatomic Pathology Report (reserved)......................................................................30

3 HEADER CONTENT MODULES..........................................................................................323.1 General Header Constraints.......................................................................................32

3.1.1 Rendering Header Information for Human Presentation......................................343.2 RecordTarget and Patient Demographics..................................................................34

3.2.1 Patient.................................................................................................................353.2.2 ProviderOrganization...........................................................................................353.2.3 RecordTarget Value Sets.....................................................................................363.2.4 RecordTarget Example........................................................................................36

3.3 componentOf Encompassing Encounter....................................................................373.3.1 Physician of Record Participant...........................................................................38

3.4 inFulfillmentOf Order.................................................................................................393.5 documentationOf Service Event and Performer.........................................................40

3.5.1 Physician Reading Study Performer.....................................................................423.5.2 Irradiation Authorizing Performer........................................................................43

3.6 Author (Person).........................................................................................................433.7 LegalAuthenticator....................................................................................................443.8 Custodian..................................................................................................................453.9 Other Participants......................................................................................................46

3.9.1 DataEnterer.........................................................................................................463.9.2 InformationRecipient...........................................................................................473.9.3 Participant (Referrer)...........................................................................................483.9.4 Authenticator.......................................................................................................49

3.10 relatedDocument.....................................................................................................50

4 SECTION-LEVEL TEMPLATES............................................................................................524.1 Addendum.................................................................................................................544.2 Clinical Information....................................................................................................544.3 Communication of Critical Results.............................................................................564.4 Comparison Study.....................................................................................................584.5 Complications Section ..............................................................................................594.6 DICOM Object Catalog Section...................................................................................614.7 OB.US Fetus Findings.................................................................................................634.8 Findings Section 18782-3..........................................................................................654.9 Impressions...............................................................................................................704.10 Procedure Indications..............................................................................................724.11 Key Images..............................................................................................................74

4.12 Labeled Subsection..................................................................................................744.13 Medical History (DIR) Section 11329-0....................................................................754.14 Current Imaging Procedure Description...................................................................764.15 Procedure Indications Section 59768-2....................................................................774.16 Radiation Exposure and Protection Information.......................................................784.17 Radiology Recommendation....................................................................................804.18 Contrast Administered.............................................................................................80Procedural Medication Activity...................................................................................................814.19 Request...................................................................................................................83

5 ENTRY-LEVEL TEMPLATES................................................................................................855.1 Allergy Observation...................................................................................................855.2 Allergy Problem Act...................................................................................................925.3 Allergy Status Observation........................................................................................955.4 Boundary Observation...............................................................................................965.5 Code Observations....................................................................................................975.6 Critical Results Urgency.............................................................................................995.7 Indication.................................................................................................................1015.8 Procedural Medication Activity................................................................................1035.9 observationMedia....................................................................................................1075.10 Postprocedure Diagnosis.......................................................................................1085.11 Pregnancy Observation..........................................................................................1095.12 Problem Concern Act (Condition)...........................................................................1135.13 Problem Observation.............................................................................................1155.14 Problem Status......................................................................................................1205.15 Procedure Activity Act...........................................................................................1225.16 Imaging Procedure................................................................................................1285.17 Service Delivery Location......................................................................................1335.18 Procedure Context.................................................................................................1365.19 Purpose of Reference Observation.........................................................................1375.20 Quantity Measurement Observation-2...................................................................1395.21 Reaction Observation............................................................................................1415.22 Referenced Frames Observation............................................................................1445.23 Result Observation................................................................................................1455.24 Result Organizer....................................................................................................1485.25 Series Act..............................................................................................................150

5.26 Severity Observation.............................................................................................1525.27 Social History Observation.....................................................................................1555.28 SOP Instance Observation.....................................................................................1585.29 Study Act...............................................................................................................1615.30 Text Observation...................................................................................................163

6 SECTION PARTICIPATION TEMPLATES............................................................................1666.1 Fetus Subject Context.............................................................................................1666.2 Observer Context....................................................................................................166

7 REFERENCES..................................................................................................................168

APPENDIX A — ACRONYMS AND ABBREVIATIONS............................................................170

APPENDIX B — ADDITIONAL EXAMPLES...........................................................................172Names..............................................................................................................................172Addresses.........................................................................................................................172Time.................................................................................................................................173CD.................................................................................................................................... 173

Table of FiguresFigure 1: Constraints format – only one allowed...................................................................19Figure 2: Constraints format – only one like this allowed......................................................19Figure 3: Binding to a single code.........................................................................................20Figure 4: XML expression of a single-code binding................................................................20Figure 5: Translation code example......................................................................................20Figure 6: nullFlavor example.................................................................................................21Figure 7: Attribute required...................................................................................................22Figure 8: Allowed nullFlavors when element is required (with xml examples).......................22Figure 9: nullFlavor explicitly disallowed...............................................................................22Figure 10: Unknown medication example.............................................................................23Figure 11: Unkown medication use of anticoagulant drug example......................................23Figure 12: No known medications example...........................................................................24Figure 13: XML document example.......................................................................................25Figure 14: XPath expression example...................................................................................25Figure 15: ClinicalDocument example...................................................................................25Figure 16: DIR ClinicalDocument/code example....................................................................29Figure 17: DIR use of the translation element to include local codes for document type......29Figure 18: header example...................................................................................................34Figure 19: recordTarget example..........................................................................................36Figure 21: Physician of record participant example...............................................................39Figure 22: DIR inFulfillmentOf example.................................................................................40Figure 23: DIR procedure context (CDA Header) illustration (non-normative).......................41Figure 24: DIR documentationOf example.............................................................................42Figure 25: Physician reading study performer example........................................................43Figure 26: Person author example........................................................................................44Figure 27: legalAuthenticator example.................................................................................45Figure 28: Custodian example...............................................................................................46Figure 29: dataEnterer example............................................................................................47Figure 30: informationRecipient example..............................................................................48Figure 31: DIR participant example.......................................................................................49Figure 32: Authenticator example.........................................................................................50Figure 33: DIR relatedDocument example............................................................................51Figure 34: Complications section example............................................................................60Figure 36: Findings section example.....................................................................................69Figure 37: WADO reference using linkHtml example.............................................................70

Figure 38: Medical (general) history section example...........................................................76Figure 39: Procedure description section example................................................................77Figure 40: Procedure indications section example................................................................78Figure 41: Allergy observation example................................................................................92Figure 42: Allergy problem act example................................................................................94Figure 43: Allergy status observation example.....................................................................96Figure 44: Boundary observation example............................................................................97Figure 45: Code observation example...................................................................................99Figure 46: Indication entry example....................................................................................103Figure 47: Procedural Medication activity example.............................................................106Figure 48: Medication information example........................................................................107Figure 49: Postprocedure diagnosis example......................................................................109Figure 50: Pregnancy observation example........................................................................112Figure 51: Not Pregnant example........................................................................................112Figure 52: Problem concern act (condition) example..........................................................115Figure 53: Problem observation example............................................................................119Figure 54: Problem observation with specific problem not observed..................................119Figure 55: Problem observation for no known problems.....................................................120Figure 56: NullFlavor example.............................................................................................120Figure 57: Problem status example.....................................................................................122Figure 58: Procedure activity act example..........................................................................126Figure 59: Imaging procedure example...............................................................................132Figure 60: Service delivery location example......................................................................135Figure 60: Procedure context template example................................................................137Figure 61: Purpose of reference example............................................................................139Figure 62: Quantity measurement observation example....................................................141Figure 63: Reaction observation example...........................................................................144Figure 64: Referenced frames observation example...........................................................145Figure 65: Result observation example...............................................................................147Figure 66: No evaluation procedures (e.g., labs/x-rays) performed example......................148Figure 67: Local code example............................................................................................148Figure 68: Result organizer example...................................................................................150Figure 69: Series act example.............................................................................................152Figure 71: Severity observation example............................................................................155Figure 72: Social history observation template example.....................................................157Figure 73: SOP instance observation example....................................................................161

Figure 74: Study act example.............................................................................................163Figure 75: Text observation example..................................................................................165Figure 76: Fetus subject context example...........................................................................166Figure 77: Observer context example.................................................................................167Figure 78: Correct use of name example 1.........................................................................172Figure 79: Incorrect use of name example 1 - whitespace..................................................172Figure 80: Incorrect use of Patient name example 2 - no tags............................................172Figure 81: Correct use telecom address example...............................................................172Figure 82: Correct use postal address example..................................................................172Figure 83: Correct use of IVL_TS example...........................................................................173Figure 84: Correct use of TS with precision to minute example..........................................173Figure 85: Correct use of TS with timezone offset example................................................173Figure 86: Incorrect use of IVL_TS example.........................................................................173Figure 87: Incorrecet use of TS - insufficient precision example..........................................173Figure 88: Incorrect use of TS when timezone offset required example..............................173Figure 89: Incorrrect use of timezone offset - not enough precision example.....................173Figure 90: Correct use of CD with no code - example.........................................................173Figure 91: Incorrect use of CD with no code - missing nullFlavor attribute example...........174

Table of TablesTable 1: DIR LOINC Document Type Codes...........................................................................28Table 2: Basic Confidentiality Kind Value Set........................................................................33Table 3: Language Value Set (excerpt).................................................................................33Table 4: Administrative Gender (HL7) Value Set...................................................................36Table 6: Medical (General) History Section Contexts.............................................................75Table 7: Procedure Indications Section Contexts...................................................................77Table 8: Allergy Observation Constraints Overview...............................................................86Table 9: Allergy/Adverse Event Type Value Set.....................................................................89Table 10: Medication Brand Name Value Set (excerpt).........................................................90Table 11: Medication Clinical Drug Value Set (excerpt).........................................................90Table 12: Medication Drug Class Value Set (excerpt)............................................................90Table 13: Ingredient Name Value Set (excerpt)....................................................................91Table 14: Allergy Problem Act Contexts................................................................................92Table 15: Allergy Problem Act Constraints Overview.............................................................93Table 16: HITSP Problem Status Value Set............................................................................94

Table 17: Allergy Status Observation Contexts.....................................................................95Table 18: Allergy Status Observation Constraints Overview..................................................95Table 19: Boundary Observation Contexts............................................................................96Table 20: Boundary Observation Constraints Overview........................................................96Table 21: Code Observations Constraints Overview..............................................................98Table 22: Critical Result Priority Value Set..........................................................................101Table 23: Indication Constraints Overview..........................................................................102Table 24: Medication Activity Constraints Overview............................................................103Table 25: Unit of Measure Value Set (excerpt)....................................................................105Table 26: Postprocedure Diagnosis Contexts......................................................................108Table 27: Postprocedure Diagnosis Constraints Overview...................................................109Table 28: Pregnancy Observation Constraints Overview.....................................................110Table 29: Problem Concern Act (Condition) Contexts..........................................................113Table 30: Problem Concern Act (Condition) Constraints Overview......................................113Table 31: ProblemAct statusCode Value Set........................................................................114Table 32: Problem Observation Constraints Overview.........................................................116Table 33: Problem Type Value Set.......................................................................................118Table 34: Problem Value Set (excerpt)................................................................................118Table 35: Problem Status Contexts.....................................................................................120Table 36: Problem Status Constraints Overview..................................................................121Table 37: Procedure Activity Act Contexts..........................................................................122Table 38: Procedure Activity Act Constraints Overview.......................................................122Table 38: Imaging Procedure Constraints Overview............................................................128Table 39: Procedure Act Status Code Value Set..................................................................131Table 40: Act Priority Value Set...........................................................................................131Table 41: Body Site Value Set (excerpt).............................................................................132Table 42: Service Delivery Location Contexts.....................................................................133Table 43: Service Delivery Location Constraints Overview..................................................134Table 44: HealthcareServiceLocation Value Set (excerpt)...................................................135Table 43: Procedure Context Constraints Overview............................................................137Table 44: Purpose of Reference Observation Contexts........................................................137Table 45: Purpose of Reference Observation Constraints Overview....................................138Table 46: DICOM Purpose of Reference Value Set...............................................................139Table 47: Quantity Measurement Observation Constraints Overview.................................139Table 48: Reaction Observation Contexts...........................................................................141Table 49: Reaction Observation Constraints Overview........................................................141

Table 50: Result Observation Contexts...............................................................................145Table 51: Result Observation Constraints Overview............................................................145Table 52: Result Organizer Contexts...................................................................................148Table 53: Result Organizer Constraints Overview...............................................................149Table 54: Series Act Contexts.............................................................................................150Table 55: Series Act Constraints Overview..........................................................................151Table 60: Severity Observation Constraints Overview.........................................................153Table 61: Problem Severity Value Set.................................................................................154Table 62: Social History Observation Contexts....................................................................155Table 63: Social History Observation Constraints Overview................................................156Table 64: Social History Type Set Definition Value Set........................................................157Table 65: Sop Instance Observation Contexts.....................................................................158Table 66: Sop Instance Observation Constraints Overview.................................................159Table 67: Study Act Contexts..............................................................................................161Table 68: Study Act Constraints Overview..........................................................................162Table 69: Text Observation Contexts..................................................................................163Table 70: Text Observation Constraints Overview...............................................................164

AcknowledgmentsThis material contains content from HL7 Consolidated CDA Implementation Guide Release 1.1. CDA is a registered trademark of Health Level Seven International.This material contains content from SNOMED CT® (http://www.ihtsdo.org/snomed-ct/). SNOMED CT is a registered trademark of the International Health Terminology Standard Development Organisation (IHTSDO).This material contains content from LOINC® (http://loinc.org). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright © Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee, and available at no cost under the license at http://loinc.org/terms-of-use.

http://www.ihtsdo.org/snomed-ct/

http://loinc.org/

SCOPE AND FIELD OF APPLICATIONThis Supplement to the DICOM Standard introduces a new mechanism for specifying templates for imaging reports. Such reports are intended to be encoded using the HL7 Clinical Document Architecture Release 2 (CDAr2, or simply CDA) Standard1.The nature of radiology reporting is evolving from purely text based reports to incorporate more discrete data elements (measurements, categorical findings, etc.). It is the purpose of this Supplement to support current and evolving practice. This Supplement therefore focuses on primarily narrative text reports, but also supports incorporation of discrete data and image references. It is envisioned that this Supplement is just the first step in DICOM specification of imaging report templates. Its scope is therefore limited primarily to radiology diagnostic imaging (including screening exams), and some interventional radiology. Future work may include in scope cardiology, anatomic pathology, or other imaging procedures, as well as templates with more required discrete data element content.

CDA and Implementation GuidesThe HL7 Clinical Document Architecture has emerged as the industry consensus standard for the formatting of clinical reports. DICOM currently provides for both encapsulation of CDA documents within DICOM SOP Instances, and for direct reference to native (unencapsulated) CDA document instances (equivalent to direct reference of DICOM SOP Instances). Native and encapsulated CDA documents may be managed on DICOM exchange media through the DICOMDIR Basic Directory Information Object.The generic CDA format is typically constrained for specific instances by implementation guides in support of specific use cases. Two such implementation guides are the Basic Diagnostic Imaging Report, published as an informative HL7 specification and based on DICOM Templates 2000 and 2005, and Procedure Notes, published as an HL7 Draft Standard for Trial Use and applicable to interventional imaging procedures (interventional radiology, endoscopy, cardiology). Both of these implementation guides were developed with participation from DICOM WG-20 / HL7 Imaging Integration Work Group. Those two guides were subsequently adapted for use under the US Meaningful Use of Electronic Health Records incentive program, and the adaptation was published in the Consolidated CDA Implementation Guide - US Realm (C-CDA).There are actually multiple layers of constraint and implementation guidance that go into a CDA imaging report. First, CDA itself is a constraint (a Refined Message Information Model, or R-MIM) applied to the HL7 v3 Reference Information Model (v3 RIM) and Implementation Technology Specification (v3 ITS). This Supplement defines several report document structures that further constrain CDA through defined or required header elements, sections, and structured entries. Further, professional societies or healthcare providers may define even more detailed constraints and guidance for use in reporting on specific sub-specialty procedures.

TemplatesThe constraints specified in implementation guides take the form of templates. Templates are formally described patterns that specify the structure and content of a document (or a 1 CDA® is a registered trademark of HL7 International.

Teri Sippel Schmidt , 04/01/14,

Status: This section has been reviewed fairly thoroughly and is “done” for now.

portion thereof). Structure includes the relationships among portions of the document; content includes concepts and vocabularies used for a particular application. Templates may impose mandatory constraints on structure and content (e.g., minimum data sets), and/or may specify recommended or optional features. Templates have several purposes:

They improve interoperability by limiting the variability of unconstrained (idiosyncratic or arbitrary) structures and content.

The specificaion of templates allows a professional society or healthcare provider to normalize best practice for reports with content appropriate for their use cases, including foreseeable secondary uses such as research or quality improvement.

A template may be used operationally in the creation of reports; an application may use the template to guide authoring of the report, ensuring the entry or composition of essential reporting elements, and structuring that data into the target encoded format.

Ultimately, templates provide a conformance validation for instances of reports against the purposes (use case) of the template.

Imaging Report Templates for CDAThis Supplement defines the CDA format structures and technical constraints, i.e.,

templates, for documents, sections, and entries to be used in imaging report instances. These report instance templates are thus a set of conformance criteria for such report instances.However, these templates may also be viewed as providing high level structures that can hide the details of implementation. For example, by defining a Findings document section or an Impressions section, users can discuss the content of those sections without needing to know how it is represented in the CDA instance. For this purpose, the Supplement specifies a public implementation independent specification for each element that allows applications to to deal with abstract report constructs (such as sections or entries) and their logical data content.

This standard therefore also has the goal of facilitating, through these public interfaces, the creation of report authoring templates by professional societies or healthcare providers for use in reporting on imaging procedures. The templates defined in this Supplement provide canonical documentation categories (e.g., sections, numerical measurements, categorical observations, etc.) that map into specific CDA structures. This Supplement is therefore a method for facilitating greenCDA2 concepts for the imaging report use case. It specifies names of data element “slots” that may be used to link data collected by the report authoring application into the CDA structural templates of this Implementation Guide. Each name is specified with the type of data elements that will populate the CDA.

Figure - Process flow using CDA Report Templates, MRRT, and RSNA Templates

Use with RSNA RadReport and IHE MRRT This work is complementary to and coordinated with the RSNA Radiology Reporting (RadReport) initiative3 and the IHE Management of Radiology Report Templates (MRRT) Profile4. RadReport is focused on developing best practice clinical content templates for authoring radiology reports; MRRT specifies an XML-based encoding for those report authoring templates that can be used by a report authoring application.RadReport and MRRT thus provide a standardized platform for the front end authoring of a report; this Supplement specifies the back end encoding of that report content into CDA structures. These are independent activities – the RadReport and MRRT authored content could be encoded into a simple text or PDF document, rather than CDA, and mechainsms other than RadReport and MRRT could provide the content authoring for CDA imaging reports conformant to the templates defined in this Supplement.

2 HL7 greenCDA: An Implementation Methodology for CDA, Release 1 Draft Standard for Trial Use (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=136) 3 http://radreport.org/ 4 http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_MRRT.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_MRRT.pdf

http://radreport.org/

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=136

Structures provided by this SupplementCDA documents include a header and a body. The header is fully structured data that allows management and exchange of clinical documents by generic document handling systems and interfaces, e.g., as specified in the IHE Cross-Enterprise Document Sharing (XDS) Profile. This Supplement specifies templates for header elements of particular interest for imaging reports, such as the order and the service event and performer.For the CDA body, the principal structures provided by this Supplement are the narrative sections for reports. The RSNA RadReport initiative has specified five canonical top level narrative sections, which are supported by specific templates: Procedure Description, Clinical Information, Comparison Study, Findings, and Impressions. This Supplement also specifies predefined subsections for some of those primary sections, e.g., Radiation Exposure within the Procedure Description section. Each section may also have defined Structured Entries (discrete data elements), usually optional in the context of a primarily narrative radiology report.This Supplement also allows user-titled subsections that might be used for a particular reporting focus, e.g., “Liver” or “Tumor 1” within Findings. Note that while the subsection title may impart informal scoping semantics to the human-readable narrative block (i.e., the title “Liver” implies that all the narrative text is about the liver), there is no formal semantic post-coordination of the title with the concept code of a structured entry in that subsection (a measurement of “length” cannot be formally inferred to mean “length of liver”). This is deemed to be acceptable for the first generation of reports produced under this Supplement, and is a potential area for future development.One exception to this non-semantic subsection user titles is for subsections in obstetric ultrasound reports whose theme is “Fetus”, or “Fetus n”. LOINC specifies a section code and CDA explicitly defines a Subject section participation that formally convey scoping context to the content of that subsection. DICOM Part 20 Section A.5.1.4.1 Subject Context has explicitly modeled the use of Subject participation for fetus.

Relationship to DICOM SRA key requirement for radiology reporting, especially in areas such as ultrasound, is to incorporate observations (e.g., measurements) recorded in DICOM Structured Report instances. It is highly desirable to also include any references to the primary evidence, e.g., links to imags and regions of interest, that are recorded in the SR. Previous related work, as standardized in DICOM Part 20, provides a mechanism for transcoding DICOM SR observations into CDA entries. However, it assumed that the CDA report formatting process is an application aware of DICOM SR constructs, and could preserve such measurements or observations with full fidelity into the clinical report. However, this Supplement does not assume that the report formatting process has any cognizance of SR. While there is a need to import observations (measurements, assessments) from SR evidence documents into the CDA format final report, this Supplement assumes an indirect method of such data import. The report authoring process, and any associated report authoring templates, are responsible for identifying SR content to be included in the report, thus allowing the clinician to review those observations in the context of the report narrative, and to modify or exclude any of those SR observations. This Supplement provides CDA structures for coded/numeric observations whose ultimate source may or may not be a DICOM SR observation.

Solomon, Harry (GE Healthcare), 04/01/14,

Do we need a class of templates that is DICOM SR Content Item aware? Or can we define a “Data Type” that is an equivalent of a Content Item?

1 GENERAL REQUIREMENTS AND CONVENTIONSThis section is substantially identical to text in HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for Trial Use, July 2012 ©Health Level Seven, reproduced by permission

1.1 Use of TemplatesTemplate identifiers (templateId) are assigned at the document, section, and entry level. When valued in an instance, the template identifier signals the imposition of a set of template-defined constraints. The value of this attribute (e.g. @root="2.16.840.1.113883.10.20.22.4.8") provides a unique identifier for the template in question.If a template is a specialization of another template, its first constraint indicates the more general template. The general template is not always required. In all cases where a more specific template conforms to a more general template, asserting the more specific template also implies conformance to the more general template.

1.1.1 Originator Responsibilities: General CaseAn originator can apply a templateId if there is a desire to assert conformance with a particular template.In the most general forms of CDA exchange, an originator need not apply a templateId for every template that an object in an instance document conforms to. The implementation guide (IG) shall assert whenever templateIds are required for conformance.

1.1.2 Recipient Responsibilities: General CaseA recipient may reject an instance that does not contain a particular templateId (e.g., a recipient looking to receive only Procedure Note documents can reject an instance without the appropriate templateId).A recipient may process objects in an instance document that do not contain a templateId (e.g., a recipient can process entries that contain Observation acts within a Problems section, even if the entries do not have templateIds).

1.2 Levels of ConstraintThe CDA standard describes conformance requirements in terms of three general levels corresponding to three different, incremental types of conformance statements:

Level 1 requirements impose constraints upon the CDA Header. The body of a Level 1 document may be XML or an alternate allowed format. If XML, it must be CDA-conformant markup.

Level 2 requirements specify constraints at the section level of a CDA XML document: most critically, the section code and the cardinality of the sections themselves, whether optional or required.


Status: this section is copied from C-CDA and we cannot really change it. “done”

Level 3 requirements specify constraints at the entry level within a section. A specification is considered “Level 3” if it requires any entry-level templates.

Note that these levels are rough indications of what a recipient can expect in terms of machine-processable coding and content reuse. They do not reflect the level or type of clinical content, and many additional levels of reusability could be defined.The section libraries for each document type list the required and optional sections.

1.3 Conformance Conventions Used in This Guide

1.3.1 Open and Closed TemplatesIn open templates, all of the features of the CDA R2 base specification are allowed except as constrained by the templates. By contrast, a closed template specifies everything that is allowed and nothing further may be included.

1.3.2 Conformance Verbs (Keywords)The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT, and SHALL NOT in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide (http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm):

SHALL: an absolute requirement SHALL NOT: an absolute prohibition against inclusion SHOULD/SHOULD NOT: best practice or recommendation. There may be valid

reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course

MAY/NEED NOT: truly optional; can be included or omitted as the author decides with no implications

The keyword "SHALL" allows the use of nullFlavor unless the requirement is on an attribute or the use of nullFlavor is explicitly precluded.The subject of a conformance verb (keyword) in a top-level constraint is the template itself; for example, the subject of C_5249 is the ClinicalDocument element. In nested constraints, the subject is the element in the containing constraint. Top-level constraints are those that begin with a number and are not indented.

Workgroup ConsensusSHALLElement must be present but can be NULL

Where necessary to explicitly preclude nullFlavor (e.g. where you want to preclude nullFlavor on observation/value), can include something like "SHALL NOT include nullFlavor".

Where SHALL is applied to an attribute, it must be present and cannot be a NULLSHALL NOTAbsolute prohibition against inclusion

http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm

http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm

Workgroup ConsensusSHOULDBest Practice or RecommendationThere may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course

SHOULD NOTNot RecommendedMAYOptional-

1.3.3 Cardinality The cardinality indicator (0..1, 1..1, 1..*, etc.) specifies the allowable occurrences within a document instance. The cardinality indicators are interpreted with the following format “m…n” where m represents the least and n the most:

0..1 zero or one 1..1 exactly one 1..* at least one 0..* zero or more 1..n at least one and not more than n

When a constraint has subordinate clauses, the scope of the cardinality of the parent constraint must be clear. In the next figure, the constraint says exactly one participant is to be present. The subordinate constraint specifies some additional characteristics of that participant.

Figure 1: Constraints format – only one allowed

1. SHALL contain exactly one [1..1] participant. a. This participant SHALL contain exactly one [1..1] @typeCode="LOC" (CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType) .

In the next figure, the constraint says only one participant “like this” is to be present. Other participant elements are not precluded by this constraint.

Figure 2: Constraints format – only one like this allowed

1. SHALL contain exactly one [1..1] participant such that it a. SHALL contain exactly one [1..1] @typeCode="LOC" (CodeSystem: 2.16.840.1.113883.5.90 HL7ParticipationType).

1.3.4 Optional and Required with CardinalityThe terms optional and required describe the lower bound of cardinality as follows:Optional means that the number of allowable occurances of an element may be 0; the cardinality will be expressed as [0..1] o[0..*] or similar. In these cases, the element may not be present in the instance.Required means that the number of allowable occurances of an element must be at least 1; the cardinality will be expressed as [m..n] where m >=1 and n >=1 for example [1..1] o[1..*].. In these cases, the element must be present in the instance. If an element is required, but is not known (and would otherwise be omitted if it were optional), it must be be represented by a nullFlavor.

1.3.5 Vocabulary Conformance The templates in this document use terms from several code systems. These vocabularies are defined in various supporting specifications and may be maintained by other bodies, as is the case for the LOINC® and SNOMED CT® vocabularies.Note that value-set identifiers (e.g., ValueSet 2.16.840.1.113883.1.11.78 Observation Interpretation (HL7) DYNAMIC) do not appear in CDA submissions; they tie the conformance requirements of an implementation guide to the appropriate code system for validation. Value-set bindings adhere to HL7 Vocabulary Working Group best practices, and include both a conformance verb (SHALL, SHOULD, MAY, etc.) and an indication of DYNAMIC vs. STATIC binding. Value-set constraints can be STATIC, meaning that they are bound to a specified version of a value set, or DYNAMIC, meaning that they are bound to the most current version of the value set. A simplified constraint, used when the binding is to a single code, includes the meaning of the code, as follows.

Figure 3: Binding to a single code

1. … code/@code="11450-4" Problem List (CodeSystem: 2.16.840.1.113883.6.1 LOINC).

The notation conveys the actual code (11450-4), the code’s displayName (Problem List), the OID of the codeSystem from which the code is drawn (2.16.840.1.113883.6.1), and the codeSystemName (LOINC).HL7 Data Types Release 1 requires the codeSystem attribute unless the underlying data type is “Coded Simple” or “CS”, in which case it is prohibited. The displayName and the codeSystemName are optional, but recommended, in all cases. The above example would be properly expressed as follows.

Figure 4: XML expression of a single-code binding

<code code="11450-4" codeSystem="2.16.840.1.113883.6.1"/>



<code code="11450-4" codeSystem="2.16.840.1.113883.6.1" displayName="Problem List" codeSystemName=”LOINC”/>

A full discussion of the representation of vocabulary is outside the scope of this document; for more information, see the HL7 V3 Normative Edition 20105 sections on Abstract Data Types and XML Data Types R1.There is a discrepancy in the implementation of translation code versus the original code between HL7 Data Types R1 and the convention agreed upon for this specification. The R1 data type requires the original code in the root. This implementation guide specifies the standard code in the root, whether it is original or a translation. This discrepancy is resolved in HL7 Data Types R2.

Figure 5: Translation code example

<code code='206525008’ displayName='neonatal necrotizing enterocolitis' codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'> <translation code='NEC-1' displayName='necrotizing enterocolitis' codeSystem='2.16.840.1.113883.19'/></code>

1.3.6 Containment Relationships Containment constraints between a section and its entry are indirect in this guide, meaning that where a section asserts containment of an entry, that entry can either be a direct child or a further descendent of that section. For example, in the following constraint:

1. SHALL contain at least one [1..*] entry such that it a. SHALL contain exactly one [1..1] Advance Directive Observation

(templateId:2.16.840.1.113883.10.20.22.4.48). the Advance Directive Observation can be a direct child of the section (i.e., section/entry/AdvanceDirectiveObservation) or a further descendent of that section (i.e., section/entry/…/AdvanceDirectiveObservation). Either of these are conformant.All other containment relationships are direct, for example:

2. SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.10.20.22.2.21".

The templateId must be a direct child of the section (i.e., section/templateId).

5 HL7 Version 3 Interoperability Standards, Normative Edition 2010. http://www.hl7.org/memonly/downloads/v3edition.cfm - V32010

http://www.hl7.org/memonly/downloads/v3edition.cfm#V32010

1.3.7 Null Flavor Information technology solutions store and manage data, but sometimes data are not available: an item may be unknown, not relevant, or not computable or measureable. In HL7, a flavor of null, or nullFlavor, describes the reason for missing data. For example, if a patient arrives at an Emergency Department unconscious and with no identification, we would use a null flavor to represent the lack of information. The patient’s birth date would be represented with a null flavor of “NAV”, which is the code for “temporarily unavailable”. When the patient regains consciousness or a relative arrives, we expect to know the patient’s birth date.

Figure 6: nullFlavor example

<birthTime nullFlavor=”NAV”/> 

Use null flavors for unknown, required, or optional attributes: NI No information. This is the most general and default null flavor.NA Not applicable. Known to have no proper value (e.g., last menstrual

period for a male).UNK Unknown. A proper value is applicable, but is not known.ASKU Asked, but not known. Information was sought, but not found (e.g.,

the patient was asked but did not know).NAV Temporarily unavailable. The information is not available, but is

expected to be available later.NASK Not asked. The patient was not asked.MSK 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.

This above list contains those null flavors that are commonly used in clinical documents. For the full list and descriptions, see the nullFlavor vocabulary domain in the CDA normative edition6. Any SHALL conformance statement may use nullFlavor, unless the attribute is required or the nullFlavor is explicitly disallowed. SHOULD and MAY conformance statement may also use nullFlavor.

Figure 7: Attribute required

1. SHALL contain exactly one [1..1] code/@code="11450-4" Problem List (CodeSystem: LOINC 2.16.840.1.113883.6.1) or 2. SHALL contain exactly one [1..1] effectiveTime/@value.

6 HL7 Clinical Document Architecture (CDA Release 2) http://www.hl7.org/implement/standards/cda.cfm

http://www.hl7.org/implement/standards/cda.cfm

Figure 8: Allowed nullFlavors when element is required (with xml examples)

1. SHALL contain at least one [1..*] id 2. SHALL contain exactly one [1..1] code 3. SHALL contain exactly one [1..1] effectiveTime

<entry> <observation classCode="OBS" moodCode="EVN"> <id nullFlavor="NI"/> <code nullFlavor="OTH"> <originalText>New Grading system</originalText> </code> <statusCode code="completed"/> <effectiveTime nullFlavor="UNK"/> <value xsi:type="CD" nullFlavor="NAV"> <originalText>Spiculated mass grade 5</originalText> </value> </observation></entry>

Figure 9: nullFlavor explicitly disallowed

1. SHALL contain exactly one [1..1] effectiveTime. a. SHALL NOT contain [0..0] nullFlavor.

1.3.8 Unknown InformationIf a sender wants to state that a piece of information is unknown, the following principles apply:

1. If the sender doesn’t know an attribute of an act, that attribute can be null.

Figure 10: Unknown medication example

<entry> <text>patient was given a medication but I do not know what it was</text> <substanceAdministration moodCode="EVN" classCode="SBADM"> <consumable> <manufacturedProduct> <manufacturedLabeledDrug> <code nullFlavor="NI"/> </manufacturedLabeledDrug> </manufacturedProduct> </consumable> </substanceAdministration></entry>

2. If the sender doesn’t know if an act occurred, the nullFlavor is on the act (detail could include specific allergy, drug, etc.).

Figure 11: Unkown medication use of anticoagulant drug example

<entry> <substanceAdministration moodCode="EVN" classCode="SBADM" nullFlavor="NI"> <text>I do not know whether or not patient received an anticoagulant drug</text> <consumable> <manufacturedProduct> <manufacturedLabeledDrug> <code code="81839001" displayName="anticoagulant drug" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/> </manufacturedLabeledDrug> </manufacturedProduct> </consumable> </substanceAdministration></entry>

3. If the sender wants to state ‘no known’, a negationInd can be used on the corresponding act (substanceAdministration, Procedure, etc.)

Figure 12: No known medications example

<entry> <substanceAdministration moodCode="EVN" classCode="SBADM" negationInd=”true”> <text>No known medications</text> <consumable> <manufacturedProduct> <manufacturedLabeledDrug> <code code="410942007" displayName="drug or medication" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/> </manufacturedLabeledDrug>

</manufacturedProduct> </consumable> </substanceAdministration></entry>

Other implementation guides recommended using specific codes to assert no known content, for example SNOMED CT 160244002 No known allergies or 160245001 No current problems or disability. Specific codes are still allowed; however, use of these codes is not recommended.

1.3.9 Data TypesAll data types used in a CDA document are described in the CDA R2 normative edition7. All attributes of a data type are allowed unless explicitly prohibited by this specification.

1.4 XML Conventions Used in This Guide

1.4.1 XPath Notation Instead of the traditional dotted notation used by HL7 to represent Reference Information Model (RIM) classes, this document uses XML Path Language (XPath) notation8 in conformance statements and elsewhere to identify the Extended Markup Language (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. This notation provides a mechanism that will be familiar to developers for identifying parts of an XML document.Xpath statements appear in this document in a monospace font.XPath syntax selects nodes from an XML document using a path containing the context of the node(s). The path is constructed from node names and attribute names (prefixed by a ‘@’) and catenated with a ‘/’ symbol.

Figure 13: XML document example

<author><assignedAuthor>...<code codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT'

code='17561000' displayName='Cardiologist' />...</assignedAuthor>

</author>

In the above example, the code attribute of the code could be selected with the XPath expression in the next figure.

Figure 14: XPath expression example

author/assignedAuthor/code/@code

7 HL7 Clinical Document Architecture (CDA Release 2). http://www.hl7.org/implement/standards/cda.cfm8 http://www.w3.org/TR/xpath/

http://www.w3.org/TR/xpath/

1.4.2 XML Examples and Sample DocumentsExtended Mark-up Language (XML) examples appear in figures in this document in this monospace 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 15: ClinicalDocument example

<ClinicalDocument xmls="urn:h17-org:v3"> ...</ClinicalDocument>

Within the narrative, XML element (code, assignedAuthor, etc.) and attribute (SNOMED CT, 17561000, etc.) names also appear in this monospace font.

2 DOCUMENT-LEVEL TEMPLATESDocument-level templates describe the purpose and rules for constructing a conforming CDA document. Document templates include constraints on the CDA header and sections by refering to templates, and constraints on the vocabulary used in those templates. Each document-level template contains the following information:

Scope and intended use of the document type Description and explanatory narrative. Template metadata (e.g., templateId, etc.) Header constraints Required and optional section-level templates

2.1 Diagnostic Imaging Report Release 2

Template Name

Diagnostic Imaging Report Release 2

Template ID 1.2.840.10008.20.1.1 (open)Parent

Template

General Description

A Diagnostic Imaging Report (DIR) is a document that contains a consulting specialist’s interpretation of image data. It conveys the interpretation to the referring (ordering) physician and becomes part of the patient’s medical record. It is for use in Radiology, Endoscopy, Cardiology, and other imaging specialties, and includes screening, diagnostic, and some interventional procedures.

Document Code From Value Set DIRDocumentTypeCodes 2.16.840.1.113883.11.20.9.32

Body StructuredBody Level 2/3

Card Condition Data Element or Section Name Template ID Vocabulary Constraint

Header ElementsGeneral Header

[1..*]Record Target and Patient Demographics

[1..1]Component of Encompassing Encounter

1.3.6.1.4.1.19376.1.4.1.3.1


Status: this section has been reviewed once, but will definitely need additional review once we are through section 4.

[1..*] In Fulfillment of Order 1.3.6.1.4.1.19376.1.4.1.3.2

[1..1]Documentation of Service Event and Performer

1.3.6.1.4.1.19376.1.4.1.3.4

[1..*] Author[0..1] Legal Authenticator[1..1] Custodian[0..2] Related Document[0..*] Other Participants

Sections

[1..1]Current Imaging Procedure Description

[0..1] Clinical Information

[0..1] Comparison / Previous Findings

[0..1] Findings (DIR)[1..1] Impressions[0..1] Addendum

[0..1] DICOM Object Catalog 2.16.840.1.113883.10.20.6.1.1

2.1.1 DIR Header Constraints

2.1.1.1 GeneralShall conform to General Header Constraints (add reference).

2.1.1.2 ClinicalDocument/templateIdConformant documents must carry the document-level templateId asserting conformance with specific constraints of a DIR.

3. SHALL contain exactly one [1..1] templateId (CONF:8404) such that ita. SHALL contain exactly one [1..1] @root=”1.2.840.10008.20.1.1”

2.1.1.3 ClinicalDocument/codeGiven that DIR documents may be transformed from established collections of imaging reports already stored with their own type codes, there is no static set of Document Type codes. The set of LOINC codes listed in the DIR LOINC Document Type Codes table may be extended by additions to LOINC and supplemented by local codes as translations.

conf:8404

The DIR document recommends use of a single document type code, 18748-4 “Diagnostic Imaging Report”, with further specification provided by author or performer, setting, or specialty. Some of these codes in the DIR LOINC Document Type Codes table are pre-coordinated with either the imaging modality, body part examined, or specific imaging method such as the view. When pre-coordinated codes are used, any coded values describing the author or performer of the service act or the practice setting must be consistent with the LOINC document type. This table is drawn from LOINC, and consists of codes whose scale is DOC and that refer to reports for diagnostic imaging procedures.

4. SHALL contain exactly one [1..1] code (3). a. This code SHOULD contain zero or one [0..1] @code), which SHOULD be

selected from ValueSet DIRDocumentTypeCode 2.16.840.1.113883.11.20.9.32 DYNAMIC (4).

Table 1: DIR LOINC Document Type Codes

Value Set: DIRDocumentTypeCodes 2.16.840.1.113883.11.20.9.32 DYNAMICCode System: LOINC 2.16.840.1.113883.6.1LOINC Code

DIR ‘Modality’

Common DIR Display Name

Setting ‘System’

Specialty/Training/Professional Level ‘Method_Type’

Preferred Code18748-4 Any Diagnositic

Imaging ReportDiagnostic Imaging

Additional Codes18747-6 Computed

TomographyCT Report CT

18755-9 Magnetic Resonance Imaging

MRI Report MRI

18760-9 Ultrasound Ultrasound Report US18757-5 Nuclear

MedicineNuclear Medicine Report

RadNuc

17787-3 Nuclear Medicine

Thyroid Scan Report

Thyroid RadNuc

18758-3 Positron Emission Tomography

PET Scan Report Pet scan

11522-0 Cardiac Ultrasound

Echocardiography Report

Heart Cardiac echo

18746-8 Colonoscopy Colonoscopy Report

Lower GI tract Colonoscopy

18751-8 Endoscopy Endoscopy Report Upper GI tract Endoscopy11525-3 Ultrasound Obstetrical

Ultrasound ReportPelvis+Fetus OB.US

43468-8 X-Ray Radiography

Radiography Report XR

conf:14834

conf:14833

Value Set: DIRDocumentTypeCodes 2.16.840.1.113883.11.20.9.32 DYNAMICCode System: LOINC 2.16.840.1.113883.6.1LOINC Code

DIR ‘Modality’

Common DIR Display Name

Setting ‘System’

Specialty/Training/Professional Level ‘Method_Type’

49512-7 X-Ray Fluoroscopy

Fluoroscopy Report XR.fluor

24606-6 Mammography Screening Report

Mammography Screening Report

Breast Mam

24605-8 Mammography Diagnostic Report

Diagnostic Mammography Report

Breast Mam

38269-7 Bone Density Report

Bone Density Report

Skeletal system

XR.DXA

Figure 16: DIR ClinicalDocument/code example

<code code=”18748-4” codeSystem=”2.16.840.1.113883.6.1” codeSystemName=”LOINC” displayName=”Diagnostic Imaging Report”/>

Figure 17: DIR use of the translation element to include local codes for document type

<code code=”18748-4” 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>

2.1.1.4 Record Target 1. SHALL contain at least one [1..*] recordTarget.

Note: Multiple recordTargets should be used only in the case of conjoined twins/triplets who are the subject of a single imaging procedure, or for special cases (e.g., pre-natal surgery) where a medical record has been established for the fetus.

2.1.2 DIR Body Constraints

The Diagnostic Imaging Report is a Level 2 or Level 3 conformant CDA document. All top-level section elements that are present in the Body of the document (i.e., the immediate components of StructuredBody) must have a code, a title, and some nonblank text or

one or more subsections, even if the purpose of the text is only to indicate that information is unknown or not applicable.

2. SHALL contain exactly one [1..1] component / structuredBody.

2.1.2.1 DICOM Object Catalog Section a. If the document contains references to DICOM SOP Instances (images,

structured report measurements, or other information objects), the component/structuredBody SHALL contain exactly one [1..1] DICOM Object Catalog Section (templateId:2.16.840.1.113883.10.20.6.1.1),

b. Otherwise, MAY contain one [0..1] DICOM Object Catalog Section

2.1.2.2 Addendum c. If the header includes a relatedDocument element with typeCode APND,

the component/structuredBody SHALL contain exactly one [1..1] Addendum Section.

2.1.2.3 DIR Clinical Statements A Diagnostic Imaging Report may contain CDA entries in any of its sections that represent, in coded form findings, image references, annotation, and numeric measurements. See PS 3.20 “Transformation of DICOM to and from HL7 Standards” for descriptions of transformations of observations from DICOM Structured Reporting instances. For this document template, Spatial Coordinates region of interest (SCOORD) for linear, area, and volume measurements are not encoded in the CDA document. If it is desired to show images with such graphical annotations, the annotations should be encoded in DICOM Softcopy Presentation State objects that reference the image. Report applications that display referenced images and annotation may retrieve a rendered image using a WADO reference in accordance with PS3.18, including the image and Presentation State, or other DICOM retrieval and rendering methods. This approach avoids the risks of errors in registering a CDA region of interest annotation with DICOM images.

2.2 Interventional Radiology Report (reserved)Similar to diagnostic; includes consents, sedation, blood loss? Use Procedure Description rather than Current Imaging Procedure Description

2.3 Anatomic Pathology Report (reserved)Kussaibi, et al. “HL7 CDA Implementation Guide for Structured Anatomic Pathology Reports Methodology and Tools” doi:10.3233/978-1-60750-588-4-289

CLINICAL INFORMATIONClinical information provided by the ordering physician: reason for anatomic pathology procedure, active problems (preoperative and/or postoperative diagnosis, lab data), collection procedure(s) and specimen description(s) for all delivered specimen(s) reported separately.

Reason for AP procedureHistory of present illnessActive ProblemsSpecimen clinical information entrySpecimen Information Organizero Collection procedureo Specimen(s) typeo Specimen location


Why is this section in here? We are not including a Path report template, are we? Their templates are much more definitive (more like cardiology). Or, are we just saying that this DIR template could also be used for Path?

INTRAOPERATIVE EXAMINATION (conditional)Intraoperative diagnoses +/- images for all delivered specimen( s) reported separately.

Intraoperative entrySpecimen Information Organizero Diagnostic observationo Link(s) to images

MACROSCOPIC OBSERVATIONCollection procedure(s) and specimen description(s) (if not provided by the ordering physician), +/- gross findings +/- images for all delivered specimen( s) reported separately.

Macroscopic observation entrySpecimen Information Organizer(s)o Collection procedureo Specimen typeo Diagnostic observation(s)o Link(s) to images

MICROSCOPIC EXAMINATION (Optional)Histopathologic findings (e.g results of histo-chemical and immunohistochemical stains) +/- images for some delivered specimen(s) reported separately.

Microscopic observation entrySpecimen Information Organizer(s)o Diagnostic observation (s)o Link(s) to images

DIAGNOSTIC FINDINGSDiagnoses +/- additional pathologic finding(s) +/- results of ancillary studi(es) (=cancer checklist(s), in case of cancer) +/- images for all specimens delivered, reported separately.

Diagnostic findings entrySpecimen Information Organizer(s)o Tumor location*o Tumor histologic type and grade*o Tumor extension (including pT, pN)*o Treatment effecto Additional findingso Results of ancillary techniqueso Link(s) to images

TISSUE DISSECTION AND ANCILLARY TESTS (Optional)Tissue dissection (representative specimens and derived specimens dissected for other ancillary procedures (flow cytometry, cytogenetics, molecular studies, electron microscopy, etc) or biorepository) for all specimens delivered, reported separately.

Tissue dissection and ancillary tests entrySpecimen Information Organizer(s)o Dissection techniqueo Specimen typeo Ancillary technique

3 HEADER CONTENT MODULESThis section describes constraints that apply to the header components. Header constraints specific to each document type are described in the appropriate document-specific section.

3.1 General Header Constraints1. SHALL contain exactly one [1..1] typeId.

a. This typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3".

b. This typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040".

2. SHALL contain exactly one [1..1] id. a. This id SHALL be a globally unique identifier for the document.

3. SHALL contain exactly one [1..1] code. a. This code SHALL specify the particular kind of document (e.g. History and

Physical, Discharge Summary, Progress Note).4. SHALL contain exactly one [1..1] title.

a. can either be a locally defined name or the display name corresponding to clinicalDocument/code.

5. SHALL contain exactly one [1..1] effectiveTime. a. Signifies the document creation time, when the document first came into

being. Where the CDA document is a transform from an original document in some other format, the ClinicalDocument.effectiveTime is the time the original document is created. The time when the transform occurred is not currently represented in CDA (CONF:9995).

6. SHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 STATIC 2010-04-21.

7. SHALL contain exactly one [1..1] languageCode which SHALL be selected from ValueSet Language 2.16.840.1.113883.1.11.11526 DYNAMIC.

8. MAY contain zero or one [0..1] setId. a. If setId is present versionNumber SHALL be present..9

9. MAY contain zero or one [0..1] versionNumber. a. If versionNumber is present setId SHALL be present..10

9 From CDA Normative Web edition: 4.2.1.7 ClinicalDocument.setId - Represents an identifier that is common across all document revisions and “Document Identification, Revisions, and Addenda” under 4.2.3.1 ParentDocument10 From CDA Normative Web edition: 4.2.1.8 ClinicalDocument.versionNumber An integer value used to version successive replacement documents


Status: needs to be re-reviewed, but not urgent. After all DIR-specific sections and entries?

conf:9995

Table 2: Basic Confidentiality Kind Value Set

Value Set: HL7 BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 STATIC 2010-04-21Code System(s):

Confidentiality Code 2.16.840.1.113883.5.25

Code Code System Print NameN Confidentiality Code NormalR Confidentiality Code RestrictedV Confidentiality Code Very Restricted

Table 3: Language Value Set (excerpt)

Value Set: Language 2.16.840.1.113883.1.11.11526 DYNAMICCode System(s):

Internet Society Language 2.16.840.1.113883.1.11.11526

Description: A value set of codes defined by Internet RFC 4646 (replacing RFC 3066). Please see ISO 639 language code set maintained by Library of Congress for enumeration of language codeshttp://www.ietf.org/rfc/rfc4646.txt

Code Code System Print Nameen Internet Society Language englishfr Internet Society Language frenchar Internet Society Language arabicen-US Internet Society Language English, USes-US Internet Society Language Spanish, US…

http://www.ietf.org/rfc/rfc4646.txt

Figure 18: header example

<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/><templateId root="2.16.840.1.113883.10.20.22.1.1"/>

<!— Diagnostic Imaging Report Release 2 Template --><templateId root="1.2.840.10008.20.1.1"/> <id extension="999021" root="2.16.840.1.113883.19"/> <code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" code="18748-4" displayName="Diagnositic Imaging Report"/> <title>Radiology Report</title> <effectiveTime value="20150329171504+0500"/><confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/><languageCode code="en-US" codeSystem="2.16.840.1.113883.1.11.11526"/><setId extension="111199021" root="2.16.840.1.113883.19"/><versionNumber value="1"/>

3.1.1 Rendering Header Information for Human PresentationMetadata carried in the header may already be available for rendering from electronic medical records (EMRs) or other sources external to the document; therefore, there is no strict requirement to render directly from the document. An example of this would be a doctor using an EMR that already contains the patient’s name, date of birth, current address, and phone number. When a CDA document is rendered within that EMR, those pieces of information may not need to be displayed since they are already known and displayed within the EMR’s user interface. Good practice would recommend that the following be present whenever the document is viewed:

Document title and document dates Service and encounter types, and date ranges as appropriate Names of all persons along with their roles, participations, participation date

ranges, identifiers, address, and telecommunications information Names of selected organizations along with their roles, participations,

participation date ranges, identifiers, address, and telecommunications information

Date of birth for recordTarget(s)

3.2 RecordTarget and Patient DemographicsThe recordTarget records the patient whose health information is described by the clinical document; it must contain at least one patientRole element.

Template ID

Parent Template none

General Description Identification of the patient demographics.

Header Element recordTarget / patientRole

Code n/a

Card Entity Description Template Spec Document

Vocabulary Constraint

[1..1] patient (player) Patient

[0..1] providerOrganization (scoper)

Patient ID assigning authority

Card Attribute Description Template Spec Document


[1.*] id

[1.*] addr

[1..*] telecom

d. A recordTarget SHALL contain exactly one [1..1] patientRole. i. This patientRole SHALL contain at least one [1..*] id ii. This patientRole SHALL contain at least one [1..*] addr.iii. This patientRole SHALL contain at least one [1..*] telecom.

3.2.1 Patientiv. This patientRole SHALL contain exactly one [1..1] patient.

1. This patient SHALL contain exactly one [1..1] name.2. Error! Hyperlink reference not valid.This patient SHALL

contain exactly one [1..1] administrativeGenderCode, which SHALL be selected from ValueSet Administrative Gender (HL7 V3) 2.16.840.1.113883.1.11.1 DYNAMIC.

3. This patient SHALL contain exactly one [1..1] birthTime. a. SHALL be precise to year.b. SHOULD be precise to day.

3.2.2 ProviderOrganizationv. This patientRole MAY contain zero or one [0..1]

providerOrganization. 1. This providerOrganization, if present, SHALL contain one or

more one [1..*] name. 2. This providerOrganization, if present, SHOULD contain at

least one [1..*] telecom. 3. Error! Hyperlink reference not valid.This

providerOrganization, if present, SHOULD contain at least one [1..*] addr.

3.2.3 RecordTarget Value SetsTable 4: Administrative Gender (HL7) Value Set

Value Set: Administrative Gender (HL7 V3) 2.16.840.1.113883.1.11.1 DYNAMICCode System(s): AdministrativeGender 2.16.840.1.113883.5.1Code Code System Print NameF AdministrativeGender FemaleM AdministrativeGender MaleUN AdministrativeGender Undifferentiated

3.2.4 RecordTarget ExampleFigure 19: recordTarget example

<recordTarget> <patientRole> <id extension=”12345” root=”2.16.840.1.113883.19”/> <!—Fake ID using HL7 example OID. -> <id extension=”111-00-1234” root=”2.16.840.1.113883.4.1”/> <!—Fake Social Security Number using the actual SSN OID. -> <addr use=”HP”> <!—HP is “primary home” from codeSystem 2.16.840.1.113883.5.1119 -> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> <!—US is “United States” from ISO 3166-1 Country Codes: 1.0.3166.1 -> </addr> <telecom value=”tel:(781)555-1212” use=”HP”/> <!—HP is “primary home” from AddressUse 2.16.840.1.113883.5.1119 -> <patient> <name use=”L”> <!—L is “Legal” from EntityNameUse 2.16.840.1.113883.5.45 -> <prefix>Mr.</prefix> <given>Adam</given> <given qualifier=”CL”>Frankie</given> <!—CL is “Call me” from EntityNamePartQualifier 2.16.840.1.113883.5.43 -> <family>Everyman</family> </name> <administrativeGenderCode code=”M” codeSystem=”2.16.840.1.113883.5.1” displayName=”Male”/> <birthTime value=”19541125”/> </patient>

<providerOrganization> <id root=”2.16.840.1.113883.19”/> <name>Good Health Clinic</name> <telecom use=”WP” value=”tel:(781)555-1212”/> <addr> <streetAddressLine>21 North Ave</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> </providerOrganization> </patientRole></recordTarget>

3.3 componentOf Encompassing EncounterTemplate ID 1.3.6.1.4.1.19376.1.4.1.3.1

Parent Template None

General DescriptionThe setting of the clinical encounter during which the documented act(s) or ServiceEvent occurred. This template includes specializations of Responsible Party, Health Care Facility, Referring Provider, and Physician of Record.

Header Element componentOf / encompassingEncounter

Code Not constrained

Card Participation Description Template Spec Document


[0..1] RESP Responsible Party

[1..1] LOC Health Care Facility

[0..1] REF Referring Provider

[0..1] ATND Physician of Record 2.16.840.1.113883.10.20.6.2.2

The id element of the encompassingEncounter represents the identifier for the encounter. When the diagnostic imaging procedure is performed in the context of a hospital stay or an outpatient visit for which there is an Encounter Number, that number should be present as the ID of the encompassingEncounter.The effectiveTime represents the time interval or point in time in which the encounter took place. The encompassing encounter might be that of the hospital or office visit in which the diagnostic imaging procedure was performed. If the effective time is unknown, a nullFlavor attribute can be used.

e. The componentOf SHALL contain exactly one [1..1] encompassingEncounter

i. This encompassingEncounter SHOULD contain at least one [1..*] id (CONF:8435).

ii. This encompassingEncounter SHALL contain exactly one [1..1] effectiveTime (CONF:8437).



conf:8437

conf:8435

iii. This encompassingEncounter MAY contain zero or more [0..1] responsibleParty (CONF:8438).

1. This responsibleParty, if present, SHALL contain exactly one [1..1] assignedEntity (CONF:9407).

a. SHOULD contain zero or one [0..1] assignedPerson OR contain zero or one [0..1] representedOrganization (CONF:8439).

iv. This encompassingEncounter SHOULD contain zero or one [0..1] Physician of Record Participant (templateId:2.16.840.1.113883.10.20.6.2.2) (CONF:8448).

Figure 20: DIR componentOf example

<componentOf> <encompassingEncounter> <id extension=”9937012” root=”1.3.6.4.1.4.1.2835.12”/> <effectiveTime value=”20060828170821”/> <encounterParticipant typeCode=”ATND”> <templateId root=”2.16.840.1.113883.10.20.6.2.2”/> <assignedEntity> <id extension=”4” root=”2.16.840.1.113883.19”/> <code code=”208D00000X” codeSystem=”2.16.840.1.113883.6.101” codeSystemName=”NUCC” displayName=”General Practice”/> <addr nullFlavor=”NI”/> <telecom nullFlavor=”NI”/> <assignedPerson> <name> <prefix>Dr.</prefix> <given>Fay </given> <family>Family</family> </name> </assignedPerson> </assignedEntity> </encounterParticipant> </encompassingEncounter></componentOf>

3.3.1 Physician of Record Participant[encounterParticipant: templateId 2.16.840.1.113883.10.20.6.2.2(open)]

This encounterParticipant is the attending physician and is usually different from the Physician Reading Study Performer defined in documentationOf/serviceEvent.

5. SHALL contain exactly one [1..1] @typeCode=”ATND” Attender (CodeSystem: HL7ParticipationType 2.16.840.1.113883.5.90) (CONF:8881).

6. SHALL contain exactly one [1..1] templateId/@root=”2.16.840.1.113883.10.20.6.2.2” (CONF:8440).

7. SHALL contain exactly one [1..1] assignedEntity (CONF:8886). a. This assignedEntity SHALL contain at least one [1..*] id (CONF:8887). b. This assignedEntity SHOULD contain zero or one [0..1] name (CONF:8890).

conf:8890

conf:8887

conf:8886

conf:8440

conf:8881

conf:8448

conf:8439

conf:9407

conf:8438

Figure 21: Physician of record participant example

<encounterParticipant typeCode=”ATND”> <templateId root=”2.16.840.1.113883.10.20.6.2.2”/> <assignedEntity> <id extension=”44444444” root=”2.16.840.1.113883.4.6”/> <code code=”208D00000X” codeSystem=”2.16.840.1.113883.6.101” codeSystemName=”NUCC” displayName=”General Practice”/> <addr nullFlavor=”NI”/> <telecom nullFlavor=”NI”/> <assignedPerson> <name> <prefix>Dr.</prefix> <given>Fay</given> <family>Family</family> </name> </assignedPerson> </assignedEntity></encounterParticipant>

3.4 inFulfillmentOf OrderTemplate ID 1.3.6.1.4.1.19376.1.4.1.3.2


General Description Identification of orders that are fulfilled by this document.

Header Element inFulfillmentOf / order

Code Not constrained

An inFulfillmentOf element represents the Placer Order that is either a group of orders (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 Digital Imaging and Communications in Medicine (DICOM) image and structured reporting data. The example of a CT examination covering chest, abdomen, and pelvis will be used in the discussion below.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.



1. There SHALL be one inFulfillmentOf/order/id for each distinct Order Placer Number associated with the report.

2. There SHALL be one inFulfillmentOf/order/id for the DICOM Accession Number in the imaging data.

Figure 22: DIR inFulfillmentOf example

<inFulfillmentOf> <order> <id extension=”10523475” root=”2.16.840.1.113883.19.4.27”/> <!-- {root}.27= accession number list *-> </order></inFulfillmentOf>

3.5 documentationOf Service Event and PerformerTemplate ID 1.3.6.1.4.1.19376.1.4.1.3.4


General Description Identification of the procedure being documented

Header Element documentationOf/ serviceEvent

CodeMAY be selected from code system LOINC, RadLex Playbook, or 2.16.840.1.113883.6.96 SNOMED CT. SHOULD include <translation> with a modality code from value set CID29, and a target region code from value set …

Card Participation Description Template Spec Document


[0..*] PRF Physician Reading Study

[0..1] SPRF Irradiation Authorizing Physician

code/@code= "113850" Irradiation Authorizing (CodeSystem: 1.2.840.10008.2.16.4 DCM)

[0..*] PRF Technologist

Each documentationOf/serviceEvent indicates an imaging procedure that the provider describes and interprets in the content of the DIR. 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 each 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 primary vocabulary to use for describing this event. However, it is recommended that the serviceEvent/code/translation element include codes representing the modality using DICOM (DCM) terminology, and target anatomic region using SNOMED.

Note: These codes may be used as health information exchange search metadata in accordance with the IHE XDS Profile.

Figure 23: DIR procedure context (CDA Header) illustration (non-normative)

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 Modality Worklist. These two ids are in a single serviceEvent.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 the ID of the Requested Procedure.

f. The documentationOf SHALL contain exactly one [1..1] serviceEvent. i. This serviceEvent SHALL contain exactly one [1..1]

@classCode="ACT" (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

ii. This serviceEvent SHOULD contain zero or more [0..*] id. iii. This serviceEvent SHALL contain exactly one [1..1] code.

1. The value of serviceEvent/code SHALL NOT conflict with the ClininicalDocument/code. When transforming from DICOM SR documents that do not contain a procedure code, an appropriate nullFlavor SHALL be used on serviceEvent/code.

iv. This serviceEvent SHOULD contain zero or more [0..*] Physician Reading Study Performer (templateId:2.16.840.1.113883.10.20.6.2.1).

0..* serviceEvent

typeCode*: <= DOCdocumentationOf

ServiceEventclassCode*: <= ACTmoodCode*: <= EVNid: SET<II> [0..*]code: CE CWE [0..1]effectiveTime: IVL<TS> [0..1]

0..* assignedEntity

performertypeCode*: <= x_ServiceEventPerformerfunctionCode: CE CWE [0..1] <= ParticipationFunctiontime: IVL<TS> [0..1]

0..1 assignedPerson

0..1 representedOrganizationAssignedEntity

ClinicalDocumentclassCode*: <= DOCCLINmoodCode*: <= EVNid*: II [1..1]code*: CE CWE [1..1] <= DocumentTypetitle*: ST [1..1]effectiveTime*: TS [1..1]confidentialityCode*: CE CWE [1..1] <=x_BasicConfidentialityKindlanguageCode: CS CNE [0..1] <= HumanLanguagesetId: II [0..1]versionNumber: INT [0..1]copyTime: TS [0..1] (Deprecated)

Figure 24: DIR documentationOf example

<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"/>  <code code="71020" displayName="Radiologic examination, chest, two views, frontal and lateral” codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT4"/> <effectiveTime value="20060823222400"/> <performer typeCode="PRF"> <templateId root="2.16.840.1.113883.10.20.6.2.1"/> <assignedEntity> <id extension="121008" root="2.16.840.1.113883.19.5"/> <code code="2085R0202X" codeSystem="2.16.840.1.113883.6.101" codeSystemName="NUCC" displayName="Diagnostic Radiology"/> <addr nullFlavor="NI"/> <telecom nullFlavor="NI"/> <assignedPerson> <name> <given>Christine</given> <family>Cure</family> <suffix>MD</suffix> </name> </assignedPerson> </assignedEntity> </performer> </serviceEvent></documentationOf>

3.5.1 Physician Reading Study Performer[performer: templateId 2.16.840.1.113883.10.20.6.2.1(open)]

This participant is the Physician Reading Study Performer defined in documentationOf/serviceEvent and is usually different from the attending physician. The reading physician interprets the images and evidence of the study (DICOM Definition)

8. SHALL contain exactly one [1..1] @typeCode="PRF" Performer (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).


10. MAY contain zero or one [0..1] time representing the time of reading the study. 11. SHALL contain exactly one [1..1] assignedEntity.

a. This assignedEntity SHALL contain at least one [1..*] id.b. Every assignedEntity element SHALL have at least one assignedPerson or

representedOrganization..

Figure 25: Physician reading study performer example

<performer typeCode="PRF"> <templateId root="2.16.840.1.113883.10.20.6.2.1"/> <assignedEntity> <id extension="111111111" root="2.16.840.1.113883.4.6"/> <code code="2085R0202X" codeSystem="2.16.840.1.113883.6.101" codeSystemName="NUCC" displayName="Diagnostic Radiology"/> <addr nullFlavor="NI"/> <telecom nullFlavor="NI"/> <assignedPerson> <name> <given>Christine</given> <family>Cure</family> <suffix>MD</suffix> </name> </assignedPerson> </assignedEntity></performer>

3.5.2 Irradiation Authorizing Performer[performer: templateId (open)]

This participant is the irradiation authorizing person who is the clinician responsible for determining that the irradiating procedure was appropriate for the indications. (DICOM Definition)

12. If modality is CT, MG, NM, PT, XR, XA, or XF, SHOULD contain exactly one [1..1] @typeCode="PRF" Performer (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

13. SHALL contain exactly one [1..1] templateId/@root="" (CONF:). 14. MAY contain zero or one [0..1] time representing the time of irradiation

authorization. 15. SHALL contain exactly one [1..1] assignedEntity.

a. This assignedEntity SHALL contain at least one [1..*] id.b. This assignedEntity SHALL contain exactly one [1..1]

code/@code="113850" Irradiation Authorizing (CodeSystem: DCM 1.2.840.10008.2.16.4) (CONF:).

c. Every assignedEntity element SHALL have exactly one assignedPerson. (CONF:).

i. This assignedPerson SHALL contain exactly one [1..1] nameii. This assignedPerson MAY contain zero or more [0..*] addr.iii. This assignedPerson MAY contain zero or more [0..*] telecom.

3.6 Author (Person)The author element represents the creator of the clinical document. This template restricts the author to be a person.



b. Such authors SHALL contain exactly one [1..1] time representing the start time of the author’s participation in the creation of the content of the clinical document

c. Such authors SHALL contain exactly one [1..1] assignedAuthor. i. This assignedAuthor SHALL contain at least one [1..*]addr.i. This assignedAuthor SHALL contain at least one [1..*] telecom. ii. This assignedAuthor SHALL contain exactly one [1..1]

assignedPerson.

Figure 26: Person author example

<author> <time value="20050329224411+0500"/> <assignedAuthor> <id extension="KP00017" root="2.16.840.1.113883.19.5"/> <addr> <streetAddressLine>21 North Ave.</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom use="WP" value="tel:(555)555-1003"/> <assignedPerson> <name> <given>Henry</given> <family>Seven</family> </name> </assignedPerson> </assignedAuthor></author>

3.7 LegalAuthenticatorTemplate ID 1.3.6.1.4.1.19376.1.4.1.3.5


General Description Description of the document’s legal authenticator, identifying the person signing the report

Header Element legalAuthenticator / assignedEntity

Code SHOULD be present with the Legal Authenticator’s specialty, with values from coding system NUCC Health Care Provider Taxonomy (in the US) or the equivalent

The legalAuthenticator identifies the single person legally responsible for the document and must be present if the document has been legally authenticated. (Note that there may also be one or more document authenticators.) Based on local practice, clinical documents may be released before legal authentication. This implies that a clinical document that does not contain this element has not been legally authenticated.



The act of legal authentication requires a certain privilege be granted to the legal authenticator depending upon local policy. All clinical documents have the potential for legal authentication, given the appropriate credentials.Local policies MAY choose to delegate the function of legal authentication to a device or system that generates the clinical document. In these cases, the legal authenticator is a person accepting responsibility for the document, not the generating device or system.Note that the legal authenticator, if present, must be a person.

b. The legalAuthenticator SHALL contain exactly one [1..1] time representing the time of signature

c. This legalAuthenticator SHALL contain exactly one [1..1] signatureCode. i. This signatureCode SHALL contain exactly one [1..1] @code="S"

(CodeSystem: Participationsignature 2.16.840.1.113883.5.89).

d. This legalAuthenticator SHALL contain exactly one [1..1] assignedEntity. i. This assignedEntity SHALL contain at least one [1..*] id.ii. This assignedEntity SHALL contain at least one [1..*]addr.ii. This assignedEntity SHALL contain at least one [1..*] telecom. iii. This assignedEntity SHALL contain exactly one [1..1]

assignedPerson. 1. This assignedPerson SHALL contain at least one [1..*] name.

Figure 27: legalAuthenticator example

<legalAuthenticator> <time value="20050329224411+0500"/> <signatureCode code="S"/> <assignedEntity> <id extension="KP00017" root="2.16.840.1.113883.19"/> <addr> <streetAddressLine>21 North Ave.</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom use="WP" value="tel:(555)555-1003"/> <assignedPerson> <name> <given>Henry</given> <family>Seven</family> </name> </assignedPerson> </assignedEntity></legalAuthenticator>

3.8 CustodianThe custodian element represents the organization that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document. Every CDA document has exactly one custodian. The custodian participation satisfies the



CDA definition of Stewardship. Because CDA is an exchange standard and may not represent the original form of the authenticated document (e.g., CDA could include scanned copy of original), the custodian represents the steward of the original source document. The custodian may be the document originator, a health information exchange, or other responsible party.

d. This custodian SHALL contain exactly one [1..1] assignedCustodian. i. This assignedCustodian SHALL contain exactly one [1..1]

representedCustodianOrganization. 1. This representedCustodianOrganization SHALL contain at

least one [1..*] id2. This representedCustodianOrganization SHALL contain

exactly one [1..1] name. 3. This representedCustodianOrganization SHALL contain

exactly one [1..1] telecom. 2. This representedCustodianOrganization SHALL contain

exactly one [1..1] addr.

Figure 28: Custodian example

<custodian> <assignedCustodian> <representedCustodianOrganization> <id root="2.16.840.1.113883.19.5"/> <name>Good Health Clinic</name> <telecom value="tel:(555)555-1212" use="WP"/> <addr use="WP"> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> </representedCustodianOrganization> </assignedCustodian></custodian>

3.9 Other Participants

3.9.1 DataEntererThe dataEnterer element represents the person who transferred the content, written or dictated by someone else, into the clinical document. The guiding rule of thumb is that an author provides the content found within the header or body of the document, subject to their own interpretation, and the dataEnterer adds that information to the electronic system. In other words, a dataEnterer transfers information from one source to another (e.g., transcription from paper form to electronic system).

2. MAY contain zero or one [0..1] dataEnterer.



a. This dataEnterer, if present, SHALL contain exactly one [1..1] assignedEntity.

i. This assignedEntity SHALL contain at least one [1..*] id.ii. This assignedEntity SHALL contain at least one [1..*] addr.iii. This assignedEntity SHALL contain at least one [1..*] telecom. iv. This assignedEntity SHALL contain exactly one [1..1]


Figure 29: dataEnterer example

<dataEnterer> <assignedEntity> <id root="2.16.840.1.113883.19.5" extension="43252"/> <addr> <streetAddressLine>21 North Ave.</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom use="WP" value="tel:(555)555-1003"/> <assignedPerson> <name> <given>Henry</given> <family>Seven</family> </name> </assignedPerson> </assignedEntity></dataEnterer>

3.9.2 InformationRecipientThe informationRecipient element records the intended recipient of the information at the time the document is created. For example, in cases where the intended recipient of the document is the patient's health chart, set the receivedOrganization to be the scoping organization for that chart.

10. MAY contain zero or more [0..*] informationRecipient. a. The physician requesting the imaging procedure

(ClincalDocument/participant[@typeCode=REF]/associatedEntity), if present, SHOULD also be recorded as an informationRecipient..

Note: When no referring physician is present, as in the case of self-referred screening examinations allowed by law, the intendedRecipient MAY be absent. b. Such informationRecipients, if present, SHALL contain exactly one [1..1]

intendedRecipient. i. This intendedRecipient MAY contain zero or one [0..1]

informationRecipient. 4. This informationRecipient, if present, SHALL contain at least

one [1..*] name.

ii. The intendedRecipient MAY be the health chart of the patient, in which case the receivedOrganization SHALL be the scoping organization of that chart..

iii. This intendedRecipient MAY contain zero or one [0..1] receivedOrganization.

1. This receivedOrganization, if present, SHALL contain exactly one [1..1] name.

Figure 30: informationRecipient example

<informationRecipient> <intendedRecipient> <informationRecipient> <name> <given>Henry</given> <family>Seven</family> </name> </informationRecipient> <receivedOrganization> <name>Good Health Clinic</name> </receivedOrganization> </intendedRecipient></informationRecipient>

3.9.3 Participant (Referrer)3. MAY contain zero or one [0..1] participant such that it

a. If participant is present, the assignedEntity/assignedPerson element SHALL be present and SHALL represent the physician requesting the imaging procedure (the referring physician AssociatedEntity that is the target of ClincalDocument/participant@typeCode=REF)..

Figure 31: DIR participant example

<participant typeCode="REF"> <associatedEntity classCode="PROV"> <id nullFlavor="NI"/> <addr nullFlavor="NI"/> <telecom nullFlavor="NI"/> <associatedPerson> <name> <given>Amanda</given> <family>Assigned</family> <suffix>MD</suffix> </name> </associatedPerson> </associatedEntity></participant>

3.9.4 AuthenticatorThe authenticator identifies a participant or participants who attested to the accuracy of the information in the document.

16. MAY contain zero or more [0..*] authenticator. a. Such authenticators, if present, SHALL contain exactly one [1..1] time. b. Such authenticators, if present, SHALL contain exactly one [1..1]

signatureCode. i. This signatureCode SHALL contain exactly one [1..1] @code="S"

(CodeSystem: Participationsignature 2.16.840.1.113883.5.89).

c. Such authenticators, if present, SHALL contain exactly one [1..1] assignedEntity.

i. This assignedEntity SHALL contain at least one [1..*] id.ii. This assignedEntity SHALL contain at least one [1..*] addr.iii. This assignedEntity SHALL contain at least one [1..*] telecom. iv. This assignedEntity SHALL contain exactly one [1..1]


Figure 32: Authenticator example

<authenticator> <time value="20050329224411+0500"/> <signatureCode code="S"/> <assignedEntity> <id extension="KP00017" root="2.16.840.1.113883.19"/> <addr> <streetAddressLine>21 North Ave.</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom use="WP" value="tel:(555)555-1003"/> <assignedPerson> <name> <given>Henry</given> <family>Seven</family> </name> </assignedPerson> </assignedEntity></authenticator>

3.10relatedDocumentA DIR may have three types of parent document:

A superseded version that the present document wholly replaces (typeCode = RPLC). DIRs may go through stages of revision prior to being legally authenticated. Such early stages may be drafts from transcription, those created by residents, or other preliminary versions. Policies not covered by this specification may govern requirements for retention of such earlier versions. 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 DIR is legally authenticated, it can be amended by a separate addendum document that references the original.

A source document from which the present document is transformed (typeCode = XFRM). A DIR may be created by transformation from a DICOM Structured Report (SR) document or from another DIR. An example of the latter case is the creation of a derived document for inclusion of imaging results in a clinical document.

4. MAY contain zero or one [0..2] relatedDocument such that it a. When a Diagnostic Imaging Report has been transformed from a DICOM

SR document, relatedDocument/@typeCode SHALL be XFRM, and relatedDocument/parentDocument/id SHALL contain the SOP Instance UID of the original DICOM SR document. (CONF:8433).



conf:8433

5. The relatedDocument/id/@root attribute SHALL be a syntactically correct OID, and SHALL NOT be a UUID..

a. 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))+.

b. OIDs SHALL be no more than 64 characters in length..

Figure 33: DIR relatedDocument example

<relatedDocument typeCode="XFRM"> <parentDocument> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.9"/>  </parentDocument></relatedDocument>

4 SECTION-LEVEL TEMPLATESThis chapter contains the section-level templates for imaging reports. These templates describe the purpose of each section and the section-level constraints. Section-level templates are always included in a document.Each section-level template contains the following:

Template metadata (e.g., templateId, etc.) Description and explanatory narrative LOINC section code Section title Requirements for a text element Subsections as appropriate Entry-level template names and Ids for referenced templates (required and

optional)Narrative Text

The text element within the section stores the narrative to be rendered, as described in the CDA R2 specification11, and is referred to as the CDA narrative block.As noted in the CDA R2 specification, the document originator is responsible for ensuring that the narrative block contains the complete, human readable, attested content of the section. Structured entries support computer processing and computation and are not a replacement for the attestable, human-readable content of the CDA narrative block. The special case of structured entries with an entry relationship of "DRIV" (is derived from) indicates to the receiving application that the source of the narrative block is the structured entries, and that the contents of the two are clinically equivalent. As for all CDA documents—even when a report consisting entirely of structured entries is transformed into CDA—the encoding application must ensure that the authenticated content (narrative plus multimedia) is a faithful and complete rendering of the clinical content of the structured source data. As a general guideline, a generated narrative block should include the same human readable content that would be available to users viewing that content in the originating system. Although content formatting in the narrative block need not be identical to that in the originating system, the narrative block should use elements from the CDA narrative block schema to provide sufficient formatting to support human readability when rendered according to the rules defined in Section Narrative Block (§ 4.3.5 ) of the CDA R2 specification.By definition, a receiving application cannot assume that all clinical content in a section (i.e., in the narrative block and multimedia) is contained in the structured entries unless the entries in the section have an entry relationship of "DRIV".Additional specification information for the CDA narrative block can be found in the CDA R2 specification in sections 1.2.1, 1.2.3, 1.3, 1.3.1, 1.3.2, 4.3.4.2, and 6.

11 HL7 Clinical Document Architecture, Release 2.0. http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm


I think this needs to be updated given the new C-CDA R1.1 table format for sections. (reflect those table row names)


Status: I don’t think the intro to Section 4.0 has been reviewed yet? Think Harry wrote it or copied it from somewhere.

http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm

Text slot:<sectionlabel> :textNarrative <content> blocksCan be used to mark off chunks of text corresponding to template chunk/module/selection/field, which can then be linked to entries or simply tagged to external resources.Tagged Content (RadLex)In addition to structured entries in a section, the section narrative block may be marked up with XML tags. One use of such markup is to provide a link between narrative text and external (non-attested) resource using the <linkHtml> markup (see CDA R2 specification section 4.3.5.2).

For radiology reports, this capability may be used to tag concepts in the narrative block to concepts defined in the RadLex terminology (http://www.radlex.org), developed by the Radiological Society of North America. The RadLex coded vocabulary is a useful tool for indexing report content for data mining purposes. It is not intended to be a complete grammar for expression of clinical statements, but rather a lexicon for tagging concepts of interest.Within the report section narrative blocks, RadLex codes may be included using the <linkHtml> element and a URL pointing to the RadLex resource. <linkHtml> elements may be embedded in the text at the location of the concept (within the scope of a content tag), or may be provided in a list at the end of the narrative block.

Example 1:<section> ... <text> ...<content>There is focal opacity at the right lung base most likely representing right lower lobe atelectasis.<linkHtml href=http://www.radlex.org/RID/RID1302 /><linkHtml href=http://www.radlex.org/RID/RID28493 /> </content></text> ... </section>

Example 2:<section><title>Findings</title><text> Pleura normal...<linkHtml href=http://www.radlex.org/RID/RID1362 /></text></section>

4.1 AddendumID tbd

Name Addendum

Effective Date (Date of Final Text adoption)


Status: one reasonable review completed. Table updated. Example xml for this section is missing though.

http://www.radlex.org/

Version Label

Expiration Date

Release Date (Date of Final Text adoption)

Status Draft (will change to Approved on Final Text adoption)

Description Addendum section for imaging report

Classification CDA Section Level

Relationships

Context

Open/Closed Open

Publishing DICOM Part….

Endorsing Authority

Revision History (Date of Final Text adoption)

Name XPath Card.

Verb Data Type

Fixed Value

Addendum section@classCode 1..1 SHALL 2.16.840.1.113883.5.6

(HL7ActClass) = DOCSECT@moodCode 1..1 SHALL 2.16.840.1.113883.5.1001

(ActMood) = EVNtemplateId 1..1 SHALL SET<II

>@root 1..1 SHALL tbd

id 1..* SHALL IIcode 1..1 SHALL CD 55107-7, LOINC, “Addendum”

text text 0..1 SHALL EDauthor author 0..1 MAY Observer Context

4.2 Clinical InformationID tbd

Name Clinical Information


Version Label

Expiration Date




Status: one reasonable review completed. Table updated. Example xml for this section is missing though.

Description Clinical details about the case such as presenting signs and symptoms, past clinical history, the overall condition of the patient, etc.


Relationships

Context

Open/Closed Open


Endorsing Authority


Sub-sections

Card Data Element or Section Name

Template ID and Specification Document Vocabulary Constraint

[0..1] Request[0..1] Procedure Indications [0..1] History (DIR)

Entries[0..*] Indication[0..*] Allergy Observation[0..*] Social History Observation[0..1] Pregnancy Observation

Name XPath Card.

Verb Data Type

Fixed Value

Clinical Information

section

@classCode 1..1 SHALL 2.16.840.1.113883.5.6 (HL7ActClass) = DOCSECT

@moodCode 1..1 SHALL 2.16.840.1.113883.5.1001 (ActMood) = EVN

templateId 1..1 SHALL SET<II>

@root 1..1 SHALL tbdid 1..* SHALL IIcode 1..1 SHALL CD 55752-0, LOINC, “Clinical

Information”

text text 0..1 SHOULD EDauthor author 0..1 MAY Observer ContextRequest component 0..1 MAY Request

Name XPath Card.

Verb Data Type

Fixed Value

Procedure Indications

component 0..1 MAY Procedure Indications

History (DIR)

component 0..1 MAY History (DIR)

Allergy Observation

entry 0..1 MAYAllergy Observation

Social History Observation

entry 0..1 MAYSocial History Observation

Pregnancy Observation

entry 0..1 MAYPregnancy Observation

4.3 Communication of Critical Results

Need a paragraph explaining how this is supposed to work. And where text goes to describe what was actually told to recipient.

ID tbd

Name Communication of Critical Results


Version Label

Expiration Date None????



Description Documentation of the notification of critical or discrepant results to a provider responsible for patient care.


Relationships

Context

Open/Closed Open


Endorsing Authority



The important question (I think) for this section is “Is there enough information here to initiate the workflow to communicate critical findings to (to whom? The referring physician? The patient?). The follow-up workflow is outside of this CDA document. Should we say that? I think yes.


Is this section consistent with the 2010 ACR WP: Dr. Berland and colleagues authored the American College of Radiology (ACR) 2010 Incidental Findings Committee's white paper on abdominal CT, which members hope will be widely applied. (See sidebar.) - Teri to look at


Status: Teri updated for March 17th review. Table format updated. Need an xml example for this section.

Sub-sections



Entries[0..1] Critical Results Urgency

Name XPath Card.

Verb Data Type

Fixed Value

Communication of Critical Results

section




@root 1..1 SHALL tbdid 1..* SHALL IIcode 1..1 SHALL CD 73568-8, LOINC, “Communication of

Critical Results”

text text 0..1 MAY EDauthor author 0..1 MAY Observer ContextCritical Results Urgency

entry 0..1 MAYSee Note 1

Note 1: The Communication of Critical Results should have content equivalent to the following text content of the RSNA Radiology Reporting Templates, Template 2: Critical Results (http://radreport.org/template/2):

[Critical, discrepant] findings were [personally communicated, other approved mode of critical results communication] by [name of reporting radiologist] to [name of requesting provider] on [date and time].

Critical: a new or unexpected imaging finding that could result in mortality or significant morbidity if appropriate diagnostic and/or therapeutic follow-up steps are not undertakenDiscrepant: an interpretation that is significantly different from a preliminary interpretation, when the preliminary interpretation has been accessible to the patient care team and the difference in interpretations may alter the patient’s diagnostic workup or management


We should explain what could go in here? Else delete. The finding itself should be in the Findings section. BUT where do we actually denote WHAT was relayed, not just the urgency of the finding? The Finding is listed elsewhere, but that does not mean it was relayed.


Intended to trigger automated process, e.g., for all “red” findings


Where does what the critical result actually is go? How do we ensure that the radiology recommendation is also communicated? (e.g., follow up CT wihtin next 2 weeks, or “don’t worry too much”. See article on 2010 ACR Critical Findings about this increasing costs.

http://radreport.org/template/2

4.4 Comparison Study

ID tbd

Name Comparison Study


Version Label




Description Documentation of the Imaging Procedure information and identification used to generate this report.


Relationships

Context

Open/Closed Open


Endorsing Authority


Sub-sections



Entries[0..1] Imaging Procedure


I would think that they key thing in this section is to get the study instance UID or the key images SOP instance UIDs, correct? Ideally, these would come from the imaging study itself? Should we state all that? (sw inserted) Would that go in the “Relationships” row in the table below? Also, do we want to allow for free text to have a rad just describe the reference study? Should we explain all of this in an intro paragraph?


Status: Teri updated for March 17th review. Table format updated. Need an xml example for this section.

Name XPath Card.

Verb Data Type

Fixed Value

Comparison Study

section




@root 1..1 SHALL tbdid 1..* SHALL IIcode 1..1 SHALL CD 18834-2, LOINC, “Radiology

Comparison study”

text text 0..1 SHOULD EDauthor author 0..1 MAY Observer ContextImaging Procedure

entry 0..1 MAY

4.5 Complications Section

ID 2.16.840.1.113883.10.20.22.2.37Name Complications Section


Version Label




DescriptionThe Complications section records problems that occurred during the procedure or other activity. The complications may have been known risks or unanticipated problems.


Relationships

Context

Open/Closed Open


Endorsing Authority



Status: Teri updated for March 17th review. Table format updated. Need to verify the xml example in this section.

Sub-sections



Entries[0..1] Problem Observation 2.16.840.1.113883.10.20.22.4.4

Name XPath Card.

Verb Data Type

Fixed Value

Complications

section




@root 1..1 SHALL tbdid 1..* SHALL IIcode 1..1 SHALL CD 55109-3, LOINC, “Complications”

text text 0..1 SHOULD EDauthor author 0..1 MAY Observer ContextProblem Observation

entry 0..1 MAY

Figure 34: Complications section example

<section> <templateId root="2.16.840.1.113883.10.20.22.2.37"/> <code code="55109-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Complications"/> <title>Complications</title> <text>Asthmatic symptoms while under general anesthesia.</text> <entry> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.4"/>  ... </observation> </entry></section>


Example needs to be verified.

4.6 DICOM Object Catalog Section

ID 2.16.840.1.113883.10.20.6.1.1Name DICOM Object Catalog Section


Version Label




DescriptionDICOM Object Catalog lists all referenced objects and their parent Series and Studies, plus other DICOM attributes required for retrieving the objects. The DICOM Object Catalog section is not intended for viewing and may contain empty section text.


Relationships

Context

Open/Closed Open


Endorsing Authority


Sub-sections

Card

Data Element or Section Name


Entries

[0..1] Study Act 2.16.840.1.113883.10.20.6.2.6

Name XPath Card.

Verb Data Type

Fixed Value

DICOM Object Catalog Section

section




@root 1..1 SHALL tbdid 1..* SHALL IIcode 1..1 SHALL CD 121181,

1.2.840.10008.2.16.4 DCM, “ Dicom Object Catalog”

text text 0..1 SHOULD EDauthor author 0..1 MAY Observer Context

Study Act entry 0..1 MAY 2.16.840.1.113883.10.20.6.2.6


The OID does not get repeated here again, does it? Delete?


In this particular section does it make sense to still have a text field? It might if they want to note that they are looking at something on a different system or ancient films or something that the system cannot just use the UID for? Or delete?


Where does the “DCM” or the UID (if you have both) go in this triplet notation?

Figure 35: DICOM object catalog section example

<section classCode="DOCSECT" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.1.1"/> <code code="121181" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="DICOM Object Catalog"/> <entry>

 <act classCode="ACT" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.6"/> <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"> ... </code>

  <entryRelationship typeCode="COMP"> <observation classCode="DGIMG" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.8"/> ... </observation> </entryRelationship> <entryRelationship typeCode="COMP"> <observation classCode="DGIMG" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.8"/> ... </observation> </entryRelationship> </act> </entryRelationship> </act> </entry></section>

4.7 OB.US Fetus Findings

ID 2.16.840.1.113883.10.20.6.1.1Name OB.US Fetus Findings


Version Label




Need to review example in detail. Update.




Description Records observations related to a fetus confirmed or discovered during an obstetric ultrasound imaging procedure.


Relationships

Context

Open/Closed Open


Endorsing Authority


Participations

Card Participation Data Element or Section Name

Template ID and Specification

DocumentVocabulary Constraint

[0..1] subject Fetus Subject Context 2.16.840.1.113883.10.20.6.2.3

Sub-sections



[0..*] Labeled SubsectionEntries

[0..*] Categorical Observation

[0..*] Numeric Observation

[0..*] observationMedia (graphical)

[0..*] SOP Instance Observation


Did I add the Participations correctly into this table?

Name XPath Card.

Verb Data Type

Fixed Value

OB.US Fetus Findings

section




@root 1..1 SHALL tbdid 1..* SHALL IIcode 1..1 SHALL CD 12129-3, LOINC, “Fetal Study

observation general US”

text text 0..1 SHOULD EDauthor author 0..1 MAY Observer ContextLabeled Subsection

component 0..* MAY

Categorical Observation

entry 0..* MAY

Numeric Observation

entry 0..* MAY

observationMedia (graphical)

entry 0..* MAY

SOP Instance Observation

entry 0..* MAY

4.8 Findings Section 18782-3

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 block of text not separated into these sections, that text SHALL be placed in the Findings section.

ID 1.3.6.1.4.1.19376.1.4.1.2.112.16.840.1.113883.10.20.6.1.2

Name Findings



I believe this is the correct value per the previous text section


Why are there 2 oids?


This is different from the LOINC code that was listed below?! Which one to use?



Version Label




Description Records clinically significant observations confirmed or discovered during the procedure.


Relationships

Context

Open/Closed Open


Endorsing Authority


Participations

Card Participation Data Element or Section Name


[0..1] Subject Fetus Subject Context 2.16.840.1.113883.10.20.6.2.3

[0..*] Author Observer Context 2.16.840.1.113883.10.20.6.2.4

Sub-sections



[0..*] Labeled Subsection See Note 1

[0..*] OB.US Fetus Findings

[0..1] Radiation Exposure and Protection Information See Note 2

[0..1] Key Images[0..1] Complications[0..1] Measurements and Annotations

Entries[1..*] Procedure Context 2.16.840.1.113883.10.20.6.2.5





Note 1: CDA conformance rules allow organization of content into implementation-defined subsections. For combined procedures (e.g., PET/CT), findings for each constituent sub-procedure might be described in a subsection of Findings. Alternatively, findings might be grouped into subsections by anatomy (e.g., a section each for head, neck and chest). The conformance rules apply to entries of the main section and any child subsections.

Note 2: Radiation Exposure and Protection Information: A Radiation Exposure and Protection Information Section SHOULD be present if the documented service is CT or X-ray.

Name XPath Card.

Verb Data Type

Fixed Value

Findings section@classCode 1..1 SHALL 2.16.840.1.113883.5.6




id 1..* SHALL IIcode 1..1 SHALL CD 59776-5, LOINC, “Procedure

Findings”


Name XPath Card.

Verb Data Type

Fixed Value

Labeled Subsection

component 0..* MAY

OB.US Fetus Findings

component0..*

MAY

Radiation Exposure and Protection Information

component

0..1

SHOULD

Key Images component 0..1 MAYComplications

component 0..1 MAY

Measurements and Annotations

component0..1

MAY

Procedure Context

entry 1..* MAY

Categorical Observation

entry 0..* MAY

Numeric Observation

entry 0..* MAY

observationMedia (graphical)

entry 0..* MAY

SOP Instance Observation

entry 0..* MAY


SHOULD?

Figure 36: Findings section example

<section> <templateId root="2.16.840.1.113883.10.20.6.1.2"/> <code code="121070" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Findings"/> <title>Findings</title> <text> <paragraph> <caption>Finding</caption> <content ID="Fndng2">The cardiomediastinum is . </content> </paragraph> <paragraph> <caption>Diameter</caption> <content ID="Diam2">45mm</content> </paragraph> ... </text> <entry> <templateId root="2.16.840.1.113883.10.20.6.2.12"/> ... </entry> </section>

1. The text elements (and their children) MAY contain Web Access to DICOM Persistent Object (WADO) references to DICOM objects by including a linkHtml element where @href is a valid WADO URL and the text content of linkHtml is the visible text of the hyperlink.

2. If clinical statements are present, the section/text SHALL represent faithfully all such statements and MAY contain additional text.

3. MAY contain zero or more [0..*] Procedure Context (templateId:2.16.840.1.113883.10.20.6.2.5).

4. If the service context of a section is different from the value specified in documentationOf/serviceEvent, then the section SHALL contain one or more entries containing Procedure Context (templateId 2.16.840.1.113883.10.20.6.2.5), which will reset the context for any clinical statements nested within those elements.

5. If the subject of a section is a fetus, the section SHALL contain a subject element containing a Fetus Subject Context (templateId 2.16.840.1.113883.10.20.6.2.3).

6. If the author of a section is different from the author(s) listed in the Header, an author element SHALL be present containing Observer Context (templateId 2.16.840.1.113883.10.20.6.2.4).

Figure 37: WADO reference using linkHtml example

<text> ... <paragraph> <caption>Source of Measurement</caption> <linkHtml href="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/dicom">Chest_PA</linkHtml> </paragraph> ...</text>

4.9 Impressions

ID 2.16.840.1.113883.10.20.6.1.1Name Impressions


Version Label




Description

The most important diagnoses or other clinical conclusions that can be made from the imaging observations and other clinical information are recorded here. This section may include recommendations for additional imaging tests or other actions, as well as global assessments, such as BI-RADS Categories or the equivalent.


Relationships

Context

Open/Closed Open





Not sure where all of this text goes. Captured some of it but not all.

Endorsing Authority


Sub-sections



[0..1] Communication of Critical Results

[0..1] Complications[0..1] Conclusions[0..1] Radiology Recommendations [0..1] Summary

Entries

[1..*] Observation "59769-0" LOINC Postprocedure Diagnosis

Name XPath Card.

Verb Data Type

Fixed Value

Impressions section@classCode 1..1 SHALL 2.16.840.1.113883.5.6




id 1..* SHALL IIcode 1..1 SHALL CD RID13170, RadLex,

“Impressions”; 121072, DCM, “Impressions”



Delete this row, correct?


Why don’t we pick just one? Dicom?


Structure in Procedure Note is ACT, with SUBJ Problem Observation


Why is this one required? Why not Conclusions or Summary instead?


What is the difference between a Conclusion and a Summary?


Does this go here or as a separate section?

Name XPath Card.

Verb Data Type

Fixed Value

Communication of Critical Results

component 0..1 MAY

Complications

component 0..1 MAY

Conclusions

component 0..1 MAY

Radiology Recommendations

component 0..1 MAY

Summary component 0..1 MAYObservation

entry 1..* MAY

4.10Procedure IndicationsFrom C-CDA

ID 2.16.840.1.113883.10.20.22.2.29Name Procedure Indications


Version Label




Description

Records details about the reason for the procedure. This section may include the pre-procedure diagnosis or diagnoses as well as one or more symptoms that contribute to the reason the procedure is being performed.



Now, is this a Section or a Sub-Section. I believe it is a Sub-section, but do you call that out here?


Note that there is another Procedure Indications sections down in 4.15. The latter should probably be deleted? Check if there is additional info in there. There are different codes in that section. Is that called from some other section than this Procedure Indications is referenced by?


This is referenced by Clinical Procedure. Not top level section.


Should we make this a new heading level after this point? After this are the sub-sections. Or isn’t it usually documented that way?


What is the difference between a Conclusion and a Summary?


Does this go here or as a separate section?

Relationships

Context

Open/Closed Open


Endorsing Authority


Sub-sections



Entries[0..*] Indication

Name XPath Card.

Verb Data Type

Fixed Value

Procedure Indications

section




@root 1..1 SHALL tbdid 1..* SHALL IIcode 1..1 SHALL CD 59768-2, LOINC, “Procedure

Indications”text text 0..1 SHOULD EDauthor author 0..1 MAY Observer ContextIndication entry 0..1 SHOULD


Is SHOULD correct?


Delete this row, correct?


18785-6 Radiology Reason for Study is called out in DICOM CID 7001


This is a sub-section already. Should this part of the table be deleted?


Is this where we put where it is called from? (Clinical Procedure)

4.11Key ImagesTemplate ID 1.3.6.1.4.1.19376.1.4.1.2.14

Parent Template

General Description The Key Images section contains narrative description of and references to DICOM Image Information Objects that illustrate the findings of the procedure reported.

Section Code 55113-5, LOINC, “Key Images”

Card Data Element or Section Name Template ID Specification

DocumentVocabular

y Constraint

Entries[0..*] SOP Instance Observation 2.16.840.1.113883.10.20.6.2.8 CDA-DIR

The Key Images section text SHALL contain image references using linkHtml elements, where @href is a valid Web Access to DICOM Persistent Object (WADO) URL and the text content of linkHtml is the either visible text of the hyperlink or a descriptor or identifier of the image.The Key Images section MAY include SOP Instance Observation entries equivalent to the linkHtml image references.

4.12Labeled SubsectionTemplate ID

Parent Template

General DescriptionNarrative subsection that allows organization of content for a labeled topic (a particular organ or anatomic feature, a lesion, a tumor, etc.). The section.code shall be absent, but the section.title shall be present.

Section Code

Card Data Element or Section Name Template ID Specification

DocumentVocabular

y Constraint

Sub-sections

[0..*] Labeled SubsectionEntries





[0..*] SOP Instance Observation 2.16.840.1.113883.10.20.6.2.8 CDA-DIR

4.13Medical History (DIR) Section 11329-0[section: templateId (open)]

Table 5: Medical (General) History Section Contexts

Used By: Contains Entries:DIR

The Medical History (DIR) section describes aspects of the medical history of the patient pertinent to the current procedure, or may be more comprehensive to include a broad view of the patient condition. It might include chief complaint, past medical history, social history, family history, surgical or procedure history, medication history, and other history information.

17. SHALL contain exactly one [1..1] templateId such that ita. SHALL contain exactly one [1..1]

@root="2.16.840.1.113883.10.20.22.2.39".18. SHALL contain exactly one [1..1] code/@code="11329-0" Medical (General)

History (CodeSystem: LOINC 2.16.840.1.113883.6.1).19. SHALL contain exactly one [1..1] title.20. SHALL contain exactly one [1..1] text.21. MAY contain zero or more [0..*] entry such that it

a. SHALL contain exactly one [1..1] Medication Activity (2.16.840.1.113883.10.20.22.4.16).

22. MAY contain zero or more [0..*] entry.a. SHALL contain exactly one [1..1] Problem Concern Act (Condition)

(2.16.840.1.113883.10.20.22.4.3).23. MAY contain zero or more [0..*] entry such that it

a. SHALL contain at least one [1..*] Social History Observation (2.16.840.1.113883.10.20.22.4.38).

24. MAY contain zero or more [0..*] entry such that ita. SHALL contain exactly one [1..1] Pregnancy Observation

(2.16.840.1.113883.10.20.15.3.8).


What’s difference from C-CDA History? Is this what we want (as subsection of Clinical Information?

25. MAY contain zero or more [0..*] entry such that ita. SHALL contain exactly one [1..1] Allergy Problem Act

(2.16.840.1.113883.10.20.22.4.30)

Figure 38: Medical (general) history section example

<section> <templateId root="2.16.840.1.113883.10.20.22.2.39"/> <code code="11329-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="MEDICAL (GENERAL) HISTORY"/> <title>MEDICAL (GENERAL) HISTORY</title> <text> <list listType="ordered"> <item>Patient has had recent issue with acne that does not seem to be related to any particular cause.</item> <item>Previous concerns of oral cancer was actually irritated gums as a result of mild food allergy.</item> <item>Patient had recent weight gain due to sedentary lifestyle and new job.</item> </list> </text> </section>

4.14Current Imaging Procedure Description

Template Name Current Imaging Procedure Description SectionTemplate ID

Parent Template

General DescriptionThe Current Imaging Procedure Description section records the particulars of the procedure and may include information about protocol, imaging device, contrast, radiation dose, medications administered (sedation, stress agents), etc.

Section Code 55111-9, LOINC, “Current Imaging Procedure Description”

Card Condition Data Element or Section Name

Template ID and Specification Document


Sub-sections[0..1] Complications

[0..1] Radiation Exposure and Protection Information

Entries[0..1] Procedure Context

[0..1] Contrast Administration[0..*] Medication Activity

Figure 39: Procedure description section example

<section> <templateId root="2.16.840.1.113883.10.20.22.2.27" /> <code code="29554-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="PROCEDURE DESCRIPTION" /> <title>Procedure Description</title> <text>The patient was taken to the endoscopy suite where ... </text></section>

4.15Procedure Indications Section 59768-2[section: templateId 2.16.840.1.113883.10.20.22.2.29(open)]

Table 6: Procedure Indications Section Contexts

Used By: Contains Entries:Procedure Note (required)Operative Note (optional)

Indication

The Procedure Indications section records details about the reason for the procedure or surgery. This section may include the pre-procedure diagnosis or diagnoses as well as one or more symptoms that contribute to the reason the procedure is being performed.


@root="2.16.840.1.113883.10.20.22.2.29".27. SHALL contain exactly one [1..1] code/@code="59768-2" Procedure Indications

(CodeSystem: LOINC 2.16.840.1.113883.6.1).28. SHALL contain exactly one [1..1] title.29. SHALL contain exactly one [1..1] text.30. MAY contain zero or more [0..*] entry such that it

a. SHALL contain exactly one [1..1] Indication (2.16.840.1.113883.10.20.22.4.19).

Figure 40: Procedure indications section example

<section> <templateId root="2.16.840.1.113883.10.20.22.2.29"/> <code code="59768-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="PROCEDURE INDICATIONS"/> <title>Procedure Indications</title> <text>The procedure is performed for screening in a low risk individual. </text> <entry> <observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.19"/> ... </observation> </entry></section>

4.16Radiation Exposure and Protection Information

Template Name Radiation Exposure and Protection Information

Template ID

Parent Template

General Description Contains information related to the radiation exposure and protection of the patient, as may be required by national or local legal requirements or standards.

Section Code 73569-6, LOINC, “Radiation exposure and protection information”

Card Condition Data Element or Section Name



Participations[0..*] Observer Context 2.16.840.1.113883.10.20.6.2.4

Entries

[1..1]

If female patient of child-bearing age. Code Observation 2.16.840.1.113883.10.20.6.2.13

code/@code="111532" Pregnancy Status (CodeSystem: 1.2.840.10008.2.16.4 DCM)

[0..1] Text Observation 2.16.840.1.113883.10.20.6.2.12

code/@code="121109" Indications for Procedure (CodeSystem: 1.2.840.10008.2.16.4 DCM)

[0..1] Text Observation 2.16.840.1.113883.10.20.6.2.12 code/@code="113921" Radiation Exposure (CodeSystem:

koenhec5, 04/01/14,

“Mandatory Conditional (MC)”. IF female patient of child-bearing age.

1.2.840.10008.2.16.4 DCM)

[0..1] Text Observation 2.16.840.1.113883.10.20.6.2.12

code/@code="113922" Radioactive Sub-stance Administered (CodeSystem: 1.2.840.10008.2.16.4 DCM)

The Radiation Exposure and Protection Information section contains information related to the radiation exposure and protection of the patient, as is required by national legal requirements or standards.

1. SHALL contain exactly one [1..1] templateId such that ita. SHALL contain exactly one [1..1] @root="" (CONF:).

2. SHALL contain exactly one [1..1] code/@code="73569-6" Radiation exposure and protection information (CodeSystem: LOINC 2.16.840.1.113883.6.1) (CONF:).

3. SHALL contain exactly one [1..1] title.4. SHALL contain exactly one [1..1] text (CONF:8061).

a. SHALL contain information on the indications for the procedureb. SHALL contain the name of the “Irradiation Authorizing” person who is

the clinician responsible for determining that the irradiating procedure was appropriate for the indications.

c. SHALL contain information on radiation exposure if and only if ionizing is applied in the context of the current procedure (detailed specification of exposure is out of the scope of this textual summary. Such information may be given in separate DICOM SR instances such as described in DICOM PS3.16 TID 10001 “Projection X-Ray Radiation Dose” or “TID 10011 CT Radiation Dose”).

d. SHALL contain information on the radioactive substance administered if and only if radioactive substance is administered in the context of the current procedure.

5. The text elements (and their children) MAY contain Web Access to DICOM Persistent Object (WADO) references to DICOM objects by including a linkHtml element where @href is a valid WADO URL and the text content of linkHtml is the visible text of the hyperlink.

6. MAY contain zero or more [0..*] entry such that ita. SHOULD contain exactly one [1..1] Code Observations

(2.16.840.1.113883.10.20.6.2.13) (CONF:).i. SHALL contain exactly one [1..1] code="111532" Pregnancy

Status (CodeSystem: DCM 1.2.840.10008.2.16.4) (CONF:).ii. SHALL contain exactly one [1..1] value (CONF:9308) being a

valid DICOM Pregnancy Status from DICOM CID 6096 (Value Set 1.2.840.10008.6.1.418)(@codeSystem is 2.16.840.1.113883.6.96 SNOMED CT)

koenhec5, 04/01/14,

Register new value set with HL7

conf:9308

conf:8061

b. MAY contain zero or one [0..1] Text Observations (2.16.840.1.113883.10.20.6.2.12) (CONF:).

i. SHALL contain exactly one [1..1] code="121109" Indications for Procedure (CodeSystem: DCM 1.2.840.10008.2.16.4) (CONF:).

c. MAY contain zero or one [0..1] Text Observations (2.16.840.1.113883.10.20.6.2.12) (CONF:).

i. SHALL contain exactly one [1..1] code="113921" Radiation Exposure (CodeSystem: DCM 1.2.840.10008.2.16.4) (CONF:).

d. MAY contain zero or one [0..1] Text Observations (2.16.840.1.113883.10.20.6.2.12) (CONF:).

i. SHALL contain exactly one [1..1] code="113922" Radioactive Substance Administered (CodeSystem: DCM 1.2.840.10008.2.16.4) (CONF:).

4.17Radiology Recommendation

Template Name Radiology Recommendation

Template ID

Parent Template

General Description Radiologist recommendation

Section Code 18783-1 LOINC “Radiology Study recommendation”




Entries

[0..1] PQObservation Observation.code = (111055, DCM, “Recommended Follow-up Interval”)

[0..1] TSObservation Observation.code = (111054, DCM, “Recommended Follow-up Date”)

4.18Contrast Administered

ID tbd

Name Contrast AdministrationEffective Date (Date of Final Text adoption)

Version Label

Expiration Date



May have been retired – check also in DICOM SR template


Description Information on administered contrast media with referenced DICOM SR contrast agent administration reports.


Relationships

Context

Open/Closed Open


Endorsing Authority


Name XPath Card.

Verb Data Type

Fixed Value

Contrast section@classCode 1..1 SHALL 2.16.840.1.113883.5.6




id 1..* SHALL IIcode 1..1 SHALL CD tbd

text text 0..1 MAY EDauthor author 0..1 MAY Observer Context

[0..1] Procedural Medication Activity

Observation.code = PS 3.16 CID 12Value (PQ Data Type)= volume/quantity of contrast administered , UCUM code for ml (unit component of PQ)Optional effectiveTimeroute code (Route of administration,2.16.840.1.113883.3.88.12.3221.8.7 (Medication Route FDA Value Set)

[0..*] Sop Instance Observation

Reference to DICOM SR contrast agent administration reports. Information on the DICOM Study and Series the referenced SR constrast agent administration report belongs to can be

koenhec5, 04/01/14,

Loinc uses contrast only for precoordinated procedure codes

found in the DICOM Object Catalog Section.

Value Set: DICOMRadiographicContrastAgent OID tbd. DYNAMICDCM 1.2.840.10008.2.16.4

Procedural Medication Activity:

1. SHALL contain exactly one [1..1] @classCode="SBADM" (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6) (CONF:7496). 2. SHALL contain exactly one [1..1] @moodCode="EVN”…

3. SHALL contain exactly one [1..1] templateId (CONF:7499) such that it a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.4.16" (CONF:10504). 4. SHALL contain at least one [1..*] id (CONF:7500).

7. SHALL contain exactly one [1..1] statusCode (CONF:7507). (constrain to completed?)

11. SHALL contain zero or one [0..1] routeCode, which SHALL be selected from ValueSet Medication Route FDA Value Set 2.16.840.1.113883.3.88.12.3221.8.7 DYNAMIC (CONF:tbd).

1. SHOULD contain zero or one [0..1] doseQuantity (CONF:7516).a. The doseQuantity, if present, SHOULD contain zero or one [0..1] @unit,

which SHALL be selected from ValueSet UnitsOfMeasureCaseSensitive 2.16.840.1.113883.1.11.12839 DYNAMIC (CONF:7526).

b. Pre-coordinated consumable: If the consumable code is a pre-coordinated unit dose (e.g. "metoprolol 25mg tablet") then doseQuantity is a unitless number that indicates the number of products given per administration (e.g. "2", meaning 2 x "metoprolol 25mg tablet") (CONF:16878).

c. Not pre-coordinated consumable: If the consumable code is not pre-coordinated (e.g. is simply "metoprolol"), then doseQuantity must represent a physical quantity with @unit, e.g. "25" and "mg", specifying the amount of product given per administration (CONF:16879).

SHALL contain exactly one [1..1] consumable (CONF:7520).(manufacturedMaterial.code -> PS 3.16 CID 12 or IHE CIRC value set?Generic Product Code and Generic Product NameProduct Brand Code and Product Brand Name?

DICOM Sup164: Adverse events?

4.19Request

ID tbd

Name RequestEffective Date (Date of Final Text adoption)

Version Label

Expiration Date



Status: reviewed on March 3rd webex.


Description Information on requested imaging studies and associated tests. It may include information on the reason for the request.


Relationships

Context

Open/Closed Open


Endorsing Authority


Name XPath Card.

Verb Data Type

Fixed Value

Request section@classCode 1..1 SHALL 2.16.840.1.113883.5.6




id 1..* SHALL IIcode 1..1 SHALL CD 55115-0, LOINC, “Request”

text text 0..1 SHALL EDauthor author 0..1 MAY Observer Context

5 ENTRY-LEVEL TEMPLATESThis part of the guide describes the clinical statement entry templates used within the sections of the consolidated documents. Entry templates contain constraints that are required for conformance. Note that the clinical statement templates are presented in alphabetical order; templates are not grouped by possible containing templates. Entry-level templates are always allowed in sections.Each entry-level template description contains the following information:

Key template metadata (e.g., templateId, etc.) Description and explanatory narrative. Required CDA acts, participants and vocabularies. Optional CDA acts, participants and vocabularies.

Several entry-level templates require an effectiveTime:The effectiveTime of an observation is the time interval over which the observation is known to be true. The low and high values should be as precise as possible, but no more precise than known. While CDA has multiple mechanisms to record this time interval (e.g., by low and high values, low and width, high and width, or center point and width), we constrain most to use only the low/high form. The low value is the earliest point for which the condition is known to have existed. The high value, when present, indicates the time at which the observation was no longer known to be true. The full description of effectiveTime and time intervals is contained in the CDA R2 normative edition12.

Entry-level templates may also describe an id element, which is an identifier for that entry. This id may be referenced within the document, or by the system receiving the document. The id assigned must be globally unique.

5.1 Allergy Observation[observation: templateId 2.16.840.1.113883.10.20.22.4.7(open)]

This clinical statement represents that an allergy or adverse reaction exists or does not exist. The agent that is the cause of the allergy or adverse reaction is represented as a manufactured material participant playing entity in the allergy observation. While the agent is often implicit in the alert observation (e.g. "allergy to penicillin"), it should also be asserted explicitly as an entity. The manufactured material participant is used to represent natural and non-natural occuring substances.NOTE: The agent responsible for an allergy or adverse reaction is not always a manufactured material (for example, food allergies), nor is it necessarily consumed. The following constraints reflect limitations in the base CDA R2 specification, and should be used to represent any type of responsible agent.

12 HL7 Clinical Document Architecture (CDA Release 2). http://www.hl7.org/implement/standards/cda.cfm

Table 7: Allergy Observation Constraints Overview

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.7']@classCode 1..1 SHALL 7379 2.16.840.1.113883.5.6

(HL7ActClass) = OBS@moodCode 1..1 SHALL 7380 2.16.840.1.113883.5.1001


>7381

@root 1..1 SHALL 10488

2.16.840.1.113883.10.20.22.4.7

id 1..* SHALL II 7382code/@code 1..1 SHALL 7383 2.16.840.1.113883.5.4

(ActCode) = ASSERTIONstatusCode 1..1 SHALL CS 7386 2.16.840.1.113883.5.14

(ActStatus) = completedadverseEventDate

effectiveTime 1..1 SHALL TS or IVL<TS>

7387

value 1..1 SHALL CD 7390adverseEventType

code 1..1 SHALL 9139 2.16.840.1.113883.3.88.12.3221.6.2 (Allergy/Adverse Event Type)

originalText 0..1 SHOULD ED 7422reference

/@value0..1 SHOULD 7400

product participant 0..1 SHOULD 7402@typeCode 1..1 SHALL 7403 2.16.840.1.113883.5.90

(HL7ParticipationType) = CSM

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

productDetail

participantRole

1..1 SHALL 7404

@classCode 1..1 SHALL 7405 2.16.840.1.113883.5.110 (RoleClass) = MANU

playingEntity

1..1 SHALL 7406

@classCode 1..1 SHALL 7407 2.16.840.1.113883.5.41 (EntityClass) = MMAT

productCoded

code 1..1 SHALL CE 7419

productFreeText

originalText

0..1 SHOULD ED 7424

reference0..1 SHOULD 7425

translation 0..* MAY SET<PQR>

7431

entryRelationship

0..1 MAY 7440

@typeCode 1..1 SHALL 7906 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = SUBJ

@inversionInd 1..1 SHALL 7446 truereaction entry

Relationship0..* SHOULD 7447

@typeCode 1..1 SHALL 7907 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = MFST

@inversionInd 1..1 SHALL 7449 trueseverity entry

Relationship0..1 SHALL 9961


@inversionInd

1..1 SHALL 9964 true

31. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

32. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001).


@root="2.16.840.1.113883.10.20.22.4.7".34. SHALL contain at least one [1..*] id.

35. SHALL contain exactly one [1..1] code/@code="ASSERTION" Assertion (CodeSystem: ActCode 2.16.840.1.113883.5.4).

36. SHALL contain exactly one [1..1] statusCode="completed" Completed (CodeSystem: ActStatus 2.16.840.1.113883.5.14).

37. SHALL contain exactly one [1..1] effectiveTime.a. If it is unknown when the allergy began, this effectiveTime SHALL contain

low/@nullFLavor="UNK".b. If the allergy is no longer a concern, this effectiveTime MAY contain zero or

one [0..1] high.38. SHALL contain exactly one [1..1] value with @xsi:type="CD".

a. This value SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet Allergy/Adverse Event Type 2.16.840.1.113883.3.88.12.3221.6.2 DYNAMIC.

b. This value SHOULD contain zero or one [0..1] originalText.i. The originalText, if present, SHOULD contain zero or one [0..1]

reference/@value.1. This reference/@value SHALL begin with a '#' and SHALL

point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1).

39. SHOULD contain zero or one [0..1] participant such that ita. SHALL contain exactly one [1..1] @typeCode="CSM" Consumable

(CodeSystem: HL7ParticipationType 2.16.840.1.113883.5.90).b. SHALL contain exactly one [1..1] participantRole.

i. This participantRole SHALL contain exactly one [1..1] @classCode="MANU" Manufactured Product (CodeSystem: RoleClass 2.16.840.1.113883.5.110).

ii. This participantRole SHALL contain exactly one [1..1] playingEntity.

1. This playingEntity SHALL contain exactly one [1..1] @classCode="MMAT" Manufactured Material (CodeSystem: EntityClass 2.16.840.1.113883.5.41).

2. This playingEntity SHALL contain exactly one [1..1] code.a. In an allergy to a specific medication the code SHALL

be selected from the ValueSet 2.16.840.1.113883.3.88.12.80.16 Medication Brand Name DYNAMIC or the ValueSet 2.16.840.1.113883.3.88.12.80.17 Medication Clinical Drug DYNAMIC.

b. In an allergy to a class of medications the code SHALL be selected from the ValueSet 2.16.840.1.113883.3.88.12.80.18 Medication Drug Class DYNAMIC.

c. In an allergy to a food or other substance the code SHALL be selected from the ValueSet

2.16.840.1.113883.3.88.12.80.20 Ingredient Name DYNAMIC.

d. This code SHOULD contain zero or one [0..1] originalText.

i. The originalText, if present, SHOULD contain zero or one [0..1] reference.

1. This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1).

e. This code MAY contain zero or more [0..*] translation.

40. MAY contain zero or one [0..1] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has subject

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).b. SHALL contain exactly one [1..1] @inversionInd="true" True.c. SHALL contain exactly one [1..1] Allergy Status Observation

(2.16.840.1.113883.10.20.22.4.28).41. SHOULD contain zero or more [0..*] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="MFST" Is Manifestation of (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] @inversionInd="true" True.c. SHALL contain exactly one [1..1] Reaction Observation

(2.16.840.1.113883.10.20.22.4.9).42. SHALL contain zero or one [0..1] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has Subject (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] @inversionInd="true" True.c. SHALL contain exactly one [1..1] Severity Observation

(2.16.840.1.113883.10.20.22.4.8).

Table 8: Allergy/Adverse Event Type Value Set

Value Set: Allergy/Adverse Event Type 2.16.840.1.113883.3.88.12.3221.6.2 DYNAMICCode System(s): SNOMED CT 2.16.840.1.113883.6.96Description: This describes the type of product and intolerance suffered by the

patienthttp://phinvads.cdc.gov/vads/ViewValueSet.action?id=7AFDBFB5-A277-DE11-9B52-0015173D1785

Code Code System Print Name420134006 SNOMED CT Propensity to adverse reactions (disorder)418038007

SNOMED CTPropensity to adverse reactions to substance (disorder)

419511003 SNOMED CT Propensity to adverse reactions to drug (disorder)418471000 SNOMED CT Propensity to adverse reactions to food (disorder)419199007 SNOMED CT Allergy to substance (disorder)416098002 SNOMED CT Drug allergy (disorder)414285001 SNOMED CT Food allergy (disorder)59037007 SNOMED CT Drug intolerance (disorder)235719002 SNOMED CT Food intolerance (disorder)

Table 9: Medication Brand Name Value Set (excerpt)

Value Set: Medication Brand Name 2.16.840.1.113883.3.88.12.80.16 DYNAMICCode System(s): RxNorm 2.16.840.1.113883.6.88Description: Brand names

http://phinvads.cdc.gov/vads/ViewValueSet.action?id=229BEF3E-971C-DF11-B334-0015173D1785

Code Code System Print Name205734 RxNorm Amoxicillin 25 MG/ML Oral Suspension [Amoxil]

856537 RxNorm24 HR Propranolol Hydrochloride 60 MG Extended Release Capsule [Inderal]

104700 RxNorm Diazepam 5 MG Oral Tablet [Valium]…



http://phinvads.cdc.gov/vads/ViewValueSet.action?id=7AFDBFB5-A277-DE11-9B52-0015173D1785

http://phinvads.cdc.gov/vads/ViewValueSet.action?id=7AFDBFB5-A277-DE11-9B52-0015173D1785

Table 10: Medication Clinical Drug Value Set (excerpt)

Value Set: Medication Clinical Drug 2.16.840.1.113883.3.88.12.80.17 DYNAMICCode System(s): RxNorm 2.16.840.1.113883.6.88Description: Clinical drug names


Code Code System Print Name313850 RxNorm Amoxicillin 40 MG/ML Oral Suspension856448 RxNorm Propranolol Hydrochloride 10 MG Oral Tablet197589 RxNorm Diazepam 10 MG Oral Tablet…

Table 11: Medication Drug Class Value Set (excerpt)

Value Set: Medication Drug Class 2.16.840.1.113883.3.88.12.80.18 DYNAMICCode System(s): NDF-RT 2.16.840.1.113883.3.26.1.5Description: This identifies the pharmacological drug class, such as Cephalosporins.

Shall contain a value descending from the NDF-RT concept types of “Mechanism of Action - N0000000223”, “Physiologic Effect - N0000009802” or “Chemical Structure - N0000000002”`. NUI will be used as the concept code.http://phinvads.cdc.gov/vads/ViewValueSet.action?id=77FDBFB5-A277-DE11-9B52-0015173D1785

Code Code System Print NameN0000011161 NDF-RT CephalosporinsN0000005909 NDF-RT 2-PropanolN0000006629 NDF-RT Filgrastim…

http://phinvads.cdc.gov/vads/ViewValueSet.action?id=77FDBFB5-A277-DE11-9B52-0015173D1785




Table 12: Ingredient Name Value Set (excerpt)

Value Set: Ingredient Name 2.16.840.1.113883.3.88.12.80.20 DYNAMICCode System(s): Unique Ingredient Identifier (UNII) 2.16.840.1.113883.4.9Description: Unique ingredient identifiers (UNIIs) for substances in drugs, biologics,

foods, and devices.http://www.fda.gov/ForIndustry/DataStandards/StructuredProductLabeling/ucm162523.htm

Code Code System Print Name

OLT4M28U3Z UNII((3-TRIFLUOROMETHYL)PHENYL)METHYL-PHOSPHONIC ACID

L0VRY82PKO UNIICYCLOHEXENE, 4-[(1Z)-1,5-DIMETHYL-1,4-HEXADIEN-1-YL]-1-METHYL-

62H4W26906 UNII BISNAFIDEQE1QX6B99R UNII PEANUT…

http://www.fda.gov/ForIndustry/DataStandards/StructuredProductLabeling/ucm162523.htm

http://www.fda.gov/ForIndustry/DataStandards/StructuredProductLabeling/ucm162523.htm

Figure 41: Allergy observation example

<observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.7"/> <id root="4adc1020-7b14-11db-9fe1-0800200c9a66"/> <code code="416098002" displayName="drug allergy" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/> <statusCode code="completed"/> <effectiveTime> <low value="20110215"/> </effectiveTime> <value xsi:type="CD" code="282100009" displayName="Adverse reaction to substance" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"> <originalText> <reference value=""/> </originalText> </value> <participant typeCode="CSM"> <participantRole classCode="MANU"> <playingEntity classCode="MMAT"> <code code="314422" displayName="ALLERGENIC EXTRACT, PENICILLIN" codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm"> <originalText> <reference value=""/> </originalText> </code> <name>Penicillin</name> </playingEntity> </participantRole> </participant> </observation>

5.2 Allergy Problem Act[act: templateId 2.16.840.1.113883.10.20.22.4.30(open)]

Table 13: Allergy Problem Act Contexts

Used By: Contains Entries:Allergies Section (entries required)Allergies Section (entries optional)

Allergy Observation

This clinical statement act represents a concern relating to a patient's allergies or adverse events. A concern is a term used when referring to patient's problems that are related to one another. Observations of problems or other clinical statements captured at a point in time are wrapped in a Allergy Problem Act, or "Concern" act, which represents the ongoing

process tracked over time. This outer Allergy Problem Act (representing the "Concern") can contain nested problem observations or other nested clinical statements relevant to the allergy concern.

Table 14: Allergy Problem Act Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value

act[templateId/@root = '2.16.840.1.113883.10.20.22.4.30']@classCode 1..1 SHALL 7469 2.16.840.1.113883.5.6

(HL7ActClass) = ACT@moodCode 1..1 SHALL 7470 2.16.840.1.113883.5.1001


>7471

@root 1..1 SHALL 10489 2.16.840.1.113883.10.20.22.4.30

id 1..* SHALL II 7472code 1..1 SHALL CD 7477 2.16.840.1.113883.6.1 (LOINC)

= 48765-2statusCode 1..1 SHALL CS 7485 2.16.840.1.113883.3.88.12.80.

68 (HITSPProblemStatus)effectiveTime 1..1 SHALL TS or

IVL<TS>

7498

entryRelationship1..* SHALL 7509


43. SHALL contain exactly one [1..1] @classCode="ACT" (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).



@root="2.16.840.1.113883.10.20.22.4.30".46. SHALL contain at least one [1..*] id.47. SHALL contain exactly one [1..1] code="48765-2" Allergies, adverse reactions,

alerts (CodeSystem: LOINC 2.16.840.1.113883.6.1).48. SHALL contain exactly one [1..1] statusCode, where the @code SHALL be selected

from ValueSet HITSPProblemStatus 2.16.840.1.113883.3.88.12.80.68 DYNAMIC.

49. SHALL contain exactly one [1..1] effectiveTime.a. If statusCode = "55561003" Active, then effectiveTime SHALL contain [1..1]

low.

b. If statusCode="413322009" Resolved, then effectiveTime SHALL contain [1..1] high.

50. SHALL contain at least one [1..*] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has subject

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).b. SHALL contain exactly one [1..1] Allergy Observation

(2.16.840.1.113883.10.20.22.4.7).

Table 15: HITSP Problem Status Value Set

Value Set: HITSPProblemStatus 2.16.840.1.113883.3.88.12.80.68 DYNAMICCode System: SNOMED CT 2.16.840.1.113883.6.96Code Code System Display Name55561003 SNOMED CT Active73425007 SNOMED CT Inactive*413322009 SNOMED CT Resolved*** An inactive problems refers to one that is quiescent, and may appear again in future.** A resolved problem refers to one that used to affect a patient, but does not any more.

Figure 42: Allergy problem act example

<entry typeCode="DRIV"> <act classCode="ACT" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.30"/> <id root="36e3e930-7b14-11db-9fe1-0800200c9a66"/> <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Allergies, adverse reactions, alerts"/> <statusCode code="active" codeSystem="2.16.840.1.113883.5.14"/> <effectiveTime value="20090909"> <low value="20090902"/> <high value="20100103"/> </effectiveTime> <entryRelationship typeCode="SUBJ"> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.7"/>  ... </observation> </entryRelationship> </act></entry>

5.3 Allergy Status Observation[observation: templateId 2.16.840.1.113883.10.20.22.4.28(open)]

Table 16: Allergy Status Observation Contexts

Used By: Contains Entries:Allergy Observation

This template represents the status of the allergy indicating whether it is active, no longer active, or is an historic allergy. There can be only one allergy status observation per alert observation.

Table 17: Allergy Status Observation Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value

observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.28']

@classCode1..1 SHALL 7318 2.16.840.1.113883.5.6

(HL7ActClass) = OBS

@moodCode1..1 SHALL 7319 2.16.840.1.113883.5.1001


>7317

@root 1..1 SHALL 10490 2.16.840.1.113883.10.20.22.4.28

code 1..1 SHALL CD 7320 2.16.840.1.113883.6.1 (LOINC) = 33999-4

statusCode 1..1 SHALL CS 7321 2.16.840.1.113883.5.14 (ActStatus) = completed

value 1..1 SHALL CE 7322 2.16.840.1.113883.3.88.12.80.68 (HITSPProblemStatus)




@root="2.16.840.1.113883.10.20.22.4.28".54. SHALL contain exactly one [1..1] code="33999-4" Status (CodeSystem: LOINC

2.16.840.1.113883.6.1).55. SHALL contain exactly one [1..1] statusCode="completed" Completed

(CodeSystem: ActStatus 2.16.840.1.113883.5.14).56. SHALL contain exactly one [1..1] value with @xsi:type="CE", where the @code

SHALL be selected from ValueSet HITSPProblemStatus 2.16.840.1.113883.3.88.12.80.68 DYNAMIC.

Figure 43: Allergy status observation example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.28"/>  <code code="33999-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Status"/> <statusCode code="completed"/> <value xsi:type="CE" code="55561003" codeSystem="2.16.840.1.113883.6.96" displayName="Active"/></observation>

5.4 Boundary Observation[observation: templateId 2.16.840.1.113883.10.20.6.2.11(open)]

Table 18: Boundary Observation Contexts

Used By: Contains Entries:Referenced Frames Observation

A Boundary Observation contains a list of integer values for the referenced frames of a DICOM multiframe image SOP instance. It identifies the frame numbers within the referenced SOP instance to which the reference applies. The CDA Boundary Observation numbers frames using the same convention as DICOM, with the first frame in the referenced object being Frame 1. A Boundary Observation must be used if a referenced DICOM SOP instance is a multiframe image and the reference does not apply to all frames.

Table 19: Boundary Observation Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value


@classCode1..1 SHALL 9282 2.16.840.1.113883.5.6

(HL7ActClass) = OBS

@moodCode1..1 SHALL 9283 2.16.840.1.113883.5.6

(HL7ActClass) = EVNcode 1..1 SHALL CD 9284 1.2.840.10008.2.16.4 (DCM) =

113036value 1..* SHALL 9285

@xsi:type 1..1 SHALL 9286 INT


58. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

59. SHALL contain exactly one [1..1] code="113036" Frames for Display (CodeSystem: DCM 1.2.840.10008.2.16.4).

60. SHALL contain at least one [1..*] value.a. Such values SHALL contain exactly one [1..1] @xsi:type, where the

@code="INT".i. Each numbers represents a frame for display.

Figure 44: Boundary observation example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.11"/> <code code="113036" codeSystem="1.2.840.10008.2.16.4" displayName="Frames for Display"/> <value xsi:type="INT" value="1"/></observation>

5.5 Code Observationsobservation: templateId 2.16.840.1.113883.10.20.6.2.13(open)]

DICOM Template 2000 specifies that Imaging Report Elements of Value Type Code are contained in sections. The Imaging Report Elements are inferred from Basic Diagnostic Imaging Report Observations that consist of image references and measurements (linear, area, volume, and numeric). Coded DICOM Imaging Report Elements in this context are mapped to CDA-coded observations that are section components and are related to the SOP Instance Observations (templateId 2.16.840.1.113883.10.20.6.2.8) or Quantity Measurement Observations (templateId 2.16.840.1.113883.10.20.6.2.14) by the SPRT (Support) act relationship.

Table 20: Code Observations Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value



(ActMood) = EVN

templateId/@root1..1 SHALL 9306 2.16.840.1.113883.10.20.6.2.

13code 1..1 SHALL CD 9307value 1..1 SHALL 9308effectiveTime 0..1 SHOULD TS or

IVL<TS>

9309

entryRelationship0..* MAY 9311

@typeCode 1..1 SHALL 9312 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = SPRT






64. SHALL contain exactly one [1..1] code.65. SHALL contain exactly one [1..1] value.66. SHOULD contain zero or one [0..1] effectiveTime.67. Code Observations SHALL be rendered into section/text in separate paragraphs.68. MAY contain zero or more [0..*] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="SPRT" Has Support (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] Sop Instance Observation (2.16.840.1.113883.10.20.6.2.8).

69. MAY contain zero or more [0..*] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SPRT" Has Support

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] Quantity Measurement Observation (2.16.840.1.113883.10.20.6.2.14).

Figure 45: Code observation example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.13"/> <code code="18782-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Study observation"/> <statusCode code="completed"/> <value xsi:type="CD" code="309530007" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Hilar mass"/> </observation>

5.6 Critical Results Urgency

Audit trail of who was notified

Table Critical Results Urgency Overview

Name XPath Card

Verb Data Type

Fixed Value

Critical Results

act

1..1 SHALL 2.16.840.1.113883.5.6 (HL7ActClass) = ACT


templateId 1..1 SHALL SET <II>

@root 1..1 SHALL tbdid 1..1 SHALL II

Result Comm type

code 1..1 SHALL CD Result Comm typecode ={critical|discrepant}

statusCode 1..1 SHALL CS 2.16.840.1.113883.5.14 (ActStatus) = completed

Result Comm priority

priorityCode 0..1 SHOULD CE 2.16.840.1.113883.1.11.16866 (ActPriority) = {S|UR|EM} (Should this be identified as a subsection number below??? Table 22 also)

effectiveTime 1..1 SHALL TSperformer 1..1 SHALL assignedEntity 1..1 SHALL

assignedperson

1..1 SHALL

reporting radiologist name

name 1..1 SHALL PN

participant 1..1 SHALL@typeCode 1..1 SHALL CS 2.16.840.1.113883.5.90

(HL7ParticipationType) = NOT participantRole 1..1 SHALL

notification contact telecom

telecom 0..* SHOULD SET <TEL>

playingEntity 1..1 SHALLnotification contact name

name 1..1 SHALL PN

Critical Result priorityCode definitionsS = Red: New or unexpected findings that are potentially immediately life-threatening, such as tension pneumothorax, ischemic bowel, or intracerebral hemorrhage. These results


Could also be a patient – put into a note.

require immediate interruptive notification of the ordering physician, covering physician, or other care team member who can initiate the appropriate clinical action for the patient.UR = Orange: New or unexpected findings that could result in mortality or significant morbidity if not appropriately treated urgently (within 2-3 days), such as an intra-abdominal abscess or impending pathological hip fracture.EM = Yellow: New or unexpected findings that could result in mortality or significant morbidity if not appropriately treated, but are not immediately life-threatening or urgent, such as a nodule on a chest x-ray or a solid renal mass on an ultrasound examination.

Table 21: Critical Result Priority Value Set

Value Set: CriticalResultPriority tbd STATICCode System(s):

ActPriority 2.16.840.1.113883.5.7

Description: A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Communication of Critical Results happened.

Code Code System Print Name (preferred display color)EM ActPriority Emergency (Yellow)S ActPriority Stat (Red)UR ActPriority Urgent (Orange)

5.7 Indication[observation: templateId 2.16.840.1.113883.10.20.22.4.19(open)]

From C-CDAThe Indication Observation documents the rationale for an activity. It can do this with the id element to reference a problem recorded elsewhere in the document or with a code and value to record the problem type and problem within the Indication. For example, the indication for a prescription of a painkiller might be a headache that is documented in the Problems Section.


Note that RadReport.org template #2 also lists:“Not critical” as one of the 4 values.

Table 22: Indication Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value




>7482

@root 1..1 SHALL 10502 2.16.840.1.113883.10.20.22.4.19id 1..1 SHALL II 7483

Problem Type

code 0..1 SHOULD

CD 7484 2.16.840.1.113883.3.88.12.3221.7.2 (Problem Type)


effectiveTime0..1 SHOUL

DTS or IVL<TS>

7488

value 0..1 SHOULD

CD 7489

Problem

@code 0..1 SHOULD

7991 2.16.840.1.113883.3.88.12.3221.7.4 (Problem)

@nullFlavor0..1 MAY 10088

70. SHALL contain exactly one [1..1] @classCode="OBS" (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

71. SHALL contain exactly one [1..1] @moodCode="EVN" (CodeSystem: ActMood 2.16.840.1.113883.5.1001).


@root="2.16.840.1.113883.10.20.22.4.19".73. SHALL contain exactly one [1..1] id.

a. Set the observation/id equal to an ID on the problem list to signify that problem as an indication.

74. SHOULD contain zero or one [0..1] code, where the @code SHOULD be selected from ValueSet Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18.


76. SHOULD contain zero or one [0..1] effectiveTime.77. SHOULD contain zero or one [0..1] value with @xsi:type="CD".

a. The value, if present, SHOULD contain zero or one [0..1] code, which SHOULD be selected from ValueSet Problem 2.16.840.1.113883.3.88.12.3221.7.4 DYNAMIC.

i. The code, if present, MAY contain zero or one [0..1] @nullFlavor.1. If the diagnosis is unkown or the SNOMED code is unknown,

@nullFlavor SHOULD be “UNK”. If the code is something other than SNOMED, @nullFlavor SHOULD be “OTH” and the other code SHOULD be placed in the translation element.

Figure 46: Indication entry example

<observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.19"/> <id extension="123456789" root="2.16.840.1.113883.19"/> <code code="409586006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Complaint"/> <statusCode code="completed"/> <value xsi:type="CD" code="195967001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Asthma"/></observation>

5.8 Procedural Medication ActivityProcedural medication activity describes substance administrations that have actually occurred prior to or during a procedure (e.g., imaging contrast/agents, anti-histamines, anti-anxiety, beta blockers to control heart rate during procedure, etc.). Procedural medication timing may be complex, but the only times of interest are pre-, peri-, and post-procedure. Detailed medication timings may be documented in other documents (e.g., DICOM Substance Administration SR).

Table 23: Medication Activity Constraints Overview

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

substanceAdministration[templateId/@root = ']@classCode 1..1 SHALL 2.16.840.1.113883.5.6

(HL7ActClass) = SBADM@moodCode 1..1 SHALL EVNtemplateId 1..1 SHALL SET<I

I>@root 1..1 SHALL

id 1..* SHALL IIstatusCode 1..1 SHALL CS COMPLETE

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

route routeCode 0..1 MAY CE Value Set CID 11timing entryRelationshi

p1.1 SHALL Observation of pre- / peri- /

post-proceduredose dose

Quantity0..1 SHOULD IVL<P

Q>@unit 0..1 SHOULD 2.16.840.1.113883.1.11.12

839 (UCUM Units of Measure (case sensitive))

rateQuantity

0..1 MAY IVL<PQ>

@unit 1..1 SHALL 2.16.840.1.113883.1.11.12839 (UCUM Units of Measure (case sensitive))

medicationInformation

consumable 1..1 SHALL

manufacturedMaterial

1..1 SHALL 7411

codedProductName


freeTextProductName

originalText 0..1 SHOULD ED 7413

reference/@value

0..1 SHOULD 7417

78. SHALL contain exactly one [1..1] @classCode="SBADM" (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

79. SHALL contain exactly one [1..1] @moodCode, which SHALL be EVN80. SHALL contain exactly one [1..1] templateId such that it

a. SHALL contain exactly one [1..1] @root.81. SHALL contain at least one [1..*] id.82. SHOULD contain zero or one [0..1] text.

a. The text, if present, SHOULD contain zero or one [0..1] reference/@value.i. This reference/@value SHALL begin with a '#' and SHALL point to its

corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1).

83. SHALL contain exactly one [1..1] statusCode value “completed”84. MAY contain zero or one [0..1] routeCode, where the @code SHALL be selected

from ValueSet CID 11.85. SHOULD contain zero or one [0..1] doseQuantity.

a. Pre-coordinated consumable: If the consumable code is a precoordinated unit dose (e.g. "metoprolol 25mg tablet") then doseQuantity is a unitless number that indicates the number of products given per administration (e.g. "2", meaning 2 x "metoprolol 25mg tablet").

b. Not pre-coordinated consumable: If the consumable code is not pre-coordinated (e.g. is simply "metoprolol"), then doseQuantity must represent a physical quantity with @unit, e.g. "25" and "mg", specifying the amount of product given per administration.

c. The doseQuantity, if present, SHOULD contain zero or one [0..1] @unit, which SHALL be selected from ValueSet UCUM Units of Measure (case sensitive) 2.16.840.1.113883.1.11.12839 DYNAMIC.

86. MAY contain zero or one [0..1] rateQuantity.a. The rateQuantity, if present, SHALL contain exactly one [1..1] @unit, which

SHALL be selected from ValueSet UCUM Units of Measure (case sensitive) 2.16.840.1.113883.1.11.12839 DYNAMIC.

87. Medication Activity SHOULD include doseQuantity OR rateQuantity.88. SHALL contain exactly one [1..1] consumable.

a. This consumable SHALL contain exactly one [1..1] manufacturedProducti. SHALL contain exactly one [1..1] @classCode="MANU" (CodeSystem:

RoleClass 2.16.840.1.113883.5.110).ii. SHALL contain exactly one [1..1] manufacturedMaterial.

1. This manufacturedMaterial SHALL contain exactly one [1..1] code,

2. This code SHOULD contain zero or one [0..1] originalText.3. This code MAY contain zero or more [0..*] translation.

Translations can be used to represent generic product name, packaged product code, etc.

Table 24: Unit of Measure Value Set (excerpt)

Value Set: UCUM Units of Measure (case sensitive) 2.16.840.1.113883.1.11.12839 DYNAMICCode System(s):

Unified Code for Units of Measure (UCUM) 2.16.840.1.113883.6.8

Description: UCUM codes include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans.http://www.regenstrief.org/medinformatics/ucum

Code Code System Print Namemmol/kg UCUM MilliMolesPerKiloGramfL UCUM FemtoLiterug/mL UCUM MicroGramsPerMilliLiter…

http://www.regenstrief.org/medinformatics/ucum

Figure 47: Procedural Medication activity example

<substanceAdministration classCode="SBADM" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.16"/> <id root="cdbd33f0-6cde-11db-9fe1-0800200c9a66"/> <text> <reference value="#med1/> Proventil 0.09 MG/ACTUAT inhalant solution, 2 puffs QID PRN wheezing </text> <statusCode code="completed"/> <effectiveTime xsi:type="IVL_TS"> <low value="20110301"/> <high value="20120301"/> </effectiveTime> <effectiveTime xsi:type="PIVL_TS" institutionSpecified="true" operator="A"> <period value="6" unit="h"/> </effectiveTime> <routeCode code="C38216" codeSystem="2.16.840.1.113883.3.26.1.1" codeSystemName="NCI Thesaurus" displayName="RESPIRATORY (INHALATION)"/> <doseQuantity value="1"/> <rateQuantity value="90" unit="ml/min"/> <maxDoseQuantity nullFlavor="UNK"> <numerator nullFlavor="UNK"/> <denominator nullFlavor="UNK"/> </maxDoseQuantity> <administrationUnitCode code="C42944" displayName="INHALANT" codeSystem="2.16.840.1.113883.3.26.1.1" codeSystemName="NCI Thesaurus"/> <consumable> <manufacturedProduct> <templateId root="2.16.840.1.113883.10.20.22.4.23"/>  ... </manufacturedMaterial> <manufacturerOrganization/> </manufacturedProduct> </consumable> <performer> ... </performer> <participant typeCode="CSM"> <participantRole classCode="MANU"> <templateId root="2.16.840.1.113883.10.20.22.4.24"/>  ... </participantRole> </participant> <entryRelationship typeCode="RSON"> <observation classCode="COND" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.19"/>  ... </observation> </entryRelationship>

<entryRelationship typeCode="REFR"> <supply classCode="SPLY" moodCode="INT"> <templateId root="2.16.840.1.113883.10.20.22.4.17"/>  ... <entryRelationship typeCode="SUBJ" inversionInd="true"> <act classCode="ACT" moodCode="INT"> <templateId root="2.16.840.1.113883.10.20.22.4.20"/>  ... </act> </entryRelationship> </supply> </entryRelationship> <entryRelationship typeCode="REFR"> <supply classCode="SPLY" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.18"/>  ... </supply> </entryRelationship> <precondition typeCode="PRCN"> <templateId root="2.16.840.1.113883.10.20.22.4.25"/>  ... </precondition></substanceAdministration>

Figure 48: Medication information example

<manufacturedProduct classCode="MANU"> <templateId root="2.16.840.1.113883.10.20.22.4.23"/> <id/> <manufacturedMaterial> <code code="329498" codeSystem="2.16.840.1.113883.6.88" displayName="Albuterol 0.09 MG/ACTUAT inhalant solution"> <originalText><reference value="#manmat1"/></originalText> <translation code="573621" codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm" displayName="Proventil 0.09 MG/ACTUAT inhalant solution"/> </code> </manufacturedMaterial> <manufacturerOrganization>...</manufacturerOrganization></manufacturedProduct>

5.9 observationMediaTemplate Name observationMedia Entry

Template ID 1.3.6.1.4.1.19376.1.4.1.4.7Parent Template none

General DescriptionThe observationMedia Entry provides an in-line graphic depiction of the section findings. It is referenced by a <renderMultiMedia> element in the section text.

Class/Mood Code Data Type Value

OBS / EVN n/a ED

The value of type ED SHALL contain an in-line encoding of a graphic. The <tel> element, if present, SHALL reference a URI for the same image as included in-line.

The ObservationMedia entry SHALL include an XML IDREFS ID attribute used as a target of a <renderMultiMedia> element in the section/text narrative block of the parent section.The observationMedia/mediaType shall be drawn from the values in Table 6.2.4.6-1.

Table 6.2.4.6-1 mediaTypesimage/gifimage/tiffimage/jpegimage/png

5.10Postprocedure Diagnosis[act: templateId 2.16.840.1.113883.10.20.22.4.51(open)]

Table 25: Postprocedure Diagnosis Contexts

Used By: Contains Entries:Postprocedure Diagnosis Section Problem Observation

The Postprocedure Diagnosis entry encodes the diagnosis or diagnoses discovered or confirmed during the procedure. Often it is the same as the pre-procedure diagnosis or indication.

Table 26: Postprocedure Diagnosis Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value

act[templateId/@root = '2.16.840.1.113883.10.20.22.4.51']@classCode 1..1 SHALL 8756 ACT@moodCode 1..1 SHALL 8757 EVNcode 1..1 SHALL CD 8758 2.16.840.1.113883.6.1

(LOINC) = 59769-0



89. SHALL contain exactly one [1..1] @classCode="ACT".90. SHALL contain exactly one [1..1] @moodCode="EVN".91. SHALL contain exactly one [1..1] code="59769-0" Postprocedure Diagnosis

(CodeSystem: LOINC 2.16.840.1.113883.6.1).92. SHALL contain at least one [1..*] entryRelationship.

a. Such entryRelationships SHALL contain exactly one [1..1] @typeCode="SUBJ" Has subject (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. Such entryRelationships SHALL contain exactly one [1..1] Problem Observation (2.16.840.1.113883.10.20.22.4.4).

Figure 49: Postprocedure diagnosis example

<act moodCode="EVN" classCode="ACT"> <templateId root="2.16.840.1.113883.10.20.22.4.51"/>  <code code="59769-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Postprocedure Diagnosis"/> <entryRelationship typeCode="SUBJ"> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.4"/>  ... </observation> </entryRelationship></act>

5.11Pregnancy Observation[observation: templateId 2.16.840.1.113883.10.20.15.3.8(open)]

Derived From C-CDA, fully compatible; addition of explicit negationInd, and merging subsidiary EDD observation into this template.


Or do we want to use SNOMED 60001007 Not Pregnant

This clinical statement represents current pregnancy status. The effective time is the time of observation.

Table 27: Pregnancy Observation Constraints Overview

Name XPath Card. Verb Data Type

CONF#

Fixed Value

observation[templateId/@root = '2.16.840.1.113883.10.20.15.3.8']@classCode 1..1 SHALL 451 2.16.840.1.113883.5

.6 (HL7ActClass) = OBS

@moodCode 1..1 SHALL 452 2.16.840.1.113883.5.1001 (ActMood) = EVN

Not Pregnant @negationInd 0..1 MAYcode 1..1 SHALL CD 454 2.16.840.1.113883.5

.4 (ActCode) = ASSERTION


effectiveTime 0..1 SHOULD TS or IVL<TS>

2018

value 1..1 SHALL CD 457 2.16.840.1.113883.6.96 (SNOMEDCT) = 77386006

entryRelationship 0..1 MAY 458@typeCode 1..1 SHALL 459 2.16.840.1.113883.5

.1002 (HL7ActRelationshipType) = REFR

observation 1..1 SHALL@classCode 1..1 SHALL 444 2.16.840.1.113883.5

.6 (HL7ActClass) = OBS

@moodCode 1..1 SHALL 445 2.16.840.1.113883.5.1001 (ActMood) = EVN

templateId 1..1 SHALL 16762

@root 1..1 SHALL 16763 2.16.840.1.113883.10.20.15.3.1

code 1..1 SHALL CD 446 2.16.840.1.113883.6.1 (LOINC) = 11778-8


Name XPath Card. Verb Data Type

CONF#

Fixed Value

Estimated Date of Delivery

value 1..1 SHALL TS 450

93. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6) (CONF:451).

94. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001) (CONF:452).

95. MAY contain zero or one [0..1] @negationInd.a. negationInd="true" SHALL be used to represent that pregnancy was not

observed (i.e., patient not pregnant).96. SHALL contain exactly one [1..1] code="ASSERTION" Assertion (CodeSystem:

ActCode 2.16.840.1.113883.5.4) (CONF:454).97. SHALL contain exactly one [1..1] statusCode="completed" Completed

(CodeSystem: ActStatus 2.16.840.1.113883.5.14) (CONF:455).98. SHOULD contain zero or one [0..1] effectiveTime.99. SHALL contain exactly one [1..1] value with @xsi:type="CD"="77386006"

Pregnant (CodeSystem: SNOMEDCT 2.16.840.1.113883.6.96) (CONF:457).100. MAY contain zero or one [0..1] entryRelationship (CONF:458) such that it

a. SHALL contain exactly one [1..1] @typeCode="REFR" Refers to (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002) (CONF:459).

b. SHALL contain exactly one [1..1] Estimated Date of Delivery (2.16.840.1.113883.10.20.15.3.1) (CONF:460).

i. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6) (CONF:444).

ii. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001) (CONF:445).

iii. SHALL contain exactly one [1..1] templateId (CONF:16762) such that it

1. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.15.3.1" (CONF:16763).

iv. SHALL contain exactly one [1..1] code="11778-8" Estimated date of delivery (CodeSystem: LOINC 2.16.840.1.113883.6.1) (CONF:446).

v. SHALL contain exactly one [1..1] statusCode="completed" Completed (CodeSystem: ActStatus 2.16.840.1.113883.5.14) (CONF:448).

vi. SHALL contain exactly one [1..1] value with @xsi:type="TS" (CONF:450).

conf:460

Figure 50: Pregnancy observation example

<observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.15.3.8"/> <id extension="123456789" root="2.16.840.1.113883.19"/> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <statusCode code="completed"/> <effectiveTime> <low value="20110410"/> </effectiveTime> <value xsi:type="CD" code="77386006" displayName="pregnant" codeSystem="2.16.840.1.113883.6.96"/> <entryRelationship typeCode="REFR">  <templateId root="2.16.840.1.113883.10.20.15.3.1"/> <observation classCode="OBS" moodCode="EVN"> <id extension="123456789" root="2.16.840.1.113883.19"/> <code code="11778-8" codeSystem="2.16.840.1.113883.6.1" displayName="Estimated date of delivery"/> <statusCode code="completed"/> <value xsi:type="TS">20110919</value> </observation> </entryRelationship></observation>

Figure 51: Not Pregnant example

<observation classCode="OBS" moodCode="EVN" negationInd="TRUE">  <templateId root="2.16.840.1.113883.10.20.15.3.8"/> <id extension="123456789" root="2.16.840.1.113883.19"/> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <statusCode code="completed"/> <effectiveTime> <low value="20110410"/> </effectiveTime> <value xsi:type="CD" code="77386006" displayName="pregnant" codeSystem="2.16.840.1.113883.6.96"/></observation>

5.12Problem Concern Act (Condition)[act: templateId 2.16.840.1.113883.10.20.22.4.3(open)]

Table 28: Problem Concern Act (Condition) Contexts

Used By: Contains Entries:Problem Section (entries optional)Problem Section (entries required)

Problem Observation

Observations of problems or other clinical statements captured at a point in time are wrapped in a "Concern" act, which represents the ongoing process tracked over time. This allows for binding related observations of problems. For example, the observation of "Acute MI" in 2004 can be related to the observation of "History of MI" in 2006 because they are the same concern. The conformance statements in this section define an outer "problem act" (representing the "Concern") that can contain a nested "problem observation" or other nested clinical statements.

Table 29: Problem Concern Act (Condition) Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value



(ActMood) = EVNid 1..* SHALL II 9026code 1..1 SHALL CD 9027

@code 1..1 SHALL 9440 2.16.840.1.113883.5.6 (HL7ActClass) = CONC

statusCode 1..1 SHALL CS 9029 2.16.840.1.113883.11.20.9.19 (ProblemAct statusCode)


9030

low 1..1 SHALL TS 9032high 0..1 SHOULD TS 9033



101. SHALL contain exactly one [1..1] @classCode="ACT" Act (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).


103. SHALL contain at least one [1..*] id.104. SHALL contain exactly one [1..1] code.

a. This code SHALL contain exactly one [1..1] @code="CONC" Concern (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

105. SHALL contain exactly one [1..1] statusCode, where the @code SHALL be selected from ValueSet ProblemAct statusCode 2.16.840.1.113883.11.20.9.19 STATIC 2011-09-09.

106. SHALL contain exactly one [1..1] effectiveTime.a. The effectiveTime element records the starting and ending times during

which the concern was active on the Problem List.b. This effectiveTime SHALL contain exactly one [1..1] low.c. This effectiveTime SHOULD contain zero or one [0..1] high.

107. SHALL contain at least one [1..*] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has subject

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).b. SHALL contain exactly one [1..1] Problem Observation

(2.16.840.1.113883.10.20.22.4.4).

Table 30: ProblemAct statusCode Value Set

Value Set: ProblemAct statusCode 2.16.840.1.113883.11.20.9.19 STATIC 2011-09-09Code System(s): ActStatus 2.16.840.1.113883.5.14Description: This value set indicates the status of the problem concern actCode Code System Print Nameactive ActStatus activesuspended ActStatus suspendedaborted ActStatus abortedcompleted ActStatus completed

Figure 52: Problem concern act (condition) example

<entry typeCode="DRIV"> <act classCode="ACT" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.3"/> <id root="36e3e930-7b14-11db-9fe1-0800200c9a66"/> <code code="CONC" codeSystem="2.16.840.1.113883.5.6"/> <statusCode code="active" codeSystem="2.16.840.1.113883.5.14"/> <effectiveTime> <low value="20090902"/> </effectiveTime> <entryRelationship typeCode="SUBJ"> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.4"/>  ... </observation> </act></entry>

5.13Problem Observation[Observation: templateId 2.16.840.1.113883.10.20.22.4.4(open)]

A problem is a clinical statement that a clinician has noted. In health care it is a condition that requires monitoring or diagnostic, therapeutic, or educational action. It also refers to any unmet or partially met basic human need.A Problem Observation is required to be wrapped in a Concern act wrapper in locations where the type of problem needs to be identified or the condition tracked. A Problem Observation can be a valid "standalone" template instance in cases where a simple problem observation is to be sent.The negationInd attribute, if true, specifies that the problem indicated was observed to not have occurred (which is subtly but importantly different from having not been observed). NegationInd='true' is an acceptable way to make a clinical assertion that something did not occur, for example, "no diabetes".

Table 31: Problem Observation Constraints Overview

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.4']@classCode 1..1 SHALL 9041@moodCode 1..1 SHALL 9042 2.16.840.1.113883.5.100

1 (ActMood) = EVN@negationInd 0..1 MAY 10139id 1..* SHALL II 9043

problemType

code 1..1 SHALL CD 9045 2.16.840.1.113883.3.88.12.3221.7.2 (Problem Type)

problemName

text 0..1 SHOULD ED 9185

reference/@value

0..1 SHOULD 9187


problemDate


9050

problemCode

value 1..1 SHALL CD 9058 2.16.840.1.113883.3.88.12.3221.7.4 (Problem)

@nullFlavor 0..1 MAY 10141ageAtOnset

entryRelationship0..1 MAY 9059


@inversionInd 1..1 SHALL 9069 trueproblemStatus entryRelationship

0..1 MAY 9063

@typeCode 1..1 SHALL 9068 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = REFR


@typeCode 1..1 SHALL 9064 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = REFR

108. SHALL contain exactly one [1..1] @classCode.109. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem:

ActMood 2.16.840.1.113883.5.1001).

110. MAY contain zero or one [0..1] @negationInd.a. negationInd="true" SHALL be used to represent that the problem was not

observed.111. SHALL contain at least one [1..*] id.112. SHALL contain exactly one [1..1] code, where the @code SHOULD be selected

from ValueSet Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18.

113. SHOULD contain zero or one [0..1] text.a. The text, if present, SHOULD contain zero or one [0..1] reference/@value.

i. This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1).


115. SHOULD contain zero or one [0..1] effectiveTime.a. The onset date SHALL be recorded in the low element of the effectiveTime

element when known.b. The resolution date SHALL be recorded in the high element of the

effectiveTime element when known.c. If the problem is known to be resolved, but the date of resolution is not

known, then the high element SHALL be present, and the nullFlavor attribute SHALL be set to 'UNK'. Therefore, the existence of an high element within a problem does indicate that the problem has been resolved.

116. SHALL contain exactly one [1..1] value with @xsi:type="CD", where the @code SHOULD be selected from ValueSet Problem 2.16.840.1.113883.3.88.12.3221.7.4 DYNAMIC.

a. This value MAY contain zero or one [0..1] @nullFlavor.i. If the diagnosis is unkown or the SNOMED code is unknown,

@nullFlavor SHOULD be “UNK”. If the code is something other than SNOMED, @nullFlavor SHOULD be “OTH” and the other code SHOULD be placed in the translation element.

117. MAY contain zero or one [0..1] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has subject

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).b. SHALL contain exactly one [1..1] @inversionInd="true" True.c. SHALL contain exactly one [1..1] Age Observation

(2.16.840.1.113883.10.20.22.4.31).118. MAY contain zero or one [0..1] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="REFR" Refers to (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] Problem Status (2.16.840.1.113883.10.20.22.4.6).

119. MAY contain zero or one [0..1] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="REFR" Refers to (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] Health Status Observation (2.16.840.1.113883.10.20.22.4.5).

Table 32: Problem Type Value Set

Value Set: Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18Code System(s): SNOMED CT 2.16.840.1.113883.6.96Description: This value set indicates the level of medical judgment used to

determine the existence of a problem.Code Code System Print Name404684003 SNOMED CT Finding409586006 SNOMED CT Complaint282291009 SNOMED CT Diagnosis64572001 SNOMED CT Condition248536006 SNOMED CT Functional limitation418799008 SNOMED CT Symptom55607006 SNOMED CT Problem

Table 33: Problem Value Set (excerpt)

Value Set: Problem 2.16.840.1.113883.3.88.12.3221.7.4 DYNAMICCode System(s): SNOMED CT 2.16.840.1.113883.6.96Description: Problems and diagnoses. Limited to terms decending from the Clinical

Findings (404684003) or Situation with Explicit Context (243796009) hierarchies.http://phinvads.cdc.gov/vads/ViewValueSet.action?id=70FDBFB5-A277-DE11-9B52-0015173D1785

Code Code System Print Name46635009 SNOMED CT Diabetes mellitus type 1234422006 SNOMED CT Acute porphyria31712002 SNOMED CT Primary biliary chrrhosis…



Figure 53: Problem observation example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.4"/>  <id root="d11275e7-67ae-11db-bd13-0800200c9a66"/> <code code="409586006" codeSystem="2.16.840.1.113883.6.96" displayName="Complaint"/> <text> ... </text> <statusCode code="completed"/> <effectiveTime> <low value="1950"/> </effectiveTime> <value xsi:type="CD" code="195967001" codeSystem="2.16.840.1.113883.6.96" displayName="Asthma"/> <entryRelationship typeCode="SUBJ" inversionInd="true"> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.31"/>  ... </observation> </entryRelationship> <entryRelationship typeCode="REFR" inversionInd="true"> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.5"/>  ... </observation> </entryRelationship></observation>

Figure 54: Problem observation with specific problem not observed

<observation classCode="OBS" moodCode="EVN" nullFlavor="NI"> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4" /> <text> No known problems</text> <statusCode code="completed" /> <value xsi:type="CD" code="195967001" codeSystem="2.16.840.1.113883.6.96" displayName="Asthma" /></observation>

Figure 55: Problem observation for no known problems

<observation classCode="OBS" moodCode="EVN" negationInd="true">  <templateId root="2.16.840.1.113883.10.20.22.4.4" /> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4" /> <statusCode code="completed" /> <value xsi:type="CD" code="55607006" codeSystem="2.16.840.1.113883.6.96" displayName="Problem" /></observation>

Figure 56: NullFlavor example

<value nullFlavor="OTH"> <translation code="1234" displayName="Example" codeSystem="2.16.840.1.113883.19.5" codeSystemName="Non-SNOMED"/></value>

5.14Problem Status[observation: templateId 2.16.840.1.113883.10.20.22.4.6(open)]

Table 34: Problem Status Contexts

Used By: Contains Entries:Problem Observation

The Problem Status records whether the indicated problem is active, inactive, or resolved.

Table 35: Problem Status Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value




>7359

@root 1..1 SHALL 10518 2.16.840.1.113883.10.20.22.4.6code 1..1 SHALL CD 7361 2.16.840.1.113883.6.1 (LOINC)

= 33999-4text 0..1 SHOULD ED 7362

reference/@value

0..1 SHOULD 7363


value 1..1 SHALL CD 7365 2.16.840.1.113883.3.88.12.80.68 (HITSPProblemStatus)




@root="2.16.840.1.113883.10.20.22.4.6".123. SHALL contain exactly one [1..1] code="33999-4" Status (CodeSystem: LOINC

2.16.840.1.113883.6.1).124. SHOULD contain zero or one [0..1] text.




126. SHALL contain exactly one [1..1] value with @xsi:type="CD", where the @code SHALL be selected from ValueSet HITSPProblemStatus 2.16.840.1.113883.3.88.12.80.68 DYNAMIC.

Figure 57: Problem status example

<observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.6"/> <code code="33999-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Status"/> <statusCode code="completed"/> <value xsi:type="CD" code="55561003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Active"/></observation>

5.15Procedure Activity Act[act: templateId 2.16.840.1.113883.10.20.22.4.12(open)]

Table 36: Procedure Activity Act Contexts

Used By: Contains Entries:Procedures Section (entries required)Procedures Section (entries optional)

IndicationInstructionsMedication ActivityService Delivery Location

The common notion of "procedure" is broader than that specified by the HL7 Version 3 Reference Information Model (RIM). Therefore procedure templates can be represented with various RIM classes: act (e.g., dressing change), observation (e.g., EEG), procedure (e.g. splenectomy). This clinical statement represents any procedure that cannot be classified as an observation or a procedure according to the HL7 RIM. Examples of these procedures are a dressing change, teaching or feeding a patient or providing comfort measures.

Table 37: Procedure Activity Act Constraints Overview

Name XPath Card.

Verb Data Type

CONF#

Fixed Value


(HL7ActClass) = ACT@moodCode 1..1 SHALL 8290 2.16.840.1.113883.11.20.

9.18 (MoodCodeEvnInt)templateId 1..1 SHALL SET<II

>8291

@root 1..1 SHALL 10519 2.16.840.1.113883.10.20.22.4.12

procedureId id 1..* SHALL II 8292procedureType

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

procedureFreeTextType

originalText 0..1 SHOULD ED 8295

reference/@value

0..1 SHOULD 8296

statusCode 1..1 SHALL CS 8298 2.16.840.1.113883.11.20.9.22 (ProcedureAct statusCode)

procedureDateTime


8299

priorityCode 0..1 MAY CE 8300 2.16.840.1.113883.1.11.16866 (ActPriority)

performer 0..* SHOULD 8301procedurePerformer

assignedEntity 1..1 SHALL 8302

id 1..* SHALL II 8303addr 1..1 SHALL SET<A

D>8304

telecom 1..1 SHALL SET<TEL>

8305

representedOrganization

0..1 SHOULD 8306

id 0..* SHOULD II 8307name 0..* MAY PN 8308addr 1..1 SHALL SET<A

D>8309


8310

participant 0..* MAY 8311@typeCode 1..1 SHALL 8312 2.16.840.1.113883.5.100

2 (HL7ActRelationshipType) = LOC


@typeCode 1..1 SHALL 8315 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = COMP

@inversionInd 1..1 SHALL 8316 trueencounter 1..1 SHALL 8317

@classCode 1..1 SHALL 8318 2.16.840.1.113883.5.6 (HL7ActClass) = ENC

@moodCode 1..1 SHALL 8319 2.16.840.1.113883.5.100

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

1 (ActMood) = EVNid 1..1 SHALL II 8320



@inversionInd 1..1 SHALL 8324 true


@typeCode 1..1 SHALL 8327 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = RSON




128. SHALL contain exactly one [1..1] @moodCode, which SHALL be selected from ValueSet MoodCodeEvnInt 2.16.840.1.113883.11.20.9.18 STATIC 2011-04-03.


@root="2.16.840.1.113883.10.20.22.4.12".130. SHALL contain at least one [1..*] id.131. SHALL contain exactly one [1..1] code.

a. This code in a procedure activity observation SHOULD be selected from LOINC (CodeSystem: 2.16.840.1.113883.6.1) or SNOMED CT (CodeSystem: 2.16.840.1.113883.6.96).

b. This code SHOULD contain zero or one [0..1] originalText.i. The originalText, if present, SHOULD contain zero or one [0..1]



132. SHALL contain exactly one [1..1] statusCode, where the @code SHALL be selected from ValueSet ProcedureAct statusCode 2.16.840.1.113883.11.20.9.22 DYNAMIC.

133. SHOULD contain zero or one [0..1] effectiveTime.

134. MAY contain zero or one [0..1] priorityCode, where the @code SHALL be selected from ValueSet ActPriority 2.16.840.1.113883.1.11.16866 DYNAMIC.

135. SHOULD contain zero or more [0..*] performer.a. The performer, if present, SHALL contain exactly one [1..1]

assignedEntity.i. This assignedEntity SHALL contain at least one [1..*] id.ii. This assignedEntity SHALL contain exactly one [1..1] addr.iii. This assignedEntity SHALL contain exactly one [1..1] telecom.iv. This assignedEntity SHOULD contain zero or one [0..1]

representedOrganization.1. The representedOrganization, if present, SHOULD contain

zero or more [0..*] id.2. The representedOrganization, if present, MAY contain zero

or more [0..*] name.3. The representedOrganization, if present, SHALL contain

exactly one [1..1] addr.4. The representedOrganization, if present, SHALL contain

exactly one [1..1] telecom.136. MAY contain zero or more [0..*] participant.

a. The participant, if present, SHALL contain exactly one [1..1] @typeCode="LOC" Location (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. The participant, if present, SHALL contain exactly one [1..1] Service Delivery Location (2.16.840.1.113883.10.20.22.4.32).

137. MAY contain zero or more [0..*] entryRelationship.a. The entryRelationship, if present, SHALL contain exactly one [1..1]

@typeCode="COMP" Has Component (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. The entryRelationship, if present, SHALL contain exactly one [1..1] @inversionInd="true" true.

c. The entryRelationship, if present, SHALL contain exactly one [1..1] encounter.

i. This encounter SHALL contain exactly one [1..1] @classCode="ENC" Encounter (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

ii. This encounter SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001).

1. Set the encounter ID to the ID of an encounter in another section to signify they are the same encounter.

iii. This encounter SHALL contain exactly one [1..1] id.138. MAY contain zero or one [0..1] entryRelationship.

a. The entryRelationship, if present, SHALL contain exactly one [1..1] @typeCode="SUBJ" Has Subject (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. The entryRelationship, if present, SHALL contain exactly one [1..1] @inversionInd="true" true.

c. The entryRelationship, if present, SHALL contain exactly one [1..1] Instructions (2.16.840.1.113883.10.20.22.4.20).

139. MAY contain zero or more [0..*] entryRelationship.a. The entryRelationship, if present, SHALL contain exactly one [1..1]

@typeCode="RSON" Has Reason (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. The entryRelationship, if present, SHALL contain exactly one [1..1] Indication (2.16.840.1.113883.10.20.22.4.19).

140. MAY contain zero or one [0..1] entryRelationship.a. The entryRelationship, if present, SHALL contain exactly one [1..1]

@typeCode="COMP" Has Component (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. The entryRelationship, if present, SHALL contain exactly one [1..1] Medication Activity (2.16.840.1.113883.10.20.22.4.16).

Figure 58: Procedure activity act example

<act classCode="ACT" moodCode="INT"> <templateId root="2.16.840.1.113883.10.20.22.4.12"/> <id root="1.2.3.4.5.6.7.8" extension="1234567"/> <code code="80146002" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Appendectomy"> <originalText> <reference value="#proc1"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20110203"/> <priorityCode code="CR" codeSystem="2.16.840.1.113883.5.7" codeSystemName="ActPriority" displayName="Callback results"/>

<performer> <assignedEntity> <id root="1.2.3.4" extension="1234"/> <addr> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom use="WP" value="(555)555-555-1234"/> <representedOrganization> <id root="2.16.840.1.113883.19.5"/> <name>Good Health Clinic</name> <telecom nullFlavor="UNK"/> <addr nullFlavor="UNK"/> </representedOrganization> </assignedEntity> </performer> <participant typeCode="LOC"> <participantRole classCode="SDLOC"> <templateId root="2.16.840.1.113883.10.20.22.4.32"/>  ... </participantRole> </participant> <entryRelationship typeCode="COMP"> <substanceAdministration classCode="SBADM" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.16"/>  ... </substanceAdministration> </entryRelationship></act>

5.16Imaging Procedure Note: derived from Procedure Activity Procedure

Table 38: Imaging Procedure Constraints Overview

Name XPath Card.

Verb Data Type

Fixed Value

Imaging Procedure

@classCode 1..1 SHALL 2.16.840.1.113883.5.6 (HL7ActClass) = PROC


templateId 1..1 SHALL SET<II>@root 1..1 SHALL

Procedure Id id 1..* SHALL IIProcedure Type

code 1..1 SHALL CD

originalText 0..1 SHOULD EDstatusCode 1..1 SHALL CS 2.16.840.1.113883.11.20.9

.22 (ProcedureAct statusCode)

procedureDateTime


priority priorityCode 0..1 MAY CE 2.16.840.1.113883.1.11.16866 (ActPriority)

method methodCode 0..1 MAY SET<CE>

1.2.840.10008.6.1.19 (CID 29 Acquisition Modality)

bodySite targetSiteCode 0..* SHOULD SET<CD>

2.16.840.1.113883.3.88.12.3221.8.9 (Body Site Value Set)

performer 0..* SHOULDassignedEntity 1..1 SHALL

procedureperformer id

id 1..* SHALL II

procedureperformer addr

addr 1..1 SHALL SET<AD>

procedureperformer telecom


playingEntity 1..1 SHALLprocedureperformer name

name 1..1 SHALL PN

participant 0..* MAY


can this be used for multi-modality studies (PET+CT)


Breakdown procedure concept components

Name XPath Card.

Verb Data Type

Fixed Value

@typeCode 1..1 SHALL 5.16.1.1.1 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = LOC

participantRole @classCode 1..1 SHALL 2.16.840.1.113883.5.111

(RoleCode) = SDLOC templateId 1..1 SHALL SET<II> @root 1..1 SHALL 2.16.840.1.113883.10.20.2

2.4.32Procedure location typecode

code 0..1 MAY CE 2.16.840.1.113883.1.11.20275 (HealthcareServiceLocation)

Procedure location addr

addr 0..* SHOULD

SET<AD>

Procedure location telecom

telecom 0..* SHOULD

SET<TEL>

playingEntity 0..1 MAY @classCode 1..1 SHALL 2.16.840.1.113883.5.41

(EntityClass) = PLCProcedure location name

name 0..1 MAY PN

reference 0..* MAY@typeCode 1..1 SHALL REFR

externalDocumentReport OID id 1..1 OID of clinical report

141. SHALL contain exactly one [1..1] @classCode="PROC" Procedure (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

142. SHALL contain exactly one [1..1] @moodCode, which SHALL be selected from ValueSet MoodCodeEvnInt 2.16.840.1.113883.11.20.9.18 STATIC 2011-04-03.


@root="2.16.840.1.113883.10.20.22.4.14".144. SHALL contain at least one [1..*] id such that

a. SHALL contain one or more [1..*] Study Instance UID145. SHALL contain exactly one [1..1] code.146. SHALL contain exactly one [1..1] statusCode, where the @code SHALL be

selected from ValueSet ProcedureAct statusCode 2.16.840.1.113883.11.20.9.22 DYNAMIC.



What is relationship to Study Act, which has same UID?


in CCDA Service Delivery Location template, this is SHALL

148. MAY contain zero or one [0..1] priorityCode, where the @code SHALL be selected from ValueSet ActPriority 2.16.840.1.113883.1.11.16866 DYNAMIC.

149. MAY contain zero or one [0..1] methodCode.a. methodCode SHALL NOT conflict with the method inherent in Procedure /

code.150. SHOULD contain zero or more [0..*] targetSiteCode.

a. The targetSiteCode, if present, SHALL contain exactly one [1..1] code, where the @code SHALL be selected from ValueSet Body Site Value Set 2.16.840.1.113883.3.88.12.3221.8.9 DYNAMIC.

151. SHOULD contain zero or more [0..*] performer such that ita. SHALL contain exactly one [1..1] assignedEntity.

i. This assignedEntity SHALL contain at least one [1..*] id.ii. This assignedEntity SHALL contain exactly one [1..1] addr.iii. This assignedEntity SHALL contain exactly one [1..1] telecom.iv. This assignedEntity SHOULD contain zero or one [0..1]

representedOrganization.1. The representedOrganization, if present, SHOULD contain

zero or more [0..*] id.2. The representedOrganization, if present, MAY contain zero

or more [0..*] name.3. The representedOrganization, if present, SHALL contain

exactly one [1..1] addr.4. The representedOrganization, if present, SHALL contain

exactly one [1..1] telecom.152. MAY contain zero or more [0..*] participant such that it

a. SHALL contain exactly one [1..1] @typeCode="DEV" Device (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] Product Instance (2.16.840.1.113883.10.20.22.4.37).

153. MAY contain zero or one [0..1] participant such that ita. SHALL contain exactly one [1..1] @typeCode="LOC" Device (CodeSystem:

HL7ActRelationshipType 2.16.840.1.113883.5.1002).b. SHALL contain exactly one [1..1] participantRole such that it

i. SHALL contain exactly one [1..1] @classCode="SDLOC" (CodeSystem: RoleCode 2.16.840.1.113883.5.111).

ii. MAY contain zero or one [0..1] code, where the @code SHALL be selected from ValueSet HealthcareServiceLocation 2.16.840.1.113883.1.11.20275 DYNAMIC.

iii. SHOULD contain zero or more [0..*] addr.iv. SHOULD contain zero or more [0..*] telecom.v. MAY contain zero or one [0..1] playingEntity.

1. The playingEntity, if present, SHALL contain exactly one [1..1] @classCode="PLC" (CodeSystem: EntityClass 2.16.840.1.113883.5.41).

a. This @classCode MAY contain zero or one [0..1] name.

Table 39: Procedure Act Status Code Value Set

Value Set: ProcedureAct statusCode 2.16.840.1.113883.11.20.9.22 DYNAMICCode System(s):

ActStatus 2.16.840.1.113883.5.14

Description: A ValueSet of HL7 actStatus codes for use with a procedure activityCode Code System Print Namecompleted ActStatus Completedactive ActStatus Activeaborted ActStatus Abortedcancelled ActStatus Cancelled

Table 40: Act Priority Value Set

Value Set: ActPriority 2.16.840.1.113883.1.11.16866 DYNAMICCode System(s):

ActPriority 2.16.840.1.113883.5.7

Description: A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.

Code Code System Print NameA ActPriority ASAPCR ActPriority Callback resultsCS ActPriority Callback for schedulingCSP ActPriority Callback placer for schedulingCSR ActPriority Contact recipient for schedulingEL ActPriority ElectiveEM ActPriority EmergencyP ActPriority PreoperativePRN ActPriority As neededR ActPriority RoutineRR ActPriority Rush reportingS ActPriority StatT ActPriority Timing criticalUD ActPriority Use as directedUR ActPriority Urgent

Table 41: Body Site Value Set (excerpt)

Value Set: Body Site Value Set 2.16.840.1.113883.3.88.12.3221.8.9 DYNAMICCode System(s):

SNOMED CT 2.16.840.1.113883.6.96

Description: Contains values descending from the SNOMED CT® Anatomical Structure (91723000) hierarchy or Acquired body structure (body structure) (280115004) or Anatomical site notations for tumor staging (body structure) (258331007) or Body structure, altered from its original anatomical structure (morphologic abnormality) (118956008) or Physical anatomical entity (body structure) (91722005) This indicates the anatomical site.http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html

Code Code System Print Name361316009 SNOMED CT entire embryonic artery38033009 SNOMED CT amputation stump9550003 SNOMED CT bronchogenic cyst302509004 SNOMED CT heart…

Figure 59: Imaging procedure example

<procedure classCode="PROC" moodCode="EVN">  <templateId root=""/> <id root="1.2.840.113619.2.62.994044785528.114289542805"/>  <code code="418023006" codeSystem="2.16.840.1.113883.6.96" displayName="CT chest, abdomen, pelvis"> </code> <statusCode code="completed"/> <effectiveTime value="20140911103241-0500"/> <methodCode code="CT" codeSystem="1.2.840.10008.2.16.4" displayName="CT"/> <targetSiteCode code="51185008" codeSystem="2.16.840.1.113883.6.96" displayName="chest"/> <targetSiteCode code="113345001" codeSystem="2.16.840.1.113883.6.96" displayName="abdomen"/> <targetSiteCode code="12921003" codeSystem="2.16.840.1.113883.6.96" displayName="pelvis"/>

http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html

<participant typeCode="LOC"> <participantRole classCode="SDLOC"> <code code="GACH" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7RoleCode" displayName="General Acute Care Hospital"/> <addr> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom nullFlavor="UNK"/> <playingEntity classCode="PLC"> <name>Good Health Clinic</name> </playingEntity> </participantRole> </participant> </procedure>

5.17Service Delivery Location[participantRole: templateId 2.16.840.1.113883.10.20.22.4.32(open)]

Table 42: Service Delivery Location Contexts

Used By: Contains Entries:Procedure Activity ProcedureProcedure Activity ObservationProcedure Activity ActEncounter Activities

This clinical statement represents the location of a service event where an act, observation or procedure took place.


not the right code system

Table 43: Service Delivery Location Constraints Overview

Name

XPath Card.

Verb Data Type

Fixed Value

participantRole[templateId/@root = '2.16.840.1.113883.10.20.22.4.32']@classCode 1..1 SHALL 2.16.840.1.113883.5.111

(RoleCode) = SDLOCtemplateId 1..1 SHALL SET<II>

@root 1..1 SHALL 2.16.840.1.113883.10.20.22.4.32

code 1..1 SHALL CE 2.16.840.1.113883.1.11.20275 (HealthcareServiceLocation)

addr 0..* SHOULD SET<AD>telecom 0..* SHOULD SET<TEL

>

playingEntity0..1 MAY

@classCode1..1 SHALL 2.16.840.1.113883.5.41

(EntityClass) = PLCname 0..1 MAY PN

154. SHALL contain exactly one [1..1] @classCode="SDLOC" (CodeSystem: RoleCode 2.16.840.1.113883.5.111).


@root="2.16.840.1.113883.10.20.22.4.32".156. SHALL contain exactly one [1..1] code, where the @code SHALL be selected from

ValueSet HealthcareServiceLocation 2.16.840.1.113883.1.11.20275 DYNAMIC.

157. SHOULD contain zero or more [0..*] addr.158. SHOULD contain zero or more [0..*] telecom.159. MAY contain zero or one [0..1] playingEntity.

a. The playingEntity, if present, SHALL contain exactly one [1..1] @classCode="PLC" (CodeSystem: EntityClass 2.16.840.1.113883.5.41).

i. This @classCode MAY contain zero or one [0..1] name.

Table 44: HealthcareServiceLocation Value Set (excerpt)

Value Set: HealthcareServiceLocation 2.16.840.1.113883.1.11.20275 DYNAMICCode System(s):

HealthcareServiceLocation 2.16.840.1.113883.6.259

Description: A comprehensive classification of locations and settings where healthcare services are provided. This value set is based on the National Healthcare Safety Network (NHSN) location code system that has been developed over a number of years through CDC's interaction with a variety of healthcare facilities and is intended to serve a variety of reporting needs where coding of healthcare service locations is required.Full value set may be found at: http://phinvads.cdc.gov/vads/SearchAllVocab_search.action?searchOptions.searchText=Healthcare+Service+Location+%28NHSN%29

Code Code System Print Name1024-9 HealthcareServiceLocation Critical Care Unit1117-1 HealthcareServiceLocation Family Medicine Clinic1128-8 HealthcareServiceLocation Pediatric Clinic1160-1 HealthcareServiceLocation Urgent Care Center…

Figure 60: Service delivery location example

<participantRole classCode="SDLOC"> <templateId root="2.16.840.1.113883.10.20.22.4.32"/> <code code="GACH" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7RoleCode" displayName="General Acute Care Hospital"/> <addr> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom nullFlavor="UNK"/> <playingEntity classCode="PLC"> <name>Good Health Clinic</name> </playingEntity></participantRole>

5.18Procedure Context

Template Name Procedure Context EntryTemplate ID

http://phinvads.cdc.gov/vads/SearchAllVocab_search.action?searchOptions.searchText=Healthcare+Service+Location+(NHSN)

http://phinvads.cdc.gov/vads/SearchAllVocab_search.action?searchOptions.searchText=Healthcare+Service+Location+(NHSN)


General DescriptionThe ServiceEvent.code of the document header may be further elaborated in the CDA structured body. This may be used to capture the components of service event as specified in the RadLex Playbook or LOINC concept definition.

Class/Mood Code Data Type Value

CLUSTER / EVN n/a n/a

Card entryRelationship Description Template Spec Document


[1..1] COMP Modality

[0..1] Study type

[0..1] Target region

[0..1] Imaging focus

[0..1] Laterality

[0..1] Contrast

[0..1] Contrast route

[0..1] Imaging agent

[0..1] Challenge

[0..1] Views

[0..1] Positioning

[0..1] Purpose

[0..1] Guidance for


Or PROC with procedure code replicated from headerAnd add participants here, rather than a separate template

Table 45: Procedure Context Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value

act[templateId/@root = '2.16.840.1.113883.10.20.6.2.5']templateId 1..1 SHALL SET<II

>9200

@root 1..1 SHALL 10530 2.16.840.1.113883.10.20.6.2.5

code 1..1 SHALL CD 9201

effectiveTime0..1 SHOULD TS or

IVL<TS>

9203

@value 1..1 SHALL 9204low 0..0 SHALL

NOTTS 9205

high 0..0 SHALL NOT

TS 9206

Figure 61: Procedure context template example

<act moodCode="EVN" classCode="ACT"> <templateId root="2.16.840.1.113883.10.20.6.2.5"/>  <code code="70548" displayName="Magnetic resonance angiography, head; with contrast material(s)" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT4"/>  <effectiveTime value="20060823222400"/></act>

5.19Purpose of Reference Observation[observation: templateId 2.16.840.1.113883.10.20.6.2.9(open)]

Table 46: Purpose of Reference Observation Contexts

Used By: Contains Entries:Sop Instance Observation

A Purpose of Reference Observation describes the purpose of the DICOM composite object reference. Appropriate codes, such as externally defined DICOM codes, may be used to specify the semantics of the purpose of reference. When this observation is absent, it implies that the reason for the reference is unknown.

Table 47: Purpose of Reference Observation Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value


@classCode1..1 SHALL 9264 2.16.840.1.113883.5.6

(HL7ActClass) = OBS

@moodCode1..1 SHALL 9265 2.16.840.1.113883.5.1001


>9266

@root 1..1 SHALL 10531 2.16.840.1.113883.10.20.6.2.9

code 1..1 SHALL CD 9267code 0..1 SHOULD 9268 2.16.840.1.113883.5.4

(ActCode) = ASSERTIONvalue 0..1 SHOULD CD 9273 2.16.840.1.113883.11.20.9.28

(DICOMPurposeOfReference)




@root="2.16.840.1.113883.10.20.6.2.9".163. SHALL contain exactly one [1..1] code.

a. This code SHOULD contain zero or one [0..1] code="ASSERTION" (CodeSystem: ActCode 2.16.840.1.113883.5.4).

b. For backwards compatibility with the DICOM CMET, the code MAY be drawn from ValueSet 2.16.840.1.113883.11.20.9.28 DICOMPurposeOfReference DYNAMIC.

164. SHOULD contain zero or one [0..1] value with @xsi:type="CD", where the @code SHOULD be selected from ValueSet DICOMPurposeOfReference 2.16.840.1.113883.11.20.9.28 DYNAMIC.

a. The value element is a SHOULD to allow backwards compatibility with the DICOM CMET. Note that the use of ASSERTION for the code differs from the DICOM CMET. This is intentional. The DICOM CMET was created before the Term Info guidelines describing the use of the assertion pattern were released. It was determined that this IG should follow the latest Term Info guidelines. Implementers using both this IG and the DICOM CMET will need to be aware of this difference and apply appropriate transformations.

Table 48: DICOM Purpose of Reference Value Set

Value Set: DICOMPurposeOfReference 2.16.840.1.113883.11.20.9.28 DYNAMICCode System(s):

DCM 1.2.840.10008.2.16.4

Code Code System Print Name121079 DCM Baseline121080 DCM Best illustration of finding121112 DCM Source of Measurement

Figure 62: Purpose of reference example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.9"/> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <value xsi:type="CD" code="121112" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Source of Measurement"/></observation>

5.20Quantity Measurement Observation-2observation: templateId 2.16.840.1.113883.10.20.6.2.14(open)]

A Quantity Measurement Observation records quantitative measurements such as linear, area, volume, and numeric measurements. If based on image data, a reference to the

Table 49: Quantity Measurement Observation Constraints Overview

Name XPath Card Verb Data Type

CONF#

Fixed Value


@classCode1..1 SHALL 9317 2.16.840.1.113883.5.6

(HL7ActClass) = OBS

@moodCode1..1 SHALL 9318 2.16.840.1.113883.5.1001


>9319

@root 1..1 SHALL 10532 2.16.840.1.113883.10.20.6.2.14Measurement name

code 1..1 SHALL CD 9320

Measurement value

value 1..1 SHALL 9324

@xsi:type 1..1 SHALL 9325 PQMeasure @unit 1..1 SHALL 2.16.840.1.113883.1.11.12839

Name XPath Card Verb Data Type

CONF#

Fixed Value

ment unit

(UCUM Units of Measure (case sensitive))

Target site targetSite

Code

0..1 MAY CD

MethodmethodCode

0..1 MAY CD

entryRelationship

0..* MAY 9327

@typeCode1..1 SHALL 9328 2.16.840.1.113883.5.1002

(HL7ActRelationshipType) = SPRTImage Reference

1..1 Sop Instance Observation




@root="2.16.840.1.113883.10.20.6.2.14".168. SHALL contain exactly one [1..1] code.169. SHALL contain exactly one [1..1] value.

a. This value SHALL contain exactly one [1..1] @xsi:type, where the @code="PQ".

170. SHOULD contain zero or one [0..1] effectiveTime.171. MAY contain zero or more [0..*] entryRelationship such that it


b. SHALL contain exactly one [1..1] Sop Instance Observation (2.16.840.1.113883.10.20.6.2.8).

Figure 63: Quantity measurement observation example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.14"/> <code code="439984002" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNM3" displayName="Diameter of structure"> <originalText> <reference value="#Diam2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime value="20060823223912"/> <value xsi:type="PQ" value="45" unit="mm"> codeSystemVersion="1.5"/> </value> </observation>

5.21Reaction Observation[observation: templateId 2.16.840.1.113883.10.20.22.4.9(open)]

Table 50: Reaction Observation Contexts

Used By: Contains Entries:Allergy ObservationMedication ActivityImmunization Activity

Medication ActivityProcedure Activity ProcedureSeverity Observation

This clinical statement represents an undesired symptom, finding, etc., due to an administered or exposed substance. A reaction can be defined with respect to its severity, and can have been treated by one or more interventions.

Table 51: Reaction Observation Constraints Overview

Name XPath Card.

Verb Data Type

CONF#

Fixed Value



(ActMood) = EVNtemplateId 1..1 SHALL SET<

II>7323

@root 1..1 SHALL 10523 2.16.840.1.113883.10.20.22.4.9id 1..1 SHALL II 7329code 1..1 SHALL CD 7327

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

reactionFreeText


reference/@value

0..1 SHOULD 7331



7332

low 0..1 SHOULD TS 7333high 0..1 SHOULD TS 7334

reactionCoded

value 1..1 SHALL CD 7335 2.16.840.1.113883.3.88.12.3221.7.4 (Problem)

severityentryRelationship

0..1 SHOULD 7580












@root="2.16.840.1.113883.10.20.22.4.9".175. SHALL contain exactly one [1..1] id.176. SHALL contain exactly one [1..1] code.

a. The value set for this code element has not been specified. Implementers are allowed to use any code system, such as SNOMED CT, a locally determined code, or a nullFlavor.

177. SHOULD contain zero or one [0..1] text.a. The text, if present, SHOULD contain zero or one [0..1] reference/@value.

i. This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1).


179. SHOULD contain zero or one [0..1] effectiveTime.a. The effectiveTime, if present, SHOULD contain zero or one [0..1] low.b. The effectiveTime, if present, SHOULD contain zero or one [0..1] high.

180. SHALL contain exactly one [1..1] value with @xsi:type="CD", where the @code SHALL be selected from ValueSet Problem 2.16.840.1.113883.3.88.12.3221.7.4 DYNAMIC.

181. SHOULD contain zero or one [0..1] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has subject

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).b. SHALL contain exactly one [1..1] @inversionInd="true" TRUE.c. SHALL contain exactly one [1..1] Severity Observation

(2.16.840.1.113883.10.20.22.4.8).182. MAY contain zero or more [0..*] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="RSON" Has reason (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] @inversionInd="true" True.c. SHALL contain exactly one [1..1] Procedure Activity Procedure

(2.16.840.1.113883.10.20.22.4.14).i. This procedure activity is intended to contain information about

procedures that were performed in response to an allergy reaction.183. MAY contain zero or more [0..*] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="RSON" Has reason (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] @inversionInd="true" True.c. SHALL contain exactly one [1..1] Medication Activity

(2.16.840.1.113883.10.20.22.4.16).i. This medication activity is intended to contain information about

medications that were administered in response to an allergy reaction.

Figure 64: Reaction observation example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.9"/>  <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <statusCode code="completed"/> <value xsi:type="CD" code="56018004" codeSystem="2.16.840.1.113883.6.96" displayName="Wheezing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/></observation>

5.22Referenced Frames Observation[observation: templateId 2.16.840.1.113883.10.20.6.2.10(open)]

A Referenced Frames Observation is used if the referenced DICOM SOP instance is a multiframe image and the reference does not apply to all frames. The list of integer values for the referenced frames of a DICOM multiframe image SOP instance is contained in a Boundary Observation nested inside this class.

184. SHALL contain exactly one [1..1] @classCode="ROIBND" Bounded Region of Interest (CodeSystem: 2.16.840.1.113883.5.6 HL7ActClass).

185. SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: 2.16.840.1.113883.5.1001 ActMood).

186. SHALL contain exactly one [1..1] code="121190" Referenced Frames (CodeSystem: 1.2.840.10008.2.16.4 DCM).

187. SHALL contain exactly one [1..1] entryRelationship. a. This entryRelationship SHALL contain exactly one [1..1] @typeCode="COMP"

Component (CodeSystem: 2.16.840.1.113883.5.1002 HL7ActRelationshipType).

b. This entryRelationship SHALL contain exactly one [1..1] Boundary Observation (templateId:2.16.840.1.113883.10.20.6.2.11).

Figure 65: Referenced frames observation example

<observation classCode="ROIBND" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.10"/> <code code="121190" codeSystem="1.2.840.10008.2.16.4" displayName="Referenced Frames"/> <entryRelationship typeCode="COMP">  <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.11"/> <code code="113036" codeSystem="1.2.840.10008.2.16.4" displayName="Frames for Display"/> <value xsi:type="INT" value="1"/> </observation> </entryRelationship></observation>

5.23Result Observation[observation: templateId 2.16.840.1.113883.10.20.22.4.2(open)]

Table 52: Result Observation Contexts

Used By: Contains Entries:Result OrganizerFunctional Status Section

This clinical statement represents details of a lab, radiology, or other study performed on a patient.

Table 53: Result Observation Constraints Overview

Name XPath Card.

Verb Data Type

CONF#

Fixed Value




>7136

@root 1..1 SHALL 9138 2.16.840.1.113883.10.20.22.4.2

resultID id 1..* SHALL II 7137resultType code 1..1 SHALL CD 7133

Name XPath Card.

Verb Data Type

CONF#

Fixed Value

text 0..1 SHOULD ED 7138reference


resultStatus


resultDateTime


7140

resultValue

value 1..1 SHALL ANY 7143

resultInterpreta-tion

interpretationCode

0..* SHOULD CE 7147

methodCode 0..1 MAY SET<CE>

7148

targetSiteCode0..1 MAY SET<C

D>7153

author 0..1 MAY 7149resultReferenceRange

referenceRange0..* SHOULD 7150

observationRange

1..1 SHALL 7151

code 0..0 SHALL NOT

7152





a. SHOULD be from LOINC (CodeSystem: 2.16.840.1.113883.6.1) or SNOMED CT (CodeSystem: 2.16.840.1.113883.6.96).

b. Laboratory results SHOULD be from LOINC (CodeSystem: 2.16.840.1.113883.6.1) or other constrained terminology named by the US Department of Health and Human Services Office of National Coordinator or other federal agency. Local and/or regional codes for laboratory results are allowed. The Local and/or regional codes SHOULD be sent in the translation element. See the Local code example figure.

193. SHOULD contain zero or one [0..1] text.

195. SHALL contain exactly one [1..1] effectiveTime.a. represents clinically effective time of the measurement, which may be

when the measurement was performed (e.g., a BP measurement), or may be when sample was taken (and measured some time afterwards).

196. SHALL contain exactly one [1..1] value with @xsi:type="ANY".197. SHOULD contain zero or more [0..*] interpretationCode.198. MAY contain zero or one [0..1] methodCode.199. MAY contain zero or one [0..1] targetSiteCode.200. MAY contain zero or one [0..1] author.201. SHOULD contain zero or more [0..*] referenceRange.

a. The referenceRange, if present, SHALL contain exactly one [1..1] observationRange.

i. This observationRange SHALL NOT contain [0..0] code.

Figure 66: Result observation example

<observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.2"/> <id root="107c2dc0-67a5-11db-bd13-0800200c9a66"/> <code code="30313-1" displayName="HGB" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <statusCode code="completed"/> <effectiveTime value="200003231430"/> <value xsi:type="PQ" value="13.2" unit="g/dl"/> <interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"/> <methodCode/> <targetSiteCode/> <author> <time/> <assignedAuthor> <id/> </assignedAuthor> </author> <referenceRange> <observationRange> <text>M 13-18 g/dl; F 12-16 g/dl</text> </observationRange> </referenceRange></observation>

Figure 67: No evaluation procedures (e.g., labs/x-rays) performed example

<entry> <act classCode="ACT" moodCode="EVN" negationInd="true"> <code code="386053000" codeSystem="2.16.840.1.113883.6.96" displayName="evaluation procedure"/> <text>No Evaluation Procedures Performed</text> <statusCode code="completed"/> </act></entry>

Figure 68: Local code example

<code code="30313-1" displayName="HGB" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"> <translation code="123-4" displayName="Example" codeSystem="2.16.840.1.113883.19.5" codeSystemName="Regional Example Code System"/></code>

5.24Result Organizer[organizer: templateId 2.16.840.1.113883.10.20.22.4.1(open)]

Table 54: Result Organizer Contexts

Used By: Contains Entries:Results Section (entries required)Results Section (entries optional)

Result Observation

This clinical statement identifies set of result observations. It contains information applicable to all of the contained result observations. Result type codes categorize a result into one of several commonly accepted values (e.g., “Hematology”, “Chemistry”, “Nuclear Medicine”). These values are often implicit in the Organizer/code (e.g., an Organizer/code of “complete blood count” implies a ResultTypeCode of “Hematology”). This template requires Organizer/code to include a ResultTypeCode either directly or as a translation of a code from some other code system.An appropriate nullFlavor can be used when a single result observation is contained in the organizer, and organizer/code or organizer/id is unknown.

Table 55: Result Organizer Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value

organizer[templateId/@root = '2.16.840.1.113883.10.20.22.4.1']

@classCode1..1 SHALL 7121 2.16.840.1.113883.5.6

(HL7ActClass)

@moodCode1..1 SHALL 7122 2.16.840.1.113883.5.1001


>7126

@root 1..1 SHALL 9134 2.16.840.1.113883.10.20.22.4.1id 1..* SHALL II 7127code 1..1 SHALL CD 7128statusCode 1..1 SHALL CS 7123 2.16.840.1.113883.5.14

(ActStatus) = completedcomponent 1..* SHALL 7124

202. SHALL contain exactly one [1..1] @classCode.a. SHOULD contain zero or one [0..1] @classCode="CLUSTER" Cluster

(CodeSystem: 2.16.840.1.113883.5.6 HL7ActClass) OR SHOULD contain zero or one [0..1] @classCode="BATTERY" Battery (CodeSystem: 2.16.840.1.113883.5.6 HL7ActClass).




a. SHOULD be selected from LOINC (codeSystem 2.16.840.1.113883.6.1) or SNOMED CT (codeSystem 2.16.840.1.113883.6.96), and MAY be selected from CPT-4 (codeSystem 2.16.840.1.113883.6.12).

b. Laboratory results SHOULD be from LOINC (CodeSystem: 2.16.840.1.113883.6.1) or other constrained terminology named by the US Department of Health and Human Services Office of National Coordinator or other federal agency. Local and/or regional codes for laboratory results SHOULD also be allowed.


208. SHALL contain at least one [1..*] component such that ita. SHALL contain exactly one [1..1] Result Observation

(2.16.840.1.113883.10.20.22.4.2).

Figure 69: Result organizer example

<organizer classCode="BATTERY" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.1"/> <id root="7d5a02b0-67a4-11db-bd13-0800200c9a66"/> <code code="57021-8" displayName="CBC W Auto Differential panel" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <statusCode code="completed"/> <component> <observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.2"/> ... </observation> </component> <component> <observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.22.4.2"/> ... </observation> </component> ... </organizer>

5.25Series Act[act: templateId 2.16.840.1.113883.10.20.22.4.63(open)]

Table 56: Series Act Contexts

Used By: Contains Entries:Study Act Sop Instance Observation

A Series Act contains the DICOM series information for referenced DICOM composite objects. The series information defines the attributes that are used to group composite instances into distinct logical sets. Each series is associated with exactly one study. Series Act clinical statements are only instantiated in the DICOM Object Catalog section inside a Study Act, and thus do not require a separate templateId; in other sections, the SOP Instance Observation is included directly.

Table 57: Series Act Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value



1 (ActMood) = EVNid 1..* SHALL II 9224

@root 1..1 SHALL 9225@extension 0..0 SHALL

NOT9226

code 1..1 SHALL CD 9228 1.2.840.10008.2.16.4 (DCM) = 113015

qualifier 1..1 SHALL SET<CS>

9229

name 1..1 SHALL PN 9230 1.2.840.10008.2.16.4 (DCM) = 121139

value 1..1 SHALL ANY 9231text 0..1 MAY ED 9233effectiveTime 0..1 SHOULD TS or

IVL<TS>9235





211. SHALL contain at least one [1..*] id.a. Such ids SHALL contain exactly one [1..1] @root.

i. The @root contains the OID of the study instance UID since DICOM study ids consist only of an OID.

b. Such ids SHALL NOT contain [0..0] @extension.212. SHALL contain exactly one [1..1] code="113015" (CodeSystem: DCM

1.2.840.10008.2.16.4).a. This code SHALL contain exactly one [1..1] qualifier.

i. This qualifier SHALL contain exactly one [1..1] name="121139" Modality (CodeSystem: DCM 1.2.840.10008.2.16.4).

ii. This qualifier SHALL contain exactly one [1..1] value with @xsi:type="ANY".

1. 1. The value element code contains a modality code and codeSystem is 1.2.840.10008.2.16.4.

213. MAY contain zero or one [0..1] text.a. If present, the text element contains the description of the series.

214. SHOULD contain zero or one [0..1] effectiveTime.a. If present, the effectiveTime contains the time the series was started.

215. SHALL contain at least one [1..*] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="COMP" Component

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).b. SHALL contain exactly one [1..1] Sop Instance Observation

(2.16.840.1.113883.10.20.6.2.8).

Figure 70: Series act example

<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"> <templateId root="2.16.840.1.113883.10.20.6.2.8"/> ... </observation> </entryRelationship></act>

5.26Severity Observation[observation: templateId 2.16.840.1.113883.10.20.22.4.8(open)]

Table 58: Severity Observation Contexts

Used By: Contains Entries:Reaction ObservationAllergy Observation

This clinical statement represents the gravity of the problem, such as allergy or reaction, in terms of its actual or potential impact on the patient. The Severity Observation can be associated with an Allergy Obervation, Reaction Observation or both. When the Severity Observation is associated directly with an Allergy it characterizes the Allergy. When the

Severity Observation is associated with a Reaction Observation it characterizes a Reaction. A person may manifest many symptoms in a reaction to a single substance, and each reaction to the substance can be represented. However, each reaction observation can have only one severity observation associated with it. For example, someone may have a rash reaction observation as well as an itching reaction observation, but each can have only one level of severity

Table 59: Severity Observation Constraints Overview

Name XPath Card.

Verb Data Type

CONF#

Fixed Value



(ActMood) = EVNtemplateId 1..1 SHALL SET<

II>7347

@root 1..1 SHALL 10525 2.16.840.1.113883.10.20.22.4.8

code 1..1 SHALL CD 7349 2.16.840.1.113883.5.4 (ActCode) = SEV

severityFreeText


reference/@value

0..1 SHOULD 7351


severityCoded

value 1..1 SHALL CD 7356 2.16.840.1.113883.3.88.12.3221.6.8 (Problem Severity)

interpretationCode

0..* SHOULD CE 9117

code 0..1 SHOULD CE 9118 2.16.840.1.113883.1.11.78 (Observation Interpretation (HL7))




@root="2.16.840.1.113883.10.20.22.4.8".219. SHALL contain exactly one [1..1] code="SEV" Severity Observation

(CodeSystem: ActCode 2.16.840.1.113883.5.4).220. SHOULD contain zero or one [0..1] text.




222. SHALL contain exactly one [1..1] value with @xsi:type="CD", where the @code SHALL be selected from ValueSet Problem Severity 2.16.840.1.113883.3.88.12.3221.6.8 DYNAMIC.

223. SHOULD contain zero or more [0..*] interpretationCode.a. The interpretationCode, if present, SHOULD contain zero or one [0..1] code,

where the @code SHOULD be selected from ValueSet Observation Interpretation (HL7) 2.16.840.1.113883.1.11.78 DYNAMIC.

Table 60: Problem Severity Value Set

Value Set: Problem Severity 2.16.840.1.113883.3.88.12.3221.6.8 DYNAMICCode System(s):

SNOMED CT 2.16.840.1.113883.6.96

Description: This is a description of the level of the severity of the problem.Code Code System Print Name255604002 SNOMED CT Mild (qualifier value)371923003 SNOMED CT Mild to moderate (qualifier value)6736007 SNOMED CT Moderate (severity modifier) (qualifier value)371924009 SNOMED CT Moderate to severe (qualifier value)24484000 SNOMED CT Severe (severity modifier) (qualifier value)399166001 SNOMED CT Fatal (qualifier value)

Figure 71: Severity observation example

<observation classCode="OBS" moodCode="EVN">  <templateId root=" 2.16.840.1.113883.10.20.22.4.8"/> <code code="SEV" displayName="Severity Observation" codeSystem="2.16.840.1.113883.5.4" codeSystemName="ActCode"/> <text> <reference value="#severity"/> </text> <statusCode code="completed"/> <value xsi:type="CD" code="371924009" displayName="Moderate to severe" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/></observation>

5.27Social History Observation[observation: templateId 2.16.840.1.113883.10.20.22.4.38(open)]

Table 61: Social History Observation Contexts

Used By: Contains Entries:Social History Section

This Social History Observation defines the patient’s occupational, personal (e.g., lifestyle), social, and environmental history and health risk factors, as well as administrative data such as marital status, race, ethnicity, and religious affiliation.

Table 62: Social History Observation Constraints Overview

Name XPath Card.

Verb Data Type

Fixed Value

Social History observation@classCode 1..1 SHALL 2.16.840.1.113883.5.6

(HL7ActClass) = OBS@moodCode 1..1 SHALL 2.16.840.1.113883.5.100

1 (ActMood) = EVNtemplateId 1..1 SHALL SET<II>

@root 1..1 SHALL 2.16.840.1.113883.10.20.22.4.38

id 1..* SHALL IIcode 0..1 SHOULD CD

socialHistoryType

code 0..1 SHOULD 2.16.840.1.113883.3.88.12.80.60 (Social History Type Set Definition)

socialHistoryFreeText

originalText

0..1 SHOULD ED

reference/@value

0..1 SHOULD

statusCode 1..1 SHALL CS 2.16.840.1.113883.5.14 (ActStatus) = completed

socialHistoryObservedValue

value 0..1 SHOULD ANY




@root="2.16.840.1.113883.10.20.22.4.38".227. SHALL contain at least one [1..*] id.228. SHOULD contain zero or one [0..1] code.

a. The code, if present, SHOULD contain zero or one [0..1] code, where the @code SHOULD be selected from ValueSet Social History Type Set Definition 2.16.840.1.113883.3.88.12.80.60 STATIC (2008-12-18 ).

b. The code, if present, SHOULD contain zero or one [0..1] originalText.i. The originalText, if present, SHOULD contain zero or one [0..1]



229. SHALL contain exactly one [1..1] statusCode="completed" (CodeSystem: ActStatus 2.16.840.1.113883.5.14).

230. SHOULD contain zero or one [0..1] value with @xsi:type="ANY".a. Observation/value can be any data type. Where Observation/value is a

physical quantity, the unit of measure SHALL be expressed using a valid Unified Code for Units of Measure (UCUM) expression.

Table 63: Social History Type Set Definition Value Set

Value Set: Social History Type Set Definition 2.16.840.1.113883.3.88.12.80.60 STATIC 2008-12-18Code System(s): SNOMED CT 2.16.840.1.113883.6.96Code Code System Print Name

229819007 SNOMED CT Tobacco use and exposure256235009 SNOMED CT Exercise160573003 SNOMED CT Alcohol intake364393001 SNOMED CT Nutritional observable364703007 SNOMED CT Employment detail425400000 SNOMED CT Toxic exposure status363908000 SNOMED CT Details of drug misuse behavior228272008 SNOMED CT Health-related behavior105421008 SNOMED CT Educational Achievement

Figure 72: Social history observation template example

<observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.38"/>  <id root="45efb604-7049-4a2e-ad33-d38556c9636c"/> <code code="230056004" codeSystem="2.16.840.1.113883.6.96" displayName="Cigarette smoking"> <originalText> <reference value="#soc2"/> </originalText> </code> <statusCode code="completed"/> <effectiveTime> <low value="1973"/> </effectiveTime> <value xsi:type="ST">None</value></observation>

5.28SOP Instance Observation[observation: templateId 2.16.840.1.113883.10.20.6.2.8(open)]

Table 64: Sop Instance Observation Contexts

Used By: Contains Entries:Series ActText ObservationCode ObservationsQuantity Measurement Observation

Purpose of Reference ObservationReferenced Frames ObservationSop Instance Observation

A SOP Instance Observation contains the DICOM Service Object Pair (SOP) Instance information for referenced DICOM composite objects. The SOP Instance act class is used to reference both image and non-image DICOM instances. The text attribute contains the DICOM WADO reference.

Table 65: Sop Instance Observation Constraints Overview

Name XPath Card.

Verb Data Type

Fixed Value

Sop Instance

observation

@classCode 1..1 SHALL 2.16.840.1.113883.5.6 (HL7ActClass) = DGIMG



@root 1..1 SHALL 2.16.840.1.113883.10.20.6.2.8

id 1..* SHALL IIcode 1..1 SHALL CDtext 0..1 SHOULD ED

@mediaType 1..1 SHALL application/dicomreference 1..1 SHALL


@value 1..1 SHALLlow 0..0 SHALL

NOTTS

high 0..0 SHALL NOT

TS

entryRelationship0..* MAY

@typeCode 1..1 SHALL 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = SUBJ


@typeCode 1..1 SHALL 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = RSON


@typeCode 1..1 SHALL 2.16.840.1.113883.5.1002 (HL7ActRelationshipType) = COMP

231. SHALL contain exactly one [1..1] @classCode="DGIMG" Diagnostic Image (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).


233. SHALL contain at least one [1..*] id.a. The @root contains an OID representing the DICOM SOP Instance UID.

234. SHALL contain exactly one [1..1] code.a. SHALL contain codeSystem 1.2.840.10008.2.6.1 DCMUID and code is an

OID for a valid SOP class name UID.235. SHOULD contain zero or one [0..1] text.

a. The text, if present, SHALL contain exactly one [1..1] @mediaType="application/dicom".

b. The text, if present, SHALL contain exactly one [1..1] reference.i. SHALL contain a @value which contains a WADO reference as a URI.

236. SHOULD contain zero or one [0..1] effectiveTime.a. The effectiveTime, if present, SHALL contain exactly one [1..1] @value.b. The effectiveTime, if present, SHALL NOT contain [0..0] low.c. The effectiveTime, if present, SHALL NOT contain [0..0] high.

237. MAY contain zero or more [0..*] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has Subject



a. SHALL contain exactly one [1..1] @typeCode="RSON" Has Reason (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] Purpose of Reference Observation (2.16.840.1.113883.10.20.6.2.9).

239. MAY contain zero or more [0..*] entryRelationship such that ita. This entryRelationship SHALL be present if the referenced DICOM object is

a multiframe object and the reference does not apply to all frames.b. SHALL contain exactly one [1..1] @typeCode="COMP" Has Component

(CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).c. SHALL contain exactly one [1..1] Referenced Frames Observation

(2.16.840.1.113883.10.20.6.2.10).

Figure 73: SOP instance observation example

<observation classCode="DGIMG" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.8"/> <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"> </code> <text mediaType="application/dicom"> <reference value="http://www.example.org/wado?requestType=WADO&studyUID=1.2.840.113619.2.62.994044785528.114289542805&seriesUID=1.2.840.113619.2.62.994044785528.20060823223142485051&objectUID=1.2.840.113619.2.62.994044785528.20060823.200608232232322.3&contentType=application/dicom"/>  </text> <effectiveTime value="20060823223232"/></observation>

5.29Study Act[act: templateId 2.16.840.1.113883.10.20.6.2.6(open)]

Table 66: Study Act Contexts

Used By: Contains Entries:DICOM Object Catalog Section - DCM 121181 Series Act

A Study Act contains the DICOM study information that defines the characteristics of a referenced medical study performed on a patient. A study is a collection of one or more series of medical images, presentation states, SR documents, overlays, and/or curves that are logically related for the purpose of diagnosing a patient. Each study is associated with exactly one patient. A study may include composite instances that are created by a single modality, multiple modalities, or by multiple devices of the same modality. The study information is modality-independent. Study Act clinical statements are only instantiated in the DICOM Object Catalog section; in other sections, the SOP Instance Observation is included directly.

Table 67: Study Act Constraints Overview

Name

XPath Card.

Verb Data Type

CONF# Fixed Value



(ActMood) = EVNtemplateId 1..1 SHALL SET<I

I>9209

@root 1..1 SHALL 10533 2.16.840.1.113883.10.20.6.2.6

id 1..* SHALL II 9210@root 1..1 SHALL 9213@extension 0..0 SHALL

NOT9211

code 1..1 SHALL CD 9214 1.2.840.10008.2.16.4 (DCM) = 113014

text 0..1 MAY ED 9215effectiveTime 0..1 SHOULD TS or

IVL<TS>

9216



240. SHALL contain exactly one [1..1] @classCode="ACT" (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6).

241. SHALL contain exactly one [1..1] @moodCode="EVN" (CodeSystem: ActMood 2.16.840.1.113883.5.1001).


@root="2.16.840.1.113883.10.20.6.2.6".243. SHALL contain at least one [1..*] id.

a. Such ids SHALL contain exactly one [1..1] @root.i. The @root contains the OID of the study instance UID since DICOM

study ids consist only of an OID.b. Such ids SHALL NOT contain [0..0] @extension.

244. SHALL contain exactly one [1..1] code="113014" (CodeSystem: DCM 1.2.840.10008.2.16.4).

245. MAY contain zero or one [0..1] text.a. If present, the text element contains the description of the study.



From Harry: Add translation of Procedure code?

a. If present, the effectiveTime contains the time the study was started.247. SHALL contain at least one [1..*] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="COMP" Component (CodeSystem: HL7ActRelationshipType 2.16.840.1.113883.5.1002).

b. SHALL contain exactly one [1..1] Series Act (2.16.840.1.113883.10.20.22.4.63).

Figure 74: Study act example

<act classCode="ACT" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.6"/> <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"> ... </act> </entryRelationship></act>

5.30Text Observation[observation: templateId 2.16.840.1.113883.10.20.6.2.12(open)]

Table 68: Text Observation Contexts

Used By: Contains Entries:Findings Section (DIR) Quantity Measurement Observation

Sop Instance Observation

DICOM Template 2000 specifies that Imaging Report Elements of Value Type Text are contained in sections. The Imaging Report Elements are inferred from Basic Diagnostic Imaging Report Observations that consist of image references and measurements (linear, area, volume, and numeric). Text DICOM Imaging Report Elements in this context are mapped to CDA text observations that are section components and are related to the SOP Instance Observations (templateId 2.16.840.1.113883.10.20.6.2.8) or Quantity Measurement Observations (templateId 2.16.840.1.113883.10.20.6.2.14) by the SPRT (Support) act relationship.A Text Observation is required if the findings in the section text are represented as inferred from SOP Instance Observations.

Table 69: Text Observation Constraints Overview

Name

XPath Card.

Verb Data Type

CONF#

Fixed Value


(ActCode) = OBS@moodCode 1..1 SHALL 9289 2.16.840.1.113883.5.1001


>9290

@root 1..1 SHALL 10534 2.16.840.1.113883.10.20.6.2.12

code 1..1 SHALL CD 9291value 1..1 SHALL 9292

@xsi:type 1..1 SHALL 9293 EDeffectiveTime 0..1 SHOULD TS or

IVL<TS>

9294

text 0..1 MAY ED 9295reference






248. SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: ActCode 2.16.840.1.113883.5.4).



@root="2.16.840.1.113883.10.20.6.2.12".251. SHALL contain exactly one [1..1] code.252. SHALL contain exactly one [1..1] value.

a. This value SHALL contain exactly one [1..1] @xsi:type, where the @code="ED".

253. SHOULD contain zero or one [0..1] effectiveTime.254. MAY contain zero or one [0..1] text.

255. MAY contain zero or more [0..*] entryRelationship such that ita. SHALL contain exactly one [1..1] @typeCode="SPRT" Has Support




b. SHALL contain exactly one [1..1] Quantity Measurement Observation (2.16.840.1.113883.10.20.6.2.14).

Figure 75: Text observation example

<text> <paragraph> <caption>Finding</caption> <content ID="Fndng2">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> </paragraph> ...</text><entry> <observation classCode="OBS" moodCode="EVN">  <templateId root="2.16.840.1.113883.10.20.6.2.12"/> <code code="121071" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Finding"/> <value xsi:type="ED"><reference value="#Fndng2"/></value> ...  </observation></entry>

6 SECTION PARTICIPATION TEMPLATES

6.1 Fetus Subject Context [relatedSubject: templateId 2.16.840.1.113883.10.20.6.2.3(open)]

For reports on mothers and their fetus(es), information on a mother is mapped to recordTarget, PatientRole, and Patient. Information on the fetus is mapped to subject, relatedSubject, and SubjectPerson at the CDA section level. Both context information on the mother and fetus must be included in the document if observations on fetus(es) are contained in the document.


@root="2.16.840.1.113883.10.20.6.2.3".258. SHALL contain exactly one [1..1] code="121026" (CodeSystem: DCM

1.2.840.10008.2.16.4).259. SHALL contain exactly one [1..1] subject.260. SHALL contain exactly one [1..1] name.

a. The name element is used to store the DICOM fetus ID, typically a pseudonym such as fetus_1.

Figure 76: Fetus subject context example

<relatedSubject> <templateId root="2.16.840.1.113883.10.20.6.2.3"/> <code code="121026" codeSystem="1.2.840.10008.2.16.4" displayName="Fetus"/> <subject> <name>fetus_1</name> </subject></relatedSubject>

6.2 Observer Context[assignedAuthor: templateId 2.16.840.1.113883.10.20.6.2.4(open)]

The Observer Context is used to override the author specified in the CDA Header. It is valid as a direct child element of a section.


@root="2.16.840.1.113883.10.20.6.2.4".262. SHALL contain exactly one [1..1] assignedAuthor.263. SHALL contain at least one [1..*] id.

a. The id element contains the author's id or the DICOM device observer UID.264. Either assignedPerson or assignedAuthoringDevice SHALL be present.


From Harry: Compare w/CCDAr2 Author Participation

Figure 77: Observer context example

<assignedAuthor> <templateId root="2.16.840.1.113883.10.20.6.2.4"/> <id extension="121008" root="2.16.840.1.113883.19.5"/> <assignedPerson> <name><given>John</given> <family>Blitz</family> <suffix>MD</suffix></name> </assignedPerson></assignedAuthor>

7 REFERENCES Cross Transaction Specifications and Content Specifications. IHE ITI Technical

Framework, Volume 3 (ITI TF-3) (see 5.2 Scanned Documents Content Model). http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol3_FT_2009-08-10.pdf

Extensible Markup Language (XML) 1.0 (Fifth Edition), http://www.w3c.org/TR/2008/REC-xml-20081126/

HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component; (HITSP/C32); Versions 2.1, 2.2, 2.3, 2.5; December 13, 2007 - July 8, 2009

HL7 Clinical Document Architecture (CDA Release 2). http://www.hl7.org/implement/standards/cda.cfm

HL7 Implementation Guide for CDA Release 2: Consultation Notes, (U.S. Realm), Draft Standard for Trial Use, Release 1, Levels 1, 2, and 3, DSTU Updated: January 2010

HL7 Implementation Guide for CDA Release 2: History and Physical (H&P) Notes (U.S. Realm) Draft Standard for Trial Use, Release 1, Levels 1, 2, and 3 A CDA Implementation guide for History and Physical Notes, DSTU Updated: January 2010

HL7 Implementation Guide for CDA Release 2: Procedure Note (Universal Realm), Draft Standard for Trial Use, Release 1, Levels 1, 2, and 3, July 2010

HL7 Implementation Guide for CDA Release 2: Unstructured Documents, Release 1, Level 1 (Universal Realm), Draft Standard for Trial Use, September 2010

HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD) A CDA implementation of ASTM E2369-05 Standard Specification for Continuity of Care Record© (CCR), April 01, 2007

HL7 Version 3 Interoperability Standards, Normative Edition 2010. http://www.hl7.org/memonly/downloads/v3edition.cfm - V32010

Implementation Guide for CDA Release 2: Imaging Integration, Levels 1, 2, and 3, Basic Imaging Reports in CDA and DICOM Diagnostic Imaging Reports (DIR) – Universal Realm, Based on HL7 CDA Release 2.0, Release 1.0, Informative Document, First Release, March 2009

Implementation Guide for CDA Release 2.0 Operative Note, (U.S. Realm), Draft Standard for Trial Use, Release 1, Levels 1, 2 and 3, Published, March 2009

Implementation Guide for CDA Release 2.0, Care Record Summary Release 2Discharge Summary, (U.S. Realm) Draft Standard for Trial Use, Levels 1, 2 and 3, December 2009

http://www.hl7.org/memonly/downloads/v3edition.cfm#V32010

http://www.w3c.org/TR/2008/REC-xml-20081126/

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol3_FT_2009-08-10.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol3_FT_2009-08-10.pdf

Implementation Guide for CDA Release 2.0, Progress Note (U.S. Realm), Draft Standard for Trial Use, Levels 1, 2, and 3, January 2011

Joint Commission Requirements for Discharge Summary (JCAHO IM.6.10 EP7). See http://www.jointcommission.org/NR/rdonlyres/C9298DD0-6726-4105-A007-FE2C65F77075/0/CMS_New_Revised_HAP_FINAL_withScoring.pdf (page 26).

Mosby's Medical Dictionary, 8th edition. © 2009, Elsevier. Taber's Cyclopedic Medical Dictionary, 21st Edition, F.A. Davis Company.

http://www.tabers.com Term Info. http://www.hl7.org/special/committees/terminfo/index.cfm Trifolia Workbench (Consolidation Project Edition). Open source template

database. http://www.lantanagroup.com/newsroom/press-releases/trifolia-workbench/ You must be logged in as a member of HL7.org to access this resource: http://www.hl7.org/login/singlesignon.cfm?next=/documentcenter/private/standards/cda/Trifolia_HL7_Consolidation_20110712-dist.zip

XML Path Language (XPath), Version 1.0. http://www.w3.org/TR/xpath/

http://www.w3.org/TR/xpath/

http://www.hl7.org/login/singlesignon.cfm?next=/documentcenter/private/standards/cda/Trifolia_HL7_Consolidation_20110712-dist.zip

http://www.hl7.org/login/singlesignon.cfm?next=/documentcenter/private/standards/cda/Trifolia_HL7_Consolidation_20110712-dist.zip

http://www.lantanagroup.com/newsroom/press-releases/trifolia-workbench/

http://www.lantanagroup.com/newsroom/press-releases/trifolia-workbench/

http://www.hl7.org/special/committees/terminfo/index.cfm

http://www.tabers.com/

http://www.jointcommission.org/NR/rdonlyres/C9298DD0-6726-4105-A007-FE2C65F77075/0/CMS_New_Revised_HAP_FINAL_withScoring.pdf



APPENDIX A — ACRONYMS AND ABBREVIATIONSADL Activities of Daily LivingAMA American Medical AssociationCCD Continuity of Care DocumentCDA Clinical Document ArchitectureCRS Care Record SummaryDICOM Digital Imaging and Communications in MedicineDIR Diagnostic Imaging ReportEHR electronic health recordDSTU Draft Standard for Trial UseH&P History and PhysicalHIMSS Healthcare Information and Management Systems SocietyHIT healthcare information technologyHITECH Health Information Technology for Economic and Clinical HealthHITSP Health Information Technology Standards PanelHL7 Health Level SevenHHS U.S. Department of Health and Human ServicesHTML Hypertext Markup LanguageIG implementation guideIHE Integrating the Healthcare EnterpriseIHTSDO International Health Terminology Standard Development OrganisationLOINC Logical Observation Identifiers Names and CodesMDHT Model-Driven Health ToolsMIME Multipurpose Internet Mail ExtensionsNPP non-physician providersNUCC Healthcare Provider Taxonomy CodeONC Office of National CoordinatorPCP primary care providerPDF portable document formatPHCR Public Health case reportsPHR personal health recordPPRF primary performers

RIM Reference Information Model RTF rich text formatS&I Standards and InteroperabilitySCOORD Spatial CoordinatesSDWG Structured Documents Working GroupSDO Standards Development OrganizationSNOMED CT Systemized Nomenclature for Medicine – Clinical TermsSOP Service Object PairSR Structured ReportTdb Template Database TIFF tagged-image file formatUCUM Unified Code for Units of MeasureUD Unstructured DocumentUDI Unique Device IdentificationUML Unified Modeling LanguageURL Uniform Resource LocatorVIS Vaccine Information StatementWADO Web Access to Persistent DICOM ObjectsXPath XML Path Language

APPENDIX B — ADDITIONAL EXAMPLES This appendix contains various examples of use from this guide.

Names

Figure 78: Correct use of name example 1

<name><given>John</given><given>Q.</given><family>Doe</family></name>

The name element in CDA contains mixed content. In XML, this means that name can contain a mix of character data and element markup in any order. The consequence of this is that all whitespace is significant, thus tab characters, carriage returns, space characters, etc. all become “part” of the person’s name.

Figure 79: Incorrect use of name example 1 - whitespace

<name><given>John</given><given>Q.</given><family>Doe</family>

</name>

Figure 80: Incorrect use of Patient name example 2 - no tags

<name>John Q. Doe</name>

Addresses

Figure 81: Correct use telecom address example

<telecom use="WP" value="tel:555-555-1212"/>

Figure 82: Correct use postal address example

<addr use="H"><streetAddressLine>17 Daws Rd.</streetAddressLine><city>Blue Bell</city><state>MA</state><postalCode>02368</postalCode><country>US</country></addr>

Time

Figure 83: Correct use of IVL_TS example

<effectiveTime><low value='20110907'/><high value='20110909'/>

</effectiveTime>

Figure 84: Correct use of TS with precision to minute example

<effectiveTime value='201109071023'/>

Figure 85: Correct use of TS with timezone offset example

<effectiveTime value='201109071023-0500'/>

Figure 86: Incorrect use of IVL_TS example


Figure 87: Incorrecet use of TS - insufficient precision example

<effectiveTime value='20110907'/> (must be precise to the minute)

Figure 88: Incorrect use of TS when timezone offset required example


Use of effectiveTime with timezone where not relevant (precise only to the day)

Figure 89: Incorrrect use of timezone offset - not enough precision example

<effectiveTime value="20110907-0500'/>

CD

Figure 90: Correct use of CD with no code - example

<code nullFlavor='NI'><originalText><reference value='#problem-1'/></originalText>

</code>

Figure 91: Incorrect use of CD with no code - missing nullFlavor attribute example

<code><originalText><reference value='#problem-1'/></originalText>

</code>

MRRT 8.1.6.1

1. The coded_content element may contain zero or more [0..*] entry elements.a. The opening tag of each entry element shall contain an ORIGTXT attribute

whose value matches the id attribute of an element in the body to which the coded content in the entry applies.

b. Field <label> <input> or <select> may contain attribute that identifies the output CDA template

c. The <term> May contain an attribute slot that identifies the slot in the associated CDA template where the value is to be plunked