Hi,
We have a project that’s working on referring lab orders from a lower level lab up to the national laboratory for CD4 viral load counts. The national lab processes the test and returns a result back to the lower level lab. The lack of standard internet connectivity at the lower level labs will cause a number of failures on both levels. Because of this, I’m scoping a push/pull mechanism that utilizes a centralized broker to store the orders and requests at the national level. In this case, the local labs would put the orders in a national broker/queue that would be read by the national lab on a regular basis. The same would happen for the lab results where the national lab would put results in the broker and the local clinic would download those results when internet connectivity was available.
The national broker would have to have a number of features:
-
access controls
-
audit capabilities to see what’s been pushed and pulled, but we would also want point of service systems to check that a specific order was picked up by the national lab
-
tracking the last time the clinic accessed the queue (from my previous post)
Questions:
-
Are others working on this problem? If so, has it been solved with OpenHIE?
-
Is this problem appropriate for an HIE, or should another mechanism be considered?
-
I know of the lab order and request HL7 profile, which defines the messaging format, but I don’t know if IHE or other standards bodies have addressed environments where the internet goes out frequently. Are we treading new ground?
-
I see that the mechanism of pushing and pulling information is core to the HIE, especially with the SHR. Though I need to solve this for lab orders/requests, this problem feels like it could be solved by a generic messaging service. Do others agree? Has anything like this been developed?
Thanks,
Craig
Hi Craig,
We faced a similar challenge (intermittang connectivity) in our Rwanda project a while ago when we were sending data from OpenMRS to the HIE (and to SHR). We developed an asynchronous data exchange mechanism where messages would be queued in OpenMRS and then sent to the HIE when there was connectivity (i.e. client to central) we didn’t implemente the reverse though. I know the OpenHIM has a queuing mechanism on its channels (@Ryan C?) that may be of use in this solution and one may consider pointing a HIM to a HIM to leverage these features – we’ve been discussing the concept of a Local Information Mediator in some of our RSA projects to support similar ideas. And come to think of it I think the DATIM work was really pushing forward the local node to central node communications through the HIM to support similar async work (I stand to be corrected).
To your questions more directly:
-
We aren’t directly working on this type of problem now (Jembi) but have in the past. I think we are a way towards solving this within OHIE with the queues in the HIM.
-
I think it is appropriate for a HIE in developing settings
-
I’m not sure about the IHE around intermittant connectivity
Hope this helps.
···
On Mon, Nov 7, 2016 at 8:01 PM, Craig A. cappl@uw.edu wrote:
Hi,
We have a project that’s working on referring lab orders from a lower level lab up to the national laboratory for CD4 viral load counts. The national lab processes the test and returns a result back to the lower level lab. The lack of standard internet connectivity at the lower level labs will cause a number of failures on both levels. Because of this, I’m scoping a push/pull mechanism that utilizes a centralized broker to store the orders and requests at the national level. In this case, the local labs would put the orders in a national broker/queue that would be read by the national lab on a regular basis. The same would happen for the lab results where the national lab would put results in the broker and the local clinic would download those results when internet connectivity was available.
The national broker would have to have a number of features:
- audit capabilities to see what’s been pushed and pulled, but we would also want point of service systems to check that a specific order was picked up by the national lab
- tracking the last time the clinic accessed the queue (from my previous post)
Questions:
- Are others working on this problem? If so, has it been solved with OpenHIE?
- Is this problem appropriate for an HIE, or should another mechanism be considered?
- I know of the lab order and request HL7 profile, which defines the messaging format, but I don’t know if IHE or other standards bodies have addressed environments where the internet goes out frequently. Are we treading new ground?
- I see that the mechanism of pushing and pulling information is core to the HIE, especially with the SHR. Though I need to solve this for lab orders/requests, this problem feels like it could be solved by a generic messaging service. Do others agree? Has anything like this been developed?
Thanks,
Craig
–
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/b40a668b-8b40-4ba9-b723-c936509a0936%40googlegroups.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.