Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Medium
-
FHIR Core (FHIR)
-
R6
-
FHIR Infrastructure
-
Workflow
-
-
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
- Call Patient.$match to identify the patient on the filler.
- Call Practitioner(Role).search to identifier the requestor.
- Call Practitioner(Role).search to identifier the performer.
- Call Condition.Create to create the Condition for reasonReference
- Call Specimen.Create to create the Specimen for the specimen reference.
- 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.