Medication constitutes a significant part of the treatment for mental health issues. However, this medication can be detrimental to the health of clients. To monitor the health of clients, Dutch care standards mandate compulsory examinations, referred to as medication protocols.
In 2023, GGzE experienced a serious incident related to medication protocols. Following this incident, GGzE assembled a project group to systematically analyse the underlying problem and develop a solution. The project group utilised the Double Diamond model (Fig. 1: Double Diamond Framework (Nessler, 2018), n.d.). As a clinical informatics trainee, I served as both project leader and designer.
The project commenced with an investigation into GGzE鈥檚 problem statement (Appendix 2). This investigation revealed that 72% of GGzE鈥檚 clients treated with medication are not monitored according to medication protocols. This is primarily due to process errors during handover moments and a lack of process controls. Consequently, necessary interventions for abnormal values are not always (timely) implemented, which can lead to health damage for clients. Between 2021 and 2023, GGzE reported 19 potentially avoidable medication safety incidents related to client monitoring.
The investigation also indicated that GGzE鈥檚 problem statement is not unique (Appendix 3). Various types of care institutions (mental health care, hospitals, and nursing homes) in different countries (the Netherlands, Belgium, Denmark, Australia, and the United States) experience similar, potentially avoidable incidents in the medication process.
The problem statement that emerged from the investigation was translated into the project goal: 鈥淓nhancing medication safety by improving client monitoring for specialist mental health medication.鈥� and the project outcome: 鈥淓nabling GGzE鈥檚 medication responsible parties to timely assess lab determinations and functional examinations related to medication protocols.鈥� The project outcome was translated into specifications (Appendix 4) and a measurement plan (Appendix 5). To support the investment decision for the project outcome, a business case was developed (Chapter 2.3).
Following the specification of GGzE鈥檚 problem statement, project goal, project outcome, and business case, potential solutions were sought. In this search, five solutions were identified. One emerged from a benchmark with three comparable mental health institutions to GGzE. Four were derived from literature research (Appendix 3). These solutions were weighed against each other using a weighting framework based on the objectives of the Quadruple Aim model (Bodenheimer & Sinsky, 2014): health, employee, quality, and cost (Appendix 7).
The weighting resulted in GGzE鈥檚 choice for the solution 鈥楻obin鈥�. 鈥楻obin鈥� automates the ordering and monitoring of lab and functional examinations related to medication protocols. It was conceived by combining several solutions from the literature: computerised order entry (Nuckols et al., 2014) combined with clinical decision support (Alotaibi & Federico, 2017), on-screen alerts (Shojania et al., 2009) combined with clinical decision support (Van Wyk et al., 2008), and robotic process automation (Syed et al., 2020). Robotic process automation (RPA) is an automation technology for business processes that uses virtual software robots to perform manual or time-consuming tasks (What Is Robotic Process Automation (RPA)? | SAP, n.d.). 鈥楻obin鈥� operates as follows:
- A prescriber enters medication into the electronic prescribing system (EPS).
- Based on the medication registration in the EPS, 鈥楻obin鈥� suggests to the prescriber to order and monitor the related medication protocol.
- The prescriber accepts or declines the suggestion. 鈥楻obin鈥� logs this decision.
- If the prescriber accepts the suggestion, 鈥楻obin鈥� orders and monitors the medication protocol in the laboratory information system (LIS).
- If the results of lab or functional examinations related to medication protocols are not received on time, 鈥楻obin鈥� alerts the prescriber.
鈥楻obin鈥� was then developed into a system design. The system design encompasses all layers of the Layer Model (Interoperability - Nictiz, 2022). Based on the system design, a proof of concept (POC) was built. The system was verified using the POC.
鈥楻obin鈥� has demonstrated the potential to solve GGzE鈥檚 problem and save costs, as evidenced by GGzE鈥檚 verification (Chapter 5) and GGzE鈥檚 business case (Chapter 2.3). The robotic solution addresses the causes of GGzE鈥檚 problem statement with an expected return-on-investment (ROI) of 11.9%.
To validate whether 鈥楻obin鈥� achieves the project goal, a user period is necessary. Before 鈥楻obin鈥� can be put into use, software suppliers of the EPS and LIS need to deliver several technical requirements aimed at data access.
Once these technical requirements are delivered, GGzE will implement 鈥楻obin鈥� in stages:
- First, a pilot with a select group of end users.
- Then, an evaluation of the pilot in which 鈥楻obin鈥� is validated.
- Upon successful validation, GGzE will proceed with broad scaling.
- One year after broad scaling, a final validation will formally reflect on GGzE鈥檚 project goal.
After 鈥楻obin鈥� has automated the mental health-related medication protocols, GGzE will also deploy it for somatic medication protocols within GGzE: COPD, CVRM, and diabetes.