I see that one of the two reference implementations for OHIE Client Registry is OpenEMPI. OpenEMPI seems much more productized and less of a reference than the other implementation, MARC-HI/MEDIC. I’m a little concerned about the status of maintenance on the OpenEMPI reference implementation. Some observations:
I see that the company which licensed it originally stopped releasing new open source licensed versions of OpenEMPI in 2016.
My question is: does anyone have any insights into the continued maintenance of the open source licensed OpenEMPI code? I’m concerned vital patches and improvements aren’t being made to the open source licensed code base. Happy to help…
@eric ,
I believe the organization’s approach has changed a bit over the last few years. You have probably already seen: https://www.openempi.org/support/. I do know that there are other community members who have been engaged in OpenHIE in the past few years that are developing tools. One emerging tool is Hearth, which is a FHIR based approach being developed by Jembi (@ryan, @daniel.futerman) . Other tools are listed here: https://wiki.ohie.org/display/documents/Reference+Technologies.
Others may have had more direct contact with the OpenEMPI team over the past few years and may be able to provide more insight.
Sorry I cannot be of more assistance. You may need to contact SYSNET to get a better idea of their approach.
@jennifer.e.shivers , thank you for the information on HEARTH. It looks like a promising project, and I hope to collaborate with the people working on it. However, being in the “early stages of development”, it does looks like HEARTH has a way to go, before it reaches the productized feature set already in OpenEMPI <= v3.1.0, which I think is the last freely licensed version. It would be good to know if HEARTH is close to being an OHIE reference Client Registry, and if not, what that would require? Or is that even something the project would want?
Just thinking out loud here … for many of us already using OpenEMPI, it might be easier to add necessary FHIR features to the v3.1.0 code base as a derivative licensed work (Libre Client Registry, similar to the StarOffice->OpenOffice->LibreOffice progression?), especially for systems already relying on the freely licensed OpenEMPI. I also like the architecture of OpenEMPI <= v3.1.0, so “if it ain’t broke”…
Another issue, and this pertains to OHIE: listing a currently closed source product (current OpenEMPI version) as a reference implementation is problematic. Linking it to a secure, updated LibreCR would be much more tenable as a reference implementation.
I don’t know which, if any of the other OHIE reference implementations are in similar situations. I’m really curious what this group thinks about this topic.
Hi @eric - I think it’s worthwhile for you to consider the progressed version of the MEDIC CR. It is part of a new open source initiative: http://santesuite.com/index.html#. The same dev team is behind this new effort.
Re OpenEMPI, I agree that we need to be clear about what are the licenses of the solutions we’re touting as OpenHIE conformant. I’m not sure, though, that these all need to be FOSS offerings. This topic is on the agenda for the OpenHIE Architecture 2019-06-10 call on Monday, I believe.
@derek.ritz ,
Thank you, I will give it a look. That site looks more promising and energized than the MedicCR github site I had encountered previously. Also, the project has a great FOSS license (Apache).
Yes, and conformance is a whole other topic. I would think conformance is independent of licensing considerations, which are more of a business decision. A reference implementation, I think, entails reusability, transparency, and other things FOSS licenses can ensure. But yes, a reference implementation also entails conformance.
Conformance is a tricky subject, because in the context of vendor products, it entails a certification regime as its basis. Which is important, but I’m definitely much more interested in the reference implementation, at least for now… I been involved in two certification initiatives for HMIS (Homeless Management Information Systems, not Hospital) over the years, and it’s a lot of work to implement.