HL7®, FHIR® and the flame Design mark are the registered trademarks of Health Level Seven International and are used with per mission.

November 20-22, Amsterdam | @HL7 @FirelyTeam | #fhirdevdays | www.devdays.com

Workflow

José Costa Teixeira

Who am I

• José Costa Teixeira

• Consultant

• IMEC, Belgium

• Background:

• Implementer

• Volunteer within SDOs (IHE, HL7, ISO)

• Data Management and Healthcare Operations

• Medication, Supply, Care coordination, Privacy

Why Workflow on FHIR?

Why Workflow

• A common implementation challenge (explicit or underlying)

• A patient safety concern

• Hard to standardize, but must interoperate

• Simple or complex

• Lots of business variance

• Design variance (prescriptive or ad-hoc; even when prescriptive, regional variations exist)

• Runtime (in real life, things happen)

https://www.ecri.org/EmailResources/PSRQ/T

op10/2016_Top10_ExecutiveBrief_final.pdf

Workflow in HL7 v2 / v3

• Messaging requires mostly pre-negotiated workflow • 1 sender, 1 or more receivers

• Expected responder / filler is usually identified

• Expected action dictated by event code

• (or “action codes” within the message) • Results are sent as a response message or

• (or future message linked by business identifier)

• Behavior could be synchronous or asynchronous

• Status was hard to manage… e.g. “Status of a prescription”

Workflow in CDA

• No intrinsic support for workflow

• No delivery mechanism

• No expectation to start action when reading a document

• Can be wrapped by other specifications to enable workflow

• E.g. IHE profiles define workflow (XDS, CATH, etc.).

• IHE XDW even provides a CDA mechanism for workflow

Workflow in other standards

• OASIS Task

• OMG BPMN

Requirements for Workflow

• Keep the simple things simple, but allow complex cases

• Allow ‘filler’ to say “yes” or “no”

• Allow ‘filler’ to negotiate

• Allow ‘placer’ to see progress and status

• Allow complex status management

• Allow ‘placer’ to change/revoke authorization

• Allow ‘placer’ to receive “results” as linked to initial request • Allow routing and re-routing to more ‘fillers’

Requirements for Workflow on FHIR

• Support REST, Messaging and Documents…

• If workflow behavior is to be consistent in FHIR, need consistent resources…

• Workflow is just in the early stages in FHIR – most implementations focusing on exposing base data

• Interoperability at the workflow level is an advanced feature, but it impacts data needs

Patterns

Workflow patterns and relationships

http://build.fhir.org/patterns.html

Workflow Patterns and Resources

Request

Event

Definition

Request vs. Task

• Request represents intention/authorization

• Request does not (by itself) represent “request to act”

• i.e. Everyone who sees a MedicationRequest doesn’t start counting pills/injecting the patient

• Even if the request “has your name on it”

• Task lets you say “please do X” / “this needs to be done”

• And “this has been done”…

• Please fulfill; Please change status; Please tell me current progress; etc.

Task

Workflow State

Request State Machine

Task state machine

+ Business Status

Workflow (execution) patterns

Workflow execution patterns

• FHIR provides some examples (not exhaustive) to show the workflow mechanisms

• Each pattern contains: • What are the steps of the pattern

• What benefits does the pattern provide

• What are the limitations

• Recommendations for use of this pattern

http://build.fhir.org/workflow.html

Direct post to filler

1. POST Request + “actionable” tag

2. 201 Created

…

1. POST Event (basedOn request)

2. 201 Created

Workflow Broker

Plan

Definition

Workflow Definition

• Can be a protocol, a standard procedure,..

• Can also be a requirement

• Supporting variation but providing anchors

“Workflow Conformance”

Resource Updates

Workflow updates - resources

• Revamped patterns based on feedback

• Use PractitionerRole instead of “onBehalfOf” pattern

• Improved some names

• “partOf“ rather than “parent”, “instantiates” rather than “definition”

• Added Event.location

• Made Event.notDone into a status, added statusReason in place of notDoneReason

• Add additional resources to choices (e.g. CareTeam to performer)

Workflow updates - others

• ExampleScenario resource

• Allows describing a full workflow “instance”

• Moving pattern alignment reporting into the build infrastructure

• Looking to map and explore mutual alignment between workflow patterns and CIMI patterns

• Seeking implementer feedback (and volunteers) to improve usefulness of workflow content

Process

Process

• Bi-weekly calls since 2016

• New section in the specification for “Workflow”

• Resource patterns (Definition, Request and Event)

• Workflow execution

• How do we say “please do”, “done”, manage tracking…?

• Product pattern

• (Workflow definition)

Adherence to patterns

• Patterns are patterns, not rules

• Some elements may not be relevant in all resources

• Some elements may be “extensions” for some resources

• Some elements may use domain-specific names

• Some elements may constrain data types, cardinalities or simplify structures

• Focus is keeping simple things simple

• Look for alignment where we don’t have reason to be distinct

Future of patterns

• Ask workgroups to “try” to follow patterns and to include hand-wavy mappings

• We have a report showing where misalignment exists

• Future: patterns misalignment reported as part of publication process

• In the future, may:

• Make mappings more formal

• Expose patterns in reference implementations (interfaces)

• Introduce additional patterns

• Will be driven by implementer feedback

What’s next

• Try to get all artifacts aligned by publication of R4 (we’re behind…) • Support publishing ExampleScenarios in both the main publication

and implementation guides (we might have 1 for R4?)

• Try to have at least one ExampleScenario for each FHIR focal area

• Eventually try to have a few for each workflow pattern – R5 target

• Continue to exercise at connectathons

• Are you doing something workflow related at DevDays?

• Continue to improve/clarify documentation

• Suggestions/volunteers welcome

More workflow-related resources

• Everything product-related (Ordering, delivering…)

• Medication

• Device

• Nutrition

• Blood

Scenarios

Scenario 1

• Pharmacy is sent two prescriptions

• Both are active

• Both are for a patient that uses the pharmacy

• Both are digitally signed

• One is “to be filled”

• One is “for your information”

• Use in drug-drug interaction checking

• How does the pharmacy know what to do with each?

Scenario 2

• Download Med Schedule to tablet

• Search MedRequests (intent=instance-order)

• Upon notification, give meds to patient

• Send(update) medAdministration

Scenario 3

• System informs of blood collection

• Nurse reports patient has impediment

• GP asks for reschedule, is accepted

• New appointment and reminder

• Photo is taken then forwarded

ExampleScenario – tools are coming

http://zeora.net/blog/mma/examplescenario-mma1-scenario.html

• Questions?

• chat.fhir.org

• jct@zeora.net

www.devdays.com