FHIR Workflow Minutes WGM 201601

Return to: WGM Minutes > 2016 > January Orlando

FHIR Workflow WGM session Monday Q3/Q4

Return to FHIR Workflow Minutes

Agenda

• Q3: Provide an overview of Workflow discussions to-date, discuss
• Q4: Walk through Workflow

Attendees

• Lloyd McKenzie (chair/partial scribe)
• Ewout Kramer (scribe)
• See File:2016JanWGMMondayWorkflow.pdf

Mon Q3

• Lloyd went through the usecases for workflow and issues encountered (see also http://wiki.hl7.org/index.php?title=FHIR_Workflow_Discussion)
• Question: is there a separation of US requirements versus European requirements? Is that considered? A: Scope is international, so about what's going to end up in the core. We will not standardize workflows, but try to designs resources to support exchanging data about workflow.
• Started out with simple scenario of ordering (do this! Ok, done!), then turned into a more generic system with tasks and subtasks and a network of cooperating systems to cover the workflow. Can you cover both without the simple use case getting unnecessarily complex? There is probably going to be multiple ways to do it.
• Is changing of fulfiller in itself an order? Keith +1, Lloyd -1. Lloyd: FHIR allows you to change anything you want as far the spec is concerned, it's about what systems will enforce and what processes are triggered, but that's not part of the spec.
• We discuss how workflow and changes in orders and workflow might be supported by a Task resource which is not necessarily an order, but a Task resulting from an order. In this case, a change of who is executing an order might result in cancelling and sending out new Tasks.
• Lloyd asks: Anyone opposed to renaming xxxxxOrder to xxxxxRequest? This means MedicationOrder becomes MedicationRequest. Is it clear what that means? One speakers thinks PrescriptionRequest is better, but Prescription is already a "request".
• If this kind of confusion starts to exist, we would probably not push too hard, since then consistency would come at the price of confusion
• Isn't "request" going to cause confusion with the lower-level notions in FHIR of a (web) request? Actually, if you look at the names of Resources, the term "Request" is pretty consistently used and does not cause confusion.

Mon Q4

• Keith Boone walked through workflow examples to date
• Question: How do interested systems know when a Task "of interest" has changed? Answer: Could subscribe, use polling
• Numerous use-cases were raised. Use cases should be added to the Workflow page
• Keith brings up the state machine diagram from the WFMC.
• About the state machine, Kevin suggested that what we do for healthcare would be respecting that state machine and supporting other statuses - hopefully not adding more state transitions, but reaching a subset.
• Discussion on Cancel: In some cases the order placer can cancel the order, by simply updating it to "state=cancelled"; in other cases, the effective cancelling may not be possible, or simply be rejected. We need to be able to support the notion of "unable to cancel".
• A discussion on statuses followed, including the clarification of the meaning of statuses e.g. "complete" and whether we can append to a workflow after it is "complete". No conclusions except that the status completion is not simple to dismiss.
• Lloyd suggested that the tool to make the diagrams can be useful and suggested Keith should help others to start using the tool if needed others can help, e.g Jose.