Exploring Ways to Add ICP Support to OpenHIE A discussion document… 2014-05-14

Preview:

Citation preview

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!

Recommended