Non-Normative Content The Normative content for these specifications may be found on the HL7, IHE, and HITSP web sites.

Diagnostic Imaging Report

[ClinicalDocument: templateId 2.16.840.1.113883.10.20.22.1.5]

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.

Diagnostic Imaging Report Header Constraints

Diagnostic Imaging Report Body Constraints

  1. SHALL contain exactly one [1..1] templateId ( CONF:8404, CONF:10042 ) such that it
    1. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.5"
  2. SHALL conform to General Header Constraints template (templateId: 2.16.840.1.113883.10.20.22.1.1) (CONF:9405, CONF:10041)
  3. SHALL contain exactly one [1..1] code (CONF:14833), where the @code SHALL be selected from ValueSet DIRDocumentTypeCodes 2.16.840.1.113883.11.20.9.32 DYNAMIC (CONF:14834)
    • Given that DIR documents may be transformed from established collections of imaging reports already stored with their own type codes, there is no static set of Document Type codes. The set of LOINC codes listed in the DIR LOINC Document Type Codes table may be extended by additions to LOINC and supplemented by local codes as translations.
      The DIR document recommends use of a single document type code, 18748-4 "Diagnostic Imaging Report", with further specification provided by author or performer, setting, or specialty. Some of these codes in the DIR LOINC Document Type Codes table are pre-coordinated with either the imaging modality, body part examined, or specific imaging method such as the view.  Use of these codes is not recommended, as this duplicates information potentially present with the header. 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 Version 2.36, June 30, 2011, and consists of codes whose scale is DOC and that refer to reports for diagnostic imaging procedures.

  4. SHALL contain exactly one [1..1] id (CONF:5363)
  5. SHALL contain [0..0] informant (CONF:8410)
    1. Contains exactly one [1..1] CDA Informant12
  6. MAY contain zero or more [0..*] informationRecipient (CONF:8411)
    • The physician requesting the imaging procedure (ClincalDocument/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.

    1. Contains exactly one [1..1] CDA Information Recipient
  7. MAY contain zero or one [0..1] participant (CONF:8414)
    1. This participant SHALL contain exactly one [1..1] associatedEntity (CONF:8415)
      1. This associatedEntity SHALL contain exactly one [1..1] associatedPerson (CONF:8415)
        1. This associatedPerson SHALL contain exactly one [1..1] name (CONF:9406)
  8. MAY contain zero or one [0..1] inFulfillmentOf

    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 and 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.
    In both cases, inFulfillmentOf/order/id is mapped to the DICOM Accession Number in the imaging data.

  9. SHALL contain exactly one [1..1] documentationOf (CONF:8416)
    1. This documentationOf SHALL contain exactly one [1..1] serviceEvent (CONF:8431)
      1. This serviceEvent SHALL contain exactly one [1..1] @classCode="ACT" Act (CodeSystem: 2.16.840.1.113883.5.6 HL7ActClass) (CONF:8430)
      2. This serviceEvent SHALL contain exactly one [1..1] code (CONF:8419)

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

      3. This serviceEvent SHOULD contain at least one [1..*] id (CONF:8418)
      4. This serviceEvent SHOULD contain zero or more [0..*] performer, where its type is Physician Reading Study Performer (CONF:8422)
        1. Contains exactly one [1..1] Physician Reading Study Performer (templateId: 2.16.840.1.113883.10.20.6.2.1)
  10. MAY contain zero or one [0..1] relatedDocument (CONF:8432)

    When a Diagnostic Imaging Report has been transformed from a DICOM SR document, relatedDocument/@typeCode SHALL be XFRM, and relatedDocument/parentDocument/id SHALL contain the SOP Instance UID of the original DICOM SR document.

    1. This relatedDocument The relatedDocument/id/@root attribute SHALL be a syntactically correct OID, and SHALL NOT be a UUID. (CONF:10030)
  11. MAY contain zero or one [0..1] componentOf (CONF:8434)
    1. This componentOf SHALL contain exactly one [1..1] encompassingEncounter (CONF:8449)
      1. This encompassingEncounter SHALL contain exactly one [1..1] effectiveTime (CONF:8437)
      2. This encompassingEncounter SHALL contain at least one [1..*] id (CONF:8435)

        In the case of transformed DICOM SR documents, an appropriate null flavor MAY be used if the id is unavailable.

      3. This encompassingEncounter SHOULD contain zero or one [0..1] encounterParticipant, where its type is Physicianof Record Participant (CONF:8448)
        1. Contains exactly one [1..1] Physicianof Record Participant (templateId: 2.16.840.1.113883.10.20.6.2.2)
      4. This encompassingEncounter MAY contain zero or one [0..1] responsibleParty (CONF:8438)
        1. This responsibleParty SHALL contain exactly one [1..1] assignedEntity (CONF:9407)
          1. This assignedEntity SHOULD contain zero or one [0..1] assignedPerson OR contain zero or one [0..1] representedOrganization (CONF:8439)
  12. SHALL contain exactly one [1..1] component (CONF:8776)
    1. Contains exactly one [1..1] Findings Section (templateId: 2.16.840.1.113883.10.20.6.1.2)
  13. SHOULD contain zero or one [0..1] component (CONF:15141)
    1. Contains exactly one [1..1] DICOM Object Catalog Section (templateId: 2.16.840.1.113883.10.20.6.1.1)
  14. This code SHOULD contain zero or one [0..1] @code="18748-4" Diagnostic Imaging Report (CodeSystem: LOINC2.16.840.1.113883.6.1) (CONF:8409)
  15. The DICOM Object Catalog section (templateId 2.16.840.1.113883.10.20.6.1.1), if present, SHALL be the first section in the document Body
  16. With the exception of the DICOM Object Catalog (templateId 2.16.840.1.113883.10.20.6.1.1), all sections within the Diagnostic Imaging Report content SHOULD contain a title element (CONF:9409)
  17. The section/code SHOULD be selected from LOINC or DICOM for sections not listed in the DIR Section Type Codes table (CONF:9410)
  18. All sections defined in the DIR Section Type Codes table SHALL be top-level sections (CONF:9411)
  19. A section element SHALL have a code element which SHALL contain a LOINC code or DCM code for sections which have no LOINC equivalent. This only applies to sections described inthe DIR Section Type Codes table (CONF:9412)
  20. Apart from the DICOM Object Catalog (templateId 2.16.840.1.113883.10.20.6.1.1), all other instances of section SHALL contain at least one text element or one or more component elements (CONF:9413)
  21. All text or component elements SHALL contain content. text elements SHALL contain PCDATA or child elements, and component elements SHALL contain child elements (CONF:9414)
  22. 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
  23. If clinical statements are present, the section/text SHALL represent faithfully all such statements and MAY contain additional text

Diagnostic Imaging Report Example

<?xml version="1.0" encoding="UTF-8"?>
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" xsi:schemaLocation="urn:hl7-org:v3 CDA.xsd">
  <typeId root="2.16.840.1.113883.1.3"/>
  <id root="MDHT" extension="1951539998"/>
  <code code="340809725"/>
  <title>TEXT FOR TITLE</title>
  <effectiveTime/>
  <confidentialityCode code="1885595934"/>
  <setId root="MDHT" extension="61418085-7097-461b-a727-1a61e8a58a3a"/>
  <versionNumber value="1"/>
  <recordTarget>
    <typeId root="2.16.840.1.113883.1.3"/>
    <patientRole/>
  </recordTarget>
  <author>
    <typeId root="2.16.840.1.113883.1.3"/>
    <time/>
    <assignedAuthor/>
  </author>
  <informant/>
  <custodian/>
  <informationRecipient/>
  <participant>
    <associatedEntity>
      <associatedPerson/>
    </associatedEntity>
  </participant>
  <inFulfillmentOf>
    <order/>
  </inFulfillmentOf>
  <documentationOf>
    <serviceEvent classCode="ACT">
      <id root="MDHT" extension="850940471"/>
      <code code="2031897318"/>
      <performer/>
    </serviceEvent>
  </documentationOf>
  <relatedDocument>
    <parentDocument/>
  </relatedDocument>
  <componentOf>
    <encompassingEncounter>
      <id root="MDHT" extension="42006015"/>
      <effectiveTime>
        <low value="2013"/>
        <high value="2013"/>
      </effectiveTime>
      <responsibleParty/>
      <encounterParticipant/>
    </encompassingEncounter>
  </componentOf>
  <component>
    <structuredBody>
      <component>
        <section>
          <typeId root="2.16.840.1.113883.1.3"/>
          <id root="MDHT" extension="2128783882"/>
          <code code="1017426974"/>
          <title>TEXT FOR TITLE</title>
          <confidentialityCode code="2045993579"/>
        </section>
      </component>
      <component>
        <section>
          <typeId root="2.16.840.1.113883.1.3"/>
          <id root="MDHT" extension="655688733"/>
          <code code="1072277132"/>
          <title>TEXT FOR TITLE</title>
          <confidentialityCode code="1140992329"/>
          <entry>
            <act>
              <typeId root="2.16.840.1.113883.1.3"/>
              <id root="MDHT" extension="23113925"/>
              <code code="1519717286"/>
              <effectiveTime>
                <low value="2013"/>
                <high value="2013"/>
              </effectiveTime>
              <entryRelationship>
                <act/>
              </entryRelationship>
            </act>
          </entry>
        </section>
      </component>
    </structuredBody>
  </component>
</ClinicalDocument>