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

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

3. Agenda Who needs this profile, and why? What “underpins” the work item? Who is supporting this work? What is the Plan? 3

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

5. Sentinel Use Cases The 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

6. 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 2 nd 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. 7

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

10. What underpins this work? HL7/OMG HSD specification Infoway blueprint discussion doc Existing HPD, PWP profiles (for “backward compatibility”) 10

11. Entity Relationships 11 FacilityProvider OrganizationResource 0..n 1..n 0..n1..n 0..n

12. “Allocation” Relationships 12 FacilityProvider ResourceFacility + + Time Slots : :

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

14. Scheduling Actors ILR-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

15. Data Maintenance Actors Facility 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

16. Interrelationship Actors ILR-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

17. Transactions (PLUGs) Facility Resource Organization Provider Resource + Facility Provider + Facility Provider + Organization Organization + Facility Slots for Resource + Facility Slots for Provider + Facility 17

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

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

20. Tasks 1. 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

21. Project 21

22. Risks The 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

23. Other stuff… 23

24. Calendar 24