2018-09-06 FHIR Meeting notes

Date

Sep 6, 2018

As a follow up from Mind the Gap team grooming, we need to review the results from spikes this sprint and make a decision on which FHIR server to use moving forward.

Comparison of servers is here: https://openlmis.atlassian.net/wiki/spaces/OP/pages/428408849/FHIR+server+options
Spike tickets still in progress: OLMIS-5350, OLMIS-5351

Time	Item	Who	Notes

Time

Item

Who

Notes

OLMIS-5350

@Łukasz Lewczyński (Deactivated)

The number of resources in the database changed each time it was created. Each test created new resources until we got to the search portion, which was fixed at 1000 resources
We don't know right now the performance of searches that return a number of results like a hierarchical or geolocation search.
We don't have any metrics on the amount of memory being used in this
- It's been reported that HAPI FHIR has poor performance on memory because it runs through the entire postgres database, extracts a particular JSON attribute and then returns it.
- Hearth uses MongoDB, storing each location as a document
The number of locations seems low compared to expectation in Tanzania

OLMIS-5351

This ticket was not picked up for work.

Decisions

Josh Discussion:

We want to do more testing at a larger scale. We may need to add a caching layer.
Josh recommends that we move forward with HAPI FHIR and be open to switching it out.
In terms of architectural fit, Postgres vs MongoDB isn't in discussion for this call.
We are looking for this to provide a REST FHIR resource as JSON. We have not implemented searches and bundles. Practitioners are part of mCSD, but we will not support that. Instead of implementing the interfaces within our
OLMIS-5351 is a dependency here

Ashraf's Discussion:

Decision: Move forward with HAPI FHIR and continue researching OLMIS-5351

Elias provided a review of the FHIR server options
- In summary, Hearth is less mature than HAPI, but is targeted at the areas where we work.
- Questions:
  - Ashraf: The wiki page includes two use cases and we believe that use case 1 is closer to the OpenLMIS implementations. Which is more appropriate for use case 1?
  - There are many factors involved and the group needs to decided on it. In terms of stability, HAPI FHIR is more stable at this point.
Performance testing was done on the local machine FHIR servers performance
- Each test was run 5 times
- Both servers are good at returning a single location
- Searching for resources took longer
- Should test with 4,000-5,000 locations, 7,000 is the max that we've seen so far, and per Non-Functional requirements we plan to support 10,000 locations
Questions:
- Can we have multiple identifiers to retrieve the location?
  - Yes, we can search by any identifier that's already in OpenLMIS
- Can we scope the role of FHIR in the space?
  - OpenLMIS is not the source of truth of facility information when there is a facility registry in country.
  - This is scoped within the context of integrating with a facility registry that already speaks FHIR.
  - As we already know, they aren't in production.
Other items:
- mCSD standard is at http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_mCSD.pdf
- The Kenya MFL includes just over 10k facilities http://kmhfl.health.go.ke/#/facility_filter/results

Need metrics on memory used @Łukasz Lewczyński (Deactivated) (should this be included in spike OLMIS-5350?)

@Łukasz Lewczyński (Deactivated): Need more testing with more facilities (10,000 facilities - need new ticket?), and more comprehensive search

@Chongsun Ahn (Unlicensed) to prioritize next tickets to focus on Use Case 2 spikes (with tentative decision for HAPI FHIR)

@Josh Zamor (Deactivated) will send an email related to OLMIS-5351 and someone else will pick up after that.