Id2.16.840.1.113883.10.20.22.1.5Effective Date2015‑08‑01
Statusdraft DraftVersion Label2.1
NameDiagnosticImagingReportV3Display NameDiagnostic Imaging Report (V3)
Description
A Diagnostic Imaging Report (DIR) is a document that contains a consulting specialist’s interpretation of image data. It conveys the interpretation to the referring (ordering) physician and becomes part of the patient’s medical record. It is for use in Radiology, Endoscopy, Cardiology, and other imaging specialties.
ContextPathname //
ClassificationCDA Document Level Template
Open/ClosedOpen (other than defined elements are allowed)
Used by / Uses
Used by 1 transaction and 0 templates, Uses 13 templates
Used by as NameVersion
2.16.840.1.113883.3.1937.99.3.4.24Transactionfinal Diagnostic Imaging Report (V3)2015‑08‑01
Uses as NameVersion
2.16.840.1.113883.10.20.6.1.1Containmentdraft DICOM Object Catalog Section - DCM 121181 (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.1.2Containmentdraft Findings Section (DIR) (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.2.1Containmentdraft Physician Reading Study Performer (V2) (2.1)2014‑06‑09
2.16.840.1.113883.10.20.6.2.2Containmentdraft Physician of Record Participant (V2) (2.1)2014‑06‑09
2.16.840.1.113883.10.20.6.2.3Containmentdraft Fetus Subject Context (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.2.4Containmentdraft Observer Context (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.2.5Containmentdraft Procedure Context (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.2.8Containmentdraft SOP Instance Observation (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.2.12Containmentdraft Text Observation (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.2.13Containmentdraft Code Observations (2.1)2015‑08‑13
2.16.840.1.113883.10.20.6.2.14Containmentdraft Quantity Measurement Observation (2.1)2015‑08‑13
2.16.840.1.113883.10.20.22.5.1.1Containmentdraft US Realm Person Name (PN.US.FIELDED) (2.1)2015‑08‑13
2.16.840.1.113883.10.20.22.5.3Containmentdraft US Realm Date and Time (DT.US.FIELDED) (2.1)2015‑08‑13
RelationshipSpecialization: template 2.16.840.1.113883.10.12.1 CDA ClinicalDocument (2005‑09‑07)
ref
ad1bbr-

Specialization: template 2.16.840.1.113883.10.20.22.1.1 US Realm Header (V3) (2015‑08‑01)
Version: template 2.16.840.1.113883.10.20.22.1.5 Diagnostic Imaging Report (2013‑01‑31)
ItemDTCardConfDescriptionLabel
cda:ClinicalDocument
R When asserting this templateId, all C-CDA 2.1 section and entry templates that had a previous version in C-CDA R1.1 SHALL include both the C-CDA 2.1 templateId and the C-CDA R1.1 templateId root without an extension. See C-CDA R2.1 Volume 1 - Design Considerations for additional detail (CONF:1198-32937).
DiagdotsrtV3
cda:templateId
II1 … 1MC-CDA R1.1 templateId root without an extensionCONFdots2936
@root
uid1 … 1F2.16.840.1.113883.10.20.22.1.5
cda:templateId
II1 … 1MSHALL contain exactly one [1..1] templateId (CONF:1198-8404) such that itCONFdots8404
@root
uid1 … 1F2.16.840.1.113883.10.20.22.1.5CONFdots0042
 SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.5" (CONF:1198-10042).
@extension
st1 … 1F2014-06-09CONFdots2515
 SHALL contain exactly one [1..1] @extension="2014-06-09" (CONF:1198-32515).
cda:id
II1 … 1SHALL contain exactly one [1..1] id (CONF:1198-30932).CONFdots0932
@root
uid1 … 1RThis id SHALL contain exactly one [1..1] @root (CONF:1198-30933).CONFdots0933
 Schematron assertrolered error 
 test//cda:ClinicalDocument/cda:id[contains(@root,'.') and (starts-with(@root,'0.') or starts-with(@root,'1.') or starts-with(@root,'2.'))] 
 MessageThe ClinicalDocument/id/@root attribute SHALL be a syntactically correct OID, and SHALL NOT be a UUID. 
 Schematron assertrolered error 
 teststring-length(//cda:ClinicalDocument/cda:id/@root)<65 
 MessageOIDs SHALL be no more than 64 characters in length. 
cda:code
1 … 1SHALL contain exactly one [1..1] code (CONF:1198-14833).

Preferred code is 18748-4 LOINC Diagnostic Imaging Report
CONFdots4833
cda:informant
NPSHALL NOT contain [0..0] informant (CONF:1198-8410).CONFdots8410
cda:informationRecipient
0 … *MAY contain zero or more [0..*] informationRecipient (CONF:1198-8411).CONFdots8411
 ConstraintThe physician requesting the imaging procedure (ClinicalDocument/participant[[]@typeCode=REF[]]/associatedEntity), if present, *SHOULD* also be recorded as an informationRecipient, unless in the local setting another physician (such as the attending physician for an inpatient) is known to be the appropriate recipient of the report. When no referring physician is present, as in the case of self-referred screening examinations allowed by law, the intendedRecipient *MAY* be absent. The intendedRecipient *MAY* also be the health chart of the patient, in which case the receivedOrganization *SHALL* be the scoping organization of that chart.
cda:participant
0 … 1MAY contain zero or one [0..1] participant (CONF:1198-8414) such that it

If participant is present, the associatedEntity/associatedPerson element SHALL be present and SHALL represent the physician requesting the imaging procedure (the referring physician AssociatedEntity that is the target of ClincalDocument/participant@typeCode=REF).
CONFdots8414
cda:associatedEntity
1 … 1MSHALL contain exactly one [1..1] associatedEntity (CONF:1198-31198).CONFdots1198
cda:associatedPerson
1 … 1Contains 2.16.840.1.113883.10.20.22.5.1.1 US Realm Person Name (PN.US.FIELDED) (2015‑08‑13)CONFdots1199
cda:inFulfillmentOf
0 … *MAY contain zero or more [0..*] inFulfillmentOf (CONF:1198-30936).

An inFulfillmentOf element represents the Placer Order that is either a group of orders (modeled as PlacerGroup in the Placer Order RMIM of the Orders & Observations domain) or a single order item (modeled as ObservationRequest in the same RMIM). This optionality reflects two major approaches to the grouping of procedures as implemented in the installed base of imaging information systems. These approaches differ in their handling of grouped procedures and how they are mapped to identifiers in the Digital Imaging and Communications in Medicine (DICOM) image and structured reporting data. The example of a CT examination covering chest, abdomen, and pelvis will be used in the discussion below. In the IHE Scheduled Workflow model, the Chest CT, Abdomen CT, and Pelvis CT each represent a Requested Procedure, and all three procedures are grouped under a single Filler Order. The Filler Order number maps directly to the DICOM Accession Number in the DICOM imaging and report data. A widely deployed alternative approach maps the requested procedure identifiers directly to the DICOM Accession Number. The Requested Procedure ID in such implementations may or may not be different from the Accession Number, but is of little identifying importance because there is only one Requested Procedure per Accession Number. There is no identifier that formally connects the requested procedures ordered in this group.
CONFdots0936
cda:order
1 … 1MThe inFulfillmentOf, if present, SHALL contain exactly one [1..1] order (CONF:1198-30937).CONFdots0937
cda:id
II1 … *This order SHALL contain at least one [1..*] id (CONF:1198-30938).CONFdots0938
cda:documentationOf
1 … 1MSHALL contain exactly one [1..1] documentationOf (CONF:1198-8416) such that it

Each 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 vocabulary to use for describing this event. 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, serviceEvent/id is the ID of the Requested Procedure.
CONFdots8416
cda:serviceEvent
1 … 1MContains 2.16.840.1.113883.10.20.6.2.1 Physician Reading Study Performer (V2) (2014‑06‑09)CONFdots8431
@classCode
cs1 … 1FACTCONFdots8430
 SHALL contain exactly one [1..1] @classCode="ACT" (CodeSystem: HL7ActClass urn:oid:2.16.840.1.113883.5.6 STATIC) (CONF:1198-8430).
cda:id
II0 … *RSHOULD contain zero or more [0..*] id (CONF:1198-8418).CONFdots8418
cda:code
1 … 1SHALL contain exactly one [1..1] code (CONF:1198-8419).CONFdots8419
cda:relatedDocument
0 … 1MAY contain zero or one [0..1] relatedDocument (CONF:1198-8432).

A DIR may have three types of parent document: • A superseded version that the present document wholly replaces (typeCode = RPLC). DIRs may go through stages of revision prior to being legally authenticated. Such early stages may be drafts from transcription, those created by residents, or other preliminary versions. Policies not covered by this specification may govern requirements for retention of such earlier versions. Except for forensic purposes, the latest version in a chain of revisions represents the complete and current report. • An original version that the present document appends (typeCode = APND). When a DIR is legally authenticated, it can be amended by a separate addendum document that references the original. • A source document from which the present document is transformed (typeCode = XFRM). A DIR may be created by transformation from a DICOM Structured Report (SR) document or from another DIR. An example of the latter case is the creation of a derived document for inclusion of imaging results in a clinical document.
CONFdots8432
 ConstraintWhen a Diagnostic Imaging Report has been transformed from a DICOM SR document, relatedDocument/@typeCode *SHALL* be XFRM, and relatedDocument/parentDocument/id *SHALL* contain the SOP Instance UID of the original DICOM SR document.
cda:parentDocument
1 … 1MThe relatedDocument, if present, SHALL contain exactly one [1..1] parentDocument (CONF:1198-32089).CONFdots2089
cda:id
II1 … 1This parentDocument SHALL contain exactly one [1..1] id (CONF:1198-32090).CONFdots2090
 Schematron assertrolered error 
 testcontains(@root,'.') and (starts-with(@root,'0.') or starts-with(@root,'1.') or starts-with(@root,'2.'))] 
 MessageOIDs *SHALL* be represented in dotted decimal notation, where each decimal number is either 0 or starts with a nonzero digit. More formally, an OID *SHALL* be in the form of the regular expression: ([[]0-2[]])(.([[]1-9[]][[]0-9[]][*]|0))+ 
 Schematron assertrolered error 
 teststring-length(@root)<65 
 MessageOIDs *SHALL* be no more than 64 characters in length 
cda:componentOf
0 … 1MAY contain zero or one [0..1] componentOf (CONF:1198-30939).

The id element of the encompassingEncounter represents the identifier for the encounter. When the diagnostic imaging procedure is performed in the context of a hospital stay or an outpatient visit for which there is an Encounter Number, that number should be present as the ID of the encompassingEncounter. The effectiveTime represents the time interval or point in time in which the encounter took place. The encompassing encounter might be that of the hospital or office visit in which the diagnostic imaging procedure was performed. If the effective time is unknown, a nullFlavor attribute can be used.
CONFdots0939
cda:encompassingEncounter
1 … 1MThe componentOf, if present, SHALL contain exactly one [1..1] encompassingEncounter (CONF:1198-30940).

The id element of the encompassingEncounter represents the identifier for the encounter. When the diagnostic imaging procedure is performed in the context of a hospital stay or an outpatient visit for which there is an Encounter Number, that number should be present as the ID of the encompassingEncounter. The effectiveTime represents the time interval or point in time in which the encounter took place. The encompassing encounter might be that of the hospital or office visit in which the diagnostic imaging procedure was performed. If the effective time is unknown, a nullFlavor attribute can be used.
CONFdots0940
cda:id
II1 … *This encompassingEncounter SHALL contain at least one [1..*] id (CONF:1198-30941).

In the case of transformed DICOM SR documents, an appropriate null flavor *MAY* be used if the id is unavailable.
CONFdots0941
cda:effectiveTime
1 … 1This encompassingEncounter SHALL contain exactly one [1..1] US Realm Date and Time (DT.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.3) (CONF:1198-30943).
Contains 2.16.840.1.113883.10.20.22.5.3 US Realm Date and Time (DT.US.FIELDED) (2015‑08‑13)
CONFdots0943
cda:responsibleParty
0 … 1This encompassingEncounter MAY contain zero or one [0..1] responsibleParty (CONF:1198-30945).CONFdots0945
cda:assignedEntity
1 … 1MThe responsibleParty, if present, SHALL contain exactly one [1..1] assignedEntity (CONF:1198-30946).CONFdots0946
 Schematron assertrolered error 
 testcda:assignedPerson | cda:representedOrganization 
 Message*SHOULD* contain zero or one [[]0..1[]] assignedPerson *OR* contain zero or one [[]0..1[]] representedOrganization 
cda:encounterParticipant
0 … 1RThis encompassingEncounter SHOULD contain zero or one [0..1] Physician of Record Participant (V2) (identifier: urn:hl7ii:2.16.840.1.113883.10.20.6.2.2:2014-06-09) (CONF:1198-30948).
Contains 2.16.840.1.113883.10.20.6.2.2 Physician of Record Participant (V2) (2014‑06‑09)
CONFdots0948
cda:component
1 … 1MSHALL contain exactly one [1..1] component (CONF:1198-14907).CONFdots4907
cda:structuredBody
1 … 1MThis component SHALL contain exactly one [1..1] structuredBody (CONF:1198-30695).CONFdots0695
cda:component
1 … 1Contains 2.16.840.1.113883.10.20.6.1.2 Findings Section (DIR) (2015‑08‑13)CONFdots0696
cda:component
0 … 1RContains 2.16.840.1.113883.10.20.6.1.1 DICOM Object Catalog Section - DCM 121181 (2015‑08‑13)CONFdots0698
cda:component
0 … *This structuredBody MAY contain zero or more [0..*] component (CONF:1198-31055) such that itCONFdots1055
cda:section
1 … 1MSHALL contain exactly one [1..1] section (CONF:1198-31056).CONFdots1056
 ConstraintAll sections defined in the DIR Section Type Codes table *SHALL* be top-level sections. *SHALL* contain at least one text element or one or more component elements
cda:code
CE1 … 1This section SHALL contain exactly one [1..1] code (CONF:1198-31057).CONFdots1057
cda:title
ST0 … 1RThis section SHOULD contain zero or one [0..1] title (CONF:1198-31058).

There is no equivalent to section/title in DICOM SR, so for a CDA to SR transformation, the section/code will be transferred and the title element will be dropped.
CONFdots1058
cda:text
SD.TEXT0 … 1RThis section SHOULD contain zero or one [0..1] text (CONF:1198-31059).

The text elements (and their children) *MAY* contain Web Access to DICOM Persistent Object (WADO) references to DICOM objects by including a linkHtml element where @href is a valid WADO URL and the text content of linkHtml is the visible text of the hyperlink.
CONFdots1059
 ConstraintIf clinical statements are present, the section/text *SHALL* represent faithfully all such statements and *MAY* contain additional text. All text elements *SHALL* contain content. Text elements *SHALL* contain PCDATA or child elements.
cda:subject
0 … *Contains 2.16.840.1.113883.10.20.6.2.3 Fetus Subject Context (2015‑08‑13)CONFdots1215
cda:author
0 … *This author element is used when the author of a section is different from the author(s) listed in the Header
Contains 2.16.840.1.113883.10.20.6.2.4 Observer Context (2015‑08‑13)
CONFdots1217
cda:entry
0 … *If the service context of a section is different from the value specified in documentationOf/serviceEvent, then the section SHALL contain one or more entries containing Procedure Context (templateId 2.16.840.1.113883.10.20.6.2.5), which will reset the context for any clinical statements nested within those elements
Contains 2.16.840.1.113883.10.20.6.2.5 Procedure Context (2015‑08‑13)
CONFdots1213
cda:entry
0 … *Contains 2.16.840.1.113883.10.20.6.2.12 Text Observation (2015‑08‑13)CONFdots1357
cda:entry
0 … *Contains 2.16.840.1.113883.10.20.6.2.13 Code Observations (2015‑08‑13)CONFdots1359
cda:entry
0 … *Contains 2.16.840.1.113883.10.20.6.2.14 Quantity Measurement Observation (2015‑08‑13)CONFdots1361
cda:entry
0 … *Contains 2.16.840.1.113883.10.20.6.2.8 SOP Instance Observation (2015‑08‑13)CONFdots1363
cda:component
0 … *This section MAY contain zero or more [0..*] component (CONF:1198-31208).CONFdots1208
 Constraint*SHALL* contain child elements