Ballot Feedback: General FHIR API interactions

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Not Persuasive with Modification
    • Priority: Medium
    • SMART Web Messaging (FHIR)
    • current
    • FHIR Infrastructure
    • (NA)
    • 1.8.4
    • Hide

      Captured in notes here: https://confluence.hl7.org/pages/viewpage.action?pageId=104570456#SMARTWebMessagingBallotReconciliationCC20210305-Proposal:

      Proposal

      Describe the fhir.* message group as a way to interact with a FHIR server that is equivalent to FHIR HTTP API supporting create, read, update, delete, patch, operations, etc. e.g. patient match, etc. We could use http://hl7.org/fhir/bundle-definitions.html#Bundle.entry.request and a Resource as the data model for requests; and http://hl7.org/fhir/bundle-definitions.html#Bundle.entry.response for responses. (as described in Bas' FHIR-29350, which would be marked Persuasive with Mod) and make it clear that this is an optional feature.  An EHR not wishing to support this is free to omit from their implementation.

      Show
      Captured in notes here: https://confluence.hl7.org/pages/viewpage.action?pageId=104570456#SMARTWebMessagingBallotReconciliationCC20210305-Proposal: Proposal Describe the fhir.* message group as a way to interact with a FHIR server that is equivalent to FHIR HTTP API supporting create, read, update, delete, patch, operations, etc. e.g. patient match, etc. We could use  http://hl7.org/fhir/bundle-definitions.html#Bundle.entry.request  and a Resource as the data model for requests; and  http://hl7.org/fhir/bundle-definitions.html#Bundle.entry.response  for responses. (as described in Bas' FHIR-29350 , which would be marked Persuasive with Mod) and make it clear that this is an optional feature.  An EHR not wishing to support this is free to omit from their implementation.
    • Bas van den Heuvel / Carl Anderson: 7-0-0
    • Enhancement
    • Compatible, substantive

      At this point in time, we believe requiring the application to communicate directly with the FHIR server should be required. There should be nothing preventing this interaction today (in fact, it is the most common interaction that exists in production), and there are likely security/auditing/etc issues raised by using the EHR application as an intermediary. There may also be technical issues raised for requests that could kick off workflows, async communication, additional failure points, and error handling that are best directly handled with direct communication by the SMART application.

            Assignee:
            Unassigned
            Reporter:
            Jenni Syed
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: