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

2. 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?

3. What are ICPs and how do they “work”?

4. 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) StartEndDecision / Branch

5. 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

6. Enrol in HIV care programme Prescribe ART Care-seeking Not an emergency HIV positive HIV test; other tests

7. 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

8. Active in HIV programme Adjust medications Not an emergency Adjust care plan, if necessary CD4; viral load; other tests Follow-up Manage ongoing care…

9. 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

10. Active in HIV programme Refill ART Not an emergency No lab test Follow-up Manage ongoing care…

11. 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

12. Patient discharged from hospital dead Care-seeking Escalate care

13. 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

14. Active in TB programme Not an emergency Record clinical observations; administer directly-observed therapy, short course Follow-up Protocl-based care…

15. How could ICP support be added to OpenHIE?

16. Mapping guidelines to ICPs…  A PEPFAR-funded analysis was made of multiple WHO care guidelines: 1.HIV 2.Malaria 3.TB 4.Antenatal care 5.Emergency care 6.Public health emergency response  There are common “atomic” tasks/processes which appear in these care workflows

17. Common tasks across WHO guidelines 17

18. 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

19. A re-usable ICP

20. Re-usable Transactions 1. “On-board” or update a client 2. Resolve client ID 3. Capture health information about a client 4. Retrieve a client’s health information 5. Order lab tests 6. Get lab results 7. Order meds 8. Dispense meds 9. Refer (escalate care) 10. Discharge 11. Send reminders / information 20

21. Re-usable Transactions 1. “On-board” or update a client 2. Resolve client ID 3. Capture health information about a client 4. Retrieve a client’s health information 5. Order lab tests 6. Get lab results 7. Order meds 8. Dispense meds 9. Refer (escalate care) 10. Discharge 11. Send reminders / information 21 “Put” content “Get” content Both (Get/Put)

22. 23 4 3 4 5 6 3 4 3 4 3 4 7 8 9 10 3 11 22 3 1 4

23. Provider level metrics Facility level metrics District level metrics National level metrics Aggregate person- centric eHealth data to generate indicators Indicators 23

24. Provider level metrics Facility level metrics Capitation Fee-for-Service DRG Global Budget DRG Leverage data to support UHC 24 OpenHIE can (and should) play a foundational role in supporting universal health coverage (UHC) initiatives

25. 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

26. What architectural building blocks would we need?

27. Current architecture 27 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 28

29. Message Queue ICP New architectural building blocks 29 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 BPMNBPMN  The Interoperability Layer (IL) can obtain workflow instructions from the ICP actor using IHE’s “Retrieve Process for Execution” (RPE) transactionsRPE  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)NAV DSUB 30

31. “Get” content 31

32. “Get” content 32 New “actor” New “transaction” New “processing logic”

33. “Put” content 33

34. “Put” content 34 New “actor” New “transaction” New “processing logic”

35. Alerts / reminders 35

36. Alerts / reminders 36 New “actor” New “transaction” New “actor” New “processing logic” New “transaction”

37. What would a new ICP Working Group do?

38. 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

39. 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?

40. How might we begin?

41. 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)

42. 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)

43. 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.)

44. Actions…  Issue a call for new members/participants  Establish a work calendar  Schedule ICP-WG conference calls  Establish a work plan  And…start!