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
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