2018-09-26 mCSD Registry Sync Meeting

Owned by Chongsun Ahn (Unlicensed)
Last updated: Oct 15, 2018 by Elias Muluneh
3 min read

Notes

Since we’ve worked on OpenLMIS acting as source of truth of facility registry (use case 1), we should be able to stand up another OpenLMIS and sync two OpenLMIS instances? Yes

OpenLMIS facility registry sync with external registry

Why not create a reference mediator?

  • We want to be able to test/demo/stand up our solution w/o too many dependencies
  • With OpenHIM mediator, we would be dependent on OpenHIM, especially if it doesn’t get adopted (ex. Tanzania doesn’t use it)
  • Have more control in our solution
Not start with the mediator solution, but do something else, like atom feed (pub/sub)
Do something that we can test/demo/complete w/o being delayed by external dependencies
FHIR subscriptions, then message sending
  • Downside is that not resilient; if receiver is down, can’t successfully ensure delivery occurs
  • Could add something like RabbitMQ for more robustness
Start with REST-hooks; for testing, could stand up a mock server (like WireMock)
OpenHIM and mediators
  • Mediator mostly standalone app
  • need to add a few extra functions to be part of OpenHIM
First iteration
  • FHIR service subscription functionality
  • Some questions about scope of updates in subscriptions
  • Do a quick spike (with PoC) on making sure HAPI FHIR subscriptions works like we would need it to

What goes over-the-wire, basic unit of communication

Simplest seems to be talking about rest-hooks
Unclear what is returned from a query to the FHIR server, a bundle?
Will subscriber be putting in query the last time it’s read?
Onus on subscriber on getting the messages they care about
If two facility registries subscribe to each other, will this create federation or an infinite loop? edge case to check
Question of what would be triggering these rest-hooks
  • Seems like FHIR defines a criteria property on what gets triggered
HAPI FHIR generates its own id, but also can be defined in the identifier property as id in another system

Other discussions

Some properties will still need to be editable by OpenLMIS even if the location is not owned by OpenLMIS
Someone should go through and create two lists
What should we do about things that are required in OpenLMIS but not in FHIR locations?
We may not want to actually add all FHIR locations into OpenLMIS
If a facility is created in national registry, it would not automatically be added to OpenLMIS
Some separate step to add them to OpenLMIS
What about if a facility is updated? Updates happen automatically?
Need to make sure we are doing smart updates when FHIR locations update facilities, that OpenLMIS facility properties are retained
When do we trigger facility updates to FHIR locations? Do we try to make it smart and only trigger updates when applicable?

Facility properties

External registry manages (OpenLMIS cannot edit)

  • id
  • code
  • name
  • latitude/longitude
  • partOf (reference to location/geoZone)
  • status? (related to active and enabled below; who should manage the status of a facility?)

OpenLMIS can edit, whether or not location managed by OpenLMIS

  • description? (this exists in FHIR Location, but perhaps we may not want to manage it there)
  • facility type
  • facility operator
  • active, enabled? (who should manage?)
  • goLiveDate, goDownDate
  • comment
  • openLmisAccessible
  • supportedPrograms
  • extraData

Action Items

OpenLMIS: the global initiative for powerful LMIS software