2018-08-31 Meeting notes

OLMIS-5261

@Elias Muluneh

• setting up HAPI FHIR as a microservice makes more sense and is easier, LOE is low

• For HAPI FHIR option, can create interceptors when making a change to FHIR server

OLMIS-5262

@Łukasz Lewczyński (Deactivated)

• Seems to default to application/fhir+xml? Can we change to JSON?

• Hearth FHIR supports JSON, although there may be a lack of feature where Hearth does support it through the header, but not support "format" request param

• Have we seen any atom feed support in the HAPI FHIR client, or the FHIR server? Any other communication method vs. direct REST calls? Do both have to be online when changes are made, or can it support async message queues? A: Seems not

  • Concern about temporal coupling; what is our approach? Ex: if we update a facility, and we try to update to the FHIR server, if it is not up, do we fail the request, or do we succeed and it is inconsistent?

    • We may want to go with temporal coupling at this point, most straightforward (both must be up, otherwise request fails)

• LoE should not be too much

• How will we handle access to the FHIR server APIs? Possibly making them "private"

  • Bigger thing to handle is that this OAuth access token is valid, since we are only dealing with just Locations and possibly Organizations

• How do we handle storing ids and version ids from FHIR to reference data?

• Spike on two options for operations: search/read, create, with data scale of X? facilities (~2700 in OpenLMIS demo data)

• Spike on two options for mCSD specific support

• Assumption that we don't need the GOFR capabilities of IntraHealth fork of Hearth