Hi All,
The OpenMRS client module for OpenHIE is located here:
https://github.com/justin-fyfe/openmrs-module-openhie-client , there are lots of helper methods which let you turn OpenMRS objects into CDA documents quite easily. There are (if I remember
correctly) OpenMRS services provided for client registry, document registry, CDA, and audit. It also is able to register, search and send updates (via AOP) to the client registry. Please note:
This module knows when/if it needs to resolve identifiers prior to contacting the IL as we use this code in other, non OpenHIE
HIE demonstrations (i.e. it is a real IHE PIX client and document consumer) and sends ATNA audits.
It requires a slight change to the OpenMRS UUID field as that is where we stuff OIDs for identifier types. That data should
be in a separate field but (see #3)
It was written in two weeks under extreme pressure (actually about 200 hours over two weeks) so I make no claims about code
quality, documentation, style (rants in comments), etc.
It hasn’t been to connectathon so it may not be completely conformant to the IHE standards. It is “hacked enough to work”
quality messages.
You can see the demo here:
http://pos.aehin.marc-hi.ca:8080/openmrs/, the username/pwd is “lucy/Mohawk123”.
The easiest and most consistent way to integrate components to the HIE Is to have each vendor implement, as best they can, the standards
based interfaces to the HIE, or else you actually gain nothing by having the HIM in terms of the dreaded n(n-1)/2.
I think the database mediator is interesting, however would insist that it be used as a tool by the vendors for using standards to
connect to the national/regional HIE (i.e. basically the HIM is turned into a Mirth type tool). I think it would be the thing of nightmares to try an do that type of thing centrally as database schema changes can be difficult to detect unless the software
vendor is the one maintaining the maps. Beyond the security considerations there are versioning, licensing (in the case of proprietary systems), and scaling issues which must be considered and I’d rather that be pushed to the experts (i.e. developers) of
those systems.
Cheers
-Justin
···
From: Pierre Dane [mailto:pierre@jembi.org]
Sent: May 19, 2016 4:55 AM
To: Ryan Crichton ryan@jembi.org
Cc: Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com; Ralf Hundertmark ralf.hundertmark@gmail.com; Craig A cappl@grameenfoundation.org; Fyfe, Justin justin.fyfe1@mohawkcollege.ca; admarcelo@up.edu.ph; Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: Configuration of connected applications (firstly OpenEMPI, OpenMRS)
Hi all,
I have another item to talk about related to POC integration with the health exchange.
We know that there are many many systems in the field that are 1) not reliably connected to the internet and 2) often proprietary, cannot be modified and/or there are no resources available to make modifications required for HIE integration.
One model that we have been thinking about (and have prototyped for an iDART integration many months ago) is to have a service that accesses the database of the POC system directly, pulls changes, creates relevant messages and queues them
until connectivity is available.
We’ve called this a LIM (local information mediator) . There are obvious concerns about security (the service having database access etc), and the operational complexity but I think those need to be dealt with on a case by case basis.
I’d be interested to hear anyone elses thoughts on this approach.
Best,
Pierre
On Thu, May 19, 2016 at 9:28 AM, Ryan Crichton ryan@jembi.org wrote:
Hi Derek,
Thanks, I don’t think I’ve managed to get a demo of this. It may be a great way to kick start this work. I really think us as OHIE need to adopt/create a reference PoC that we maintain to keep inline with our workflows for demonstration
purposes and to ensure our workflows are actually implementable. If we maintain a reference PoC then we also won’t have to keep building a new system for demos that we are giving.
Is the source code for this demo PoC available anywhere?
Cheers,
Ryan
On Mon, May 16, 2016 at 1:44 PM Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
I’m drawing Justin Fyfe into the conversation. Justin developed a module that was employed to connect
OpenMRS to the OpenHIM as part of the live interoperability demo presented at the AeHIN conference in Bali last October. I’m also cc’ing Alvin Marcelo since, only a few weeks ago, the new AeHIN COIL lab took delivery of all of the IP developed by the MEDIC
lab for the Bali demo, so he has a copy of that, too.
I hope this is helpful.
Warmest regards,
Derek.
**Derek Ritz,**P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
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:
openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com]
On Behalf Of Ralf Hundertmark
Sent: Monday, May 16, 2016 4:52 AM
To: Craig A
Cc: Interoperability Layer (OpenHIE)
Subject: Re: Configuration of connected applications (firstly OpenEMPI, OpenMRS)
Hi Craig,
Yes, we are trying to connect OpenMRS as a point of service application through OpenHIM to the OpenEMPI.
It is very straight forward with our legacy application but I guess for OpenMRS we need to write a new module.
Our team is now learning how to do that using the resources here:
https://wiki.openmrs.org/display/projects/Integrate+Registration+Module+with+a+Master+Patient+Index
We will certainly join the group and share.
Best regards,
Ralf
On 12 May 2016 at 00:02, Craig A cappl@grameenfoundation.org wrote:
Hi Ralf,
I think I read this differently than Ryan. Are you having trouble connecting OpenMRS as a point of service application or within the OpenHIE infrastructure (Shared Health Record)?
I second Ryan’s recommendation on providing a reference implementation of a point of service system and would like to support that effort in the new
OpenHIE Implementers Network working group.
Sincerely,
Craig
On Thursday, May 5, 2016 at 8:06:17 AM UTC-7, Ryan Crichton wrote:
Hi Ralf,
Thanks for reaching out. Unfortunately, there isn’t an out of the box method of connecting OpenMRS to OpenHIE. There has been some work done by the OpenMRS community to try to hook
into OpenEMPI, however, I’m not sure of the state of these. Although, they may help you get started:
https://wiki.openmrs.org/display/projects/Integrate+Registration+Module+with+a+Master+Patient+Index
https://wiki.openmrs.org/display/projects/IHE+Interoperability±+Patient+Administration+Management
I think it would be great for OpenHIE to provide a reference implementation of a point of care system like OpenMRS that can connect to OpenHIE. Would this be something that you
would be interested in? If so, perhaps we could start the discussions around this within OpenHIE.
Cheers,
Ryan
On Sun, May 1, 2016 at 3:36 PM Ralf Hundertmark ralf.hun...@gmail.com wrote:
Hi everybody,
We are setting up a OpenHIE lab environment and have now managed to install the following systems individually:
OpenMRS, OpenEMPI, OpenHIM Core and Console, another instance of OpenMRS (serving as SHR) and informan.
We have followed the tutorials for creating a mediator and that has worked smoothly.
Now however, for quite some time we are struggling to get both OpenMRS and OpenEMPI to connect to the OpenHIM core.
I would be very happy to learn how the two applications MRS and EMPI are configured (on their respective sides) to start “talking” with the core.
Thanks a lot,
Ralf
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27845829934 | Skype: ryan.graham.crichton
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout.
–
Pierre Dane
Jembi Health Systems
Software Development Manager
tel: +27 (0)21 701 0939
cel: +27 (0)83 680 8274
email:
pierre@jembi.org
web:
www.jembi.org
and /or may want to create a shadow environment that can be manipulated but keep a master copy of the demo that does not change.