ICP - OpenHIE Wiki

Download Report

Transcript ICP - OpenHIE Wiki

Exploring Ways to Add ICP Support
to OpenHIE
A 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
Care-seeking
Not an emergency
HIV test; other tests
Prescribe ART
HIV positive
Enrol in HIV care
programme
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

Manage ongoing care…
Not an emergency
CD4; viral load;
other tests
Follow-up
Adjust medications
Adjust care plan, if
necessary
Active in HIV
programme
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

Manage ongoing care…
Not an emergency
No lab test
Follow-up
Refill ART
Active in HIV
programme
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

Care-seeking
Escalate care
Patient discharged
from hospital dead
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

Protocl-based care…
Not an emergency
Follow-up
Record clinical observations;
administer directly-observed
therapy, short course
Active in TB
programme
How could ICP support be
added to OpenHIE?
Mapping guidelines to ICPs…

A PEPFAR-funded analysis was made of multiple
WHO care guidelines:
1.
2.
3.
4.
5.
6.

HIV
Malaria
TB
Antenatal care
Emergency care
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 diseasefocused 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
Re-usable Transactions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
“On-board” or update a client
Resolve client ID
Capture health information about a client
Retrieve a client’s health information
Order lab tests
Get lab results
Order meds
Dispense meds
Refer (escalate care)
Discharge
Send reminders / information
20
Re-usable Transactions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
“On-board” or update a client
Resolve client ID
Capture health information about a client
Retrieve a client’s health information
Order lab tests
Get lab results
“Put” content
Order meds
“Get” content
Dispense meds
Both (Get/Put)
Refer (escalate care)
Discharge
Send reminders / information
21
1
3
3
2
4
5
4
6
3
3
4
4
7
11
8
3
3
4
3
4
9
10
22
Indicators
National
level metrics
District level
metrics
Facility level
metrics
Aggregate personcentric eHealth data to
generate indicators
Provider
level metrics
23
Leverage data to support UHC
Global Budget
DRG
Facility level
metrics
Capitation
Fee-for-Service
DRG
Provider
level metrics
OpenHIE can (and should) play a foundational
role in supporting universal health coverage
(UHC) initiatives
24
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?
Current architecture
Data
Warehouse
TS
Facility
Registry
Health
Worker
Registry
Client
Registry
Shared
Health
Record
Interoperability Layer
Point of
Service
Applications
27
New architectural building blocks
An ICP actor is a workflow server; it is a repository
of guidelines expressed in BPMN (the standardsbased 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

28
New architectural building blocks
InfoManager
Data
Warehouse
TS
Facility
Registry
Health
Worker
Registry
Client
Registry
Interoperability Layer
Shared
Health
Record
ICP
Message
Queue
Point of
Service
Applications
Message Clients
29
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)
30
“Get” content
31
“Get” contentNew “actor”
New “transaction”
New “processing logic”
32
“Put” content
33
“Put” content
New “actor”
New “transaction”
New “processing logic”
34
Alerts / reminders
35
Alerts / reminders
New “actor”
New “actor”
New “actor”
New “transaction”
New “processing logic”
New “transaction”
New “transaction”
New “transaction”
36
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 ICPWG 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 ICPWG 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!