Why are we breaking FHIR REST? - HRex #114

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • US Da Vinci HRex (FHIR)
    • STU3
    • Financial Mgmt
    • Profile overview [deprecated]
    • Hide

      First, we'll fix the description to actually be talking about unsolicited rather than solicited.  Second, we agree that wrapping data with Communication is not appropriate here.  We will replace this section on unsolicited communication with the different options covered by the data exchange decision tree - which includes allowance for simple RESTful POST/PUT, batch, transaction and bulk data, but also allows for the use of operations and messaging.  As yet, we haven't identified a need for unsolicited transmissions of data that wrap their information using Communication, but we will talk with the attachments (PIE) work group to understand their use and, if necessary, incorporate that into the decision tree and HRex as well.

      Show
      First, we'll fix the description to actually be talking about unsolicited rather than solicited.  Second, we agree that wrapping data with Communication is not appropriate here.  We will replace this section on unsolicited communication with the different options covered by the data exchange decision tree - which includes allowance for simple RESTful POST/PUT, batch, transaction and bulk data, but also allows for the use of operations and messaging.  As yet, we haven't identified a need for unsolicited transmissions of data that wrap their information using Communication, but we will talk with the attachments (PIE) work group to understand their use and, if necessary, incorporate that into the decision tree and HRex as well.
    • Richard Esmond / Marti Velezis : 9-0-0
    • Correction
    • Non-substantive

      Existing Wording: The Request (Solicited Communication) information exchange interaction is a alternative way to handle a Pull interation for a FHIR APIs.

      Comment:

      Why do we need an alternative way to handle a pull interaction in RESTful FHIR? It feels like we're re-creating document exchange and breaking any semblance to a RESTful design approach. Why isn't this is a series of simple CRUD operations, which are already well defined in FHIR and extremely widely implemented? Also, maturity of the Communication resources are low. Why base such an important comm interaction on an unproven, minimally implemented resource?

      Summary:

      Why are we breaking FHIR REST?

            Assignee:
            Unassigned
            Reporter:
            Isaac Vetter
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: