Been looking into fhir and how its integrated with OpenMRS. I looked at the the openmrs fhir module and after looking at the code, I came with these diagrams to explain what is happening there. Correct me if I’m wrong.
From the diagram above, it shows that fhir system is built on top of openmrs without any modification of our data model and api which I think is a good thing. The OpenMRS FHIR java api stands as an interface between fhir specific classes and openmrs. My question now is, since this is meant to be used when fhir type resources are requested, it has to be fhir strict. So what happens if a user assuming the system is completely fhir makes a post to say /DiagnosticOrder. What do we do with fields in DiagnosticOrder that we don’t have in our data model. Do we just ignore them or what? And also I’m curious as to how the decision to map fhir resources to openmrs data model is made. For example we have RadiologyOrder in radiology. While looking at DiagnosticOrder - FHIR v1.0.2 which just became an old specification, there are 3 resources that can work as RadiologyOrder. We have DiagnosticOrder, ReferralRequest, and ProcedureOrder. I understand what all the three fhir resources mean as explained by the spec but it would seem RadiologyOrder is used for all 3 purposes. So in building the fhir module, how do we decide that radiology orders will map to DiagnosticOrder, ReferralRequest or ProcedureOrder?
NOTE: These are not uml diagrams. I didn’t have any other tool to express what I want so I used uml components but they by no means bare uml meaning. The arrows just show which components interact with which.
Sorry but I only used a uml tool because i could not think of another tool to describe what I mean. The arrows don’t have uml meaning. It just shows which part of the system interacts with which. It has no relation to uml diagrams though it uses uml components.
The goal for the FHIR JAVA API was not only to leverage the OpenMRS JAVA API where only translation is needed (to avoid redundancy of business logic), but also to bypass the OpenMRS JAVA API and grow its own FHIR DAO layer where FHIR needs go outside the OpenMRS model.
In the near future, we’d like to support our bespoke REST API and FHIR side-by-side as your diagram suggests. Assuming FHIR adoption for new development takes off as expected and as our FHIR support & experience matures, we would start deprecateing REST in favor of FHIR.
We should be explicit about what parts of FHIR are supported and target adding support for those resources with the biggest near-term benefits – i.e., more mature resources and those that are preventing early adoption of our FHIR API.
One of the reasons for not committing everyone fully to the FHIR API right now is that FHIR is rapidly evolving. For example, the DiagnosticOrder in your example no longer exists. Over the past year it was renamed DiagnosticRequest and later subsumed into ProcedureRequest.
My advice would be to hack in the right direction – i.e., make an informed choice of where things will land and combine this with making the API as intuitive (consistent) as possible along with documentation and good examples. Obviously, for less mature resources, this task is harder. For radiology orders, this would be ProcedureRequest (or, if we’re supporting an earlier version, then DiagnosticOrder).
I disagree very very strongly with Burke on this point.
FHIR provides a great API for systems to communicate with each other, but if you are a JS developer writing a web client for OpenMRS, our native REST API is much much better.
Further, as @ivange94 notes, the OpenMRS model does not exactly match the FHIR one (and it will never match exactly). Therefore the FHIR API will never fully satisfy what consumers need to do with OpenMRS.
We will always have both a native REST API and also a FHIR API.
This is fair. I don’t think we disagree with plans for our bespoke REST or FHIR APIs within OpenMRS; rather, on expectations for the future capabilities of FHIR. Unlike @darius, I’m still hopeful the FHIR API could someday reach a point where it’s preferable (e.g., just as easy or easier for devs to use, better documented, with more tools/libraries available, etc.) and serves just as well for UI development as it does for interoperability between systems.
In other words, we won’t be deprecating the REST API until even @darius is favoring the FHIR API over it for day-to-day development.
Yes, FHIR is becoming more and more mature day by day. But they are still evaluating the use of FHIR specification and doing major changes to it. FHIR is very very active project and diversity of people are actively engage in improving the standard. With all of these efforts I believe FHIR will become the standard across medical data exchange. According to my experience, the data model of OpenMRS is not fully align with the resource representation of FHIR. In the long run, we may need to rethink how we should make our data model compatible with FHIR.
I think an example in support of @darius point is that FHIR will most probably never have resources for OpenMRS modules because this is something specific to OpenMRS and not related to exchange of medical infos. And as a dev I would still want to access such resources.
Much as it would be nice to align the data model with FHIR, I want to think the reality is that existing systems still use older standards, it’s been probably 3yrs+ when all we’re hearing is that FHIR is the new thing, I’m not saying this isn’t true but I still think the whole FHIR phenomenon hasn’t caught on as one might think in existing production systems. I wouldn’t recommend anybody with constrained developer resources to spend a lot of their time to change their existent APIs to align with FHIR yet. However, it should be fine for new features.
