exploring ways to add icp support to openhie a discussion document… 2014-05-14
TRANSCRIPT
Exploring Ways to Add ICP Support to OpenHIEA discussion document…2014-05-14
What’s in this deck…
What are ICPs and how do they “work”? How could ICP support be added to
OpenHIE How would we describe the ICPs? What building blocks would we need to
operationalize them? What might be the scope of an OpenHIE
ICP Working Group? How could we launch and grow this?
What are ICPs and how do they “work”?
What are ICPs?
Integrated Care Pathways (ICPs) describe evidence-based, person-centric care workflows that may be long-running and cross institutional boundaries
For example – the WHO’s HIV care guidelines or TB guidelines may be expressed as ICPs
An ICP may be described using rudimentary graphical primitives from the Business Process Modeling Notation (BPMN)
Start End Decision / Branch
Example: Positive HIV test
A client arrives at a VCT clinic to be tested for HIV Pretest counselling is done; consent is obtained
to conduct the test HIV “quick tests” and other tests are performed
as per the 3ILPMS protocol The results of the tests are positive; post-test
counselling is provided As per guidelines, the client is immediately put
on ART The client is enrolled in the HIV programme and
will receive ongoing guideline-based care
Enrol in HIV care programme
Prescribe ART
Care-seeking
Not an emergency
HIV positive
HIV test; other tests
Example: HIV Care Management
A client receives HIV care management reminders
The client attends a regular follow-up visit Lab tests are performed as per guidelines Based on the test results, the medication
regime (and, potentially, the care plan) is adjusted, as per guidelines
The client’s ongoing care management, including reminders, reflects any changes to the care plan
Active in HIV programme
Adjust medications
Not an emergency
Adjust care plan, if necessary
CD4; viral load; other tests
Follow-up
Man
age
ongo
ing
care
…
Example: ART Refill
A client receives HIV care management reminders
The client attends a regular follow-up visit Guideline-based care is delivered; clinical
observations are recorded ART medications are refilled The client’s ongoing care management,
including reminders, reflects the care plan
Active in HIV programme
Refill ART
Not an emergency
No lab testFollow-up
Man
age
ongo
ing
care
…
Example: Death from HIV/AIDS
A very ill client presents at a facility Based on initial assessments, the client’s
care is escalated The client dies while in hospital and is
discharged dead The client is removed from the active HIV
care management programme
Patient discharged from hospital dead
Care-seeking
Escalate care
Example: Directly-observed Therapy
A client receives TB care management reminders
The client attends a follow-up visit as per the care plan
Guideline-based care is provided The client’s TB drugs are directly
administered The client’s ongoing care management,
including reminders, reflects progress in the therapy as per DOTS protocols
Active in TB programme
Not an emergency
Record clinical observations; administer directly-observed
therapy, short course
Follow-up
Prot
ocl-b
ased
car
e…
How could ICP support be added to OpenHIE?
Mapping guidelines to ICPs…
A PEPFAR-funded analysis was made of multiple WHO care guidelines: 1. HIV 2. Malaria 3. TB4. Antenatal care5. Emergency care6. Public health emergency response
There are common “atomic” tasks/processes which appear in these care workflows
Common tasks across WHO guidelines
17
Leveraging re-usable building blocks
Deconstruction: The analysis of multiple disease-focused programmes yielded a set of common processes and an “archetypal ” pattern
Generalization: This re-usable pattern, made up of re-usable building blocks, may be employed as the basis for describing care pathways
Operationalization: By leveraging if-then branch logic, different paths thru the archetypal ICP may be used to operationalize multiple care guidelines
A re-usable ICP
20
Re-usable Transactions
1. “On-board” or update a client2. Resolve client ID3. Capture health information about a client4. Retrieve a client’s health information5. Order lab tests6. Get lab results7. Order meds8. Dispense meds9. Refer (escalate care)10. Discharge11. Send reminders / information
21
Re-usable Transactions
1. “On-board” or update a client2. Resolve client ID3. Capture health information about a client4. Retrieve a client’s health information5. Order lab tests6. Get lab results7. Order meds8. Dispense meds9. Refer (escalate care)10. Discharge11. Send reminders / information
“Put” content
“Get” content
Both (Get/Put)
22
2 3 4
3 4
5 63 4
3 4
3 47
8
9 103
11
3
1
4
23
Providerlevel metrics
Facility level metrics
District level metrics
National level metrics
Aggregate person-centric eHealth data to
generate indicators
Indicators
24
Providerlevel metrics
Facility level metrics
CapitationFee-for-Service
DRG
Global BudgetDRG
Leverage data to support UHC
OpenHIE can (and should) play a foundational role in supporting universal health coverage
(UHC) initiatives
Operationalizing ICPs
Multiple guideline-based care workflows mays be described as unique pathways through a set of common processes
To operationalize guideline-based care, eHealth infrastructure would need to:
Support the common processes (building blocks) Support the decision logic for each guideline’s
unique care pathway In this way, the re-usable ICP may be
leveraged to operationalize a broad array of guideline-based care workflows
What architectural building blocks would
we need?
27
Current architecture
Interoperability Layer
Point of Service
Applications
TS
Health Worker Registry
Facility Registry
Client Registry
Shared Health Record
Data Warehouse
28
New architectural building blocks
An ICP actor is a workflow server; it is a repository of guidelines expressed in BPMN (the standards-based Business Process Modeling Notation)
An InfoManager actor is a cross-indexed database of facility, provider, organization and service information
A Message Queue actor is a database of messages intended for an identified Message Client
An Message Client actor represents a uniquely defined end-point for an HIE-generated message
29
Message
QueueICP
New architectural building blocks
Interoperability Layer
Point of Service
Applications
TS
Health Worker Registry
Facility Registry
Client Registry
Shared Health Record
Data Warehouse
InfoManager
Message Clients
30
New standards…
Workflow processes can be defined using BPMN The Interoperability Layer (IL) can obtain workflow
instructions from the ICP actor using IHE’s “Retrieve Process for Execution” (RPE) transactions
As appropriate, guideline-informed messages may be written to a Message Queue; these messages may indicate that a specific Message Client is the intended recipient
Message Clients, directly or through an intermediary, may poll (or subscribe to) a Message Queue (NOTE: IHE’s NAV or DSUB profiles could possibly be leveraged)
31
“Get” content
32
“Get” contentNew “actor”
New “transaction”
New “processing logic”
33
“Put” content
34
“Put” contentNew “actor”
New “transaction”
New “processing logic”
35
Alerts / reminders
36
Alerts / remindersNew “actor”
New “transaction”
New “transaction”
New “transaction”
New “actor” New “actor”
New “processing logic”New “transaction”
What would a new ICP Working Group do?
Scope…
The ICP Working Group (ICP-WG) would be “care process” focused; it would answer the question: what will we use the HIE for?
The ICP-WG will draw in stakeholders from existing care domains: MNCH, Immunizations, HIV, TB, Malaria, NCDs (e.g. Diabetes, COPD), Emergency Care, etc.
The HIE transactions exposed by OpenHIE’s technical communities will be leveraged by the ICP-WG to document, orchestrate and operationalize care guidelines
Scope…
There will be technical issues for the WG to resolve How will ICPs be described? How will decision logic be operationalized within
OpenHIE’s architecture? There will be governance issues to address, too
Which care guidelines will be operationalized? What will be the governance of ICPs? How will country adaptations be managed? What reportable metrics will be supported, and how?
How might we begin?
Immediate opportunities..
There are active projects underway that could benefit from and leverage ICP support in OpenHIE BID immunization projects (TZ, ZM) South African maternal care project RHIE project
By leveraging standards-based architectural elements, a working technical prototype could quickly be developed (~3-4 months)
Existing care guidelines could be leveraged as initial “base” ICPs (e.g. WHO, national adaptations)
Launch strategy
Start a parade (everyone loves a parade!)… Make immediate, pragmatic technology and ICP
decisions to enable rapid prototyping TZ EPI guideline; ZA maternal care guideline Express guidelines using BPMN Leverage IHE RPE profile for IL-ICP messaging
Engage with active project team members as first ICP-WG participants (e.g. BID, ZA maternal project, RHIE)
Leverage initial activities to draw in new participants over the course of the first year (e.g. JLN, WHO, World Bank, GSMA, other country partners, other care domains)
Proposed ICP-WG leadership
As agreed at the Indy Architecture meeting, at launch, InSTEDD and ecGroup will provide leadership for the new working group; Ed and Derek will (initially) co-chair
ecGroup will provide technical support for initial rapid prototype development of an ICP “actor”
The governance structure will be evolved by the working group memebers over the course of the first year; it will be fluid… domain-specific subgroups may arise (e.g. MNCH, EPI, etc.)
Actions…
Issue a call for new members/participants Establish a work calendar
Schedule ICP-WG conference calls Establish a work plan
And…start!