Participants
Initial Notes
Tickets for reference:
Jira Legacy server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key SELV3-13 Jira Legacy server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key SELV3-14
...
Josh has mentioned FHIR service as a possible solution for retrieving the data. Malawi is submitting measure reports based on requisitions to FHIR service using nifi. We could do a similar thing - using nifi to publish measures based on stock data and then probably fetch needed info on the requisition screen.
Additional Notes
New Properties
So as to bolster cross-system interoperability, we need to follow GDD naming conventions when adding new properties to our domain model. That’s the minimum we need to do in order to add min/max temperature values to Orderables and/or TradeItems.
In GDD, the datatype of minimumToleranceTemperature contains a numeric primitive as well as a unit of measure (UoM) which is like an emum (“CodeList”) of allowable values (eg: Fahrenheit, Celsius, etc).
We should be explicit about which UoM we’re using. This may be through convention and documentation of our API. It may be through properties within the responses served by our API.
A robust implementation would allow clients to specify both a value and a UoM. Internally, OpenLMIS would then convert between various units of measure (eg: Celsius to Fahrenheit) whenever necessary.
Alternatively, though, we could require values to be specified in eg: Fahrenheit and return an error if they aren’t. This would suffice for now.
We should use minimumToleranceTemperature rather than minimumTemperature.
An Orderable can be either a:
TradeItem Type Orderable - An Orderable backed by a TradeItem (ie: with a specific manufacturer)
Commodity Type Orderable - An Orderable which isn’t backed by a TradeItem
Our new properties (like minimumToleranceTemperature) should technically be associated within TradeItem Type Orderables. In that case, we have a specific manufacturer of a tangible item specifying that their product has a minTemp of X.
Nevertheless, it would be alright to instead associate our new properties with Commodity Type Orderables. In that case, something like minTemp would be a reference value. A “reference value” is essentially an “approximate value.” For instance, when buying multiple instances of product X from various vendors, each vendor may have a different price. It’s still useful to be able to say that product X generally costs a certain amount, though, and this single value is its reference price. The reference price is informative rather than definitive. So to, TradeItem Type Orderableshave specific minimumToleranceTemperature values, whereas Commodity Type Orderables have reference minimumToleranceTemperature values.
The minimumToleranceTemperature property should have that name regardless of whether we add it to a TradeItem Type Orderable or a Commodity Type Orderable, and regardless of whether or not it’s thus a reference-value. Users simply have to understand from context (rather than based on the property name) whether or not it’s a reference value.
As mentioned, our new properties (like minimumToleranceTemperature) should technically be associated within TradeItem Type Orderables. It’s common, though, for TradeItem properties to instead be defined within Orderable. It would be fine to define our properties within Orderable.
PCMT
PCMT v1 will be done on or prior to January 20th.
The 3.9 version of OpenLMIS, slated for release sometime in March, will then include integration with it. The longterm vision for OpenLMIS is that it rely on rather than merely support PCMT for product management. Therefore, for SELV, we shouldn’t necessarily invest time in updating existing product screens to support new properties that we add. Instead, it may be better to invest the time into PCMT (wherein users would have access to the new properties).
We can play with any of these PCMT servers:
http://demo.akeneo.com
http://test.pcmt.villagereach.org - Work in progress so Jenky
http://showcase.pcmt.villagereach.org
Username and password for each server: admin/admin
We can do whatever we'd like to these servers - they automatically reset themselves on a set schedule.
Also check out https://gitlab.com/pcmt/pcmt/-/wikis/home.
Services
The stock-management service should contain the endpoint which returns the total volume of all inventory and/or all inventory which requires CCE.
The CCE service should probably be where we’d have an endpoint which returns the total available CCE volume at any given facility.
Because we won’t be sending any of our new properties/values to ColdTrace, we shouldn’t have to update our FHIR endpoints.
The Core team plans on quarterly OpenLMIS releases. We can coordinate the release of individual services with them, however, at any time.
Identifying Products Reliant on CCE
We probably shouldn’t presume that existence of a non-null maxToleranceTemperature means that an Orderable needs cold-chain.
Action Items
- Josh Zamor will verify 1) whether we should use inBoxCubeDimension to specify the volume of Orderables/TradeItems, and 2) how we should distinguish between products which need CCE and those which don’t.