(Service accounts – backend connections/tokens with Nexleaf)
Create account or meta data with group structure to ensure that domain, path, tokens (access service account) for accessing openLMIS are known to the components in the NL system which will consume the data.
Future: single sign-on
Not in scope for Minimum Integration / first phase
OLMIS-3386: For interoperability with Nexleaf, provice FHIR Device resources for OpenLMIS CCE Inventory
For interoperability with Nexleaf, provice FHIR Device resources for OpenLMIS CCE Inventory
NexLeaf product being a consumer of the facility registry
Nexleaf needs to know how to read FHIR resources to discover facilities and CCE. Nexleaf needs to build a sync tool to do initial discover and updating (scheduled? push button?) of master data from openLMIS.
Tech design for CCE Inventory sync
Need to hold joint planning/tech design to identify the approach or the mappings of certain fields. There are 3 possible options on the table. #1 and #3 are the best.
CCEquipment catalog synchronization
OpenLMIS share their Equipment List with Nexleaf. Both sides ensure there is consistent mapping between fields indicating the make and model.
Needs to know make/model of devices at each facility. Need to make sure CCE catalog in both OpenLMIS and Nexleaf are synced
OLMIS-3136: Allow CCE Inventory Alerts to be pushed into OpenLMIS
Advocacy & Long-Term
PQS Catalog Standardization
Larger advocacy to get standardized, consistent, non-disappearing PQS list that is available as CSV/Excel (and not just PDF).
Standard REST API (HL7 FHIR?) for the PQS database
ATOM feed to query for changes from a facility registry
Maybe this includes advocacy with FHIR and OpenHIE communities? Promote this as a future standard?
we could look at fields in SELV API; talk about what we know about our users; what specifically means "needs attention" for us; what is the combination of Nexleaf metrics that tips something into the Non-Functional status?
Notes from : Who is the person looking at the information in OpenLMIS? We will want to make sure the person taking care of the equipment has time to address. Decided we focus on
What is the type of information exchanged?
The configuration of the flag would live within Nexleaf and a generic set of data will be passed. Based on configuration in Nexleaf.
% of time out of range (uptime)
For X duration
Potentially number of alarms
May be different flags for different levels (MJ: I wasn't clear if this was said so feel free to delete)
What would be the format of the information?
Martin will come up with a JSON proposal for that.
Does OpenLMIS store the data? Can previous days get updated?
For now, no.
Josh: Let's hold off on addressing this and we'll get back to it.
For the future conversation, MJ Thoughts: perhaps storage goes into our data warehousing strategy but would different from triggering the flag.
How frequently should there be updates?
For the future conversation.
Can OpenLMIS users not edit the functionality status if a device has RTM?
Yes, they will update the functionality status based on the information from RTM.
(added 10/25): Should OpenLMIS communicate information back to Nexleaf? (added 10/25): Snoozing functionality & needs
does OpenLMIS keep an 'audit log' of the history of functionality status changes over time? (whether it was set manually or set by the RTM service account?)
discuss how future roadmaps for OpenLMIS and Nexleaf dovetail but do not overlap here; EG, Nexleaf is working on an 'issue tracker' type capability; OpenLMIS roadmap has a 'needs attention' flag on CCE equipment
Architecture note: Languages should also be supported. ISO standard
OpenLMIS 3.0 upgrade in existin countries
Is there an OpenLMIS-using country planning to scale up to 3.0 and start using these features? - Conversation is definitely happening in Mozambique, but no clear plans yet. Can keep team updated on updates with other countries as well
What this achieves: Shared facility list, shared CCE inventory device list, OpenLMIS consumes alerts from ColdTrace, standardization of catalog devices (long term).
Notification API proposal
Notifications will take the following form and be expressed as JSON objects
After we implement the first two, we should look into OLMIS-3915 and how we want to support it
Martin inquired about learning more about Data Warehousing. MJ shared Reporting and Data Warehouse Strategy and asked if Martin could let her know what areas he is interested in digging more into. MJ can schedule a meeting with Peter at Ona.
Check in on scheduling for the week of Jan 22.
In person check in
VR has started on the FHIR representation tickets.
Nexleaf added more detail the API notification and status
Martin Lukac would you help me with a slide on ColdTrace and brief summary of the blog we did? Thanks!
Check in Meeting
Update from NexLeaf
tested the serializtion numbers, works good
Update from VR
View the historical alerts
Planning to wrap up
Getting issue details...STATUS
Getting issue details...STATUS
Check in Meeting
Mary Jo to give an update on what happened. Indicated that we'd like to do the demo again in the upcoming 3.3 webinar.
Automatic dismissing of alerts
Outstanding item which could be changed updated in the future. It might be problematic if OpenLMIS dismisses the alert (makes it inactive) when there is an end date in the message. Unclear what the best behavior is given that OpenLMIS isn't currently in used.
Need to alert to Terence when we restart and before the webinar
Josh, Mary Jo, Martin talked about PQS standards.
Out of Scope:
Synchronizing user accounts & permissions across platforms
Achieving a shared, standardized PQS catalog (this is a long term goal that is not covered by this)
What does a "change in functionality status" mean to us/our users? Does that include only changes to functionality statuses (working, not working) or does it also include alerts about no data available? It's easier to do red, yellow, green, rather than functional/non-functional
Decided that we use a "needs attention flag"
What kind of information does Nexleaf need back from OpenLMIS around the needs attention flag.
Decided that OpenLMIS will not send information back.
How will the Needs Attention Flag work on the OpenLMIS side?