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
Time
Item
Who
Notes
Authentication
OAuth2 in OpenLMIS v3
5min
Master data alignment
(Or put another way: aligning NexLeaf alerts to OpenLMIS CCE inventory)
Name
RESTful HTTP & JSON?
Ideas:
FHIR / healthsites.io / GOFR
GLN / Serial #
Messages / Alerts
Framing the definition in NexLeaf
Using "types" of alerts to drive process in OpenLMIS (only one process atm, flagging a piece of inventory as needing review)
Push or Pull
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?
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.
