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

Unsolicted notifications should be limited to defined use cases and triggers

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • US Da Vinci Alerts (FHIR)
    • 0.2.0 [deprecated]
    • Infrastructure & Messaging
    • Home (index)
    • 1.1.2
    • Hide

      The intent and scope of the IG is to create a framework for developing unsolicited notifications for other use cases besides admit and discharge. The hope is that any organization or implementer could use it implement another unsolicited notifications scenario.

      It is the expectation that user agreements between the parties would address the allowed use cases.

      See FHIR-26617 adding user agreements to assumptions

      Add to the roles the following clarification:
      ~/output/index.html#roles

      "It is the responsibility of the Receiver/Intermediary to filter and sort the Da Vinci notifications it receives"

      Add to the Framework workflow how this can be done:
      ~/output/guidance.html#pushing-unsolicited-notifications-to-the-receiver-or-intermediary

      "The Receiver/Intermediary may sort and filter notifications based on the MessageHeader.event codes. For example, `notification-admit` can be used to to filter for patient admission notifications."

      Add to Assumptions:
      ~/output/guidance.html#preconditions-and-assumptions

      "The Sender shall provide structured data whenever possible."

      See FHIR-26133 regarding specific future scenarios created by Da Vinci

      Show
      The intent and scope of the IG is to create a framework for developing unsolicited notifications for other use cases besides admit and discharge. The hope is that any organization or implementer could use it implement another unsolicited notifications scenario. It is the expectation that user agreements between the parties would address the allowed use cases. See FHIR-26617 adding user agreements to assumptions Add to the roles the following clarification: ~/output/index.html#roles "It is the responsibility of the Receiver/Intermediary to filter and sort the Da Vinci notifications it receives" Add to the Framework workflow how this can be done: ~/output/guidance.html#pushing-unsolicited-notifications-to-the-receiver-or-intermediary "The Receiver/Intermediary may sort and filter notifications based on the MessageHeader.event codes. For example, `notification-admit` can be used to to filter for patient admission notifications." Add to Assumptions: ~/output/guidance.html#preconditions-and-assumptions "The Sender shall provide structured data whenever possible." See FHIR-26133 regarding specific future scenarios created by Da Vinci
    • Ulrike Merrick/Nick Radov: 3-0-1
    • Clarification
    • Compatible, substantive

      Unsolicted notifications should be limited to defined use cases and triggers, with named message types. We don't want to create a scenario where people can start sending alerts based on self defined triggers; that could create a system where someone has to manually review the alert and decide what to do with it. Far more efficient would be a set of specific alert use cases/triggers that developers could program to route certain message types to specific work queues. Perhaps the best way to deal with this would be for actors to only use unsolicited notifications for approved/defined use cases. What we want to avoid are free text messages that would require manual review.

      Existing Wording:

      Out of Scope: What constitutes a trigger (nature of the event as defined in your organization)

            Unassigned Unassigned
            celine_lefebvre Celine Lefebvre
            Celine Lefebvre
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: