Hi all.
Sorry to slow responding to this very interesting thread; I’ve been traveling the last few days.
There are a number of referral message specs and patterns that have been balloted as standards-based processes. Some or all of them may be of use to us; we can tap into whatever “serves us” from the pre-existing body of work in this space.
· Carl F has already identified the CSD (Care Services Discovery) profile. This profile, as the name implies, may be leveraged to answer questions germane to referral workflows such as: “at which facility/facilities is service X provided?”; “what are all the services provided at facility Y?”; “who are the health workers who provide service X… and at what facilities?”; “what are the services provided by organization Z… and at which facilities are these services provided?”. The first section of this profile describes a set of use cases that the profile is intended to satisfy; a number of these use cases are referral workflows. The CSD spec can be found here: http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_CSD.pdf.
· When a subject of care is referred to a specific health worker (a specialist) or to a specific facility, summary information about the patient is also (typically) conveyed. There are IHE profiles regarding referral content; specifically, the XDS-MS (medical summary) CDA document is used to fulfill this use case. IHE’s patient care coordination (PCC) technical framework describes the content modules and the rules around exchanging such CDA documents (vol 1: http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol1.pdf; vol 2: http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf; supplementary content modules: http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_CDA_Content_Modules.pdf). OpenHIE’s workflows for saving clinical information and querying for clinical information may be leveraged to save and query for these referral documents. [NOTE: the XDS-MS content profile is very flexible, but the minimum required content elements are relatively few.]
· There are a number of IHE profiles that have been specifically developed to support patient referrals. These are generally managed by the PCC technical committee. A list of IHE’s PCC profiles, including a number of supplements which are in trial implementation, is found here: http://wiki.ihe.net/index.php/Profiles#IHE_Patient_Care_Coordination_Profiles. Any CDA-based profile is supportable, today, by OpenHIE’s existing clinical information save & query workflows. Some of the newer PCC profiles leverage FHIR – and this is slated to be supported in a future version of OpenHIE (maybe v2?).
Also, as discussed on our FR call today, there are different referral “archetypes” and we are well-served to separate these out so that their unique characteristics can be understood and supported.
Point-to-point referral vs. refer-to-queue…
· Refer a subject of care to a specific health worker. This referral is very precisely articulated and may well lead to an appointment being set up with the target care-giver.
· Refer a subject of care to a specific service queue. This kind of referral is more generic; it may refer a patient for specialized testing or surgery… but not to a specific health worker. The premise is that the queued patient will be serviced by the next available provider. In the case of a specialist referral, this “becomes” an instance of case #1 once the provider-referral connection is made. However, in urgent or even emergent cases where a patient is referred to a facility that offers the necessary service, the queue the patient joins is the physical queue in the facility waiting room.
· Sometime referrals are care pathway-based escalations triggered by a lab result or by a clinical observation (e.g. blood pressure, temperature, etc.). An HIV patient whose CD4 count drops below the MOH-set threshold is automatically referred into the ARV treatment programme, for example. A pregnant mum with a high blood pressure reading at her ANC visit may be routinely referred from the health outpost to the district clinic. [This latter pattern is also reflective of geographic catchment areas that share a common referral facility.]
One of the things I’d strongly advocate for is idea that we would try to construct our referral workflow out of the “primitives” that we already have in OpenHIE; that this would be a “composite” workflow in the same way our “save clinical information” workflow is. I hope there is support for this line of thinking. It is how we get “paid back” for the effort we’ve put into implementing generic, re-usable, standards-conformant capabilities in our infrastructure.
Derek.
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality.
···
From: ohie-implementers@googlegroups.com [mailto:ohie-implementers@googlegroups.com] On Behalf Of Carl Fourie
Sent: Thursday, August 11, 2016 4:43 AM
To: OpenHIE Implementers Network (OHIN)
Subject: [ohie-implementers] Re: Referral Registry solution and model
Hey Scott
I’m wondering if your first use case described here (where is this service etc) could be fulfilled by an implemented CSD/Infoman with the facility and provider registry info?
I’m not so sure that recording the details of a referral in an EMR only is the best solution as it may make it difficult to look for duplicates and keep a historical record of all referrals across a implementation area (national etc).
I guess it could be argured that a referral registry is a “sliver” across the entire HIE: Refered Patient [PMI], Referring Provider [PR], Referring Facility [FR], Facility Referred to [FR], Referal Details [SHR], +Business Logic for follow ups etc. Or it may be better suited by a fit or purpose tool of similar function like InfoManager.
I’m wondering what the communities experience is in what data is needed to manage referral? My first pass would be:
Register New Referral
Patient Details [Name, Contact Mechanism, ID]
Referral Encounter [Date of Referral, Referral Reason (Coded), Facility Referred to, Date of Expected Visit]
Referral Provider [Provider Detail (Name, ID), Refering Facility (optional)]
Referral UUID
Register Completed Referral
Referral ID [Referral UUID*, Patient Details [Name, Contact Mechanism, ID]]
Referral Encounter [Date of Encounter]
Provider [Provider Detail (Name, ID), Facility (optional)]
I think that should help cover the questions:
-
Who was referred to X facility for Y reason?
-
Who has missed the expected visit date?
-
How many people have been referred for Y reason
-
How many referrals have been completed?
-
How many people have been seen at a facility taht wasn’t their referring facility.
-
How many people have not presented by X Date?
-
Am I able to generate reminders to persons to meet referral?
Anyone have any thoughts or comments on this? Tear it apart and or replace with your experiences etc?
On Thursday, August 11, 2016, Scott Teesdale steesdale@instedd.org wrote:
Hi - awesome conversation going here. We have bumped into the need and a series of related ones a few times as well. Although I dont think we were as interested in having a registry of all patients referred everywhere - more so we have looked into what it would take to create a POS tool that could leverage say HIE components - to get the facility/provider information they need to say, based on you needing this service - here is where you should go now and are they open, ask for this person, etc… Recording of the details of the referral seems like it could best exist in the EMR.
We have a facility registry community meeting tomorrow, I’ll add it into the mix of topics and report back here if we are able to source some additional details (tangible examples or potentials scenarios for how it could work).
- Scott
On Wed, Aug 10, 2016 at 3:14 PM, Carl Fourie carl@jembi.org wrote:
Niamh it reads that your system that you have referenced encompass a range of key functions from referrals to live support desk with emergency response features too. How long has this been running?
I think you raise a great point in the value and need for political buy in and direction for a large nation wide impact solution. @Carl L is your use case national or more project specific?
With regards to the actual workflows and day to day functions is there any documentation (or are you able to describe/share) what the various data exchange and fundamental functions of the solution is? I’m curious to see if there are common feature sets/functionality and or workflows between the 3 ideas on the table.
Cheers
Carl
On Wednesday, August 10, 2016, Darcy, Niamh ndarcy@rti.org wrote:
We have several referral Use Cases we implement in Indonesia, in 6 provinces and 40 districts in a “Referral Exchange”. This is not specifically based on OHIE as Indonesia is very decentralized and the MoH sets more standards around what data it needs and does not specify what HIS the district needs to support – each one doing their own thing for HMIS currently. This also includes in some districts call centres connected into the Exchange, where providers can call in with emergency questions and ask for assistance, along with automated routing.
This is also used as the Emergency Response system in 10 of these districts also (think 911 for those of you in the US). This handles emergency maternal and neonatal referrals. What is critical here is the governance and clinical work and then the technology follows – the MoU at the district level between the DHO and the providers, facilities to agree to referral pathways and standards has been very key – and these MoUs (called PKs) then convert into decrees which is a long process. The clinical side set some of the patient stabilization guidelines ahead of referral to reduce morbidity and mortality, for the leading causes of mortality. This created a collective sense of district ownership for health services rather than leaving this to specific providers, facilities, etc. This included public and private facilities also which is key in a referral network.
Am very interested in this question, and as we worked on eHealth Strategy in Tanzania we included a ‘Referral Exchange’ as a key component under the ‘EMR’ and management area.
Niamh
From: ohie-implementers@googlegroups.com [mailto:ohie-implementers@googlegroups.com] On Behalf Of Carl Fourie
Sent: Wednesday, August 10, 2016 9:20 AM
To: Pierre Dane pierre@jembi.org
Cc: OpenHIE Implementers Network (OHIN) ohie-implementers@googlegroups.com; Carl Leitner litlfred@gmail.com
Subject: Re: [ohie-implementers] Referral Registry solution and model
Hey all
Thanks for the rapid feedback. @Pierre I think it may be a different work flow but would like to hear from others and or to review the work flows against referral etc? Maybe it’s a function of a registry like this or a separate business function.
@Carl L: that would be fantastic. Anything g you can share here or point us towards? I’m very interested in understanding the work flows and business logic with reminders etc.
In discussing here a very high level set of functions would see a Referral Registery (RR) needing to have an option of registering a referral from a known institution including patients, reason, where referred to and date. As well as receiving a referral complete notification. Reminder to patient and reports to managers. (very high level as working on tiny keys ;-))
Sound similar and or are there other points in here that I’m missing?
Carl Fourie | Senior Program Manager | Jembi Health Systems NPC | +27715404477 | Skype: carl.fourie17
On 10 Aug 2016 1:49 p.m., “Pierre Dane” pierre@jembi.org wrote:
Interesting to note that these may or may not be ‘notifiable’ diseases in some countries - i.e. the lab is required to notify the MoH. This would be another pathway separate to referral - I think?
On Wed, Aug 10, 2016 at 2:42 PM Carl Leitner litlfred@gmail.com wrote:
Hi Carl,
We have some referral use cases that we are expecting to support over the coming year in at least one country. We have some initial high-level designing around this. Would be happy to have a discussion around this.
Cheers,
-carl
On Aug 10, 2016, at 8:32 AM, Carl Fourie carl@jembi.org wrote:
Hi All
I’ve been chatting to a colleague who is doing some work and discussions from a blood safety perspective and one of the topics that is coming up is the opportunity to refer patients that have positive test results for test such as HIV or Syphilis. This got me thinking that this is not a problem that is unique to blood safety but that the concept of “Referrals and lost to follow up” is in many areas of health care.
2 Questions:
1 - Has anyone done anything around this with OpenHIE before or have any experience (read solutions) to share around this?
2 - if not how could this be done using OpenHIE?
Cheers
Carl
–
Regards
Carl Fourie
Senior Program Manager | Digital Health Division
Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org
Email Disclaimer:
This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWg8AfOhADSxy7CMD-aHNguOX9NkkWK55pR54UdkAJ3Sxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/F71F7621-B766-4B81-9845-F00404B3A71B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
–
sent from mobile device
–
You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWh4eFwRaQYVRkaM977a55F2khoS7HSk0g9xNV2faQmU8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
–
Regards
Carl Fourie
Senior Program Manager | Digital Health Division
Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org
Email Disclaimer:
This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjq9mycq6w%3D_M1Oy1_AdAsWucExwqg3S8sbyZ0bGGC6nQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
–
Scott Teesdale
Project Manager - InSTEDD
Email: steesdale@instedd.org
Skype: scott.teesdale
Social: Twitter / LinkedIn
–
Regards
Carl Fourie
Senior Program Manager | Digital Health Division
Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org
Email Disclaimer:
This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWi-J0Srr4sSBzdXFM%2BYN%2B-RY72jTJmzjCdDH_Ce3qW%3DgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
