What IHE Delivers eReferral Search Services (eRSS) A proposed project leading to an IHE profile for...
-
Upload
daniel-young -
Category
Documents
-
view
216 -
download
0
Transcript of What IHE Delivers eReferral Search Services (eRSS) A proposed project leading to an IHE profile for...
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
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
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