This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
. Page versions: R5 R4B R4 R3
12.7 Ad-Hoc Workflow Communication Patterns 
TODO: Discussion (or reference to one) on Polling and Subscription
12.7.1 Option A: Simple RESTful POST or PUT
12.7.1.1 Steps
- The placer makes a RESTful call to create or update a record or a POST to invoke an
operation over HTTP
- The receiver responds with a 2xx HTTP response indicating whether the request was successfully processed or not and, if appropriate, provides the response to the request in the payload of the HTTP response
12.7.1.2 Benefits
- Simplest of all the possible workflow architectures
- Placer knows whether the request was accepted or not and knows when the task has been done
12.7.1.3 Limitations
- Only works for automated execution where the decision to perform the request and the execution of the request can be done synchronously within the HTTP timeout period (generally on the order of 10s of seconds).
- Requires that the placer have authority to post directly to the placer's system
- Requires that the "request" be expressible as a simple creation, update or operation invocation
- Only works for "fulfillment" requests for Request resources - can't handle request for state changes or information
12.7.1.4 Usage Recommendations
This is by far the most common pattern in FHIR for simple changes as it requires the least overhead. However, it covers only automated responses, and does not support any actual workflows of more than one step. If human processing is involved in the request
execution, then this approach won't suffice. This approach is listed here to make sure that implementers consider whether they can make this one work first before falling back to one of the more sophisticated patterns.
12.7.1.5 Usage Examples
???
12.7.2 Option B: Direct POST of request to fulfiller's system
12.7.2.1 Steps
- Placer system invokes a create by POSTing a 'request' resource (e.g. MedicationRequest,
ProcedureRequest, ReferralRequest, etc.) to the appropriate RESTful resource endpoint (e.g. [base]/MedicationRequest) on the filler system and places an actionable
tag on the resource that indicates the request is intended to be acted upon, not merely stored.
- The filler synchronously responds with a "201" indicating that that they have received and stored (created) the resource on their system
- At some later point, the filler POSTs an 'event' resource (e.g. MedicationDispense,
DiagosticReport, Encounter, etc.) to the appropriate resource endpoint on the placer system, including a
basedOn link to the 'request' resource that the action
was performed in fulfillment of.
- The placer system synchronously responds with a "201" indicating they've received and store (created) the resource on their system
12.7.2.2 Benefits
- Lowest amount of overhead. No need for Task. No need for polling or subscriptions
- Explicit acknowledgement that filler has received the request
12.7.2.3 Limitations
- Can only use when requesting fulfillment (can't use to request status change or other updates)
- Placer and filler must be able to communicate directly (i.e. know each other's respective endpoints), must each have a FHIR server, and must have "write" permissions to each other's servers. This could become unmanageable if there are a
large (or dynamic) number of placers and fillers that need to communicate
- No indication of agreement to act on the request
- There's no ability to negotiate fulfillment - no ability to say "no"
- This completely reverses the usual provenance of resources, as the request only exists on the fulfiller's system, and the event only exists on the placer's system. This greatly limits the use of these resources for any other purpose.
12.7.2.4 Usage Recommendations
Use this approach when there's no ability to have queue servers and no support/need for complexity of Task, polling or pub/sub (and no need for negotiation or the ability for the filler to say "no"). This is a pseudo-messaging architecture that doesn't
actually use messaging architecture.
12.7.2.5 Usage Examples
12.7.3 Option C: POST of request to placer/queue server system, receiver uses polling or subscription
12.7.3.1 Steps
- Placer system creates a 'request' resource (e.g. MedicationRequest, DiagnosticOrder, ReferralRequest, etc.) by a system action or a POST on either its own system or a third party queue server system and places an "actionable" tag on the resource
that indicates the request is intended to be acted upon. The request explicitly identifies the intended fullfiller
- The filler system uses polling (or a subscription) at the placer or queue server system to see if there are any "new" requests that: are tagged as "actionable", have the filler identified as the intended performer, and are a type of request
"of interest" to the filler.
- At some later point, the filler creates an 'event' resource (e.g. MedicationDispense, DiagosticReport, Encounter, etc.) via a system action, or a POST on either its own system, the same queue server as the request was placed on, or some alternate
queue server, including a link to the 'request' resource that the action was performed in fulfillment of
- The placer system uses polling (or a subscription) to the filler or queue server system to see if there are any "new" events that are tied to any outstanding requests the placer has initiated
12.7.3.2 Benefits
- Placer and fulfiller don't have to communicate directly (can act through queue server). This can reduce the number of point-to-point interfaces that need to be supported
- Preserves the conventional management and ownership of the request and event at the placer and fulfiller's systems respectively
- No need for Task
12.7.3.3 Limitations
- Can only use when requesting fulfillment (can't use to request status change or other updates)
- Additional complexity of using subscription or polling
- Polling by the placer for "anything related to these 500 open orders" could be onerous, especially if some orders never get closed.
- Placer and fulfiller must know where to poll or subscribe for content - this could be a large number of systems
- No indication of agreement to act on the request
- There's no ability to negotiate fulfillment - no ability to say "no"
- Placer may not know when (or if) filler system has retrieved the request
12.7.3.4 Usage Recommendations
This pattern could be used when there's no support/need for complexity of Task, usually for simple two step workflows. This is a more typically RESTful approach where data resides on the server "owned" by the data creator and is accessed by other systems.
12.7.3.5 Usage Examples
12.7.4 Option D: Messaging request from placer to filler & acknowledgment
TODO: needs review and update
12.7.4.1 Steps
- Placer sends message to filler system including Request resource (and other relevant resources) along with a MessageHeader with an "event" code saying "please fulfill" and "data" element pointing to the Request resource as the item to fulfill.
Message could potentially use Task instead of MessageHeader.event to convey desired action (ongoing discussion)
- Filler system sends a response indicating receipt of the message and, optionally an indication of their intention to fulfill the request
- Filler system may send incremental messages to the placer showing progress (e.g. specimen collected, preliminary results, final results)
12.7.4.2 Benefits
- Reduced number of communications
- All relevant data sent in one package
- Responses can be asynchronous and content may be routed
- There's an ability to negotiate fulfillment - i.e. the ability to say "no"
- Can request things other than just fulfillment (e.g. please suspend)
- Explicit acknowledgement that filler has received and agreed to act on the request (though no need for the placer to check)
12.7.4.3 Limitations
- Messaging is "heavy"
- Need to negotiate what allowed responses are and what data can be present in request and response messages
- Additional complexity of setting up and maintaining a subscription or polling infrastructure
- Additional complexity of using Task
- Need message delivery infrastructure in place
12.7.4.4 Usage Recommendations
Existing messaging infrastructure (e.g. v2 LTP, MLTP, WSI Web Services, Direct, VISA, REST, etc.) and a need to stay consistent with that architecture
12.7.5 Option E: Services request from placer to filler & acknowledgment
TODO: Needs review, update and more work - there's not a lot of experience using FHIR services to manage the fulfillment process
12.7.5.1 Steps
- Placer may create and store a Request resource on their own system or a queue server.
- Placer invokes a service on the filler system saying "please fulfill this order", including the content or a reference to the request resource and any other relevant data
- Filler system responds (synchronously if using HTTP, but may be asynchronous if using SOAP or other transport mechanisms) with conformation of receipt and, optionally indication of intention to fulfill and/or results
12.7.5.2 Benefits
12.7.5.3 Limitations
12.7.5.4 Usage Recommendations
TBD
12.7.6 Additional Scenarios
TODO: needs review and update. Possibly add options about using messaging and/or services instead of polling/subscription in above scenarios
12.7.6.1 POST of "request" resource for filler system, response via Task
This is a variation ofOption H, where the Workflow broker is essentially merged with the fulfiller. It still allows the placer to only use a POST of the request, and be made aware of the changes to
the other resources via subscpriotn or polling.
- Placer system invokes a "create" action by POSTing a 'request' resource (e.g. MedicationRequest, DiagnosticOrder, ReferralRequest, etc.) to the appropriate RESTful resource endpoint (e.g. [base]/MedicationRequest) on the filler, placer or
queue server system and sets a "tag" on the resource that indicates the request is "actionable"
- Filler POSTs a Task resource to its own system or a queue server system, pointing to the request resource and indicating intent to fulfill or refusal to fulfill
- Placer system uses either polling or pub/sub to become aware of the existence of the task and fulfillment intent
- Fulfiller may update the Task to indicate interim progress notes
- Placer either polls the Task to note acceptance and changes or uses a subscription to determine the same
- Fulfiller POSTs an event resource to its own system or to a queue server system
- Fulfiller Updates the Task resource to change its status to completed and to point to the event resource
- Placer system becomes aware of the update via polling or subscription
- Placer system retrieves the event
- Placer system marks the request as "complete"
12.7.6.2 Querying the status of a workflow using REST
- Placer sends query for Task(s) that have a focus of the request of interest to a system (placer system, queue server or filler) that holds tasks related to their request.
- System returns a query response showing all related tasks (typically just one). Task shows current status.
12.7.6.3 Querying the status of a workflow using services
- Placer invokes a "what's the status of this order" service, passing the request business identifier or URL of the request
- Services responds with a Task showing the current state of the fulfillment of the request
12.7.6.4 Cancellation of a Task using REST - placer owns
- Placer sends an update to the Task setting the status to "cancelled" signalling they are no longer concerned about the outcome of the task
- Filler receives notification of the update (because the task is on their system, or because they poll it, or are subscribed to it) and ceases work if they are able
12.7.6.5 Cancellation of a Task using REST - filler owns
- Placer creates a new task requesting cancellation of the original fulfillment task
Fulfillment of the "cancellation task" can be requested using any of the mechanisms above
- Filler decides whether they are able to cancel the task and update the "cancellation" task to indicate either cancellation is complete or has been refused
Workflow
|
Propose a change