Hi @Mekom@all am implementing pilot OpenHIE implementation InstantHIE at a clinic , but while looking at Ozone docs and repos and even cambodia implementation
I just have a few questions though.
Does Ozone support an MPI like opencr or santeMPI or any other to quickly detect patient duplication, if not can it be integrated or better still have the entire Ozone HIS plug into an existing HIE workflow to specifically provide other clients(03, Senaite, odoo) and the rest ? important for detecting patient duplicates resulting from registration from multiple sites.
Is the 03 component of Ozone ready for basic hospital / clinic workflows?
Can 03 be switched with Refapp 2.x just in case within the Ozone HIS architecture ?
About interoperability, which interface(is it directly with hapifhir or rather via a mediator like say OpenHIM) does ozone use to allow for plugging of other fhir compatible systems / clients ?
Have also been tracking various release sprints for Ozone and looks to be in alpha phases . does this mean it’s not ready for actual production ? Am asking this because am thinking of actually switching OpenHIE with Ozone for piloting if the above are possible
Not at the moment since Ozone HIS is currently marketed a solution for health facilities (which doesn’t mean that it is all that it is, but that’s how it’s spun). However this can easily be achieved technically by adding new messaging routes its OpenMRS-drive middleware technology (OpenMRS EIP).
Depending on the requirements, one would want to introduce an additional layer between the facility-based EHR (Ozone HIS) and remote components of the national HIS (DHIS2, SHR, MPI, etc). This is typically where OpenHIM or any suitable alternative would come.
Yes, with caution. O3 has been rolled out to production in various ways, the only case that we know of O3 being used “as is“ in production is within Oz Kh that directly depends on O3 Ref App, see here. Oz Kh depends on the plain Ozone which in turns depends on the plain O3 Ref App (here).
This is fundamentally possible but would need to be tested thoroughly. We would like for Ozone to support all official and generic OpenMRS distributions to be options to choose from to be the EMR component, namely:
O3 (that’s the default)
Bahmni EMR (that’s the case for a number of Ozone Hybrids out there)
Ref App 2.x (that’s been done to some limited extent)
However right now only first two have been actively implemented and tested.
Ozone HIS uses a generic middleware EIP tooling that leverages OpenMRS EIP since in Ozone HIS pretty much all workflows are driven by OpenMRS. The middleware leverages both FHIR and OpenMRS’ REST Web Services and can interface with any other web API.
It is on Ozone’s roadmap to go beyond Ozone HIS and progressively turn into a platform that abides more strictly to OpenHIE standards.
The default flavour of Ozone HIS (as demo’d on the website) is as ready as O3 is ready. However Ozone as the integration/interoperability layer is used in production at multiple sites in the form of Ozone Hybrid (that is Ozone HIS where the EMR component is Bahmni EMR instead of O3).