Equipment Module
Target release | |
|---|---|
Epic | Equipment |
Document status | DRAFTED |
Priority | MED |
eLMIS Status | Implemented, not in use |
OpenLMIS Status | Not implemented |
PATH | @Amanda BenDor (Unlicensed) |
OpenLMIS | @Mary Jo Kochendorfer (Deactivated) |
JSI | @Alpha Nsaghurwe (Unlicensed) |
Goals/Scope
To manage inventory of equipment and maintenance of equipment and act as a communications interface between health facilities, private maintenance service contractors, and Ministry of Health equipment staff about equipment functional status and maintenance. This includes laboratory equipment and other equipment, such as fridges.
Status in eLMIS: In eLMIS, not in use
Status in OpenLMIS: Not in OpenLMIS. However pieces of this functionality will be build with the featureset of CCE catalog and inventory management.
Priority: High priority generally, but could be in a separate system rather than in OpenLMIS
Background
eLMIS has an equipment module which is not in OpenLMIS. It is developed in eLMIS, but not yet in use. The diagnostics unit of the Ministry of Health, as well as CHAI, have been involved in defining requirements for this module. There is a PowerPoint of screen shots available. While this module is not directly linked with the core commodity supply focus of eLMIS, the supply of and use of laboratory reagents is dependent on whether laboratory equipment is available and operational.
Roles in Tanzania:
A combination of Ministry of Health zonal equipment workshop officials and private sector service contractors are responsible for assisting health facilities and districts with equipment maintenance.
Ministry of Health officials perform regular assessments and check ups.
Service contractors may also perform regular servicing as well as repairs.
Equipment vendors typically employ the service contractors and provide the servicing as part of their warranties
Assumptions
User Stories
# | Title | User Story | Label | Importance | Notes |
|---|---|---|---|---|---|
1 | Configure equipment values | As an administrator I want to configure lists of values that can be associated to equipment including:
so that these are available for selection by other users when entering equipment. | Tanzania equipment | Must have |
|
2 | Set up of vendors, service contracts and donors | As an administrator I want to configure vendors and service contractors: companies with their contact details, geographic coverage and specialty. | Tanzania equipment | Must have | Geographic coverage and specialty are currently free text, but may be useful to model this in other ways. Companies can be a vendor or a service contractor or both. In the current version of the module there is no distinction between vendors and service contractors, but they should be separate entities, with some entities being both vendor and service contractors and others being one or the other. |
| Set up of service contract users | As an administrator I want to associate service contractors with users (staff of the service contractor) and give these users login access to the system so that they can respond to maintenance requests in the system. | Tanzania equipment | Must have |
|
3 | Enter service contracts | As an administrator I want to set up service contracts with geographic coverage and start and end dates so that service contracts can be entered in the system. | Tanzania equipment | Must have | Each contract has a service contractor. Geographic coverage is currently free text, this could be modeled differently. Each contract can cover the equipment of multiple vendors, can have multiple service types, be for multiple equipment sub-types and cover multiple health facilities. Currently the interface requires ticking each facility separately - this could be improved. |
3 | Configure donors | As an administrator I want to set up lists of donors so that users can run a report which show equipment status by donors | Tanzania equipment | Must have |
|
4 | Enter individual pieces of equipment | National-level staff want to enter equipment when it is procured or imported so that pieces of equipment can be tracked over time. | Tanzania equipment | Must have | Each piece of equipment has:
|
5 | Link equipment to a facility with install date | As a national/district/facility-level staff I want to link pieces of equipment to the health facilities where they are located and the year of installation at that facility so that the pieces of equipment can be tracked over time. | Tanzania equipment | Must have | Status updates should include dates. |
6 | Track status of equipment | As a national/district/facility-level staff I want to update the status of equipment - including operational status (eg fully operational), whether active or decommissioned, “replacement recommended” with a reason so that the pieces of equipment can be tracked over time. | Tanzania equipment | Must have | Status updates should include dates. |
7 | Log MOH assessments | As a national/district/facility-level staff I want to record assessments by Ministry of Health officials and dates of assessments so that the pieces of equipment can be tracked over time. | Tanzania equipment | Must have | Status updates should include dates. |
8 | Submit equipment maintenance request | As a facility user I want to request maintenance of a specific piece of equipment so that these can be managed and tracked in the system | Tanzania equipment | Must have | They can select the service contractor, give reason for requesting maintenance, and specify a recommended maintenance visit date. |
9 | Respond to maintenance request | As a service contractor I want to respond to maintenance requests assigned to me so that these can be managed and tracked in the system. | Tanzania equipment | Must have | They will record text about the service performed and recommend a “next service date”. |
Diagrams
See PDF and screen shots below.
Dependencies
Description | Link |
|---|---|
Open Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome | Status | |
|---|---|---|---|
| 1 | Add PowerPoint slides with screenshots referenced in the background in the Tanzania gap analysis document. | Added to diagrams section. | Closed |
| 2 | For Tanzania user stories: review the "so thats" added, review the label, and review the priority level. |
|
|
| 3 | Do we know why it isn't being used in eLMIS? Do we have any user feedback or key challenges faced? Would be useful to understand the why so we can take that into account. |
|
|
@Brandon Bowersox-Johnson met with Albertho Chengula at the GHSC-TA-TZ office in Dar es Salaam on August 16, 2018 regarding the Lab Equipment Module (LEM).
Background
The LEM module was developed in eLMIS in Tanzania around 2015, but has not yet been rolled out into production. It was held up by project close-out of the SCMS project, but there is still a need and a request for LEM features. There are ~350 labs in Tanzania, and labs have specific issues with stock-outs of lab commodities and re-agents. But when machines are not working, there is no need to resupply those reagents, so currently telephone calls are placed to every lab to check what machines are functional in order to plan deliveries. Donors also have special requests: CDC and Global Fund want monthly reports on which lab equipment is operational, for example.
Specific Features/Requests
The user stories in the page above capture some, but not all, of what Albertho raised. He raised some other items that I do not see in the user stories, and also has some totally new feature requests.
Admin Rights vs User Rights: This appears to be an existing bug in the system. The user rights do not allow easy creation of a user account with the normal end-user rights. Albertho has only been able to try out the LEM features using an admin account. Troubleshooting is needed.
Log Downtime: I am not clear if this is what is meant by "Assessments" in user story #7 on the page above. A desired feature is to log the date ranges when any equipment is down/non-functional. Albertho suggests that a date range is enough (do not need the specific time of the day). This would allow users to run reports about how much equipment downtime they have faced. And it would give national visibility into what equipment is working and not functioning. Apparently labs do have to track this information already for ISO certification, and that is probably logged on paper right now.
Non-Functioning Equipment Blocks Ordering Re-agents: I do not see this feature documented above, but @Alfred Mchau (Deactivated) reports that this feature has been working in the LEM module previously. When a piece of lab equipment is non-functioning, that information stops the user from ordering its re-agents in the lab R&R form. One type of machine may have 15+ reagents, so there must be a system to associate those. Note: The Lab program in eLMIS-TZ also has special tabs different than the other R&R forms for other programs (it is not called "Full Supply").
Maintenance Records: This feature request goes a bit beyond user story #9 above. Albertho says that when maintenance occurs, they want to be able to attach a scanned PDF in addition to written notes. This is important so it's easy to capture what was repaired about the machine and archive it digitally.
Planned Preventative Maintenance: I do not see this feature fully documented above, but @Alfred Mchau (Deactivated) reports that this feature has been working in the LEM module previously. The system would allow each piece of equipment to have a planned maintenance date cycle, EG every 6 months starting at the installation/operation date. This would generate alerts/notifications when it is time for any planned preventative maintenance.
Reporting: Albertho suggests users will want an overall report of what equipment is deployed in the country and what is operational/non-functional. In the Background above, we mention some of the stakeholders that want this visibility. User story #6 above includes the tracking, but not really the visibility/reporting.
Pre-populate Re-agent Orders: This is a new feature request not captured above. Some lab equipment digitally tracks how many tests were run, and some big labs have Laboratory Information Systems that track this. Through integration with these systems, perhaps we could auto-populate the R&R form based on how many re-agents were likely consumed based on the number of tests run during the period. Systems like this are only used at big hospitals currently, so it is not clear if the benefit outweighs the cost.
Approaches
Because of funding limitations, I suggest a number of creative approaches to address these needs:
Lean/MVP: Roll out the current LEM in eLMIS as-is, with only minor bug fixes. This is a Lean approach–roll out the current feature, see how much it is used, see the value of the data, and over time then it will be easier to advocate for more features if they prove to be needed or if people see the value or the marginal benefit.
Bring LEM into OpenLMIS v3: Consider moving the feature as-is into Version 3, without re-designing or rewriting it. Use the existing code and do the minimum necessary to wire it into v3. It can be made as an optional add-on module/microservice. It doesn't have to be perfect or be as configurable if it's not part of the core product.
Run OpenLMIS v2 in parallel with v3: Alternatively, keep OpenLMIS v2 running in order to power all of these Equipment features. There are few inter-connections between the LEM and other parts of OpenLMIS. So in the "incremental" upgrade scenario where you run v2 and v3 in parallel, it's possible that Requisitions could be powered by v3 even if Equipment is still powered by v2.
Consider Existing Lab or Equipment Platforms: Rather than code all these features into OpenLMIS, maybe they are best addressed or partially addressed by some existing lab software (BLIS, eLAB, Giva, LabNet, OpenLS)? When you look at the feature list, perhaps asset management systems could help track what equipment is where and what is functional and the Planned Preventative Maintenance schedules; perhaps that same tool or a separate ticketing or case management can help track service requests and repair history. Then there is a bit of custom integration to connect to the R&R forms for ordering re-agents.
Note: Approach 4 is potentially the very complex and costly solution. I think option 1 and 2 could be just as effective with far less effort.
Resources