201705 Workflow
Workflow
Submitting WG/Project/Implementer Group
Justification
Workflow is an essential part of healthcare - orders, care protocols, referrals are the drivers of most activity within in-patient settings and a great deal of activity in community care as well. FHIR is concerned with workflow when there's a need to share information about workflow state or relationships, when there's a need to coordinate or drive the execution of workflow across systems and when there's a need to define allowed actions, dependencies and conditions on behavior.
This track aims to test, and familiarize implementers with the Workflow Management Patterns. Specifically towards sharing of the state of a workflow and requesting / fulfilling actions or information from a different organization or department. The need for standardization in this field comes from healthcare workflows that are traditionally outsorced by an organization (requesting lab-orders or diagnostic imaging), shared between departments (medication dispense and administration) or have participants from different organizations (tumor board).
Proposed Track Lead
Oliver Krauss
- Email: oliver dot krauss at fh-hagenberg dot at
- Zulip: Oliver Krauss
- Skype: krauss_o
See Connectathon_Track_Lead_Responsibilities
Expected participants
Planning on attending the Connectathon and participating in the Workflow Track? Please drop a line in the Zulip chat!
- CGM Clinical Austria
- HL7 Austria
- ITH Icoserve
- Research & Development Upper Austria GmbH
- University of Upper Austria
Roles
Note that any participant can choose to implement only a single or more roles listed. A FHIR Server with a workflow broker is already provided by the track organizers.
Placer
Is responsible for creating a request for an action they seek fullfillment for. Optionally the Placer can create tasks to detail processing details. Upon getting events from the Filler the Placer needs to update the request-state and possibly verify the actions set by the Filler.
Filler
Claims, rejects or fullfills a request made by the Placer. Optionally the Filler can create tasks for a request, or subtasks for tasks already associated with the request by the Placer. Notifies Placer of the task process by sending events.
Broker
Acts as an intermediary between Placer and Filler. It takes responsibilty to seek fullfillment from the Placer and handles issues such as prioritization or rejection by a possible fullfillment candidate. It needs to be aware of possible fullfillers and their capabilities beforehand.
Scenarios
The following scenarios are based on the tumor-board use-case of assigning a patient to a tumor board discussion, with sample-resources detailed in the next section. The use-case is a part of the tumor-board preparation workflow (details here), where the discussion of a patient is requested for a planned tumor-board (ProcedureRequest) and results in the patient being discussed in the board ((Task) -> optional see scenarios), and finally resulting in a conducnted tumor-board where the patient was discussed(Procedure).
The scenario is one possible use case of many for manging workflows in healthcare. You are free to use any of the request / response resources as listed on the workflow page, but need to negotiate the used resources and details with a second partner for testing yourself. Note that the workflow-steps still stay the same, no matter what resource you use.
Resources and Samples
ProcedureRequest resource for discussing a patient in a tumor-board: File:201705 FHIR Connectathon Track Proposals ProcedureRequest.txt
Task to discuss the patient in the tumor-board: File:201705 FHIR Connectathon Track Proposals Task.txt
Procedure that details that the tumor-board has been conducted: File:201705 FHIR Connectathon Track Proposals Procedure.txt
Sample Practitioner: File:201705 FHIR Connectathon Track Proposals Practitioner.txt
Sample Patient: File:201705 FHIR Connectathon Track Proposals Patient.txt
Sample Organization: File:201705 FHIR Connectathon Track Proposals Organization.txt
Scenario: Request without tasks handled by Workflow Broker
Action: Placer sends a request to the workflow broker. Workflow broker negotiates who fullfills. Assigned fullfiller acts accordingly, and sends events of the progress. Precondition: workflow broker is aware of fullfillers and their capabilities Success Criteria: request gets fullfilled Bonus point: States of request, tasks and events are handled correctly
Basic script for the Placer
- Placer creates a ProcedureRequest and posts it to the workflow broker - Placer polls the workflow broker to check if there is a Procedure to it's ProcedureRequest (Procedure.basedOn) - Placer gets the Procedure - Placer updates/puts the ProcedureRequest to appropriate state
Basic script for the Workflow Broker
- broker polls for requests made by placers - broker creates requests based on request of Placer with fullfiller that can handle the request - Fullfillers either claim or reject request - On rejection broker goes to 2 with different fullfiller
Basic script for the Filler
- Filler polls the workflow broker to check if there is a ProcedureRequest for them - Filler uses the content of the request to craft a Procedure as the response claiming or rejecting the request - On claim Filler also claims the based-on request and posts progress events to the workflow broker
Scenario: Request with Tasks defined by Placer handled by Workflow Broker
Action: Placer sends a request to the workflow broker. Workflow broker creates tasks and searches for appropriate fullfillers and negotiates who fullfills. Assigned fullfiller acts accordingly, and sends events of the progress. Precondition: workflow broker is aware of fullfillers and their capabilities Success Criteria: request gets fullfilled Bonus point: States of request, tasks and events are handled correctly
Basic script for the Placer
- Placer creates a ProcedureRequest and posts it to the workflow broker - Placer polls the workflow broker to check if there is a Procedure to it's request - Placer gets the Procedure - Placer updates/puts the ProcedureRequest to appropriate state
Basic script for the Workflow Broker
- broker polls for requests made by placers - broker creates tasks with fullfiller that can handle the request - Fullfillers either claim or reject task - On rejection broker goes to 2 with different fullfiller
Basic script for the Workflow Broker Events on Task
- broker polls for events on the broker-generated tasks - broker handles according to state-machine to create events for request made by placers - eg. broker notifies in progress after first task starts, but only sends finished when all tasks finish.
Basic script for the Filler
- Filler polls the workflow broker to check if there is a Task for them - Filler rejects or accepts task - Filler posts progress to the task accordingly, and upon fullfillment creates a Procedure, answering the original request (Task.basedOn)
Bonus Scenario: Fullfiller registers with Workflow Broker
Action: Fullfiller registers with broker and provides them with request-types they want to fullfill. Precondition: - Success Criteria: Broker has fhir-resource that identifies fullfiller Bonus point: -
Fullfillers can register according to the requested PerformerType (Procedure.performerType). For this they can register with the following two options:
A) Practitioner with an assigned PractitionerRole where Request.performerType must match PractitionerRole.speciality
B) HealthcareService where the Request.performerType must match teh HealthcareService.specialty
Basic script for Filler-registration
- Filler creates Practitioner+PractitionerRole or HealthcareService and submits to broker
Adaption of scripts for placer based on bonus-scenario
- Placer creates a ProcedureRequest WITH a set performerType
Test Scripts
TBD
Connectathon Summary
TBD after Connectathon
