201705 Workflow

Workflow

Submitting WG/Project/Implementer Group

The FHIR Workflow Project.

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 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 XXX use-case, with sample-resources detailed here. 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 detailes 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

TODO: Which Use-Case do we use? Option International: Workflow calls often revolve around Medication or lab-order. TODO: Based on the use-case update the scripts to include event/state chains.

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 XXX request and posts it to the workflow broker
 - Placer polls the workflow broker to check if there is an XXX event to it's request
 - Placer gets the XXX event
 - Placer updates/puts the XXX request to appropriate state
 

Basic script for 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 1 with different fullfiller
 

Basic script for the Filler

 - Filler polls the workflow broker to check if there is an XXX request for them
 - Filler uses the content of the request to craft a XXX event as the response claiming or rejecting
 - 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 XXX request and posts it to the workflow broker
 - Placer polls the workflow broker to check if there is an XXX event to it's request
 - Placer gets the XXX event
 - Placer updates/puts the XXX request to appropriate state
 

Basic script for 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 1 with different fullfiller
 

Basic script for 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 an XXX task for them
 - Filler uses the content of the request to craft a XXX event as the response claiming or rejecting
 - On claim Filler posts progress events for tasks to the workflow broker

Bonus Scenario: Fullfiller registers with Workflow Broker

Action: Fullfiller registers with broker and provides them with request-types they want to fullfill. Precondition: We discussed in the workflow-call how that works Success Criteria: Broker has fhir-resource that identifies fullfiller Bonus point: -

TODO: discuss in call how this works

Test Scripts

TBD

Connectathon Summary

TBD after Connectathon