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

Update Clinical Safety Checklist

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: High High
    • FHIR Core (FHIR)
    • STU3
    • FHIR Infrastructure
    • Clinical Safety (safety)
    • Hide
      • Add a 21th bullet stating:

      "For content that reasonably be exposed using more than one FHIR resource, care must be taken to ensure that the client will find the information they need. One pattern to ensure this is to expose data through each applicable resource on the REST endpoint. See discussion on [wiki page]"

      • Create a wiki page with the attached materials and some context.
      Show
      Add a 21th bullet stating: "For content that reasonably be exposed using more than one FHIR resource, care must be taken to ensure that the client will find the information they need. One pattern to ensure this is to expose data through each applicable resource on the REST endpoint. See discussion on [wiki page] " Create a wiki page with the attached materials and some context.
    • Josh Mandel/Bryn Rhodes: 9-0-1
    • Enhancement
    • Non-substantive
    • STU3

    Description

      Following the Baltimore connectathon and PC/SD joint meeting on Tues Q2, this tracker is being logged to request an update to the clinical safety checklist.

      Refer to the attached PPT and Excel spreadsheet to view the Venn diagram illustrating that there is overlap between DocumentReference and DiagnosticReport. For example, a scanned CBC report could be considered both a DocumentReference (since it was a scanned document) as well as a DiagnosticReport (due to the document type / contents).

      If a client is querying to get all Lab Reports, Radiology Reports, or Cardiology Reports using DiagnosticReport alone, then they might miss those reports that are only exposed as a DocumentReference. Likewise, if a client is querying to get all documents available, then they might miss those documents that were exposed via DiagnosticReport only.

      Other trackers were logged to update DiagnosticReport (GF#19249) and DocumentReference (GF#19250) boundaries. This tracker is focused only on the clinical safety checklist.

      While the attached materials are specific to DiagnosticReport and DocumentReference, the checklist item could be broader in nature given there could be other resources using Attachment data type that may have similar considerations (e.g. overlap with DocumentReference). Or, even more broadly, per Grahame, degenerate poorly populated resources are hard to differentiate, which is a risk that should at least be acknowledged, do clients can decide how to best mitigate (e.g. query multiple resources to get all of the desired data)

      Attachments

        Activity

          People

            Unassigned Unassigned
            michelle.m.miller Michelle Miller
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: