2018-09-06 FHIR Meeting notes

Owned by Sam Im (Deactivated)
Last updated: Sept 07, 2018 by Łukasz Lewczyński (Deactivated)
3 min read

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes

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:

  • HAPI seems more mature in the space
  • Hearth has better performance

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


Meeting Notes

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

Action items

OpenLMIS: the global initiative for powerful LMIS software