Spike: Which FHIR libraries/servers could help us?

To implement mCSD, we need to support a few of the FHIR Resources as well as the additional transactions identified by mCSD. As part of this there are various technologies (libraries, servers) which implement some or maybe even all of what we need.

This spike would be to survey what's already out there and evaluate if we can leverage them, or will be able to leverage them in the near future, to minimize the amount of work we need to do.

Known FHIR and mCSD tech:

• HAPI FHIR - Supports all FHIR Resources, appears to be very mature

• HEARTH - Supports some FHIR, and some profiles

• FHIR's wiki on open source FHIR

Some initial pros and cons

HAPI FHIR

+ Appears to be the most mature reference implementation
+ Gives us a few options, we could leverage it as a full server, or more likely as Java libraries in our Java services to convert our data models to/from FHIR
+ Commercially backed by Smile-CDR
+ Apache 2 license
- Doesn't and likely wouldn't ever try to implement IHE or OpenHIE profiles such as mCSD, we'd need to add that support on-top of its capabilities.
- If used as a Server, database may not meet our production needs.

Jembi Hearth

+ Aimed at being a FHIR compliant server
+ Is working to add many different IHE / OpenHIE profiles (mCSD I believe is on the list)
+ Is working to deliver a platform which provides the most useful bits of FHIR, while also making it easier to add more workflows on top.
+ BSD 3 license
+ Backed by non-profit Jembi
- Only option is to use it as a Server
- It doesn't support all of FHIR - both in Resources, but also perhaps in Search, Bundle and other capabilities of FHIR.
- Newer to the scene, on the maturity spectrum of open source it appears to be still early in growing beyond an internal project (documentation, diversity of contributions, implementations)

Acceptance Criteria:

• Survey the various tech (servers, libraries, etc) that's out there, asking yourself what fits our needs best.

• Briefly evaluate each for (bullet points and/or paragraphs work):

  • Apparent maturity

  • Open Source fit

  • Technical fit with OpenLMIS

  • Security - and how would it work with OpenLMIS' security mechanism?

  • Testing and quality

  • Deployment/package/version management if applicable

  • Licenses and Contributions

• Writeup findings in the wiki, or in something that may be linked to from the wiki

• Present findings and give your recommendations to the technical committee

• Feel free to add what you feel is missing. e.g. What looks more interesting? What fits well with our open source community? Which has a better mascot? etc...