...
- 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.
- Can we have multiple identifiers to retrieve the location?
- 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
Action items
- 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 will send an email related to OLMIS-5351 and someone else will pick up after that.