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

Clarify Communication Scope and Usage

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Resolved - change required (View Workflow)
    • Priority: Medium
    • Resolution: Persuasive with Modification
    • Specification:
      FHIR Core (FHIR)
    • Raised in Version:
      STU3
    • Work Group:
      Patient Care
    • Related Artifact(s):
      Communication
    • Resolution Description:
      Hide

      Definition

      A clinical or business level record of information being transmitted or shared; e.g. an alert that was sent to a responsible provider, a public health agency communication to a provider/reporter in response to a case report for a reportable condition. 

      Scope 

      The purpose of a Communication resource is to surface that data was shared to track adherence to guidelines or protocols or to provide business documentation of actions taken.

      Communication can also be used as part of an information exchange to provide context about the information sharing occurring.  Please see [TBD] for guidance on when this is appropriate.

      Communication is one of the event resources in the FHIR workflow specification.

      This resource is a record of a communication even if it is planned or has failed. A communication is a record of the conveyance of information from one entity, a sender, to another entity, a receiver. The sender and receivers may be patients, practitioners, related persons, organizations, or devices. Communication use cases include:

      • A reminder or alert delivered to a responsible provider
      • A recorded notification from the nurse to the on-call physician (or any other specified person) that a patient's temperature exceeds a value
      • A response from a public health agency to a provider caring for a patient presenting with a communicable disease reportable to the public health agency
      • Patient educational material sent by a provider to a patient
      • Unable to deliver lab results to ordering physician
      • Submission of supplementary health information to a payer in support of a claim

      Non-patient specific communication use cases may include:

      • A nurse call from a hall bathroom
      • Advisory for battery service from a pump

      Note

      Using Communication to wrap or accompany data

      In FHIR, data is typically shared between systems without any need for the Communication resource to accompany or contain the data being shared, i.e. all FHIR exchanges are communications of some form, but that doesn't mean they need the Communication resource.  However, in some cases, when data is shared there is a need to provide context about why the data is being conveyed and Communication is one of the mechanisms that FHIR provides that can share this context.  Specifically, Communication allows conveying information about reasons for sharing, encounter that provides context for sharing, order or protocol that drove the need to share, etc.  Note that some contextual information is expected to be captured by most FHIR systems even in absence of Communication, such as where did the data come from and when was the data received.  This metadata is generally captured in Provenance.  In addition to Communication, MessageHeader can capture similar metadata and Composition in FHIR documents can also serve a similar purpose.  Refer to [Data Sharing Decision Tree TBD] for guidance on which data sharing mechanism is appropriate in which circumstances.  If mixing multiple mechanisms to convey communication metadata, care should be taken to ensure that each mechanism is necessary and the information conveyed in each layer is appropriately consistent.

      Communication and CommunicationRequest

      There is no requirement that Communication and CommunicationRequest always go together.  Communication can exist without there having been a CommunicationRequest.  For example, a practitioner might capture that they have provided a smoking cessation pamphlet to a patient that would be a Communication instance, but there would have been no "request" that led to the action (unsolicited).  As well, a CommunicationRequest can be fulfilled in many ways, e.g. by phone call, email, system to system data sharing and there might not be a requirement to surface this data sharing at the clinical / business level, i.e. no need for a Communication instance.

      Where there is a need to explicitly track fulfillment of a CommunicationRequest, Communication is the most natural resource to establish this linkage.  The event can be tied to the request using Communication.basedOn.  

      Show
      Definition A clinical or business level record of information being transmitted or shared; e.g. an alert that was sent to a responsible provider, a public health agency communication to a provider/reporter in response to a case report for a reportable condition.  Scope   The purpose of a Communication resource is to surface that data was shared to track adherence to guidelines or protocols or to provide business documentation of actions taken. Communication can also be used as part of an information exchange to provide context about the information sharing occurring.  Please see  [TBD]  for guidance on when this is appropriate. Communication is one of the  event  resources in the FHIR  workflow  specification. This resource is a record of a communication even if it is planned or has failed. A communication is a record of the conveyance of information from one entity, a sender, to another entity, a receiver. The sender and receivers may be patients, practitioners, related persons, organizations, or devices. Communication use cases include: A reminder or alert delivered to a responsible provider A recorded notification from the nurse to the on-call physician (or any other specified person) that a patient's temperature exceeds a value A response from a public health agency to a provider caring for a patient presenting with a communicable disease reportable to the public health agency Patient educational material sent by a provider to a patient Unable to deliver lab results to ordering physician Submission of supplementary health information to a payer in support of a claim Non-patient specific communication use cases may include: A nurse call from a hall bathroom Advisory for battery service from a pump Note Using Communication to wrap or accompany data In FHIR, data is typically shared between systems without any need for the Communication resource to accompany or contain the data being shared, i.e. all FHIR exchanges are communications of some form, but that doesn't mean they need the Communication resource.  However, in some cases, when data is shared there is a need to provide context about why the data is being conveyed and Communication is one of the mechanisms that FHIR provides that can share this context.  Specifically, Communication allows conveying information about reasons for sharing, encounter that provides context for sharing, order or protocol that drove the need to share, etc.  Note that some contextual information is expected to be captured by most FHIR systems even in absence of Communication, such as where did the data come from and when was the data received.  This metadata is generally captured in Provenance.  In addition to Communication, MessageHeader can capture similar metadata and Composition in FHIR documents can also serve a similar purpose.  Refer to  [Data Sharing Decision Tree TBD]  for guidance on which data sharing mechanism is appropriate in which circumstances.  If mixing multiple mechanisms to convey communication metadata, care should be taken to ensure that each mechanism is necessary and the information conveyed in each layer is appropriately consistent. Communication and CommunicationRequest There is no requirement that Communication and CommunicationRequest always go together.  Communication can exist without there having been a CommunicationRequest.  For example, a practitioner might capture that they have provided a smoking cessation pamphlet to a patient that would be a Communication instance, but there would have been no "request" that led to the action (unsolicited).  As well, a CommunicationRequest can be fulfilled in many ways, e.g. by phone call, email, system to system data sharing and there might not be a requirement to surface this data sharing at the clinical / business level, i.e. no need for a Communication instance. Where there is a need to explicitly track fulfillment of a CommunicationRequest, Communication is the most natural resource to establish this linkage.  The event can be tied to the request using Communication.basedOn.  
    • Resolution Vote:
      Lloyd McKenzie / Paul Knapp : 10-0-0
    • Change Category:
      Enhancement
    • Change Impact:
      Non-substantive
    • Applied for Version:
      R5

      Description

      Clarify how Communication is used. Is Communication an event or a workflow? When is a Communication resource created outside of the content of a CommunicationRequest? When are the two resource duplicative? Discussions at the May WGM revealed that Communication has several variations:

      1) A record of a (sent) communication ( i.e., the content is sitting in the receiver's in box)

      2) The communication of the thing/content itself ( i.e., this is the first time the receiver gets the the content - clinician gives patient a brochure)

      3) How does 2) above differ from CommunicationRequest in certain workflows - that is all you get

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              ehaas Eric Haas
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Vote Date: