This page is part of the FHIR Specification (v3.3.0: R4 Ballot 2). 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: R5R4BR4R3
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,
ServiceRequest, etc.) to the appropriate RESTful resource endpoint (e.g. [base]/MedicationRequest) on the filler system and places an actionabletag 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 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. ServiceRequest 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 might 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 subscription or polling.
Placer system invokes a "create" action by POSTing a 'request' resource (e.g. ServiceRequest 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
. Page versions: R5 R4B R4 R3
|
Propose a change