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

RequestOrchestration behavior underdefined

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • FHIR Core (FHIR)
    • R5
    • FHIR Infrastructure
    • STU
    • RequestOrchestration (was RequestGroup)
      Request Pattern
    • 12.4.10.3
    • Hide
      1. What happens/how to log the results of the clinician choosing from the different options provided by the resource.

      Will create a change request w/ pull request that CDS document on the OrchestrationRequest page that there is no expectation for systems to specifically identify their "choices" within the options presented by a RequestOrchestration, but that if workflow needs this to occur, it could be accomplished with a 'filler-order' RequestOrchestration basedOn the 'original-order' RequestOrchestration that narrows the order to reflect the filling clinician's choices.

      2. How to track the resulting events back to the source RequestOrchastration.

      We will identify places where Request pattern resources don't support RequestOrchestration in their basedOn element and submit change requests to ask this to be addressed (possibly along with other alignment issues)

      3. Indicate whether the intent of the component requests will still be 'option' after they have been chosen/accepted.

      Will create a change request w/ pull request that CDS make clear that 'choosing' to follow a path does not change the 'intent' of the resource chosen.  However, a new Request instance with a different intent can be 'basedOn' the original.  

      4. When is the resource 'completed' when the clinicians made his/hers choice or when all resulting requests are finished.

      Will document that a RequestOrchestration is marked as `completed` when the author or business rules deem the needed/appropriate actions described in the orchestration have been fully executed.

      5. Are groupIdentifiers used to group the requests related to a RequestOrchestration?

      Will make explicit that groupIdentifier and RequestOrchestration are different and independent concepts and the RequestOrchestration.groupIdentifier is used when the RequestOrchestration was ordered as part of a group of other things.  It does not group anything within the orchestration.

      6. When to use which compound request pattern.

      Will provide additional guidance on when to use groupIdentifier vs. RequestOrchestration.  Specifically, groupIdentifier is for multiple things ordered/signed at once whose status can change independently.  RequestOrchestration is for a single order with multiple interdependent parts but which has a single status and where individual parts can't be cancelled or suspended independently.

      Show
      What happens/how to log the results of the clinician choosing from the different options provided by the resource. Will create a change request w/ pull request that CDS document on the OrchestrationRequest page that there is no expectation for systems to specifically identify their "choices" within the options presented by a RequestOrchestration, but that if workflow needs this to occur, it could be accomplished with a 'filler-order' RequestOrchestration basedOn the 'original-order' RequestOrchestration that narrows the order to reflect the filling clinician's choices. 2. How to track the resulting events back to the source RequestOrchastration. We will identify places where Request pattern resources don't support RequestOrchestration in their basedOn element and submit change requests to ask this to be addressed (possibly along with other alignment issues) 3. Indicate whether the intent of the component requests will still be 'option' after they have been chosen/accepted. Will create a change request w/ pull request that CDS make clear that 'choosing' to follow a path does not change the 'intent' of the resource chosen.  However, a new Request instance with a different intent can be 'basedOn' the original.   4. When is the resource 'completed' when the clinicians made his/hers choice or when all resulting requests are finished. Will document that a RequestOrchestration is marked as `completed` when the author or business rules deem the needed/appropriate actions described in the orchestration have been fully executed. 5. Are groupIdentifiers used to group the requests related to a RequestOrchestration? Will make explicit that groupIdentifier and RequestOrchestration are different and independent concepts and the RequestOrchestration.groupIdentifier is used when the RequestOrchestration was ordered as part of a group of other things.  It does not group anything within the orchestration. 6. When to use which compound request pattern. Will provide additional guidance on when to use groupIdentifier vs. RequestOrchestration.  Specifically, groupIdentifier is for multiple things ordered/signed at once whose status can change independently.  RequestOrchestration is for a single order with multiple interdependent parts but which has a single status and where individual parts can't be cancelled or suspended independently.
    • Bas van den Heuvel/Jose Costa Teixeira: 5-0-0
    • Clarification
    • Non-substantive
    • R5

    Description

      Section 12.4.10.3 and the text in the RequestOrchestration resource provides some explanation to in what way this resource can be used to create Compound Requests.

      It is clear in what manner a compound request can be made and in what way the different options can be expressed.

      In the case of ServiceRequest and other requests, the request (order) triggers a set of actions that are logged as being 'basedOn' the orginal request. 

      Please define this behavior regarding RequestOrchestration resources in more detail. Specifically address the following questions:

      1. What happens/how to log the results of the clinician choosing from the different options provided by the resource.
      2. How to track the resulting events back to the source RequestOrchastration.
      3. Indicate whether the intent of the component requests will still be 'option' after they have been chosen/accepted.
      4. When is the resource 'completed' when the clinicians made his/hers choice or when all resulting requests are finished.
      5. Are groupIdentifiers used to group the requests related to a RequestOrchestration?
      6. When to use which compound request pattern.

      Attachments

        Activity

          People

            bryn.rhodes Bryn Rhodes
            bvdh Bas van den Heuvel
            Bas van den Heuvel
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: