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

Consider including the orchestration work in the workflow patterns

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R6
    • FHIR Infrastructure
    • Workflow
    • Hide

      We don't want to identify all of the possible steps that would be pre-requisites to initiating a request because those will be widely varying.  However, we will add the following:

      "This section of the specification is focused on the specifics of initiating a request for something to be done and then managing that request through to completion/termination.  There are a wide range of pre-requisite steps to creating requests, including patient identification, determining service performers, linking to conditions, goals, etc., pointing to higher-order requests.  This section doesn't get into those pre-requisites.  However, certain request workflow approaches may impose architectural requirements on what pre-requisites are necessary and for whom.  For example, if a request is initiated by posting a Task to a fulfilling system, the placer may first need to determine who the Patient is in that system.  This will not be necessary if they're creating the Task in the placer environment. "

      Show
      We don't want to identify all of the possible steps that would be pre-requisites to initiating a request because those will be widely varying.  However, we will add the following: "This section of the specification is focused on the specifics of initiating a request for something to be done and then managing that request through to completion/termination.  There are a wide range of pre-requisite steps to creating requests, including patient identification, determining service performers, linking to conditions, goals, etc., pointing to higher-order requests.  This section doesn't get into those pre-requisites.  However, certain request workflow approaches may impose architectural requirements on what pre-requisites are necessary and for whom.  For example, if a request is initiated by posting a Task to a fulfilling system, the placer may first need to determine who the Patient is in that system.  This will not be necessary if they're creating the Task in the placer environment. "
    • Jose Costa Teixeira/Rita Torkzadeh: 6-0-0
    • Clarification
    • Non-substantive

    Description

      Some of the workflow options (e.g, [Option B|https://hl7.org/fhir/R4/workflow-ad-hoc.html)] imply that you can just POST a request resource.  That skips over the pre-work that will normally be necessary.  There are a few options here:

      Option 1 - Have the placer gather references from the filler

      1. Call Patient.$match to identify the patient on the filler.
      2. Call Practitioner(Role).search to identifier the requestor.
      3. Call Practitioner(Role).search to identifier the performer.
      4. Call Condition.Create to create the Condition for reasonReference
      5. Call Specimen.Create to create the Specimen for the specimen reference.
      6. THEN POST the ServiceRequest, with all the references populated with the results of your previous queries.

      Option 2 - Have the filler resolve references from the placer.

      In this case, the placer could POST the request with and have the references point back to the placer's FHIR server, but then the filler needs to perform .Read calls to retrieve that data (after having performed authorization).  This approach requires bi-directional authorization, as the placer must get authorization to POST to the filler, and the filler must get authorization to pull references from the placer, though this bi-directional authz may be necessary anyway if there is an expectation for event data to flow back.

       

      Option 3 - Use pre-coordinated logical references.

      Option 4 - Something else I've not thought of.

       

      With at least Option 1 and 2, omitting the orchestration work related to references makes this option seem simpler than it actually is.

       

      Recommendation:  Mention how references in the request resource may impact the complexity as a limitation.

       

       

       

       

       

       

       

      1.  

      Attachments

        Activity

          People

            Unassigned Unassigned
            cooper.thompson Cooper Thompson
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: