Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-25243

Link DocumentReference to DiagnosticReport

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Applied (View Workflow)
    • Medium
    • Resolution: Not Persuasive with Modification
    • FHIR Core (FHIR)
    • R4
    • Orders & Observations
    • DiagnosticReport
      DocumentReference
    • Hide

      The commenter confuses the workflow of US EHRs and business decision that are described in USCore with the FHIR Core specification. There are no requirements that DocReference exist for every DiagnosticReport presentedForm in the FHIR Standard. Therefore there is no need to change the specification.

      However, based on the referenced Zulip Chat change the following text in the introduction to DiagnosticReport from

      "Other diagnostics - Cardiology, Gastroenterology etc." to
      "Other diagnostics such as Cardiology, Gastroenterology etc."

      Show
      The commenter confuses the workflow of US EHRs and business decision that are described in USCore with the FHIR Core specification. There are no requirements that DocReference exist for every DiagnosticReport presentedForm in the FHIR Standard. Therefore there is no need to change the specification. However, based on the referenced Zulip Chat change the following text in the introduction to DiagnosticReport from "Other diagnostics - Cardiology, Gastroenterology etc." to "Other diagnostics such as Cardiology, Gastroenterology etc."
    • John Moehrke / Rob Hausam: 8-0-5
    • Clarification
    • Non-substantive

    Description

      As already been pointed out in FHIR-19250 and FHIR-19249, the boundaries between DocumentReference and DiagnosticReport are somewhat unsharp. In fact, both resources match with their definition to a large set of possible documents. For implementers it is hard to distinguish the right resource, ending up in recommendations as given in theĀ US Core Clinical Notes Guidance:

      In order to enable consistent access to scanned narrative-only clinical reports the Argonaut Clinical Note Server SHALL expose these reports through both DiagnosticReport and DocumentReference [...]

      Following this recommendation, duplicate resources link to the very same content, to make sure everyone finds all relevant documents in a server. Then at least those two resources should refer to each other. In the current build of DiagnosticReport (as of 2019-11-22) the DiagnosticReport.media.link has been made a DocumentReference (unlike R4 release).
      In the resource DocumentReference on the other hand, only DocumentReference.context.related could be used to link a DiagnosticReport.
      This is not self-explanatory at all and a compatible implementation won't be assured among all implementers.

      Please clarify these specific use cases of having both resources for one single document and describe a designated way of linking both to each other.

      Attachments

        Issue Links

          Activity

            People

              john_moehrke John Moehrke
              christophgraumann Christoph Graumann (Inactive)
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: