Diagnostic Imaging Report



Digital Imaging and Communications in Medicine (DICOM)Supplement 155: Imaging Reports using HL7 Clinical Document Architecture (revision and replacement of PS3.20)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 USAVERSION: Draft 2014-06-20Developed in accordance with: DICOM Workitem 2010-04-D Open issuesUse of Accession Numbers and Order Placer Numbers and Order Filler Number in inFulfillmentOf in header (section 8.2.3) – do they need identifiers to distinguish each use?Do we need specific Conformance requirements in Part 2? Are the conformance requirements in Section 6 adequate?Do we need an Implementation Technology Specification for the data types used in the template public interfaces?Style of specification for template – tabular, or conformance statements, or both?Any reason for section.id to be mandatory? Used at all?Is it clear from the business names that Contrast Administered is in Procedural Medications?Radiology Recommendations was kept as a separate section within Impressions to be able to label it as such. Is this necessary? PCPs interviewed said they want the emphasis as a teaching tool as well as just to highlight the recommendation so that they do not miss it.Relationship to DICOM SR: 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?Imaging Header, Sec 8.2: Coarse Anatomic Region- IHE RAD CP 248 and the Canadian SCWG have the concept of a “coarse anatomic region” in image and report headers to help to search, organize, and pre-fetch information. Should it be adopted and included here? If not, how can this problem be addressed?Imaging Header, Sec 8.2: Irradiating Authorizing Agent (IrradiationAuthorizingID)– does the id need to also be in the imaging header or is sufficient to be in the Radiation Section of the document itself?Sec 8.2.4: “documentationOf Service Event and Performer”: clarify who the Performer isSec 8.2.10: “Authenticator:- do we need Authenticator in the radiology reports?Sec 9.2: Clinical Inforamtion Section: Do we need more detailed entries for current medications / meds held prior to exam?Sec 9.2: Clinical Inforamtion Section: Should the Adverse Events section be reduced to an entry which for pre-established contrast/sedation contraindication?Sec 9.4: Comparison Study Section: How do we want to reference a study with its StudyInstanceUID / procedureCode / performedLocation? / date? Do we need link to prior report?Section 9.8.1: Adverse Events Section: Check 2.16.840.1.113883.3.88.12.3221.6.2 (Allergy/Adverse Event Type) does not contain appropriate codesSec 9.8.4.1: text element of Key Images Section: From C-CDA. Is this what we want? Or doe we want attested inline image using observationMedia?Sec 9.8.6: OBUS Fetus Findings: Note that LOINC section code includes US concept. Is this too limiting? Or is this the only practical OB modality?Sec 10.3: Procedural Medications Entry: Duplicate and simplify with “contrast” business namesSec 10.7: Series Act Entry: do we just want to use modality as act.code?App A: Summary of Business Names: needs to be completed/updated after everything else is doneAll Figure and Table numbers need to be updated when this document content is “done”.Does the MRRT discussion get lost when this is no longer a Supplement with the Supplement Intro? I think that is a huge mistake.Add a complete example as an appendix.Should all Value Sets be moved to Part 16?Clean up all DIR referencesClosed issuesArbitrary block of measurements from measurement app put into a CDA section. (D. Rubin) Resolution: just put into Findings, or into user-labeled subsectionTable of Contents TOC \o "1-4" \h \z \u Open issues PAGEREF _Toc391404391 \h 2Closed issues PAGEREF _Toc391404392 \h 3Table of Tables PAGEREF _Toc391404393 \h 10Acknowledgments PAGEREF _Toc391404394 \h 10Introduction to Supplement 155 PAGEREF _Toc391404395 \h 11CDA and Implementation Guides PAGEREF _Toc391404396 \h 11Templates PAGEREF _Toc391404397 \h 12Imaging Report Templates for CDA PAGEREF _Toc391404398 \h 12Use with RSNA RadReport and IHE MRRT PAGEREF _Toc391404399 \h 13Structures provided by this Supplement PAGEREF _Toc391404400 \h 13Relationship to DICOM SR PAGEREF _Toc391404401 \h 141Scope and Field of Application PAGEREF _Toc391404402 \h 162Normative and Informative References PAGEREF _Toc391404403 \h 173Definitions PAGEREF _Toc391404404 \h 193.1Codes and Controlled Terminology Definitions PAGEREF _Toc391404405 \h 194Symbols and Abbreviations PAGEREF _Toc391404406 \h 205Conventions PAGEREF _Toc391404407 \h 225.1Template metadata PAGEREF _Toc391404408 \h 225.1.1Template IDs and Version PAGEREF _Toc391404409 \h 225.1.2Open and Closed Templates PAGEREF _Toc391404410 \h 225.2Template Table Structure PAGEREF _Toc391404411 \h 235.2.1Business names PAGEREF _Toc391404412 \h 235.2.2Nesting level PAGEREF _Toc391404413 \h 245.2.3Element /Attribute Names and XPath Notation PAGEREF _Toc391404414 \h 245.2.4Cardinality PAGEREF _Toc391404415 \h 255.2.5Conformance Verbs PAGEREF _Toc391404416 \h 255.2.6Data Type PAGEREF _Toc391404417 \h 265.2.7Values / Vocabulary Conformance PAGEREF _Toc391404418 \h 265.2.8Invocation of Subsidiary Templates PAGEREF _Toc391404419 \h 275.2.8.1Vocabulary Binding And Constraints PAGEREF _Toc391404420 \h 275.2.9Additional Requirements PAGEREF _Toc391404421 \h 275.3Encoding PAGEREF _Toc391404422 \h 285.3.1translation PAGEREF _Toc391404423 \h 285.3.2Null Flavor PAGEREF _Toc391404424 \h 285.3.3Unknown Information PAGEREF _Toc391404425 \h 295.3.4XML ID and multiple element instantiations PAGEREF _Toc391404426 \h 316Conformance PAGEREF _Toc391404427 \h 326.1As a Creator PAGEREF _Toc391404428 \h 326.2As a Receiver PAGEREF _Toc391404429 \h 326.2.1Rendering Header Information for Human Presentation PAGEREF _Toc391404430 \h 327Document-Level Templates PAGEREF _Toc391404431 \h 337.1Imaging Report PAGEREF _Toc391404432 \h 337.1.1clinicalDocument/code PAGEREF _Toc391404433 \h 357.1.2Addendum PAGEREF _Toc391404434 \h 377.1.3Clinical Statements PAGEREF _Toc391404435 \h 377.2Interventional Radiology Report (reserved) PAGEREF _Toc391404436 \h 377.3Anatomic Pathology Report (reserved) PAGEREF _Toc391404437 \h 378Header Content Modules PAGEREF _Toc391404438 \h 388.1General Header Constraints PAGEREF _Toc391404439 \h 388.1.1effectiveTime PAGEREF _Toc391404440 \h 408.1.2recordTarget PAGEREF _Toc391404441 \h 408.1.3recordTarget/patientRole/Patient/birthTime PAGEREF _Toc391404442 \h 418.1.4LegalAuthenticator PAGEREF _Toc391404443 \h 438.1.5Author (Person) PAGEREF _Toc391404444 \h 448.1.6Custodian PAGEREF _Toc391404445 \h 458.2Imaging Header PAGEREF _Toc391404446 \h 458.2.1componentOf/encompassingEncounter PAGEREF _Toc391404447 \h 488.2.2Physician of Record Participant PAGEREF _Toc391404448 \h 498.2.3inFulfillmentOf/Order PAGEREF _Toc391404449 \h 508.2.4documentationOf Service Event and Performer PAGEREF _Toc391404450 \h 508.2.5Physician Reading Study Performer PAGEREF _Toc391404451 \h 528.2.6Irradiation Authorizing Performer PAGEREF _Toc391404452 \h 538.2.7DataEnterer PAGEREF _Toc391404453 \h 538.2.8InformationRecipient PAGEREF _Toc391404454 \h 548.2.9Participant (Referrer) PAGEREF _Toc391404455 \h 558.2.10Authenticator PAGEREF _Toc391404456 \h 558.3Parent Document PAGEREF _Toc391404457 \h 559Section-Level Templates PAGEREF _Toc391404458 \h 579.1General requirements for section/text PAGEREF _Toc391404459 \h 579.1.1<content> markup and links from entries PAGEREF _Toc391404460 \h 579.1.2<renderMultiMedia> markup and graphical content PAGEREF _Toc391404461 \h 589.1.3<linkHtml> markup and external references PAGEREF _Toc391404462 \h 589.1.4<linkHtml> markup and image references PAGEREF _Toc391404463 \h 589.2Clinical Information PAGEREF _Toc391404464 \h 599.3Imaging Procedure Description PAGEREF _Toc391404465 \h 609.3.1component/section Radiation Exposure and Protection Information PAGEREF _Toc391404466 \h 629.4Comparison Study PAGEREF _Toc391404467 \h 629.5Findings PAGEREF _Toc391404468 \h 649.5.1text PAGEREF _Toc391404469 \h 659.6Impressions PAGEREF _Toc391404470 \h 659.7Addendum PAGEREF _Toc391404471 \h 679.7.1section/@ID PAGEREF _Toc391404472 \h 689.7.2author PAGEREF _Toc391404473 \h 689.8Sub-sections PAGEREF _Toc391404474 \h 699.8.1General Section Entries PAGEREF _Toc391404475 \h 699.8.2Request PAGEREF _Toc391404476 \h 709.8.3Procedure Indications PAGEREF _Toc391404477 \h 729.8.4Medical (General) History PAGEREF _Toc391404478 \h 739.8.5Complications Section PAGEREF _Toc391404479 \h 749.8.6Radiation Exposure and Protection Information PAGEREF _Toc391404480 \h 769.8.6.1text PAGEREF _Toc391404481 \h 789.8.6.2entry/observation SOP Instance PAGEREF _Toc391404482 \h 789.8.6.3entry/observation Pregnancy PAGEREF _Toc391404483 \h 789.8.6.4entry/observation Indication PAGEREF _Toc391404484 \h 789.8.6.5entry/observation Dose measurements PAGEREF _Toc391404485 \h 799.8.7Key Images PAGEREF _Toc391404486 \h 809.8.7.1section/text PAGEREF _Toc391404487 \h 819.8.7.2SOP Instance Observation PAGEREF _Toc391404488 \h 819.8.7.3observationMedia PAGEREF _Toc391404489 \h 819.8.8DICOM Object Catalog PAGEREF _Toc391404490 \h 829.8.9OBUS Fetus Findings PAGEREF _Toc391404491 \h 849.8.9.1section/@ID PAGEREF _Toc391404492 \h 869.8.9.2FetusID PAGEREF _Toc391404493 \h 869.8.10Labeled Subsection PAGEREF _Toc391404494 \h 879.8.10.1title PAGEREF _Toc391404495 \h 889.8.11Communication of Actionable Results PAGEREF _Toc391404496 \h 889.8.11.1Communication of and Categories of Actionable Findings PAGEREF _Toc391404497 \h 899.8.12Radiology Recommendation PAGEREF _Toc391404498 \h 919.8.12.1entry/procedure and @ID PAGEREF _Toc391404499 \h 929.8.12.2entry/procedure/effectiveTime PAGEREF _Toc391404500 \h 9210Entry-level Templates PAGEREF _Toc391404501 \h 9410.1Coded Observation PAGEREF _Toc391404502 \h 9410.1.1observation/@ID PAGEREF _Toc391404503 \h 9610.1.2text/reference/@value and Related Narrative Block Markup PAGEREF _Toc391404504 \h 9610.2Actionable Results Urgency PAGEREF _Toc391404505 \h 9710.3Procedural Medication PAGEREF _Toc391404506 \h 9910.3.1text/reference/@value and Related Narrative Block Markup PAGEREF _Toc391404507 \h 10110.3.2doseQuantity PAGEREF _Toc391404508 \h 10210.4observationMedia PAGEREF _Toc391404509 \h 10310.4.1observationMedia/@ID and Related Narrative Block Markup PAGEREF _Toc391404510 \h 10410.4.2image and reference PAGEREF _Toc391404511 \h 10410.5Procedure Technique PAGEREF _Toc391404512 \h 10410.5.1id PAGEREF _Toc391404513 \h 10610.5.2code PAGEREF _Toc391404514 \h 10610.5.3methodCode PAGEREF _Toc391404515 \h 10610.5.4targetSiteCode PAGEREF _Toc391404516 \h 10610.6Quantity Measurement PAGEREF _Toc391404517 \h 10710.6.1observation/@ID PAGEREF _Toc391404518 \h 10910.6.2text/reference/@value and Related Narrative Block Markup PAGEREF _Toc391404519 \h 10910.7Study Act PAGEREF _Toc391404520 \h 11010.7.1act/@ID PAGEREF _Toc391404521 \h 11110.8Series Act PAGEREF _Toc391404522 \h 11210.8.1act/@ID PAGEREF _Toc391404523 \h 11310.9SOP Instance Observation PAGEREF _Toc391404524 \h 11410.9.1observation/@ID PAGEREF _Toc391404525 \h 11610.9.2entryRelationship PAGEREF _Toc391404526 \h 11710.9.2.1entryRelationship/@typeCode=SUBJ (SOP Instance) PAGEREF _Toc391404527 \h 11710.9.2.2entryRelationship/@typeCode=RSON (Purpose of Reference) PAGEREF _Toc391404528 \h 11710.9.2.1entryRelationship/@typeCode=COMP (Referenced Frames) PAGEREF _Toc391404529 \h 117Appendix A —Summary of Business Names PAGEREF _Toc391404530 \h 119Appendix B —Additional Examples PAGEREF _Toc391404531 \h 120Names PAGEREF _Toc391404532 \h 120Addresses PAGEREF _Toc391404533 \h 120Time PAGEREF _Toc391404534 \h 121CD PAGEREF _Toc391404535 \h 121Appendix C —Mapping DICOM SR to CDA PAGEREF _Toc391404536 \h 123Table of Figures TOC \c "Figure" Figure 1: XML document example PAGEREF _Toc264812235 \h 22Figure 2: Template element / and attribue example PAGEREF _Toc264812236 \h 22Figure 3: XPath expression example PAGEREF _Toc264812237 \h 23Figure 5: Translation code example PAGEREF _Toc264812238 \h 26Figure 6: nullFlavor example PAGEREF _Toc264812239 \h 27Figure 8: XML example of allowed nullFlavors when element is required PAGEREF _Toc264812240 \h 27Figure 10: Unknown medication example PAGEREF _Toc264812241 \h 28Figure 11: Unkown medication use of anticoagulant drug example PAGEREF _Toc264812242 \h 28Figure 12: No known medications example PAGEREF _Toc264812243 \h 29Figure 16: DIR ClinicalDocument/code example PAGEREF _Toc264812244 \h 36Figure 17: use of the translation element to include local codes for document type PAGEREF _Toc264812245 \h 36Figure 18: header example PAGEREF _Toc264812246 \h 40Figure 19: recordTarget example PAGEREF _Toc264812247 \h 41Figure 20: legalAuthenticator example PAGEREF _Toc264812248 \h 43Figure 21: Person author example PAGEREF _Toc264812249 \h 43Figure 22: Custodian example PAGEREF _Toc264812250 \h 44Figure 23: componentOf example PAGEREF _Toc264812251 \h 48Figure 24: Physician of record participant example PAGEREF _Toc264812252 \h 48Figure 25: DIR inFulfillmentOf example PAGEREF _Toc264812253 \h 49Figure 26: DIR procedure context (CDA Header) illustration (non-normative) PAGEREF _Toc264812254 \h 50Figure 27: documentationOf example PAGEREF _Toc264812255 \h 51Figure 28: Physician reading study performer example PAGEREF _Toc264812256 \h 52Figure 29: dataEnterer example PAGEREF _Toc264812257 \h 53Figure 30: informationRecipient example PAGEREF _Toc264812258 \h 53Figure 31: participant example PAGEREF _Toc264812259 \h 54Figure 32: Authenticator example PAGEREF _Toc264812260 \h 54Figure 33: DIR relatedDocument example PAGEREF _Toc264812261 \h 55Figure 38: WADO reference using linkHtml example PAGEREF _Toc264812262 \h 58Figure 35: Clinical Information section example PAGEREF _Toc264812263 \h 59Figure 36: Current Imaging Procedure description section example PAGEREF _Toc264812264 \h 61Figure 37: Comparison study section example PAGEREF _Toc264812265 \h 62Figure 37: Findings section example PAGEREF _Toc264812266 \h 64Figure 39: Impressions section example PAGEREF _Toc264812267 \h 66Figure 40: Addendum section example PAGEREF _Toc264812268 \h 68Figure 90: Observer context example PAGEREF _Toc264812269 \h 69Figure 42: Request section example PAGEREF _Toc264812270 \h 71Figure 43: Procedure indications section example PAGEREF _Toc264812271 \h 72Figure 44: Adverse Events section example PAGEREF _Toc264812272 \h 73Figure 45: Complications section example PAGEREF _Toc264812273 \h 74Figure 46: Radiation Exposure and Protection section example PAGEREF _Toc264812274 \h 78Figure 48: Key Images section example PAGEREF _Toc264812275 \h 80Figure 49: DICOM object catalog section example PAGEREF _Toc264812276 \h 82Figure 50: OBUS Fetus Findings section example PAGEREF _Toc264812277 \h 84Figure 51: Labeled sub-section example PAGEREF _Toc264812278 \h 86Figure 52: Communication of Actionable Results section example PAGEREF _Toc264812279 \h 89Figure 53: Radiology recommendation section example PAGEREF _Toc264812280 \h 90Figure 58: Coded observation example PAGEREF _Toc264812281 \h 93Figure 56: Procedural Medication activity example PAGEREF _Toc264812282 \h 98Figure 70: Procedure Technique template example PAGEREF _Toc264812283 \h 102Figure 76: Quantity measurement observation example PAGEREF _Toc264812284 \h 104Figure 83: Series act example PAGEREF _Toc264812285 \h 107Figure 86: SOP instance observation example PAGEREF _Toc264812286 \h 109Figure 75: Purpose of reference example PAGEREF _Toc264812287 \h 110Figure 87: Study act example PAGEREF _Toc264812288 \h 112Figure 91: Correct use of name example 1 PAGEREF _Toc264812289 \h 114Figure 92: Incorrect use of name example 1 - whitespace PAGEREF _Toc264812290 \h 114Figure 93: Incorrect use of Patient name example 2 - no tags PAGEREF _Toc264812291 \h 114Figure 94: Correct use telecom address example PAGEREF _Toc264812292 \h 114Figure 95: Correct use postal address example PAGEREF _Toc264812293 \h 114Figure 96: Correct use of IVL_TS example PAGEREF _Toc264812294 \h 115Figure 97: Correct use of TS with precision to minute example PAGEREF _Toc264812295 \h 115Figure 98: Correct use of TS with timezone offset example PAGEREF _Toc264812296 \h 115Figure 99: Incorrect use of IVL_TS example PAGEREF _Toc264812297 \h 115Figure 100: Incorrecet use of TS - insufficient precision example PAGEREF _Toc264812298 \h 115Figure 101: Incorrect use of TS when timezone offset required example PAGEREF _Toc264812299 \h 115Figure 102: Incorrrect use of timezone offset - not enough precision example PAGEREF _Toc264812300 \h 115Figure 103: Correct use of CD with no code - example PAGEREF _Toc264812301 \h 115Figure 104: Incorrect use of CD with no code - missing nullFlavor attribute example PAGEREF _Toc264812302 \h 116Table of Tables TOC \c "Table" Table 1: DIR LOINC Document Type Codes PAGEREF _Toc264812303 \h 35Table 2: Basic Confidentiality Kind Value Set PAGEREF _Toc264812304 \h 39Table 3: Language Value Set (excerpt) PAGEREF _Toc264812305 \h 40Table 4: Administrative Gender (HL7) Value Set PAGEREF _Toc264812306 \h 41Table 5: Radiation Exposure Quantities Value Set PAGEREF _Toc264812307 \h 78Table 18: Coded Observation Constraints Overview PAGEREF _Toc264812308 \h 92Table 19: Critical Result Priority Value Set PAGEREF _Toc264812309 \h 95Table 9: Procedural Medication Activity Constraints PAGEREF _Toc264812310 \h 96Table 10: Unit of Measure Value Set (excerpt) PAGEREF _Toc264812311 \h 98Table 23: imageMediaTypes PAGEREF _Toc264812312 \h 100Table 32: Procedure Technique Constraints Overview PAGEREF _Toc264812313 \h 101Table 47: Quantity Measurement Observation Constraints Overview PAGEREF _Toc264812314 \h 103Table 55: Series Act Contexts PAGEREF _Toc264812315 \h 105Table 56: Series Act Constraints Overview PAGEREF _Toc264812316 \h 106Table 64: Sop Instance Observation Constraints Overview PAGEREF _Toc264812317 \h 108Table 46: DICOM Purpose of Reference Value Set PAGEREF _Toc264812318 \h 110Table 65: Study Act Contexts PAGEREF _Toc264812319 \h 110Table 66: Study Act Constraints Overview PAGEREF _Toc264812320 \h 111AcknowledgmentsThis 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? (). This material contains content from LOINC? (). 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 to Supplement 155This 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) Standard.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 for CDA. Its scope is therefore limited primarily to radiology diagnostic imaging (including screening exams), and some interventional radiology and cardiology (where clinicans may deem the templates appropriate). Future work may include in scope anatomic pathology or other imaging procedures, as well as templates with more required discrete data element content.DICOM and ReportingReporting has been a significant part of the DICOM standards development program since work on Supplement 23: Structured Reporting began in 1995. That Supplementdefined a report encoding based on the classical DICOM attributes and data elements specified in DICOM Part 5, with templates specified in Part 16. There was substantial discussion during the development of Supplement 23 as to whether reports should be encoded using XML, at that time not yet a widely deployed technology.While DICOM Structured Reporting has an established place in the encoding of image analysis results, or “evidence documents”, it has seen only limited use for clinical reports. The clinical report production and distribution environment has not been amenable to the use of classical DICOM object and data element encoding.The DICOM Standards Committee in 2010 decided to approve a Work Item for an approach to reporting based on CDA. The DICOM Standards Committee, as the premier worldwide collaboration between imaging-related professional societies and the imaging industry, was agred as the appropriate organization to produce CDA Implementation Guides and Templates for specific clinical imaging use cases.CDA and Implementation GuidesThe HL7 Clinical Document Architecture has emerged as the industry consensus standard for the formatting of clinical reports across all medical disciplines. 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 Structured Reporting 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 RMIM) 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 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 CDA72390016510000This 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 greenCDA 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.98742543053000Figure - Process flow using CDA Report Templates, MRRT, and RSNA TemplatesUse with RSNA RadReport and IHE MRRT This work is complementary to and coordinated with the RSNA Radiology Reporting (RadReport) initiative and the IHE Management of Radiology Report Templates (MRRT) Profile. 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.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.PS3.20 - Imaging Reports using HL7 Clinical Document ArchitectureScope and Field of ApplicationThis part of the DICOM Standard specifies templates for the encoding of imaging reports using the HL7 Clinical Document Architecture Release 2 (CDAr2, or simply CDA) Standard. Within this scope are clinical procedure reports for all specialties that use imaging for screening, diagnostic, or therapeutic purposes.This Part constitutes an implementation guide for CDA, and is harmonized with the approach to standardized templates for CDA implementation guides developed by HL7.It also follows the approach of HL7 greenCDA, providing “business names” for data elements that link data in user terminology, e.g., collected by a report authoring application, to specific CDA encoded elements.As an implementation guide for imaging reports, particular attention is given to the use and reference of data collected in imaging procedures as explicit evidence within reports.This data includes images, waveforms, measurements, annotations, and other analytic results managed as DICOM SOP Instances. Specifically, the Part inclues a specification for transformation of certain DICOM Structured Report instances into CDA documents.Normative and Informative ReferencesThe following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.ISO/IEC Directives, Part 2ISO/IEC Directives, Part 2 - Rules for the structure and drafting of International Standards - Sixth edition, 2011ANSI/HL7 CDA?, R2-2005HL7 Version 3 Standard: Clinical Document Architecture (CDA) Release 2, 2005.CDA? is a registered trademark of HL7 International.ANSI/HL7 V3 CPPV3MODELS, R1-2012HL7 Version 3 Standard: Core Principles and Properties of Version 3 Models, Release 1ANSI/HL7 V3 CMET, R2-2009Health Level Seven Version 3 Standard: Common Message Element Types, Release 2, 2009.ANSI/HL7 V3 DT, R1-2004HL7 Version 3 Data Types Abstract Specification, Release 1 – November 2004. [Note: this specific release version is required by CDA R2]ANSI/HL7 V3 XMLITSDT, R1-2004HL7 Version 3 XML Implementation Technology Specification - Data Types, Release 1 – April 2004. [Note: this specific release version is required by CDA R2]HL7 CDA R2 DIR IG, R1-2009Health Level Seven Implementation Guide for CDA Release 2: Imaging Integration, Basic Imaging Reports in CDA and DICOM, Diagnostic Imaging Reports (DIR) Release 1.0 – Informative, 2009.HL7 CDAR2_IG_IHE_CONSOL HL7 Implementation Guide for CDA? Release 2: IHE Health Story Consolidation, Release 1.1 - US Realm, Draft Standard for Trial Use, July 2012 ()HL7 CDAR2_IG_GREENMOD4CCD HL7 Implementation Guides for CDA? R2: greenCDA Modules for CCD?, Release 1 – Informative, April 2011 ()HL7 v3-2014HL7 Version 3 Interoperability Standards, Normative Edition 2014. (] LOINC Logical Observation Identifier Names and Codes, Regenstrief Institute, Indianapolis 2013.This product includes all or a portion of the LOINC? table, LOINC panels and forms file, LOINC document ontology file, and/or LOINC hierarchies file, or is derived from one or more of the foregoing, subject to a license from Regenstrief Institute, Inc. Your use of the LOINC table, LOINC codes, LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file also is subject to this license, a copy of which is available at?. The current complete LOINC table, LOINC Users' Guide, LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file are available for download at?. The LOINC table and LOINC codes are copyright ? 1995-2013, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee. The LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file are copyright ? 1995-2013, Regenstrief Institute, Inc. All rights reserved. THE LOINC TABLE (IN ALL FORMATS), LOINC PANELS AND FORMS FILE, LOINC DOCUMENT ONTOLOGY FILE, AND LOINC HIERARCHIES ARE PROVIDED "AS IS."? ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. LOINC? is a registered United States trademark of Regenstrief Institute, Inc. A small portion of the LOINC table may include content (e.g., survey instruments) that is subject to copyrights owned by third parties. Such content has been mapped to LOINC terms under applicable copyright and terms of use. Notice of such third party copyright and license terms would need to be included if such content is included.RFC 3066 Tags for the Identification of Languages, Internet Engineering Task ForceSNOMED CT? Systematized Nomenclature of Medicine - Clinical Terms, International Release, International Health Terminology Standards Development Organisation (IHTSDO), January 2013SNOMED CT is a registered trademark of the International Health Terminology Standard Development Organisation (IHTSDO).UCUM Unified Code for Units of Measure, Regenstrief Institute, Indianapolis 2013.This product includes all or a portion of the UCUM table, UCUM codes, and UCUM definitions or is derived from it, subject to a license from Regenstrief Institute, Inc. and The UCUM Organization. Your use of the UCUM table, UCUM codes, UCUM definitions also is subject to this license, a copy of which is available at . The current complete UCUM table, UCUM Specification are available for download at . The UCUM table and UCUM codes are copyright ? 1995-2013, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved.THE UCUM TABLE (IN ALL FORMATS), UCUM DEFINITIONS, AND SPECIFICATION ARE PROVIDED "AS IS." ANY EXPRESS OR IMPLIED WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.XML Extensible Markup Language (XML) 1.0 (Fifth Edition), World Wide Web Consortium, 2008 () xml:idxml:id Version 1.0, World Wide Web Consortium, 2005 () XPathXML Path Language (XPath), Version 1.0, World Wide Web Consortium, 1999 () DefinitionsFor the purposes of this Standard the following definitions apply.Codes and Controlled Terminology DefinitionsThe following terms used in this Part of the DICOM Standard are defined in PS3.16:Context GroupA set of coded concepts defined by a Mapping Resource forming a set appropriate to use in a particular context.Context ID (CID)Identifier of a Context Group.TemplateA pattern that describes the Content Items, Value Types, Relationship Types and Value Sets that may be used in part of a Structured Report content tree, or in other Content Item constructs, such as Acquisition Context or Protocol Context. Analogous to a Module of an Information Object Definition.Template ID (TID)Identifier of a Template.Coding SchemesDictionaries (lexicons) of concepts (terms) with assigned codes and well defined meanings.Symbols and AbbreviationsThe following symbols and abbreviations are used in this Part of the Standard.ANSIAmerican National Standards InstituteCDAClinical Document Architecture (HL7)DICOMDigital Imaging and Communications in MedicineHL7Health Level 7HMDHierarchical Message Description (HL7)IHEIntegrating the Healthcare EnterpriseIODInformation Object DefinitionISOInternational Standards OrganizationLOINCLogical Observation Identifiers Names and CodesMRRTIHE Management of Radiology Report Templates ProfileNEMANational Electrical Manufacturers AssociationOIDObject Identifier (ISO 8824)SNOMEDSystematized Nomenclature of MedicineSRStructured ReportingUCUMUnified Code for Units of MeasureUIDUnique IdentifierXMLExtensible Markup LanguageADPostal Address (HL7 v3 Data Type)CECoded With Equivalents (HL7 v3 Data Type)CDConcept Descriptor (HL7 v3 Data Type)CSCoded Simple Value (HL7 v3 Data Type)EDEncapsulated Data (HL7 v3 Data Type)ENEntity Name (HL7 v3 Data Type)IIInstance Identifier (HL7 v3 Data Type)INT Integer Number (HL7 v3 Data Type)OIDISO Object Identifier (HL7 v3 Data Type)ONOrganization Name (HL7 v3 Data Type)PNPerson Name (HL7 v3 Data Type)PQPhysical Quantity (HL7 v3 Data Type)STCharacter String (HL7 v3 Data Type)TELTelecommunication Address (HL7 v3 Data Type)TSPoint in Time (HL7 v3 Data Type)UIDUnique Identifier String (HL7 v3 Data Type)ConventionsTemplate metadataEach template has a set of metadata, as specified in the HL7 Templates Specification. The metadata is presented as a table, as shown below.Template ID OIDNameEffective DateVersion LabelStatus“draft”, “active”, “review” or “retired”Description Classificationtype of the template, e.g. CDA Section LevelRelationships relationships to other templates or model artifactsContextOpen/ClosedRevision HistoryTemplate IDs and VersionTemplate 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.A template may be further qualified by a version label. This label may be used as the extension attribute of the templateId (e.g., @extension="20150309"). Note that the version label is typically not used as a conformance constraint, to allow both creators and recivers to adapt to evolution in the templates.Open and Closed TemplatesIn open templates, all of the features of the CDA 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.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. Template Table StructureEach template is specified in tabular form, as shown below.NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValueSubsidiary TemplateScopingBusinessName ElementBusinessNameReferencedBusinessNameBusiness namesThis Part uses “business names”, as described in the greenCDA specification, to more easily and consistently identify and map common data elements from imaging reports into the proper context-specific CDA/XML structure.In this guide, the business names are represented in camelCase (alternating upper and lower case, no spaces) in the Name column of the template tables. Business names are hierarchically organized, and contextually scoped by higher level business names. Data element level business names are shown in normal font, while business names that provide scoping for data elements are shown in bold font. Referenced business names from included templates are shown in italic (see section 5.2.9)Examples:The top level scoping business name is “ImagingReport”The business name for the text element of the Clinical Information report section is “ImagingReport:ClinicalInformation:Text”The business name for the text element of the Impressions section is “ImagingReport:Impressions:Text”Note that both Clinical Information and Impressions define a business name “Text”, but these are distinguished by their hierarchical locationA summary of all of the business names are given in Appendix A of this document.The formal specification of business names is intended to facilitate the implementation of production logic for report authoring applications to interact with a report formatting application. That production logic would captures the business content of the report, with minimal regard to the encoding in CDA. The use of business names or the specification of such production logic is outside the scope of this Standard.Nesting levelCDA documents are encoded using the Extensible Markup Language (XML), and are marked up through hierarchically nested XML elements (tags). The Nesting Level column of the template tables identifies the hierarchical level of each element relative to the other elements in the table using the character right angle bracket ‘>’.XML elements may have attributes, encoded as name=value pairs within the element tag. Such attributes are identified using the character at sign ‘@’.Element /Attribute Names and XPath Notation The name of each XML element and attribute used in a CDA document for which specific constraints are applied is shown in the Element/Attribute column of the template tables. Elements and attributes that use the default value specified in CDA Specification are not shown. For example, the Section element has default attributes classCode='DOCSECT' and moodCode='EVN'; these are not listed in the templates.XML Path Language (XPath) notation is used in this Standard to identify the XML elements and attributes within the CDA document instance to which various constraints are applied. The implicit context of these expressions is the root of the document. This notation provides a mechanism that will be familiar to developers for identifying parts of an XML document.Xpath statements appear in this Part 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. Following is an example of a fragment of a CDA document.Figure SEQ Figure \* ARABIC 1: XML document example<author><assignedAuthor>...<code codeSystem='2.16.840.1.113883.6.96' codeSystemName='SNOMED CT' code='17561000' displayName='Cardiologist' />...</assignedAuthor></author>Following is an example of a fragment of a template specification table that defines the document fragment.Figure SEQ Figure \* ARABIC 2: Template element / and attribue example…Nest LevelElement/ Attribute…author> assignedAuthor…>> code>>@ @code…In the above example, the code attribute of the code element could be selected with the XPath expression in the next figure.Figure SEQ Figure \* ARABIC 3: XPath expression exampleauthor/assignedAuthor/code/@codeCardinality 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 one1..* at least one 0..* zero or more1..n at least one and not more than nThe 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] or [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] or [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. Conformance Verbs Each element / attribute has a conformance verb (keyword) in addition to the cardinality constraint.The keywords shall, should, may, should not, shall not, and NEED not in this document are to be interpreted as described in ISO/IEC Directives, Part 2, Annex H “Verbal forms for the expression of provisions”:shall: an absolute requirementshall not: an absolute prohibition against inclusionshould/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 coursemay/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.Within the template, the keyword cond (conditional) may be present. In this case, the specification of the condition, and the conformance verbs associated with the condition being true or false, are described below the table.In an open template, additional elements and attributes allowed by the CDA Specification are not precluded by template constraints, unless there are applicable shall not template specifications.Data TypeThe data type associated with each element / attribute is specified, as described in the CDA Specification.Many data types are non-primitive, and may specify constituent component elements and/or attributes. Such subsidiary components are specified in the templates if specific constraints are to be applied to them.Values / Vocabulary Conformance The template table may specify specific values or vocabularies to be used with an element or attribute. The constraint may be to a single fixed value, to a Value Set from which the value is to be drawn, or to a named Concept Domain.Value constraints include a conformance verb (shall, should, may, etc.) as defined in Conformance Verbs. Additionally, constraints specifying Value Sets include a coding strength conformance CWE (Coded With Extensibility) or CNE (Coded with No Extensibility), as defined in Core Principles and Properties of HL7 Version 3 Models, Release 1. Further, Value Set constraints may include 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. By default, Value Sets have dynamic binding, unless explicitly specified with static binding.Values of Data Type CS (Coded Simple Value) have a fixed code system defined in the CDA Specification, and are simple strings. The template tables identify only the constraint on the code value, and do not specify that fixed code system nor the code meaning (display name).Single values of Data Type CD (Concept Descriptor) or CE (Coded With Equivalents) are specified in the template tables with the triplet notation specified in PS3.16:(CodeValue, Coding Scheme Designator, "Code Meaning")The Coding Scheme Designator is a simple human readable identifier of the code system, and corresponds to the optional codeSystemName attribute of the CD or CE element. The CDA Specification requires the Code System OID to be encoded in an attribute of the CD or CE element. The corresponding OID for each Coding Scheme Designator is provided in the PS3.16 Section titled “Coding Schemes”. The Code Meaning is encoded in the displayName attribute of the CD or CE element. As defined in Core Principles and Properties of HL7 Version 3 Models, “A Concept Domain is a named category of like concepts (a semantic type) that is specified in the vocabulary declaration of an attribute in a information model… Concept Domains exist to constrain the intent of the coded element while deferring the binding of the element to a specific set of codes until later in the specification …process.” In this Standard, Concept Domains are used to provide a named category in a structural template that can be bound to a specific value or value set by an invoking template, thus specializing the structural template for a particular use case. For example, the Quantity Measurement template “observationType” Concept Domain can be bound to a value set of fetal ultrasound measurements in one invoking template, or to a value set of cardiac CT measurements in another invoking template.Invocation of Subsidiary TemplatesA template may invoke (include) subsidiary templates. Templates typically have one of two styles, a single parent element with child element structure, or a flat list of sibling elements.The single parent element style is typical for the top level Document, Section, and Entry templates, and the parent element is of the HL7 v3 RIM act class. Invocation of such a template therefore involves an actRelationship element; that actRelationship element is specified in the invoking template.The flat list style is typical for sets of attributes aggregated for editorial convenience.Invocation of a subsidiary template includes the name of invoked template and its templateID, specified in the Subsidiary Template column of the invoking template table. For an invoked template of the single parent element style, the scoping business name and top level element are provided in italics in the invoking template table. This indicates this is data copied from the specification in invoked template for the readers convenience.Vocabulary Binding And ConstraintsA template invocation may provide vocabulary Concept Domain binding or other vocabulary constraints, e.g., limiting an element in the invoked template to a specific value from its defined Value Set. These vocabulary constraints are specified in tabular form, as shown below. Concept Domain or ElementBindingAdditional RequirementsEach template may be accompanied by additional requirements and usage explanations in narrative specification language.EncodingA full discussion of the representation of vocabulary is outside the scope of this document; for more information, see the HL7 V3 specifications on Abstract Data Types and XML Data Types R1 referenced in the CDA Specification.translationData Type CD (Concept Descriptor) and CE (Coded With Equivalents) allow a translation code, which allows the encoding of the same concept in an alternate coding system. This supports the encoding of both an originally entered (local) code, and a code specified for cross-system interoperability.There is a discrepancy in the use of translation code versus the root code between HL7 Data Types R1 and this Standard. The Data Types R1 requires the original code (as initially entered in an information system application) in the root. This Standard follows the convention used in the Consolidated CDA Implementation Guide specification, which specifies the standard interoperable code in the root, whether it is original or a translation. Note:This discrepancy is resolved in HL7 Data Types R2 to follow the convention used here, but CDA uses Data Types R1.Figure SEQ Figure \* ARABIC 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>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 v3, 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 SEQ Figure \* ARABIC 6: nullFlavor example<birthTime nullFlavor="NAV"/> <!--coding an unknown birthdate-->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.MSKThere 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 specification. 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 SEQ Figure \* ARABIC 8: XML example of allowed nullFlavors when element is required<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>Unknown InformationIf a document creator wants to state that a piece of information is unknown, the following principles apply:1.If the creator doesn’t know an attribute of an act, that attribute can be null.Figure SEQ Figure \* ARABIC 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 creator doesn’t know if an act occurred, the nullFlavor is on the act (detail could include specific allergy, drug, etc.).Figure SEQ Figure \* ARABIC 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 SEQ Figure \* ARABIC 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.XML ID and multiple element instantiationsThe XML Specification allows each markup tag to have an ID attribute, unique within the document, that allows reference to that markup. In this implementation guide, the unique XML ID is required for elements that may have multiple instantiations in the same context. Each instantiation has its own XML ID, which is used as a discriminator between those multiple instantiations. This allows business name based logic for authoring applications to identify specific instances of an element.As a convention, the business name for each element that may nave multiple instantiations has a suffix [*], indicating the use of the XML ID as a discriminator.Example:The business name based production logic for two measurements might be, e.g., -- instantiate two measurementsnew ImagingReport:Findings:QuantityMeasurement[Q21a] -- "Q21a" is the XML IDnew ImagingReport:Findings:QuantityMeasurement[Q21b] -- "Q21b" is the XML ID-- set value for first measurementcontext ImagingReport:Findings:QuantityMeasurement[Q21a]|:MeasurementName = {"112058", "DCM", "Calcium score"}|:MeasurementValue = "8"-- set value for second measurementcontext ImagingReport:Findings:QuantityMeasurement[Q21b]|:MeasurementName = {"408716009", "SNOMED", "Stenotic lesion length"}|:MeasurementValue = "14"|:Units = "mm"In the CDA R2 Specification and this Implementation Guide, the XML ID capability is also used to provide linkage between structured entries and the corresponding narrative text (see section 9.1 below).ConformanceAs a CreatorAn application may claim conformance to this Part as a document creator if it creates a CDA document in accordance with one or more of the document level templates defined herein. Templates are logical specifications, and may invoke subsidiary templates. The creator is responsible for the requirements for correct serialization of elements in accordance with the CDA Standard.Note: This is particularly relevant when including “general” templates, whose elements need to be sorted into appropriate sequence locations. E.g., template IDs need to be encoded with the other template IDs of the invoking element.As a ReceiverAn application may claim conformance to this Part as a document receiver if it performs specialized processing of a CDA document utilizing one or more of the templates defined herein. Note: In general, receivers of CDA documents are expected to follow the fundamental rules of the CDA Standard to support their intended use, and are not expected to assert specific conformance claims for specific CDA templates. However, applications that perform operations using CDA Level 2 (section headings) or Level 3 (structured entries) coded content may assert conformance to specific templates.For example, and application that extracts structured entries about planned follow-up procedures from the Recommendations section and tracks their performance may claim specific conformance to the Recommendations section template.Add note about IHE CDA options – View, Document Import, Section Import, Discrete Data Import Rendering Header Information for Human Presentation(This section is reproduced from the Consolidated CDA Implementation Guide Section 2.8)Metadata 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 datesService and encounter types, and date ranges as appropriateNames of all persons along with their roles, participations, participation date ranges, identifiers, address, and telecommunications informationNames of selected organizations along with their roles, participations, participation date ranges, identifiers, address, and telecommunications informationDate of birth for recordTarget(s)As a Clinical Content SpecifierBinding to vocabulary … 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. Imaging Report Template ID tbdNameImaging ReportEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description This CDA Imaging Report template defines the report content and technical constraints for documents, sections, and entries to be used in imaging report instances. This template may apply to screening, diagnostic, or theuraputic radiology, cardiology, or other imaging reports. The body of an Imaging Report contains five main imaging report sections: (relevant) Clinical (patient) information; Current Imaging procedure description;Comparison studies;FindingsImpressionsplus potentially an Addendum(s)The report templates sponsored by the RSNA Informatics Reporting initiative () follow this general section outline.ClassificationCDA Document LevelRelationships ContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateImagingReportClinicalDocument?>templateId1..1SHALLII??>@@root1..1SHALLUIDSHALL1.2.840.10008.20.1.1DocType>code1..1SHALLCDSHALL CWE DYNAMICValue Set CID7021>1..1SHALL?General Header>1..1SHALL?Imaging Header>0..1MAYParent Document?>component1..1SHALL???>>structuredBody1..1SHALL??>>component0..1MAY?ClinicalInformation>>>sectionClinical Information>>component1..1SHALL?ProcedureDescription>>>sectionImaging Procedure Description>>component0..1MAY?ComparisonStudy?>>>sectionComparison Study>>component0..1MAY?Findings>>>sectionFindings>>component1..1SHALL?Impressions?>>>sectionImpressions>>component0..*COND?Addendum[*]?>>>sectionAddendumIn addition to the header and parent document information, at a high level, an Imaging Report contains five main imaging report sections, plus potentially an addendum(s), each of which may include additional supporting or detailed information. These are:(relevant) Clinical (patient) information –Medical history Reason(s) for current procedureCurrent Imaging procedure description Date/time of procedureRequested procedure informationComplications, which identifies complications encountered during this imaging procedureMedication/Contrast Administered during the procedureRadiation Exposure information, if applicableIdentification of image set(s), for example Study UIDComparison studies Imaging procedure description(s) for prior comparison studiesFindings Labeled sub-section, which cohesively organize a set of more detailed information or measurements, often by organ or anatomy. For example, “The following information and measurements pertain to the liver.”Fetus findings sub-section, if applicable, one per fetusImpressionsGeneral outcome (narrative text)A Critical or Actionable Finding, which must be followed up on and reportedA Key Images section which identifies a limited number of images which are critical to the diagnosisA Radiology Recommendation, often for follow-up studiesAddendum(s), if applicable To aid in the creation of these reports, other templates are defined, such as:General section entries, which gathers and makes consistent attributes that are common to many sectionsclinicalDocument/codeGiven that Imaging Report 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.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. Table SEQ Table \* ARABIC 1: DIR LOINC Document Type CodesValue Set: DIRDocumentTypeCodes?2.16.840.1.113883.11.20.9.32 DYNAMICCode System: LOINC 2.16.840.1.113883.6.1LOINC Code ‘Modality’Common Display NameSetting ‘System’Specialty/Training/Professional Level ‘Method_Type’18748-4AnyDiagnostic Imaging ReportDiagnostic Imaging75238-6AnyInterventional radiology procedure noteInterventionalradiology18747-6Computed TomographyCT ReportCT18755-9Magnetic Resonance MRI ReportMRI18760-9UltrasoundUltrasound ReportUS18757-5Nuclear MedicineNuclear Medicine ReportRadNuc17787-3Nuclear Medicine Thyroid Scan ReportThyroidRadNuc18758-3Positron Emission TomographyPET Scan ReportPet scan11522-0UltrasoundEchocardiography ReportHeartCardiac echo18746-8Visible LightColonoscopy ReportLower GI tractColonoscopy18751-8Visible LightEndoscopy ReportUpper GI tractEndoscopy11525-3Ultrasound Obstetrical Ultrasound ReportPelvis+FetusOB.US43468-8X-Ray RadiographyRadiography ReportXR49512-7X-Ray FluoroscopyFluoroscopy ReportXR.fluor24606-6Mammography Mammography Screening ReportBreastMam24605-8 Mammography Diagnostic Mammography ReportBreastMam38269-7Bone DensitometryBone Density ReportSkeletal system?XR.DXAFigure SEQ Figure \* ARABIC 16: DIR ClinicalDocument/code example<code code=”18748-4” codeSystem=”2.16.840.1.113883.6.1” codeSystemName=”LOINC” displayName=”Diagnostic Imaging Report”/>Figure SEQ Figure \* ARABIC 17: 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>Addendum If the header includes a relatedDocument element with typeCode APND, the component/structuredBody SHALL contain at least one Addendum Section.Clinical Statements An 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, and places all imaage rendering within the scope of DICOM standards.Interventional Radiology Report (reserved)Similar to diagnostic; includes consents, sedation, blood loss, reference to operative report Use Procedure Description rather than Current Imaging Procedure Description?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 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.General Header ConstraintsNameNest LevelElement/ AttributeCardElem/ Attr ConfDataTypeValue ConfValue Subsidiary Template?typeId1..1SHALLII??@@root1..1SHALLUID2.16.840.1.113883.1.3@@extension1..1SHALLSTPOCD_HD000040?templateId1..1SHALLII??@@root1..1SHALLUID?tbddocumentIDid1..1SHALLIItitletitle1..1SHALLSTcreationTimeeffectiveTime1..1SHALLTSconfidentialityconfidentialityCode1..1SHALLCESHALL CNE STATIC 2010-04-21BasicConfidentialityKind 2.16.840.1.113883.1.11.16926 languageCodelanguageCode1..1SHALLCSSHALL CNELanguage 2.16.840.1.113883.1.11.11526setIdsetId1..1CONDIIversionNumberversionNumber1..1CONDINTPatient[*]recordTarget1..*SHALL@ID1..1CONDXML ID>patientRole1..1SHALLPatientID>>id1..*SHALLIIPatientAddr>>addr1..*SHALLADPatientTele>>telecom1..*SHALLTEL>>patient1..1SHALLPatientName>>>name1..1SHALLPNPatientGender>>>Administra-tiveGenderCode1..1SHALLCESHALL CNEAdministrative Gender 2.16.840.1.113883.1.11.1PatientBirthTime>>>birthTime1..1SHALLTS>>providerOrganization0..1MAYproviderOrgName>>>name1..*SHALLONproviderOrgTel>>>telecom1..*SHOULDTELproviderOrgAddr>>>addr1..*SHOULDADlegalAuthenticator0..1SHOULDSigningTime>time1..1SHALLTS>signatureCode1..1SHALLCSSHALL CNE“S”>assignedEntity1..1SHALLSignerID>>id1.*SHALLIISignerAddr>>addr1.*SHALLADSignerTel>>telecom1..*SHALLTEL>>assignedPerson1..1SHALLSignerName>>>name1..1SHALLPNAuthor0..*SHALL>assignedAuthor1..1SHALLAuthorID>>id1.*SHALLIIAuthorAddr>>addr1.*SHALLADAuthorTel>>telecom1..*SHALLTEL>>person1..1SHALLAuthorName>>>name1..1SHALLPNcustodian1..1SHALL>assignedCustodian1..1SHALL>>representedCustodianOrganization1..1SHALLCustodianOrgID>>>id1.*SHALLIICustodianOrgName>>>name1..*SHALLONCustodianOrgAddr>>>addr1.*SHALLADCustodianOrgTel>>>telecom1..*SHALLTELeffectiveTimeSignifies 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 recordTargetThe recordTarget records the patient whose health information is described by the clinical document; it must contain at least one patientRole element. 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. In such a case, the recordTarget element SHALL include an XML ID attribute that serves as the business name discriminator associated with an instance of the element. Table SEQ Table \* ARABIC 2: Basic Confidentiality Kind Value SetValue 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.25CodeCode SystemPrint NameN Confidentiality CodeNormalRConfidentiality CodeRestricted VConfidentiality CodeVery Restricted Table SEQ Table \* ARABIC 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.11526Description: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 codes CodeCode SystemPrint NameenInternet Society LanguageenglishfrInternet Society LanguagefrencharInternet Society Languagearabicen-USInternet Society LanguageEnglish, USes-USInternet Society LanguageSpanish, US…Figure SEQ Figure \* ARABIC 18: header example<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/><!— Imaging Report Release 2 Template --><templateId root="1.2.840.10008.20.1.1"/><!-- General Header Template --><templateId root="2.16.840.1.113883.10.20.22.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"/>recordTarget/patientRole/Patient/birthTime SHALL be precise to year, SHOULD be precise to day.Table SEQ Table \* ARABIC 4: Administrative Gender (HL7) Value SetValue Set: Administrative Gender (HL7 V3) 2.16.840.1.113883.1.11.1 DYNAMICCode System(s): AdministrativeGender 2.16.840.1.113883.5.1CodeCode SystemPrint NameFAdministrativeGenderFemaleMAdministrativeGenderMaleUNAdministrativeGenderUndifferentiatedFigure SEQ Figure \* ARABIC 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>LegalAuthenticatorThe 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.The legalAuthenticator SHALL contain exactly one [1..1] time representing the time of signatureFigure SEQ Figure \* ARABIC 20: 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>Author (Person)The author element represents the creator of the clinical document. This template restricts the author to be a person. Such author 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 Figure SEQ Figure \* ARABIC 21: 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>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. Figure SEQ Figure \* ARABIC 22: 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>Imaging HeaderNameNest LevelElement/AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary Template?componentOf1..1SHALL>encompassingEncounter1..1SHALLencounterID>>id0..1SHOULDencounterTime>>effectiveTime1..1SHALL>>location0..1MAY>>>healthCareFacility1..1SHALL>>>>location0..1SHOULDHealthcareFacilityName>>>>>name1..1SHALLENHealthcareFacilityAddress>>>>>addr1..1SHALLAD>>>>serviceProviderOrganization0..1SHOULDHealthcareProviderOrganizationName>>>>>name1..1SHALLON>>encounterParticipant0..*MAY>>@@typeCode1..1SHALL“ATND”>>>assignedEntity1..1SHALL>>>>assignedPerson1..1SHALLAttendingPhysicianName>>>>>name1..1SHALLENinFulfillmentOf1..*SHOULD>order1..1SHALLOrderPlacerNumber>>id0..1SHOULDIIOrderFilllerNumber>>id0..1SHOULDIIAccessionNumber>>id1..1SHALLIIOrderedCode>>code0..1SHOULDCEOrderPriority>>priorityCode0..1SHOULDCEValue Set 2.16.840.1.113883.1.11.16866 (ActPriority)documentationOf1..1SHALL>serviceEvent1..1SHALL>>id0..*SHOULDProcedureCode>>code1..1SHALLCEModalityCode>>>translation1..1SHALLCDSHALL CNEValue Set CID 29 Modality AnatomicRegionCode>>>translation0..1SHOULDCDCoarse Anatomic RegionProcedureTime>>effectiveTime1..1SHALLTS>>performer0..1SHOULD>>@@typeCode1..1SHALLCSSHALL“PRF”>>>assignedEntity1..1SHALLPerformer ID>>>>id1..1SHALLII>>>>assignedPerson1..1SHALLPerformerName>>>>>name1..1SHALLPNparticipant1..1SHALL@@typeCode1..1SHALLCSSHALLREF>assignedEntity1..1SHALLReferrerAddr>>addr0.*SHOULDADReferrerTel>>telecom0..*SHOULDTEL>>assignedPerson1..1SHALLReferrerName>>>name1..1SHALLPNdataEnterer0..1MAY>assignedEntity1..1SHALLTranscriptionistID>>id0..1SHOULDII>>assignedPerson0..1SHOULDTranscriptionistName>>>name1..1SHALLPNcomponentOf/encompassingEncounterThe 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.Figure SEQ Figure \* ARABIC 23: 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>Physician of Record ParticipantThis encounterParticipant with typeCode="ATND" Attender is the attending physician and is usually different from the Physician Reading Study Performer defined in documentationOf/serviceEvent.Figure SEQ Figure \* ARABIC 24: 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>inFulfillmentOf/OrderAn 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.There SHALL be one inFulfillmentOf/order/id for each distinct Order Placer Number associated with the report.There SHALL be one inFulfillmentOf/order/id for the DICOM Accession Number in the imaging data. Figure SEQ Figure \* ARABIC 25: DIR inFulfillmentOf example<inFulfillmentOf> <order> <id extension=”10523475” root=”2.16.840.1.113883.19.4.27”/> <!-- {root}.27= accession number list *-> </order></inFulfillmentOf>documentationOf Service Event and PerformerEach 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 SEQ Figure \* ARABIC 26: 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.Figure SEQ Figure \* ARABIC 27: documentationOf example<documentationOf> <serviceEvent classCode="ACT"> <id root="1.2.840.113619.2.62.994044785528.114289542805"/> <!-- study instance UID --> <id extension="123453" root="1.2.840.113619.2.62.994044785528.26"/> <!-- DICOM Requested Procedure ID --> <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>Physician Reading Study PerformerThis 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) Figure SEQ Figure \* ARABIC 28: 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>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).Figure SEQ Figure \* ARABIC 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>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.Figure SEQ Figure \* ARABIC 30: informationRecipient example<informationRecipient> <intendedRecipient> <informationRecipient> <name> <given>Henry</given> <family>Seven</family> </name> </informationRecipient> <receivedOrganization> <name>Good Health Clinic</name> </receivedOrganization> </intendedRecipient></informationRecipient>Participant (Referrer)Figure SEQ Figure \* ARABIC 31: 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>AuthenticatorThe authenticator identifies a participant or participants who attested to the accuracy of the information in the document.Figure SEQ Figure \* ARABIC 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>Parent DocumentNameNest LevelElement/AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary Template?relatedDocument0..1MAY@@typecode1.1SHALLCSSHALL"RPLC">parentDocument1..1SHALLReplacedDocumentID>>id1..1SHALLIIReplacedDocumentsetID>>setId1..1CONDIIReplacedDocumentVersion>>versionNumber1..1CONDINT?relatedDocument0..1MAY@@typecode1.1SHALLCSSHALL"XFRM">parentDocument1..1SHALLTransformedDocumentID>>id1..1SHALLIIA DIR may have two 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.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. Figure SEQ Figure \* ARABIC 33: DIR relatedDocument example<!-- transformation of a DICOM SR --><relatedDocument typeCode="XFRM"> <parentDocument> <id root="1.2.840.113619.2.62.994044785528.20060823.200608232232322.9"/> <!-- SOP Instance UID (0008,0018) of SR sample document--> </parentDocument></relatedDocument>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. General requirements for section/textThe text element within the section stores the narrative to be rendered, as described in the CDA R2 specification, 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. 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.The narrative block allows a variety of markup. The markup that implements various types of internal and external linkage is shown in the table below, and is implicitly included in the conformance specifications for each section narrative block. The markup elements may occur at any point within the narrative block text as allowed by the CDA R2 specification. NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateTexttext1..1SHALLEDContent[*]>content0..*MAYST>@@ID1..1SHALLXML IDSee xml ID attributeGraphic[*]>renderMultiMedia0..*MAY>@@referencedObject1..1SHALLXML IDREFExtRef[*]>linkHtml0..*MAY>@@href1..1SHALLURI<content> markup and links from entriesThe CDA narrative block may contain the <content> markup element to wrap a block of text so that it can be explicitly identified using the XML ID attribute, and referenced from elsewhere in the document. Specifically, structured entries may link to their equivalent narrative rendering in a content block using the XML ID (see CDA R2 Specification, section 4.3.5.1).<renderMultiMedia> markup and graphical contentThe CDA narrative block may contain the <renderMultiMedia> markup element to include graphical content, e.g., a coronary tree diagram or myocardial wall motion “bulls-eye chart”. The renderMultiMedia element links to an observationMedia structured entry using the XML ID of that entry (see CDA R2 Specification, section 4.3.5.6).<linkHtml> markup and external referencesThe CDA narrative block may contain the <linkHtml> markup to provide a link between narrative text and an external (non-attested) resource (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 (), 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 URI 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= /><linkHtml href= /> </content></text> ... </section>Example 2:<section><title>Findings</title><text> Pleura normal...<linkHtml href= /></text></section><linkHtml> markup and image referencesThe 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.Figure SEQ Figure \* ARABIC 38: WADO reference using linkHtml example<text> ... <paragraph> <caption>Source of Measurement</caption> <linkHtml href="">Chest_PA</linkHtml> </paragraph> ...</text>Clinical InformationTemplate ID tbdNameClinical InformationEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Clinical details about the case such as presenting signs and symptoms, past clinical history, the overall condition of the patient, etc.ClassificationCDA Section LevelRelationships Invoked by Imaging Report Document Level TemplateContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateClinicalInformationsection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID>id1..1SHALLII>code1..1SHALLCDSHALL55752-0, LOINC, “Clinical Information”title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>component0..1MAYRequest>>section1..1SHALLRequest>component0..1MAYProcedureIndications>>section1..1SHALLProcedure Indications>component0..*MAYHistory>>section1..1SHALLHistory>0..1MAYGeneral Section EntriesFigure SEQ Figure \* ARABIC 35: Clinical Information section example<section> <templateId root="2.16.840.1.113883.10.20.22.2.27" /> <code code="55752-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="CLINICAL INFORMATION" /> <title>Clinical Information</title> <text>The patient was admitted to the hospital ... </text></section>Imaging Procedure Description Template ID TBD NameImaging Procedure DescriptionEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description The Imaging Procedure Description section records the technical details of the procedure and may include information about protocol, imaging device, contrast, radiation dose, medications administered (sedation, stress agents), etc.ClassificationCDA Section LevelRelationships Invoked by Imaging Report Document Level TemplateContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateProcedureDescriptionsection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID>id0..1MAYII>code1..1SHALLCESHALL(55111-9, LOINC, “Current Imaging Procedure Description”) title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>entry1..1SHALLprocedureTechnique>>procedure1..1SHALLProcedure Technique>entry0..*MAYproceduralMedication[*]>>substanceAdministration1..1SHALLProcedural Medication>component0..1MAYComplications>>section1..1SHALLComplications Section>component0..1CONDRadiationExposure>>section1..1SHALLRadiation Exposure and Protection Information>component1..1SHALLDICOMObjectCatalog>>section1..1SHALLDICOM Object Catalog Sectioncomponent/section Radiation Exposure and Protection InformationA Radiation Exposure and Protection Information Section MAY be present if the documented service utilizes ionizing radiation.Figure SEQ Figure \* ARABIC 36: Current Imaging Procedure description section example<section> <templateId root="TBD" /> <code code="55111-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="CURRENT IMAGING PROCEDURE DESCRIPTION" /> <title>Current Imaging Procedure Description</title> <text>A CT study was acquired with 2.5 mm images of the abdomen and pelvis with 140 mL of... </text> <! ---see examples for other sections/entries /></section>Comparison StudyTemplateID TbdNameComparison StudyEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Documentation of a prior Imaging Procedure to which the current images were comparedClassificationCDA Section LevelRelationships Invoked by Imaging Report Document Level TemplateContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateComparisonStudysectoion1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUIDtbd>id1..*SHALLII>code1..1SHALLCD18834-2, LOINC, “Radiology Comparison study”title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>entry0..*MAYprocedureTechnique>>procedure1..1SHALLProcedure Technique>0..1MAYGeneral Section EntriesFigure SEQ Figure \* ARABIC 37: Comparison study section example<section> <templateId root="2.16.840.1.113883.10.20.22.2.27" /> <code code="18834-2” codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Radiology Comparison Study" /> <title>Comparison Study</title> <text>A prior CT with contrast performed on May 7, 2012, showed that... </text></section>Findings Template ID 1.3.6.1.4.1.19376.1.4.1.2.112.16.840.1.113883.10.20.6.1.2NameFindingsEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Records clinically significant observations confirmed or discovered during the procedure.ClassificationCDA Section LevelRelationships Invoked by Imaging Report Document Level TemplateContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateFindingssection>templateId1..1SHALLII>@@root1..1SHALLUIDtbd>id1..*SHALLII>code1..1SHALLCDSHALL59776-5, LOINC, "Procedure Findings"title>title1..1SHALLSTtext>text1..1CONDEDSee section/text requirements>component0..*MAYOBUSFetusFindings[*]>>section1..1SHALLOBUS Fetus Findings>component0..*MAYSubsection[*]>>section1..1SHALLLabeled Subsection>0..1MAYGeneral Section EntriesFigure SEQ Figure \* ARABIC 37: 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>textText is required if there are findings not recorded in subsections.If clinical statements are present, the section/text SHALL represent faithfully all such statements and MAY contain additional text. ImpressionsTemplate ID tbdNameImpressionsEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)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.ClassificationCDA Section LevelRelationships Invoked by Imaging Report Document Level TemplateContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateImpressionssection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID>id1..*SHALLII>code1..1SHALLCDSHALL19005-8, LOINC, "Impressions"title>title1..1SHALLSTtext>text0..1SHALLEDSee section/text requirements>component0..*MAYCommunicationOfActionableFindings>>section1..1SHALLCommunication of Actionable Results>component0..1MAYKeyImages>>section1..1SHALLKey Images>component0..*MAYRadiologyRecommendation>>section1..1SHALLRadiology Recommendation>entry0..*MAYcodedObservation>>observation1..*MAYCDCoded ObservationFigure SEQ Figure \* ARABIC 39: Impressions section example<section> <templateId root="2.16.840.1.113883.10.20.22.2.27" /> <code code="121072" codeSystem="1.2.840.10008.2.16.4" codeSystemName="DCM" displayName="Impressions" /> <title>Impressions</title> <text>This exam identified… </text> <!--- other sections and entries here ---/></section>AddendumTemplate ID tbdNameAddendumEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Addendum section for imaging report includes supplemental information added to the original document contents.In this section, Addendums are presented as text (not coded entries).ClassificationCDA Section LevelRelationships Invoked by Imaging Report Document Level TemplateContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateAddendum[*]section1..1SHALL@@ID1..1SHALLXML IDSee xml ID attribute>templateId1..1SHALLII>@@root1..1SHALLUIDSHALLtbd>id1..*SHALLII>code1..1SHALLCDSHALL55107-7 LOINC, "Addendum" title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>author1..1SHALLtime>>time1..1SHALLTS>>assignedAuthor1..1SHALLauthorID>>>id1..*SHALLII>>>>person1..1SHALLauthorName>>>>>name1..1SHALLPNsection/@IDThe Addendum section SHALL include an XML ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the template. Even if only one Addendum section is intantiated, the ID attribute shall be present.authorNote that the Author identified in the document header is the author of the original report, as that participation sets the default authoring context for the report. The Author participation in this section shall be present, and identifies the author of the addendum, even if the same as the author of the original report.Figure SEQ Figure \* ARABIC 40: Addendum section example<section> <templateId root="2.16.840.1.113883.10.20.22.2.27"/> <code code="55107-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName=" Addendum"/> <title> Addendum Document</title> <text> The supplemental information added to the original document contents...</text> <author> <time value=”20140605143000+0500”/> <assignedAuthor> <id extension=”xyz” root=”2.16.840.1.113883.19.5”/> <assignedPerson> <name> <given>Henry</given> <family>Radiologist</family> </name> </assignedPerson> </assignedAuthor></author></section>Sub-sectionsGeneral Section EntriesTemplate ID tbdNameGeneral Section EntriesEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description This template specifies the common set of structured entries that may be invoked in a CDA imaging report section, and an author participation for the section. ClassificationCDA Section LevelRelationships Invoked by Findings section and its sub-sections, Clinical Information, and other sectionsContextSiblingOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary Templateauthor0..*MAY>assignedAuthor1..1SHALLAuthorID>>id1.*SHALLII>>person1..1SHALLAuthorName>>>name1..1SHALLPNentry0..*MAYCodedObservation[*]>observation1..1SHALLCoded Observationentry0..*MAYQuantityMeasurement[*] >observation1..1SHALLQuantity Measurement entry0..*MAYObservationMedia[*]>observationMedia1..1SHALLObservation Mediaentry0..*MAYSOPInstance[*]>observation1..1SHALLSOP Instance ObservationNote that there is no business name associated with this template. Rather, this template is an editorial convenience for template specification, and the business names for the elements of this template are logically part of the business name scope of the invoking template.Figure SEQ Figure \* ARABIC 90: 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>RequestTemplate ID tbdNameRequestEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Information on requested imaging studies and associated tests. It may include information on the reason for the request.ClassificationCDA Section LevelRelationships Invoked in Clinical InformationContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateRequestsection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUIDtbd>id1..*SHALLII>code1..1SHALLCD55115-0, LOINC, “Request”title>title1..1SHALLSTtext>text0..1SHALLEDSee section/text requirements>0..1MAYGeneral Section EntriesFigure SEQ Figure \* ARABIC 42: Request section example<section> <templateId root="2.16.840.1.113883.10.20.22.2.27" /> <code code="55115-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="REQUEST" /> <title>Request</title> <text>PTA (Iliac Angioplasty) for treatment of symptomatic artherosclerotic disease in both iliac arteries ... </text></section>Procedure IndicationsTemplate ID 2.16.840.1.113883.10.20.22.2.29NameProcedure IndicationsEffective Date(Date of Final Text adoption)Version LabelDICOM-yyyymmddStatusDraft (will change to Approved on Final Text adoption)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.ClassificationCDA Section LevelRelationships Invoked in Clinical Information Section Level templateContextOpen/ClosedOpenRevision HistoryFrom Consolidated CDA r1.1NameNest LevelElement/AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateProcedureIndicationssection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID2.16.840.1.113883.10.20.22.2.29>id1..*SHALLII>code1..1SHALLCD59768-2, LOINC, “Procedure Indications” title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>entry0..*MAYcodedObservation[*]>>observation1..1SHALLSee bindingCoded Observationentry/observation The binding to the Coded Observation concept domains shall be: Concept Domain or ElementBindingObservationType432678004, SNOMED, “Indication for procedure”Other concept domainsunspecifiedNote:In Consolidated CDA r1.1 the binding to the observationType is to Value Set Problem Type (2.16.840.1.113883.3.88.12.3221.7.2) with conformance SHOULD. Values from that Value Set are acceptable here as well.Figure SEQ Figure \* ARABIC 43: 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 as a follow-up for abnormal screening result. </text></section>Medical (General) HistoryTemplate ID 2.16.840.1.113883.10.20.22.2.39NameMedical (General) HistoryEffective Date2012-07Version LabelStatusDraft (will change to Approved on Final Text adoption)Description History general describes all aspects of medical history of the patient even if not pertinent to the current procedure, and may include chief complaint, past medical history, social history, family history, surgical or procedure history, medication history, and other history information. The history may be limited to information pertinent to the current procedure or may be more comprehensive. It may also be reported as a collection of random clinical statements or it may be reported categorically. Categorical report formats may be divided into multiple subsections, including Past Medical History and Social History.ClassificationCDA Section LevelRelationships Invoked in Clinical Information Section Level templateContextOpen/ClosedOpenRevision HistoryFrom Consolidated CDA r1.1NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateHistorysection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID2.16.840.1.113883.10.20.22.2.39>id1..*SHALLII>code1..1SHALLCD11329-0, LOINC, “History General”title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>0..1MAYGeneral Section EntriesFigure SEQ Figure \* ARABIC 44: 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="History General" /> <title>Relevant medical history</title> <text><list> <item>Patient reported adverse reaction to iodine. </item> <item>Patient is smoker (1 pack daily). </item></text></section>Complications Section Template ID tbdNameComplications SectionEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description The Complications section records problems that occurred during the procedure or other activity. The complications may have been known risks or unanticipated problems.ClassificationCDA Section LevelRelationships Invoked in Imaging Procedure Description sectionContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateComplicationssection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUIDtbd>id1..*SHALLII>code1..1SHALLCDSHALL55109-3, LOINC, “Complications”title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>entry0..*MAYCodedObservation[*]>>observationCoded ObservationFigure SEQ Figure \* ARABIC 45: 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>A small post-procedure right pneumothorax is present. </text> <entry> <observation classCode="OBS" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.13"/> <!-- Code Observation --> ... </observation> </entry></section>Radiation Exposure and Protection InformationTemplate ID tbdNameRadiation Exposure and Protection InformationEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)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.ClassificationCDA Section LevelRelationships Invoked in Current Imaging Procedure Description sectionContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateRadiationExposuresection1..1SHALL>templateId1..1SHALLII>>@@root1..1SHALLUID>code73569-6, LOINC, “Radiation exposure and protection information”>id1..1SHALLIItitle>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>entry0..1COND>>procedure1..1SHALL>>@@moodCode1..1SHALLCSEVN>>>code1..1SHALLCDtbd, DCM, “Patient exposure to ionizing radiation”>>>participant1..1SHALL>>@@typeCode1..1SHALLCSSHALLRESP>>>participantRole1..1SHALLIrradiationAuthorizingID>>>>id1..1SHALLII>>>>functionCode1..1SHALLCESHALL113850, DCM, "Irradiation Authorizing" >>>>playingEntity1..1SHALLIrradiationAuthorizingName>>>>>name1..1SHALLPN>entry0..1MAYSOPInstance[doseReport]>>observation1..1SHALLSOP Instance Observation>entry0..1CONDcodedObservation[pregnancy]>>observation1..1SHALLSee bindingCoded Observation>entry0..1MAYcodedObservation[indication]>>observation1..1SHALLSee bindingCoded Observation>entry0..*MAYquantityMeasurement[*]>>observation1..1See bindingQuantity Measurement>entry0..1MAY>>substanceAdministration>>@@classCode1..1SHALLSHALLSBADM>>@@moodCode1..1SHALLSHALLEVN>>>code1..1440252007, SNOMED, "Administration of radiopharmaceutical"RadioactivityDose>>>doseQuantity0..1SHOULDPQ>>>consumable1..1SHALL>>>>manufacturedProduct1..1SHALL>>>>>material1..1SHALLRadiopharmaceutical>>>>>>code1..1SHALLCESHOULDCWECID 25 (radiopharmaceuticals) or CID 4021 (PET radiopharmaceuticals)texttext SHALL contain:information on the indications for the procedurethe name of the “Irradiation Authorizing” person who is the clinician responsible for determining that the irradiating procedure was appropriate for the indications.summary 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).information on the radioactive substance administered if and only if radioactive substance is administered in the context of the current procedure.entry/procedure Patient ExposureIf modality is CT, MG, NM, PT, XR, XA, or XF, the section SHOULD contain a procedure entry for the exposure of the patient to ionizing radiationThis entry SHALL have a participant, the irradiation authorizing person who is the clinician responsible for determining that the irradiating procedure was appropriate for the indications. Note:This may be the same person as the performing physician identified in the header.entry/observation SOP InstanceThe section may include a reference to a DICOM Dose Report SOP Instance that provides a detailed record of exposure.entry/observation PregnancyA coded observation entry shall be present if the patient is female and child-bearing age. The binding to the Coded Observation concept domains shall be: Concept Domain or ElementBindingObservationType364320009, SNOMED, "Pregnancy observable"ObservationValueValue Set CID 6096, 1.2.840.10008.6.1.418, DICOM Pregnancy StatusOther concept domainsunspecifiedentry/observation Indication An indication for procedure recorded in this section should be consistent with any indications identified in the Clinical Information and/or Procedure Indications section. It is included here for conformance with regulatory requirements in some jurisdictions for the indications to be specified in the context of the radiation exposure information. The binding to the Coded Observation concept domains shall be: Concept Domain or ElementBindingObservationType432678004, SNOMED, “Indication for procedure”Other concept domainsunspecifiedentry/observation Dose measurements The section may include multiple dose measurements. The binding to the Quantity Measurement concept domains shall be: Concept Domain or ElementBindingObservationTypeValue Set Radiation Exposure QuantitiesOther concept domainsunspecifiedTable SEQ Table \* ARABIC 5: Radiation Exposure Quantities Value SetValue Set: Radiation Exposure QuantitiesCode System(s):DCMDescription:CodeCode SystemPrint Name 111637DCMAccumulated Average Glandular Dose (mammo)113830DCMMean CTDIvol113813DCMCT Dose Length Product Total113722DCMDose Area Product TotalFigure SEQ Figure \* ARABIC 46: Radiation Exposure and Protection section example<section> <templateId root="XXXX" /> <code code="73569-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="RADIATION EXPOSURE AND PROTECTION INFORMATION" /> <title> Radiation exposure and protection information </title> <text>This is going to be a lot of work tocreate this example, so let’s get the table finished first so I don’t need to repeat ... </text></section>Key ImagesID 1.3.6.1.4.1.19376.1.4.1.2.14NameKey ImagesEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description The Key Images section contains narrative description of and references to DICOM Image Information Objects that illustrate the findings of the procedure reported.ClassificationCDA Section LevelRelationships Invoked in Impressions sectionContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateKeyImagessection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID>id1..*SHALLII>code1..1SHALLCD55113-5, LOINC, “Key Images”title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements >entry0..*SHOULDSOPInstance[*] >>observation1..1SHALLSOP Instance Observation>entry0..*MAYGraphic[*]>>observationMedia1..1SHALLObservation Mediasection/textThe Key Images section text SHALL contain image references using linkHtml elements, where @href is a valid Web Access to DICOM Persistent Object (WADO) URL. See section 5.1.4. The text content of linkHtml should be either visible text of the hyperlink, or a descriptor or identifier of the image, or a (limited resolution) copy of the image (see 5.8.8.3). SOP Instance ObservationThe Key Images section SHOULD include SOP Instance Observation entries equivalent to the linkHtml image references.observationMediaThe Key Images section MAY include observationMedia entries with in-line encoded copies of the referenced images, linked into the narrative block using the renderMultiMedia markup. See section 5.1.2. The renderMultiMedia may be positioned within the linkHtml markup. These in-line encoded images may have limited resolution and lossy compression as appropriate for inclusion in a report.Figure SEQ Figure \* ARABIC 48: Key Images section example<section> <templateId root="1.3.6.1.4.1.19376.1.4.1.2.14" /> <code code="55113-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Key Images" /> <title>Key Images</title> <text>Maximum extent of tumor is shown in <linkHtml href=; image 1 <renderMultiMedia referencedObject="refimag1" /> </linkHtml> </text> <entry> <!--SOP Instance reference> <observation classCode=DGIMG moodcode=EVN ID="SOP1-2"> </entry> <entry> <!--inline rendered image> <observationMedia ID="refimag1"> <value representation=B64 mediaType="image/jpeg"> Bgd3fsET4g... </value> </observationMedia> </entry></section>DICOM Object Catalog Template ID 2.16.840.1.113883.10.20.6.1.1NameDICOM Object Catalog SectionEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description DICOM 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.ClassificationCDA Section LevelRelationships Invoked in Current Imaging Procedure Description SectionsContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateDICOMCatalogsection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID2.16.840.1.113883.10.20.6.1.1>id1..*SHALLII>code1..1SHALLCD"121181" DCM "Dicom Object Catalog" title>title1..1SHALLtext>text0..1SHOULDEDSee section/text requirements>entry0..*SHOULDStudy[*]act1..1SHALLStudy Act 2.16.840.1.113883.10.20.6.2.6Figure SEQ Figure \* ARABIC 49: 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> <!-- **** Study Act **** --> <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"/> <!-- **** Series Act****--> <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> <!-- **** SOP Instance UID *** --> <!-- 2 References --> <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>OBUS Fetus FindingsTemplate ID NameOBUS Fetus FindingsEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Records observations related to a fetus confirmed or discovered during an obstetric ultrasound imaging procedure.ClassificationCDA Section LevelRelationships Invoked in Findings sectionContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateOBUSFetusFindings[*]section1..1SHALL@@ID1..1SHALLXML IDSee xml ID attribute>templateId1..1SHALLII>@@root1..1SHALLtbd>id1..*SHALLII>code1..1SHALLCD"12129-3" Fetal Study observation general US (LOINC)title>title1..1SHALLSTtext>text1..1SHALLEDSee section/text requirements>subject1..1SHALL>>relatedSubject1..1SHALL>>>code1..1SHALLCE"121026" DCM Fetus >>>subject1..1SHALLFetusID>>>>name1..1SHALLPN>component0..*MAYSection>>section1..1SHALLLabeled Subsection>0.1MAYGeneral section EntriesFor 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.section/@IDThe OBUSFetusFindings sub-section SHALL include an XML ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the template. Even if only one fetus findings sub-section is intantiated, the ID attribute shall be present.Example:The business name for the narrative text in a subsection about fetus A might be ImagingReport:Findings:OBUSFetusFindings[FetusA]:textFetusIDThe subject/relatedSubject/subject/name element is used to store the DICOM fetus ID, typically a pseudonym such as “fetus A”. This is in addition to the identification in the XML ID tag, and shall be present even if only one fetus is identified in the document.Figure SEQ Figure \* ARABIC 50: OBUS Fetus Findings section example<section> <templateId root="2.16.840.1.113883.10.20.22.2.27" /> <code code="12129-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Fetal Study observation general US" /> <title>Fetus A</title> <text>Estimated gestational age of 27 weeks... </text> <relatedSubject> <code code="121026" codeSystem="1.2.840.10008.2.16.4" displayName="Fetus"/> <subject> <name>fetus A</name> </subject> </relatedSubject></section>Labeled SubsectionTemplate ID TBDNameLabeled SubsectionEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Narrative or coded 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.The attribute ID may be defined in advance by a radiology report template (e.g., “liver”) or dynamically by the report creator device (eg., for multiple tumors).ClassificationCDA Section LevelRelationships Invoked in Findings sectionContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateSubsection[*]section1..1SHALL@@IDXML IDSee xml ID attribute>templateId1..1SHALLII>@@root1..1SHALLtbd>id1..*SHALLII>code0..0SHALL NOTtitle>title1..1SHALLSTSee titletext>text1..1SHALLEDSee section/text requirements>0..1MAYGeneral section EntriestitleThe title element is used to identify the topic (specific organ or anatomic feature, abnormality, lesion, etc.) as the subject of the sub-section findings in the human readable document. As there is no section.code, this is the required mechainsm to represent the section purpose as free text.Figure SEQ Figure \* ARABIC 51: Labeled sub-section example<section ID="Liver"> <templateId root="2.16.840.1.113883.10.20.22.2.27" /> <title>Liver</title> <text>No evidence of cirrhosis, nodular regeneration, or ... </text></section>Communication of Actionable ResultsTemplate ID tbdNameCommunication of Actionable FindingsEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description Specific finding, including actionable (aka critical) findings documented in text or as coded entries, are found in the Findings Section. The actionable findings may be duplicated in the Impressions Section in either text or as coded entries. The actionable findings may be new (critical) or a change to a previous report/diagnosis (discrepant).This section provides documentation of notification that has occurred of an actionable finding to a provider responsible for patient care. ClassificationCDA Section LevelRelationships Invoked in Impressions sectionContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateCommunicationOfActionable Findingssection1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUIDtbd>Id1..*SHALLII>code1..1SHALLCDSHALL“73568-8” LOINC Communication of Critical Results text>text1..1SHALLEDSHALLSee section/text requirementsand Communication of and Categories of Actionable Findings>entry0..1MAYactionableResultsUrgency>>act1..1SHALLSHALLActionable Results UrgencyCommunication of and Categories of Actionable Findings The Communication of Critical Results should have content equivalent to the following text content of the RSNA Radiology Reporting Templates, Template 297: Communication of Actionable Finding ().Actionable Finding categories 1, 2, and 3 are defined by: Larson PA, et al. J Am Coll Radiol 2014; published online. DOI 10.1016/j.jacr.2013.12.016.SUMMARY OF CATEGORIES OF FINDINGS“…the (ACR) work group defines 3 categories of actionable findings that require, respectively, communication and clinical decision within minutes (category 1), hours (category 2), or days (category 3).”Or, more in more detail, the categories are defined as (see reference for complete definitions):Category 1: Communication Within MinutesCategory 1 findings are those that could lead to death or significant morbidity if not promptly recognized, communicated, and acted upon. Direct verbal communication to the ordering clinician is generally required as promptly as possible. Documentation of the communication may be required by local policy or The Joint Commission (TJC) requirements.Category 2: Communication Within HoursCategory 2 findings are clinically significant observations that generally explain a patient’s acute presenta- tion and require specific medical or surgical treatment, but they do not have the same urgency and severity as those in category 1. In many cases, these findings will be communicated in the same manner as those in category 1, but other mechanisms, such as a promptly available finalized report, a preliminary report sent by secure fax, a phone message, and perhaps other mechanisms as defined locally, may be sufficient. The referring provider will often be expecting to receive the results promptly, which may help ensure their receipt if the results are not directly communicated. Many of these cases will come from the emergency department, where there may be well-defined methods of communication, and in outpatient cases, the refer- ring clinician will often have requested expedited communication. However, the radiologist should ensure that the results were received, understood, and acted upon appropriately.Category 3: Communication Within DaysCategory 3 findings generally do not require any immediate treatment or other action, but in the long term, they could be very significant. These are often referred to as “incidental” or “unexpected.” Many of these findings will require follow-up imaging but, in some cases, not for many months. Because they are often unexpected by the ordering provider and often inci- dental to the primary purpose of the imaging examina- tion, there is a greater risk of the findings being overlooked than when there is an acute finding that explains a patient’s presenting clinical complaints. In some cases, the provider responsible for following up on a finding will not be the same person who ordered the study. This is particularly true for patients presenting through the emergency department. The identity of the provider who will be responsible for follow-up may not even be known at the time of the examination, and therefore that provider may not receive a copy of the imaging report. For these reasons, category 3 findings present a significant risk to patients of failure to receive appropriate care or follow-up.Examples in category 3 can range from a definitive diagnosis of a new malignancy to a questionable finding that may or may not even be real and, if real, may be more likely benign than malignant.Furthermore, the documentation of the communication of the actionable findings should contain:method [discussed directly | discussed by telephone | described in message] by [ person ] to [ person ] on [<date>] at [<time>] Figure SEQ Figure \* ARABIC 52: Communication of Actionable Results section example<section> <templateId root="2.16.840.1.113883.XXXXX" /> <code code="73568-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Communication of Critical Results" /> <title>Communication of Actionable Results</title> <text>Dr. Smith was phoned at 262-966-0120 at 3:14pm on Wednesay, June 4, 2014, and the incidental finding was discussed directly with Dr. Smith to explain… </text> <! – see Actionable Results Urgency entry example --- /></section>Radiology RecommendationTemplate ID TBDNameRadiologist’s recommendation Effective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description This section provides a section with a separate heading/title to describe the radiologist’s recommendation for follow-up studies or procedures.ClassificationCDA Section LevelRelationships Invoked in Impressions sectionContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateRecommendationsection>templateId1..1SHALLIISHALL>@@root1..1SHALLUID>id1..*SHALLII>codeSHALL“18783-1” LOINC Study recommendation title>title0..1MAYSTtext>text0..1SHALLED>entry0..*MAYfollowupProcedure[*]>>procedure1..1SHALL>>@@ID1..1SHALLXML IDSee xml ID attribute>>@@moodCode1..1SHALLCSSHALLPRPProcedureCode>>>code1..1SHALLCDMAYCWECID 6028 Mammography Recommended Follow-upWhen>>>effectiveTime1..1SHOULDTSentry/procedure and @IDThe Recommendation section may include entries for recommended follow-up procedures. Each entry/procedure SHALL include an XML ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the element. Even if only one procedure entry is intantiated, the ID attribute shall be present.entry/procedure/effectiveTimeGive examples of recommended follow-up intervals using TS data typeFigure SEQ Figure \* ARABIC 53: Radiology recommendation section example<section> <templateId root="XXX" /> <code code="18783-1" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="RADIOLOGY STUDY RECOMMENDATION" /> <title>Radiology Recommendation</title> <text>Biopsy should be considered. Follow-up at short interval.</text></section>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 edition.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. Coded ObservationTemplate ID 2.16.840.1.113883.10.20.6.2.13NameCoded ObservationEffective DateVersion LabelStatusDescription ClassificationRelationships ContextOpen/ClosedopenRevision HistoryFrom Consolidated CDA r1.1Added optional targetSiteCode and methodCode with business namesNameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateCodedObservation[*]observation@@ID1..1SHALLXML IDSee xml ID attribute@@moodCode1..1SHALLSHALL"EVN">templateId1..1SHALLII>@@root1..1SHALLSHALL'2.16.840.1.113883.10.20.6.2.13'>id1..1SHALLIIObsName>code1..1SHALLCDConcept Domain ObservationTypeObsValue>value1..1SHALLCDConcept Domain ObservationValue>@@xsi:type1..1SHALLSHALL“CD”TargetSite>targetSiteCode0..1MAYCDConcept Domain ObservationSiteMethod>methodCode0..1MAYCDConcept Domain ObservationMethod>text0..1SHOULDED>>reference1..1SHALLref>>@@value1..1SHALLXML IDREF#contentRef>entryRelationship0..*MAY>@@typeCode1..1SHALLCSSHALL"SPRT"SOPInstance[*]>>observation1..1SHALLSOP Instance Observation>entryRelationship0..*MAY>@@typeCode1..1SHALLCSSHALL"SPRT"QuantityMeasurement[*]>observation1..1SHALLQuantity Measurement Table SEQ Table \* ARABIC18: Coded Observation Constraints Overviewobservation/@IDThe Coded Observation entry SHALL include an XML IDREFS ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the template. Example:The business name for a measurement might correspond to a specific item on a questionnaire, e.g., ImagingReport:Findings:CodedObservation[Q21a]:ObsValuetext/reference/@value and Related Narrative Block MarkupThe Observation entry SHOULD include a text/reference element, whose value attribute (not to be confused with the value element of the Observation class) SHALL begin with a '#' and SHALL point to its corresponding narrative in the parent section (using the approach defined in CDA Release 2, section 4.3.5.1). See Section 5.1.1.Figure SEQ Figure \* ARABIC 58: Coded observation example<observation classCode="OBS" moodCode="EVN" ID="obs-1" > <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"/> <!-- entryRelationship elements referring to SOP Instance Observations or Quantity Measurement Observations may appear here --></observation>Actionable Results UrgencyThe Actionable Results Urgency provides an audit trail of who/how/when was notified regarding actionable results findings.Template ID NameEffective DateVersion LabelStatusDescription ClassificationRelationships ContextOpen/ClosedRevision HistoryNameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateactionableResultsUrgencyact1..1SHALL>@@classCode1..1SHALLCSACT>@@moodCode1..1SHALLCSEVN>templateId1..1SHALLII>@@root1..1SHALLUIDtbd>id1..1SHALLIIresultType>code1..1SHALLCDSHOULDResult Comm typecode ={Category 1 | Category 2 | Category 3 "} (see Communication of and Categories of Actionable Findings>text0..1SHOULDED>>reference1..1SHALLref>>@@value1..1SHALL#contentRef>statusCode1..1SHALLCSSHALLCOMPLETEDResult Comm priority>priorityCode0..1SHOULDCE2.16.840.1.113883.1.11.16866 (ActPriority) = {S|UR|EM} See Table mTime>effectiveTime1..1SHALLTS SHALLDate and Time that results were communicated>performer1..1SHALL>>assignedEntity1..1SHALL>>>assignedperson1..1SHALLreporting Physician Name>>>>name1..1SHALLPN>participant1..1SHALL>@@typeCode1..1SHALLCSNOT>>participantRole1..1SHALLnotification Contact Telecom>>>telecom1..1SHALLTEL>>>playingEntity1..1SHALLnotificationContactName>>>>name1..1SHALLPNNote: could be the patientTable XX Actionable Results Urgency OverviewTable SEQ Table \* ARABIC 19: Critical Result Priority Value SetValue Set: CriticalResultPriority tbd STATICCode System(s):ActPriority 2.16.840.1.113883.5.7Description:A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Communication of Critical Results happened.CodeCode SystemPrint Name (preferred display color)EMActPriorityEmergency (Yellow)SActPriorityStat (Red)URActPriorityUrgent (Orange)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 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.Procedural Medication Procedural medication describes a substance administration that has 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). Template ID NameEffective DateVersion LabelStatusDescription ClassificationRelationships ContextOpen/ClosedRevision HistoryNameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateproceduralMedicationsubstanceAdministration1..1SHALL@@ID1..1SHALLXML IDSee xml ID attribute@@classCode1..1SHALLCSSHALL“SBADM”@@moodCode1..1SHALLCSSHALL“EVN”>templateId1..1SHALLII>@@root1..1SHALLUIDSHALL2.16.840.1.113883.10.20.22.4.16>id1..1SHALLIImedicationAdministered>text0..1SHOULDEDThe narrative text should contain whether the medication was administered pre-, peri-, or post- procedure.>>reference/@value0..1SHOULDSHALL#contentRef>statusCode1..1SHALLCSSHALL“COMPLETED”route>routeCode0..1MAYCECID 11, Route Of Administrationdose>doseQuantity0..1SHOULDPQdoseUnit>@@unit0..1SHOULD2.16.840.1.113883.1.11.12839 (UCUM Units of Measure (case sensitive))rate>rateQuantity0..1MAYPQrateUnit>@@unit1..1SHALL2.16.840.1.113883.1.11.12839 (UCUM Units of Measure (case sensitive))>consumable1..1SHALL>>manufacturedProduct1..1SHALLCD>>@@classCode1..1SHALLSHALL“MANU” >>>manufacturedMaterial1..1SHALLcodedProductName>>>>code1..1SHALLCEfreeTextProductName>>>>>original Text0..1SHOULDEDTable SEQ Table \* ARABIC9: Procedural Medication Activity Constraints text/reference/@value and Related Narrative Block MarkupThe substanceAdministration entry SHOULD include a text/reference element, whose value attribute SHALL begin with a '#' and SHALL point to its corresponding narrative in the parent section (using the approach defined in CDA Release 2, section 4.3.5.1). See Section 5.1.1.doseQuantityPre-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").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.Table SEQ Table \* ARABIC 10: 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.8Description: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. SystemPrint Namemmol/kgUCUMMilliMolesPerKiloGramfLUCUMFemtoLiterug/mLUCUMMicroGramsPerMilliLiter…Figure SEQ Figure \* ARABIC 56: 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 (???CHANGE TO DI EXAMPLE?) </text> <statusCode code="completed"/> <routeCode code="C38216" codeSystem="2.16.840.1.113883.3.26.1.1" codeSystemName="NCI Thesaurus" displayName="RESPIRATORY (INHALATION)"/> <timing <doseQuantity value="1"/> <rateQuantity value="90" unit="ml/min"/> <consumable> <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> </consumable></substanceAdministration>observationMediaTemplate ID 1.3.6.1.4.1.19376.1.4.1.4.7NameobservationMedia EntryEffective Date(Date of Final Text adoption)Version LabelStatusDraft (will change to Approved on Final Text adoption)Description The observationMedia Entry provides an in-line graphic depiction of the section findings. It is referenced by a <renderMultiMedia> element in the section text.ClassificationCDA Entry LevelRelationships ContextOpen/ClosedOpenRevision History(Date of Final Text adoption)NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateobservationMedia[*]observationMedia1..1SHALL@@ID1..1SHALLXML IDSee xml ID attribute>templateId1..1SHALLII>@@root1..1SHALLUID1.3.6.1.4.1.19376.1.4.1.4.7image>value1..1SHALLEDsee section 6.9.2>@@representation1..1SHALLCSSHALL"B64"mediaType>@@mediaType1..1SHALLCSCNESTATICValue set imageMediaTypes UIDtbdimageURI>>reference0..1MAYTELobservationMedia/@ID and Related Narrative Block MarkupThe ObservationMedia entry SHALL include an XML IDREFS ID attribute (not to be confused with the id element of the act class) used as a target of a <renderMultiMedia> element in the section/text narrative block of the parent section. See Section 5.1.2.image and referenceThe value of type ED SHALL contain an in-line encoding of a graphic using base64. The <reference> element, if present, SHALL reference a URI for the same image as included in-line.Table SEQ Table \* ARABIC 23: imageMediaTypesValue Set: imageMediaTypes UIDtbd STATICCode System(s):Internet Engineering Task Force RFC2046Description:MIME media types/subtypes allowed for images/graphics encoded in-line in CDA reports.CodeCode SystemPrint Nameimage/gifRFC2046image/tiffRFC2046image/jpegRFC2046image/pngRFC2046Procedure TechniqueTemplate ID NameEffective DateVersion LabelStatusDescription The Procedure Technique entry allows the encoding of various parameters of the image acquisition. Other details may be found in other entries (e.g., procedural medication).ClassificationRelationships ContextOpen/ClosedRevision HistoryNameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateprocedureTechniqueprocedure1..1SHALL>templateId1..1SHALLII>@@root1..1SHALLUID2.16.840.1.113883.10.20.6.2.5>id1..*SHALLprocedureCode>code1..1SHALLCDeffectiveTime>effectiveTime0..1SHOULDTS >@@value1..1SHALL >>low0..0SHALL NOT>>high0..0SHALL NOTmethodCode>methodCode0..*MAYCDSee Note 1modality>methodCode1..1SHALLCDSHALL CNEModality (CID 29)targetSite>targetSiteCode0..1SHOULDCDConcept Domain targetSite>>qualifier1..1>>>name1..1SHALLCD272741003, SNOMED, “laterality”laterality>>>value1..1SHALLCDlaterality (CID 244)Table SEQ Table \* ARABIC32: Procedure Technique Constraints Overviewidprocedure/id does not correspond to any DICOM UID, but is an arbitrary identifier for this entry.codeWhen invoked from the Current Imaging Procedure Description section, procedure/code SHALL be identical to documentationOf/serviceEvent/code in the CDA header.methodCodeWhen invoked from the Current Imaging Procedure Description section, procedure/methodCode used for modality SHALL be identical to documentationOf/serviceEvent/code/translation used for modality in the CDA header. Note 1: methodCode may be used to encode study type, contrast use, challenge, views , positioning (CID 91-94), etc.targetSiteCodeprocedure/targetSiteCode may be used to encode the specific anatomic focus, and is not necessarily identical to documentationOf/serviceEvent/code/translation used for anatomic region in the CDA header.Figure SEQ Figure \* ARABIC 70: Procedure Technique template example<procedure moodCode="EVN" classCode="PROC"> <templateId root="2.16.840.1.113883.10.20.6.2.5"/> <id root="1.2.840.6544.33.9100653988717.997527582600170"/> <procedureCode code="70548" displayName="Magnetic resonance angiography, head; with contrast material(s)" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT4"/> <effectiveTime value="20060823222400"/> <methodCode code="MR" displayName="Magnetic Resonance” codeSystem="1.2.840.10008 FIX THIS OID" codeSystemName="DCM"/> <targetSiteCode value= <targetSiteCode code="56322004" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Left PDA"> <qualifier> <value code="40415009" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="proximal" /> </qualifier> </targetSiteCode> <targetSiteCode code="56322004" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Left PDA"> <qualifier> <value code="255562008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="mid" /> </qualifier> </targetSiteCode></procedure>Quantity Measurement observation: templateId 2.16.840.1.113883.10.20.6.2.14(open)]Template ID NameEffective DateVersion LabelStatusDescription A Quantity Measurement records quantitative measurements such as linear, area, volume, and numeric measurements. If based on image data, a reference to the image may be present.ClassificationRelationships ContextOpen/ClosedRevision HistoryNameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateQuantityMeasurement[*]observation1..1SHALL@@ID1..1SHALLXML IDSee xml ID attribute@@moodCode1..1SHALLCSSHALLEVN>templateId1..1SHALLII>@@root1..1SHALLUIDSHALL2.16.840.1.113883.10.20.6.2.14>id1..1SHALLIIMeasurementName>code1..1SHALLCDConcept Domain ObservationTypeMeasurementValue>value1..1SHALLPQ>@@xsi:type1..1SHALLSHALLPQMeasurementUnit>@@unit1..1SHALLCSSHALLCNE2.16.840.1.113883.1.11.12839 (UCUM Units of Measure (case sensitive))TargetSite>targetSiteCode0..1MAYCDMethod>methodCode0..1MAYCD>text0..1SHOULD>>reference1..1SHALLref>>@@value1..1SHALL#contentRef>entryRelationship0..*MAY>@@typeCode1..1SHALLCSSHALLSPRTSOPInstance[*]>>observation1..1SHALLSOP Instance ObservationTable SEQ Table \* ARABIC47: Quantity Measurement Observation Constraints Overviewobservation/@ID The QuantityMeasurement observation entry SHALL include an XML IDREFS ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the template. Example:The business name for a measurement might correspond to a specific item on a questionnaire, e.g., ImagingReport:Findings:QuantityMeasurement[Q21a]:MeasurementValuetext/reference/@value and Related Narrative Block MarkupThe Observation entry SHOULD include a text/reference element, whose value attribute (not to be confused with the value element of the Observation class) SHALL begin with a '#' and SHALL point to its corresponding narrative in the parent section (using the approach defined in CDA Release 2, section 4.3.5.1). See Section 5.1.1.Example:The business name based production logic for a measurement might be, e.g., new ImagingReport:Findings:Content[Q21]ImagingReport:Findings:Content[Q21] = "Calcium score (Agatston): 8"new ImagingReport:Findings:QuantityMeasurement[Q21a]ImagingReport:Findings:QuantityMeasurement[Q21a]:MeasurementName = {"112058", "DCM", "Calcium score"}ImagingReport:Findings:QuantityMeasurement[Q21a]:MeasurementValue = "8"ImagingReport:Findings:QuantityMeasurement[Q21a]:MeasurementUnit = "[arb'U]"ImagingReport:Findings:QuantityMeasurement[Q21a]:Method = {"112055","DCM","Agatston"}ImagingReport:Findings:QuantityMeasurement[Q21a]:ref = "#Q21"Figure SEQ Figure \* ARABIC 76: 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" unit="mm">45 </value> <!-- entryRelationships to SOP Instance Observations may go here --></observation>Study ActTemplate ID 2.16.840.1.113883.10.20.6.2.6NameStudy ActEffective DateVersion LabelStatusDescription 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.ClassificationRelationships ContextUsed By: DICOM Object CatalogOpen/ClosedOpenRevision HistoryFrom Consolidated CDA 1.1NameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateStudy[*]act1..1SHALL@@classCode1..1SHALLCSACT@@moodCode1..1SHALLCSEVN@@ID1..1SHALLXML IDSee xml ID attribute>templateId1..1SHALLII>@@root1..1SHALL2.16.840.1.113883.10.20.6.2.6>id1..1SHALLII>@@root1..1SHALLUIDStudy Instance UID>@@extension0..0SHALL NOT>code1..1SHALLCD113014, DCM, "Study" Description>text0..1MAYEDTime>effectiveTime0..1SHOULDTS >entryRelationship1..*SHALL>@@typeCode1..1SHALLCSCOMPSeries[*]>>actSeries ActTable SEQ Table \* ARABIC66: Study Act Constraints Overviewact/@IDThe act entry SHALL include an XML IDREFS ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the template.Figure SEQ Figure \* ARABIC 87: Study act example<act classCode="ACT" moodCode="EVN" ID="S90051051"> <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"/> <effectiveTime value="20060823223232"> <!-- **** Series ****--> <entryRelationship typeCode="COMP"> <act classCode="ACT" moodCode="EVN"> ... </act> </entryRelationship></act>Series ActTemplate ID 2.16.840.1.113883.10.20.22.4.63NameSeries ActEffective DateVersion LabelStatusDescription 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.ClassificationRelationships Used By:Study ActContextOpen/ClosedopenRevision HistoryFrom Consolidated CDATable SEQ Table \* ARABIC56: Series Act Constraints OverviewNameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateSeries[*]act1..1SHALL@@classCode1..1SHALLCSACT@@moodCode1..1SHALLCSEVN@@ID1..1SHALLXML IDSee xml ID attribute>templateId1..1SHALLII>@@root1..1SHALLUID2.16.840.1.113883.10.20.22.4.63>id1..1SHALL>@@root1..1SHALLUIDSeries Instance UID>@@extension0..0SHALL NOT>code1..1SHALLCD113015 DCM Series >>qualifier1..1SHALL>>>name1..1SHALLCD121139 DCM Modality Modality>>>value1..1SHALLCDSHALL CNEValue Set 1.2.840.10008.6.1.19 (CID 29 Acquisition Modality)Description>text0..1MAYEDTime>effectiveTime0..1SHOULDTS >entryRelationship1..*SHALL>@@typeCode1..1SHALLCSCOMPSOPInstance[*]>>observation1..1SOP Instance Observationact/@IDThe act entry SHALL include an XML IDREFS ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the template.Figure SEQ Figure \* ARABIC 83: Series act example<act classCode="ACT" moodCode="EVN" ID="Series01"> <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> <!-- **** SOP Instance UID *** --> <entryRelationship typeCode="COMP"> <observation classCode="DGIMG" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.6.2.8"/> ... </observation> </entryRelationship></act>SOP Instance ObservationTemplate ID 2.16.840.1.113883.10.20.6.2.8NameSOP Instance ObservationEffective DateVersion LabelStatusDescription 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.ClassificationRelationships ContextOpen/ClosedopenRevision HistoryFrom Consolidated CDA 1.1; directly incorporates descendant templates Purpose of Reference Observation, Referenced Frames, and Boundary ObservationNameNest LevelElement/ AttributeCardElem/ Attr ConfData TypeValue ConfValue Subsidiary TemplateSOPInstance[*]observation1..1SHALL@@classCode1..1SHALLCSDGIMG@@moodCode1..1SHALLCSEVN@@ID1..1SHALLXML IDSee xml ID attribute>templateId1..1SHALLII>@@root1..1SHALLUID2.16.840.1.113883.10.20.6.2.8SOPInstanceUID>id1..*SHALLIISOP Instance UID>code1..1SHALLCDSOPClassUID>@@code1..1SHALLSTSOP Class UID>@@codeSystem1..1SHALLUIDSHALL1.2.840.10008.2.6.1>text0..1SHOULDED>@@mediaType1..1SHALLSTSHALLapplication/dicomWADOReference>>reference1..1SHALL>effectiveTime0..1SHOULDTS >entryRelationship0..*MAY>@@typeCode1..1SHALLCSSHALLSUBJSOPInstance>>observation1..1SHALLSOP Instance Observation>entryRelationship0..1MAY>@@typeCode1..1SHALLCSSHALLRSON>>observation1..1SHALL>>@@classCode1..1SHALLCSOBS>>@@moodCode1..1SHALLCSEVN>>>code1..1SHALLCDSHALLASSERTION, ActCode (2.16.840.1.113883.5.4)PurposeOfReference>>>value1..1SHALLCDSHALLCWEDYNAMICValue set 2.16.840.1.113883.11.20.9.28 (DICOMPurposeOfReference)>entryRelationship0..1MAY>@@typeCode1..1SHALLCSSHALLCOMP>>observation1..1SHALL>>@@classCode1..1SHALLCSROIBND>>@@moodCode1..1SHALLCSEVN>>code1..1SHALLCDSHALL121190, DCM, "Referenced Frames" >>entryRelationship1..1SHALL>>@@typeCode1..1SHALLCSSHALLCOMP>>>observation1..1SHALL>>>@@classCode1..1SHALLCSOBS>>>@@moodCode1..1SHALLCSEVN>>>code1..1SHALLCDSHALL113036, DCM, "Frames for Display" ReferencedFrames>>>value1..1SHALLLIST<INT>Table SEQ Table \* ARABIC64: Sop Instance Observation Constraints Overviewobservation/@IDThe observation entry SHALL include an XML IDREFS ID attribute (not to be confused with the id element of the act class) that serves as the business name discriminator associated with an instantiation of the template.entryRelationshipNo entryRelationship shall be present in a SOP Instance Observation included within a DICOM Object Catalog section.entryRelationship/@typeCode=SUBJ (SOP Instance)This template recursively invokes itself to allow a Presentation State SOP Instance reference to identify the target Image SOP Instances. Note: This is not required, as the Presentation State SOP Instance itself identifies the target Image SOP Instances.entryRelationship/@typeCode=RSON (Purpose of Reference)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.Note:In Consolidated CDA r1.1, this was defined using a separate “Purpose of Reference Observation” template, which is included directly in this specification.entryRelationship/@typeCode=COMP (Referenced Frames)A Referenced Frames 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 observation identifies frames using the same convention as DICOM, with the first frame in the referenced object being Frame 1. A Referenced Frames Observation must be used if a referenced DICOM SOP instance is a multiframe image and the reference does not apply to all frames.Note:In Consolidated CDA r1.1, this was defined using separate “Referenced Frames Observation” and “Boundary Observation” templates, which are included directly in this specification.Table SEQ Table \* ARABIC 46: DICOM Purpose of Reference Value SetValue Set: DICOMPurposeOfReference 2.16.840.1.113883.11.20.9.28 DYNAMICCode System(s):DCM 1.2.840.10008.2.16.4CodeCode SystemPrint Name121079DCMBaseline121080DCMBest illustration of finding121112DCMSource of MeasurementFigure SEQ Figure \* ARABIC 75: 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>Figure SEQ Figure \* ARABIC 86: 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=""/> <!--reference to image 1 (PA) --> </text> <effectiveTime value="20060823223232"/></observation>Additional Examples This appendix contains various examples of use from the Consolidated CDA Implementation Guide r1.1.NamesFigure SEQ Figure \* ARABIC 91: 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 SEQ Figure \* ARABIC 92: Incorrect use of name example 1 - whitespace<name><given>John</given><given>Q.</given><family>Doe</family></name>Figure SEQ Figure \* ARABIC 93: Incorrect use of Patient name example 2 - no tags<name>John Q. Doe</name>AddressesFigure SEQ Figure \* ARABIC 94: Correct use telecom address example<telecom use="WP" value="tel:555-555-1212"/> Figure SEQ Figure \* ARABIC 95: 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>TimeFigure SEQ Figure \* ARABIC 96: Correct use of IVL_TS example<effectiveTime><low value='20110907'/><high value='20110909'/></effectiveTime>Figure SEQ Figure \* ARABIC 97: Correct use of TS with precision to minute example<effectiveTime value='201109071023'/> Figure SEQ Figure \* ARABIC 98: Correct use of TS with timezone offset example<effectiveTime value='201109071023-0500'/>Figure SEQ Figure \* ARABIC 99: Incorrect use of IVL_TS example<effectiveTime value='20110907'/>Figure SEQ Figure \* ARABIC 100: Incorrecet use of TS - insufficient precision example<effectiveTime value='20110907'/> (must be precise to the minute)Figure SEQ Figure \* ARABIC 101: Incorrect use of TS when timezone offset required example<effectiveTime value='20110907'/>Use of effectiveTime with timezone where not relevant (precise only to the day)Figure SEQ Figure \* ARABIC 102: Incorrrect use of timezone offset - not enough precision example<effectiveTime value="20110907-0500'/> CD Figure SEQ Figure \* ARABIC 103: Correct use of CD with no code - example<code nullFlavor='NI'><originalText><reference value='#problem-1'/></originalText></code>Figure SEQ Figure \* ARABIC 104: Incorrect use of CD with no code - missing nullFlavor attribute example<code><originalText><reference value='#problem-1'/></originalText></code>Mapping DICOM SR to CDAEquivalent of current Part 20 Annex A – work in progress!CDA Business NameDICOM SRImagingReport: DocTypeImagingReport: documentIDImagingReport: titleCode Meaning (0008,0104) of "Equivalent Meaning of Concept Name" (TID 1210) if code is available. If code is not present: Code Meaning (0008,0104) of Concept name code sequence (0040,A043) of the root content item. .ImagingReport: creationTimeContent Date (0008,0023), Content Time (0008,0033) of the SR Document General ModuleImagingReport: confidentialityImagingReport: languageCodeCode Sequence (0040,A043) of "Language of Content Item and Descendants" code content item (TID 1204): <code value as code property, coding scheme designator as codeSystemName property, code meaning as displayName property> (as defined by the IETF (Internet Engineering Task Force) RFC 3066)ImagingReport: setIdImagingReport: versionNumberImagingReport: Patient:IDImagingReport: Patient:AddrImagingReport: Patient:TeleImagingReport: Patient:NameImagingReport: Patient:GenderImagingReport: Patient:BirthTimeImagingReport: Patient:providerOrgNameImagingReport: Patient:providerOrgTelImagingReport: Patient:providerOrgAddrImagingReport: SigningTimeVerification DateTime (0040,A030) within Verifying Observer Sequence.ImagingReport: SignerIDVerifying Observer Identification Code Sequence (0040,A088): code value as identifierImagingReport: SignerAddrImagingReport: SignerTelImagingReport: SignerNameVerifying Observer Name (0040,A075) within Verifying Observer SequenceImagingReport: AuthorIDImagingReport: AuthorAddrImagingReport: AuthorTelImagingReport: AuthorNameImagingReport: CustodianOrgIDImagingReport: CustodianOrgNameImagingReport: CustodianOrgAddrImagingReport: CustodianOrgTelImagingReport: encounterIDAdmission Id (0038,0010) and Issuer of Admission ID Sequence (0038;0014) of the Patient Study ModuleImagingReport: encounterTimeImagingReport: HealthcareFacilityNameImagingReport: HealthcareFacilityAddressImagingReport: HealthcareProviderOrganizationNameImagingReport: AttendingPhysicianNamePhysician(s) of Record (0008,1048)ImagingReport: OrderPlacerNumber@extension = TEXT Value where Concept Code = (121021, DCM, "FillerNumber") @root = TEXT where (110190, DCM, "Issuer of Identifier") as CONCEPT MOD to (121021, DCM, "FillerNumber")ImagingReport: OrderFilllerNumberImagingReport: AccessionNumberImagingReport: OrderedCodeRequested Procedure Code Sequence (0032,1064) within the Referenced Request Sequence (0040,A370)ImagingReport: OrderPriorityImagingReport: ProcedureCodeImagingReport: ModalityCodeImagingReport: AnatomicRegionCodeImagingReport: ProcedureTimeImagingReport: Performer IDImagingReport: PerformerNameImagingReport: ReferrerAddrPerson's Address (0040,1102) of Referring Physician Identification Sequence (0008,0096): DICOM ST (Short Text) String Data TypeImagingReport: ReferrerTelPerson's Telephone Numbers (0040,1103) of Referring Physician Identification Sequence (0008,0096): DICOM LO (Long String) String Data TypeImagingReport: ReferrerNameReferring Physician's Name (0008,0090)ImagingReport: TranscriptionistIDPerson Identification Code Sequence (0040,1101) within Participant Sequence (0040,A07A) where Participation Type (0040,A080) equals "ENT" (Data Enterer): code value as identifierImagingReport: TranscriptionistNamePerson Name (0040,A123) of Participant Sequence (0040,A07A) where Participation Type (0040,A080) equals "ENT" (Data Enterer).ImagingReport: TransformedDocumentIDSOP Instance UID (0008,0018) of original DICOM SR Composite Object. 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 entries 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.PS3.16 - Content Mapping ResourceCID 7021? Imaging Report Document TitlesType:ExtensibleVersion:yyyymmddTable?CID 7021.?Imaging Report Document TitlesCodeCoding SchemeCommon Display Name18748-4LOINC Diagnostic Imaging Report75238-6LOINC Interventional radiology procedure note18747-6LOINC CT Report18755-9LOINC MRI Report18760-9LOINC Ultrasound Report18757-5LOINC Nuclear Medicine Report17787-3LOINC Thyroid Scan Report18758-3LOINC PET Scan Report11522-0LOINC Echocardiography Report18746-8LOINC Colonoscopy Report18751-8LOINC Endoscopy Report11525-3LOINC Obstetrical Ultrasound Report43468-8LOINC Radiography Report49512-7LOINC Fluoroscopy Report24606-6LOINC Mammography Screening Report24605-8 LOINC Diagnostic Mammography Report38269-7LOINC Bone Density Report ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download