Versions Compared

Old Version 1

changes.mady.by.user Sam Im

Saved on

compared with

New Version 2

changes.mady.by.user Chongsun Ahn (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Goals

Discussion items

TimeItemWhoNotes
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
  • Spike on two options for mCSD specific support
  • Assumption that we don't need the GOFR capabilities of IntraHealth fork of Hearth

Action items

  •