What IHE Delivers eReferral Search Services (eRSS) A proposed project leading to an IHE profile for eReferral Search Services based on the HL7/OMG Human.

What IHE Delivers

eReferral Search Services (eRSS)

A proposed project leading to an IHE profile for eReferral Search Services based on the HL7/OMG Human Services Directory (HSD) specification for interlinked registries (ILR)

1

What will this profile do?1. Describe the eReferral Search Services

(eRSS) client query and server response functionality

2. Support maintenance of the underlying registry information for the core entities

3. Support maintenance of the relationships between these registries

4. Provide a slot-based mechanism to support rudimentary scheduling of combinations of providers & facilities and of care resources & facilities.

2

AgendaWho needs this profile, and why?

What “underpins” the work item?

Who is supporting this work?

What is the Plan?

3

What problem is being solved?eRSS problem statement: In many scenarios, a client must be referred to an escalated or specialized level of care. In order to effect such a referral in a distributed health services environment, there must be a mechanism to determine where specialized equipment, services and/or providers are to be found – and when they are available there.

4

Sentinel Use CasesThe eRSS profile will support two key scenarios:

1. Querying for care resources at facilities and allocating capacity (slots)

2. Querying for providers at facilities and allocating capacity (slots)

Sort order functionality will support looking for “soonest” and/or “nearest” available, or combinations of these

Querying for and allocating resources + providers at facilities is supported by combining the two sentinel use cases

5

Query & Allocate Resources at a Facility

Mosa is a young pregnant woman; she is being seen by a community health worker, Grace, who is conducting Mosa’s 2nd antenatal care (ANC) visit.

Grace records ANC observations using SMS on her mobile phone.

Mosa’s blood pressure reading is high; she should be referred to see a clinician.

The cloud-based mHealth application queries an interlinked registries service to determine the closest facility (geo-coded Facility Registry) offering maternal care services (Resource Registry eRSS Client: R+F Slot LIST (order by “nearest” ASC, “soonest” ASC)

An SMS reply from the mHealth service indicates to Grace that maternal clinics operate on Tuesdays and Thursdays at the health facility closest to Mosa’s village.

Grace prepares a referral note for Mosa. Mosa is automatically added to the patient queue for the next maternal clinic at the facility. eRSS Client: R+F Slot ALLOCATE

6

7

Query & Allocate Provider at Facility

David Lambert sees his family physician, Dr. Black, regarding a recent knee injury.

Dr. Black diagnoses the problem as a torn ACL and decides to refer David to an orthopedic surgeon.

Dr. Black uses his EMR to search for orthopedic surgeons; a list is returned sorted by available consult timeslot (soonest to latest) and by location (closest to farthest). eRSS Client: P+F Slot LIST

After discussing the options with David, Dr. Black chooses Dr. Bone from the list and a “pending referral” is automatically created. eRSS Client: P+F Slot ALLOCATE

David returns home. Later that day, Dr. Bone’s office reviews the pending referral and accepts it. ILR-PF Slot Client: P+F Slot GET, P+F Slot UPDATE

A “scheduled referral” message is communicated to Dr. Black and to David. (out of scope)

8

9

What underpins this work?HL7/OMG HSD specification

Infoway blueprint discussion doc

Existing HPD, PWP profiles (for “backward compatibility”)

10

Entity Relationships

11

Facility Provider

OrganizationResource

0..n

1..n

1..n

1..n

0..n1..n

0..n

0..n

0..n 0..n

“Allocation” Relationships

12

Facility Provider

ResourceFacility +

+

Time Slots

:

:

ScopeSupport PLUGs (Put, List, Update, Get) for each of the 4 “registries”

Support establishing and maintaining relationships between the registries

Support “slot” management: Exposing Querying Allocating Committing

13

Scheduling ActorsILR-PF Slot Client & Server –supporting PLUG of provider + facility allocatable time slots

ILR-RF Slot Client & Server –supporting PLUG of resource + facility allocatable time slots

eReferral Scheduling Service (eRSS) Client & Server – the applications that will allocate schedulable slots

14

Data Maintenance ActorsFacility Registry Client & Server –supporting PLUG of facility information

Resource Registry Client & Server –supporting PLUG of resource information

Provider Registry Client & Server –supporting PLUG of provider information

Organization Registry Client & Server –supporting PLUG of organization information

15

Interrelationship ActorsILR-OF Client & Server – the applications supporting PLUG of interlinked organization + facility information

ILR-PO Client & Server – the applications supporting PLUG of interlinked provider + organization information

ILR-PF Client & Server – the applications supporting PLUG of interlinked provider + facility information

ILR-RF Client & Server – the applications supporting PLUG of interlinked resource + facility information

16

Transactions (PLUGs)Facility

Resource

Organization

Provider

Resource + Facility

Provider + Facility

Provider + Organization

Organization + Facility

Slots for Resource + Facility

Slots for Provider + Facility

17

Who is supporting this work?Canada Health Infoway SMEs Standards Collaborative

• Jurisdictional partners• IHE Canada

OpenHIE funded by PEPFAR Regenstrief Institute

• InSTEDD• Mohawk College• DHIS Project – University of Olso• Jembi (South African NGO)• Columbia University – Earth Institute• IntraHealth

Rwanda Ministry of Health – RHEA Project

eHealth Australia

18

What is the Plan?Develop and document Volume 1: Use Cases, Actors, Transactions, Process Flows, Implementation Strategies (milestone 1)

Develop and document Volume 2: Transactions (milestone 2)

Prototype and test at 2014 Connectathon (milestone 3)

19

Tasks1. Identify and evaluate the full suite of existing message standards

available for each of the proposed transactions and attempt to determine the vendor adoption of each of these.

2. Determine “light” (json, xml, hData) messages which align with existing HL7v3 standards

3. Select standards for each transaction

4. Develop “compound” transactions, as necessary, and define these using a rigorous orchestration language such as BPEL.

5. Develop IHE-conformant documentation for the use cases supported by this profile

6. Develop companion documentation (non normative) describing alternate configurations of registries.

20

Project

21

ID Task Name Work Duration Start Finish

1 Registry Management Client & Server 228 hrs 30.5 days Mon 13-01-07 Mon 13-02-182 Base Registries 84 hrs 12.5 days Mon 13-01-07 Wed 13-01-23

15 Combinations of Registries 144 hrs 18 days Wed 13-01-23 Mon 13-02-1834 ILR Query Client & Server 116 hrs 37 days Tue 13-01-15 Wed 13-03-06

35 Base Registries 28 hrs 26 days Tue 13-01-15 Tue 13-02-1940 Combinations of Registries 88 hrs 11 days Wed 13-02-20 Wed 13-03-0651 eSchedule Client & Server 48 hrs 6 days Thu 13-03-07 Thu 13-03-1455 Use Case Documentation 160 hrs 20 days Mon 13-01-07 Fri 13-02-0156 Technical Transaction Documentation 320 hrs 40 days Fri 13-03-15 Thu 13-05-09

Details

WorkWorkWorkWorkWorkWorkWorkWorkWork

M T W T F S S M T W T F S S M T W T F S S M T W T F'12 Nov 11 '12 Nov 18 '12 Nov 25 '12 Dec 02

RisksThe scope appears large; it will need to be documented well to be digestible by vendors

There is ambiguity regarding how “Care Resources” are defined; this must be cleared up without sacrificing flexibility

The profile will be used in both developed and developing country contexts; satisfying differing constraints with a single profile may present challenges/trade-offs

22

Other stuff…

23

Calendar

24