2017-08-29 NexLeaf Integration Meeting notes

Date

29 Aug 2017

Attendees

• Josh Zamor

• Martin Lukac

• Terrance

Goals

• Authentication
• Outline how an OpenLMIS and NexLeaf integration aligns around master data:  Administrative hierarchy → Facility → Fridge → RTM → Sensor
• Frame the sorts of messages (alerts) that an integration with OpenLMIS is most interested in, looking for generic APIs
• Readout for project on architecture for authentication, master data alignment and message/alert "types"

Discussion items

Notes

Basic Conceptual Arch Diagram

Authentication (and push/pull)

• general agreement on using OAuth2
• first iteration is the use-case of pushing alerts from Nexleaf to OpenLMIS, this means that Nexleaf would get form OpenLMIS a web-token
• more work is needed on OpenLMIS' oauth2 implementation to support SSO (use cases where user wants to see details in Nexleaf after being notified in OpenLMIS that there is an issue)
  • should re-visit JWT

Master data alignment

• the fridge is the basic unit to identify (history is important)
• unique identification is a problem (people and process) - getting a serial number isn't always guaranteed.  e.g. in SELV we could only get things like:  Dometic 1 and Dometic 2.
• identification systems (aka coding systems) are needed.  However getting an implementation to use one (any one) is usually a people and process challenge.
• "service discovery" feels useful.  And FHIR could help here.  As an example we could imagine that there is a FHIR server which identifies FHIR locations and (possibly a separate one) Devices.  Devices may be located within a Location.  A Nexleaf user that is working to add an RTM device to a refrigerator could discover the fridge directly by knowing the device's identification (e.g. GLN, serial number) or by finding the fridges (Device) which are inside a Facility (Location).  The FHIR lists of Facilities and Refigerator's are shared, ideally where a ministry-ran Facility Registry is a FHIR server for Facilities and the CCE inventory (fridges, freezers, cold rooms, etc) is a FHIR server that OpenLMIS and Nexleaf (and possibly others) share.
  • the FHIR server for CCE inventory is ideally stand-alone, so that OpenLMIS could be deployed without Nexleaf and Nexleaf could be deployed without OpenLMIS, and yet should an implementation suddenly connect the two, the structure of where CCE inventory is located within Facilities is defined in a re-usable place.
• FHIR appears to help support uniquely identifying a thing such as a fridge (RESTful principal with the unique identification being the URL) while allowing for the people and process to also uniquely identify the thing through supporting identifications through multiple coding systems (e.g. GLN, serial number, etc)
• There is a lot to verify here:
  • do we really understand FHIR correctly
  • which systems would need to implement FHIR:  OpenLMIS (seems logical)?  Nexleaf?
  • who runs the FHIR server when either OpenLMIS or Nexleaf are deployed when there aren't integrations?  i.e. how do we support on-ramps for integrations, and also customers of both systems to get start in either with minimal overhead.
  • is their a potential to leverage a reference implementation such as http://hapifhir.io/
    • how does auth work?

Summary:

•  Oauth2 works for everyone. It covers the base cases of push or pull
• Generally seems to cover future use cases
• Need to consider webtoken cycling/user paths [terence? correct this?]

• General agreement that first pass could be coldtrace pushing alarms/notifications/status to openlmis.

• For interfaces between openLMIS and an RTM system we need:
• unique CCE identifiers across the systems
• unique facility identifiers across the systems (helps with the humans aspects)
• consider things like GLN since getting serial numbers is difficult
• GLN is pay to play ... will countries pay? what value does it have that an openlmis generated uuid won't provide?

• Operations we need around equipment/facilities for interfaces to work:
• service discovery/browsing: ability to get the whole list
• update: enough information to track changes either manually via regular service discovery or some sort of update mechanism/differential feed

• Questions
• Are there other identifiers that are needed?
• Can existing facility registries be used?
• Will FHIR help out? How would it fit in our systems?

Action items

• Josh Zamor to get more up to speed on FHIR
• Martin Lukac to update these notes
• Josh Zamor to write the tickets for improving Auth service to support web-tokens for Nexleaf to push alerts
• Josh Zamor to write the epic for SSO - use case is an OpenLMIS user navigating to Nexleaf for more information after seeing in OpenLMIS that there is an equipment issue.
• Josh Zamor to share more with Rachel Powers (Deactivated) this idea of Alert "types" for inclusion in user stories.
• Josh Zamor and Martin Lukac to hold another architecture call to share notes/thoughts on master data alignment, FHIR, etc next Wed (Sept 6)