workflow - devdays.com€¦ · if workflow behavior is to be consistent in fhir, need consistent...
TRANSCRIPT
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
www.devdays.com