As part of the OpenHIE hack-connect-a-thon, an attempt was made to prototype using HEARTH as an FHIR server in the OpenLMIS v3 microservice. However, this work does not fully address the need to evaluating what other options are available and which one is the most suiting framework to use in OpenLMIS. This page is an attempt to document lessons learned so far and document topics/questions that may need to be answered with a full spike.
...
OpenLMIS v3.4 exposes a partial implementation of Location resource specification from the mCSD profile. To conform with the mCSD profile, OpenLMIS needs to support the full set of operations related to resources like Location and Organization as outlined in ITI-91. To support these set of interactions, one less expensive option is to use a FHIR server running as a microservice in OpenLMIS.
At the OpenHIE hack-connect-a-thon, a prototype close to this diagram was developed. However, there are a number of research topics that need to be addressed for the spike to be complete. On a higher level the most significant topic is evaluating the different available tools and deciding which one is the most appropriate dependency to be adopted in OpenLMIS as ticketed here:
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Using each tool, there is a need to evaluate the following.
...
- How does the update get triggered? Polling? or will we customize hearth to trigger processes in OpenLMIS?
- What happens with conflicts?
Using HAPI API
- How does the update get triggered?
- What happens with conflicts?
- Explore if and how the implementation option in the diagram below can be used for this use case: it is from http://hapifhir.io/
| Question | Proposition | LoE |
|---|---|---|
| How does the update get triggered? | We could create a server Interceptor which will send a request to the reference data service. To define what resource should be created in the OpenLMIS, we could use the physicalType field from a location resource. | Medium / Large |
| What happens with conflicts? (determining FHIR resources that are "owned" by OpenLMIS vs. FHIR resources that are not, so OpenLMIS cannot update those resources) | We could use an extra data property in facility/geographic zone like fhirResource and when FHIR server will send a request the flag will be set to true. To avoid problems, the flag should be editable only for service-level tokens. In other words, if a user will try to set this flag, an error message will be shown. | Small / Medium |
| How to determine OpenLMIS resources that can be modified by OpenLMIS (because they were created in Reference Data and synced to FHIR), vs. those that cannot (because they were created in FHIR and synced to Reference Data)? | With the flag that was described in the previous question, it should be easy to verify which resources are from FHIR server and which from OpenLMIS. | Small |
| How to "ignore" mCSD FHIR resources that OpenLMIS reference data does not need to sync | With the server interceptor, it should be easy to verify which requests should be also sent to the OpenLMIS. | Small |
Other research topics
- How to more appropriately represent facilities and OpenLMIS entities?
- Identities (should openlmis identity be used as is in FHIR server? or should the identifiers be used to reference the identifier?
- should tags field be used in any way? like for other attributes that we care about? facility type? or other metadata?
- How would we want to use Organization resource from FHIR spec? Does it make sense to use it to represent some of the supply chain relationships like supervisory nodes? facilities? facility owners? public/private etc?
- in the current OpenLMIS Location resource, there are some references like programs in identifiers. is an OpenLMIS program an identifier for all facilities that support that program?
...