On the 24th of January we had a workshop kindly provided by Compositional IT to come up with a development plan for the Dutch National “Noodlijst”. In this session we have created a roadmap existing out of three phases. Within these three phases we have established clear tasks that have to be completed in a certain order. These tasks are grouped and determine a goal for each phase. Each phase has its own deadline and the agreed length of the project sums up to roughly two years.
Introduction
The central point of this session was the Noodlijst App, which is Dutch for Emergency list app. It calculates interventions in an emergency situation. The calculations depend on age, weight and height [1]. Any healthcare worker should be able to use this app. Currently the app is made specifically for the Wilhelmina Kinderziekenhuis (WKZ) Utrecht. The goal is to expand the usage of this app nation (world?) wide. For this to realize, funding is needed. A letter of intent has been set up and signed by a number of stakeholders to show the relevance and need for this app.
However, the current local app must be updated in various ways. The most important is the calculation engine, which is called GenSolver. Currently, work is in progress, in cooperation with the applied mathematics division of the University of Utrecht, to make this engine correct and as fast as possible. This is, in short, a general overview of the current situation.
What exactly needs updating besides the calculation engine?
The current prototype has to be upgraded to the latest versions of the following underlying technologies (in priority ordering):
Whiteboard session (lead by Compositional IT)
This main goal of this session is to have a long-term plan laid out. The following points should be addressed:
- Where are we going with this project?
- What needs to be done?
- What are the current priorities?
- How much work is needed for certain tasks?
From beginning to end: what does the current app do?
First we need to know what the prototype does. Most important, it allows to enter patient details (age, weight, height and perhaps gender). With this data a series of calculations can be started.
From age we can estimate the average weight and height. After that, the user can adjust the weight and height to match these properties to a specific patient. So the client side calls to calculate certain interventions[2] that depend on some conditions. We can classify the interventions into groups. The interventions are based on what you want to treat. However, a list of interventions can be grouped together by a classification scheme and the user can pick a set of these interventions. After the user has picked such a set, the user can click on specific interventions and it will show the details.
Remarks:
- The user can open up the app with a link in which the patient details are already filled in.
- The list of interventions is hard-coded. The calculations are also hard-coded and instead we want those calculations to be done by GenSolver on the fly.
The phases
We have divided the project into three phases. The most important phase is the first one. The most work will be done here. Phase two is more concentrated on MDR-certification and phase 3 is more focused on the final points.
Phase 1 (After this phase the app should be ready and correct!):
- GenSolver has to be finished. Currently it supports most of the calculations, but there are certain outliers. There should be no room for errors. To go live, this is a must. Situation: Currently working on this.
- GenSolver should be integrated with Elmish app. For the connection with the emergency list app the following will be applied: it should be integrated together with the emergency list app, but also kept separate. Situation: Not started.
- The interaction between GenSolver and the emergency list app should be as follows. GenSolver delivers a service to the emergency list app. From the emergency list app the user can query GenSolver and receive the calculated interventions.
- Configurability: The calculated items are put in a google spreadsheet. These calculated items differ per hospital. So this spreadsheet will probably look different for each hospital[3]. It should also be possible to be able to change these calculated items on the fly per patient.
- Authentication: not needed in the first phase.
- Storing interventions as a database should be done. The google spreadsheet solution is not definitive. It is merely to show how it would work. For final application, a database solution is needed.
- Versioning should be done as quickly as possible.
- We need to take certain “MDR-certification points” (usability, security and safety) into account during the design already. Otherwise this has to be done afterwards which can cause problems and a lot of extra work.
- Automated testing. Testing the engine itself and the app. Verification and validation. We can see validation as acceptance testing and verification as technical testing.
- Material IU can be chosen as user interface technology. However, other possibilities can also be considered. The advantage of MaterialUI is that it is based on a very extensive and proven UI library.
Phase 2 (Configurability kicks in! After this phase it could be used in other hospitals):
- Certified MDR audit trail features.
- Authentication is needed. Perhaps in the following way, an application that opens up with a certain key which immediately opens up the app to use. Once you want to configure or change other settings you need to log in. It is important that a health worker can access the app fast and does not need to fill in other administrative stuff (which hospital, other specifications etc.). The priority is to have fast calculated orderables with minimal things to click and type. Stress-friendly.
- Configurability: Google sheet integration also, but can change down the road.
Phase 3 (Internationalisation! After this phase the app is MDR-certified):
- Usability.
- Accessibility.
- Store patient specific data.
The MDR-certification is important and difficult to put in a phase. There are some remarks regarding this.
MDR-certification:
- Can there be any changes to the app after being MDR-certified? It depends. A significant change that can affect safety could lead to a new certification process. Technical changes are possible to do. For example, the release of a new version. We first have to implement everything that would require a new certification process. Implementing to make it configurable; that would really influence the MDR certification. So this should be done before starting the certification process.
- Certification may need year or year and a half. It is possible to create and use the app in Casper’s hospital without having the certification, but this is not entirely clear yet. However, for other hospitals it is needed. Note that we can do a lot without certification and label it as research purposes.
Planning and whiteboard
| Delivery dates | |
| Phase 1 | Dec 2022 |
| Phase 2 | Q2-Q3 2023 |
| Phase 3 | Dec 2023 |
[1] It was noted that perhaps gender must be included.
[2] An intervention is “something” that you apply to the patient. It can be medication, but also applying defibrillation to the patient. In essence, it is an act that needs to be calculated. We will also refer to this as an orderable.
[3] The app will be hospital specific. Each hospital has its own spreadsheet and specifications. However, the app does not change technically.
