EXPANDING THE NEXUS
SYSTEM TO FACILITATE THE
PRESCRIPTION OF
CYTOSTATICS AND THE
PLANNING OF
CHEMOTHERAPY
A Scientific Research Project
TOUFIK AGAROUD
Expanding the NEXUS system to facilitate the prescription of
cytostatics and the planning of chemotherapy – A Scientific
Research Project
Student Toufik Agaroud Meibergdreef 3 1055 PE Amsterdam Collegekaart nummer: 10820892 Email: t.agaroud@amc.uva.nl MentorEmmy ter Stege Product Owner
Email: emmy.ter.stege@nexus-nederland.nl
Medication team
Development & solution department, NEXUS Nederland B.V.
Tutor
Willem-Jan P. ter Burg Faculty of Medicine
Department of Medical Informatics, AMC‐UvA Email:w.j.terburg@amc.uva.nl
Location of Scientific Research Project
Medication team
Development & solution department, NEXUS Nederland B.V. Weverstede 35
3431 JS Nieuwegein The Netherlands
Practice teaching period
Table of Contents
Brief definition list ... 1
Abstract – English & Dutch ... 2
Introduction ... 3
Research scope & goals ... 4
Methods ... 4
Qualitative research ... 4
Current state description (step 1 – 4) ... 6
Requirements gathering (step 5) ... 6
The gap analysis (step 6) ... 7
Future state description (step 7 & 8) ... 7
Results... 8
The medication process ... 8
The functional description of the NEXUS software applications ... 10
The NEXUS architecture ... 12
The gap identification ... 16
The future state ... 20
Discussion ... 24
Conclusion ... 26
References ... 27
Appendix A – Extensive definition list ... 29
Appendix B – NICTIZ medication process V9.0.7... 31
Appendix C – Sequence diagram of the planning process ... 32
Brief definition list
This section briefly explains the basic terminology needed to understand this thesis. For a more extensive list of terminology we will refer to Appendix A throughout this document by highlighting important terms in blue, either in text or in figures and tables.
The NEXUS system: the complex whole of applications developed at NEXUS that are working
together as part of an overall mechanism.
NEXUS EPS: the Electronic Prescription System (EPS) developed by NEXUS, sometimes denoted as
MediChart
NEXUS EHR: the Electronic Health Record (EHR) developed by NEXUS Cytostatics: medication used for the destruction of cancer cells
Cytostatics (prescription) module: a component of an EPS which enables the prescription of
cytostatics
NEXUS medication – and planning software: a collective term to refer to the medication module
Abstract – English & Dutch
English
Introduction: NEXUS is currently developing a medication module from which an Electronic
Prescription System (EPS) is a part of. One of the requirements that NEXUS customers have been requesting is the integration of a cytostatics module in the EPS and the ability to plan chemotherapy. This research will therefore focus on the requirements of a cytostatics prescription module and a chemotherapy planning tool, so that prescription of cytostatics and planning of chemotherapy will soon be possible within the NEXUS system.
Methods: The overall method included a qualitative study design in which the current state of the
NEXUS medication – and planning software has been qualitatively described and compared to the desired state featuring the ability of chemotherapy prescription and planning. The gaps that resulted from this comparison using a gap-analysis ultimately led to a final recommendation for NEXUS.
Results: In total we were able to identify 17 gaps in the medication- and planning software of
NEXUS: 12 gaps in the medication software with regarding chemo prescription and 5 gaps regarding chemo planning. Ultimately, after merging similar functionalities, this has led to 16 new software functionalities that must be implemented by introducing or expanding software services and fact sheets.
Conclusion: To expand the overall NEXUS system with a cytostatics prescription module and a
planning tool for chemotherapy, a number of software services must be expanded or introduced. For the most part this expansion takes place at the German side of NEXUS and therefore a good coordination is needed between the Dutch and German branch of the organization.
Dutch
Introductie: NEXUS is momenteel bezig met het ontwikkelen van een medicatie module met onder
andere een Elektronisch Voorschrijf Systeem (EVS). Een aanvullende wens van zowel NEXUS als de gebruikers is de integratie van een cytostatica-module in het EVS en de mogelijkheid om
chemotherapie te plannen. Dit onderzoek zal zich daarom richten op de vereisten van een cytostatica voorschrijfmodule en een planningstool voor chemotherapie, zodat het voorschrijven van cytostatica en het plannen van chemotherapie straks mogelijk wordt binnen het algehele NEXUS-systeem.
Methodes: De algehele methode omvatte een kwalitatieve onderzoeksopzet waarbij de huidige
staat van de NEXUS medicatie-en planningssoftware kwalitatief is beschreven en vervolgens is vergeleken met de toekomstige staat waarin het voorschrijven van kuren en het plannen van chemotherapie mogelijk is. De gaps die hieruit resulteerden door middel van een gap-analyse hebben uiteindelijk geleid tot een eindadvies voor NEXUS.
Resultaten: In totaal hebben we 17 gaps kunnen vinden in de medicatie – en planning software van
NEXUS: 12 gaps in de medicatie software met betrekking tot chemo voorschrijving en 5 gaps met betrekking tot chemo planning. Uiteindelijk heeft dat na samenvoeging van soortgelijke
functionaliteiten geleid tot 16 nieuwe software functionaliteiten die moeten worden geïmplementeerd door het introduceren of uitbreiden van softwareservices en factsheets.
Conclusie: Om het algehele NEXUS-systeem uit te breiden met een cytostatica voorschrijf module en
een planningstool voor chemotherapie, moeten er een aantal softwareservices uitgebreid of
geïntroduceerd worden. Deze uitbreiding vindt voor het grootste gedeelte plaats aan de Duitse kant van NEXUS en hiervoor moet dus een goede afstemming plaatsvinden vanuit de Nederlandse tak van de organisatie.
Introduction
Electronic Prescription System’s (EPS’s), or more commonly referred to as computerized provider order entry (CPOE) systems, are the computerized alternatives of paper-based medical prescription. With the emerge of EPS’s physicians, physician assistants, pharmacists and nurse practitioners are able to cooperate within one general electronic system sharing the goal of adequate delivering of medication to the patient [1,2].
The biggest benefit of EPS’s as well as the main reason for its emergence is the reduction of risks associated with traditional medical prescription such as more accurate, understandable and correct prescriptions leading to less erroneous medications given to patients. The decrease in medication errors will logically lead to less medical harm by erroneous medications. Multiple studies have underlined these benefits of EPS’s [3 - 5].
NEXUS is a software company with a location in the Netherlands (NEXUS-Netherlands) and in
Germany (NEXUS-Germany). Currently NEXUS-Germany is developing an EPS called MediChart which has been implemented by NEXUS-Netherlands into their own Electronic Health Record (EHR). This EPS has been slightly modified by NEXUS-Germany to the Dutch care standards so that it can be used in the Dutch healthcare. MediChart is currently still in development within a project carried out by the German and Dutch branch of NEXUS. Among one of the things that the Dutch customers desire in the NEXUS EPS is the ability to prescribe cytostatics. In addition to this requirement the customers would also like to be able to digitally plan chemotherapy.
Presently NEXUS customers are using stand-alone applications such as Cato and Kurad to prescribe cytostatics and plan chemotherapy. However the use of external applications often leads to double registration of data which is not desirable. Therefore the NEXUS customers plead for an alternative solution where all functionalities including data registration are integrated into one system. This ideal solution includes the integration of a cytostatics module inside the NEXUS EPS and a planning tool to plan chemotherapy. Unfortunately it is not clear how this new system, incorporating
prescription and planning aspects of chemotherapy, should be developed which is what this research will focus on.
This project will focus on answering the following main question: how can we expand the current
NEXUS system in order to facilitate the prescription of cytostatics and the planning of chemotherapy?
In order to answer this question a gap-analysis will be conducted to identify gaps in the current
NEXUS medication – and planning software. These gaps will provide insights to what is needed to implement both a cytostatics prescription module and a planning tool for chemotherapy. The analysis can be broken down into the following sub-questions:
1. How does the workflow look like with regard to the prescription of medication and the planning of treatment in general and specifically for chemotherapy?
2. What are the requirements of an EPS to support the workflow of medication prescription for chemotherapy?
3. What are the requirements of a planning tool to support the workflow of treatment planning for chemotherapy?
4. How are the current NEXUS EPS and the NEXUS planning tool integrated into the NEXUS EHR?
Keywords: medication software, oncology, anti-cancer drugs, treatment planning, software gaps
Research scope & goals
This research will focus on two phases of chemotherapy in particular: the prescription of cytostatics and the planning of chemotherapy treatment. Other phases of chemotherapy such as the
declaration and preparation process of cytostatics will be discarded as we see prescription and planning as the most prominent phases of chemotherapy.
As explained earlier NEXUS is divided into a branch in Germany and a branch in the Netherlands. Our research will concern both branches but will mainly focus on the Dutch branch as the research will be carried out there. This research paper will therefore be aimed at the Dutch NEXUS in the first place but could also concern the NEXUS customers and the German branch of NEXUS. Additionally, we will refer to the two NEXUS branches in this thesis as NEXUS-Netherlands and NEXUS-Germany. If the term ‘NEXUS’ is used without any suffixes then it always refers to the Dutch NEXUS unless explicitly stated differently.
The main objective of this research is to study the needs to expand the overall NEXUS system in order to facilitate the prescription of chemo cures and the planning of chemotherapy treatment. The desired system components missing are a cytostatics prescription module and a chemotherapy planning tool. In order to achieve the main objective some sub-objectives can be formulated:
To understand the process of prescription and planning within chemotherapy To gather requirements needed to enable chemotherapy prescription and planning To evaluate and understand the current NEXUS medication – and planning software To identify gaps in the current NEXUS medication – and planning software
The final result of this research will consist of an advice to NEXUS-Netherlands including the answer on our main research question and recommendations regarding the implementation of the missing chemotherapy functionalities. Within this advice we will also state the role that the two NEXUS branches will have to play in order to successfully expand the overall NEXUS system.
Methods
Qualitative research
The overall approach of this research was a qualitative study design in which an exploratory research is conducted to study the current state of the NEXUS medication - and planning software in relation to the desired state for chemotherapy. This research was divided into three phases: the current state description, the gap analysis and the future state description. We will thoroughly describe each
of these phases below containing the steps that have been taken. For each of the steps we will describe the data that was used, the result that it has generated and the method used to present the results (if necessary).
In addition we want to present a general overview of the overall methodology for this research. This overview can be found in Figure 1 below in the form of a flowchart. This flowchart presents the overall methodology in 8 steps. These steps will be explained on the next page in more detail in relation to the three research phases mentioned earlier.
Current state description (step 1 – 4)
Step 1: the first step taken in this research was inspecting the treatment planning and medication
prescription process in general and for chemotherapy. To reason for this step was to assess to what extent the two processes differ from each other. For the general processes we used a reference model: the NICTIZ medication process V9.0.7. This reference model describes a standardized medication process in which a clear distinction is made between therapy and logistics [7]. We used the NICTIZ reference model to create a UML activity diagram using a business process meta-model. The purpose of the activity diagram was to present the business processes of prescription and planning in general. As for the prescription and planning process for chemotherapy we conducted interviews with the staff of the oncology department at the Academic Medical Center (AMC) and the St. Anna hospital to gain insights. The information of the interviews was then mapped to the NICTIZ reference model leading to a second activity diagram specifically for chemotherapy.
Step 2: next we studied the current NEXUS medication – and planning software by conducting
interviews with NEXUS experts, attending workshops and studying software documentation. The aim of this step was to gain a good overview of the current capabilities of the medication – and planning software. During this research step we looked into the functional aspect of the NEXUS software. Moreover, we studied the most important and relevant functionalities of the software with a special focus on application components for medication prescription and treatment planning. These functionalities were modelled into a functional model in the form of a list. The method used to model the list was a functional meta-model.
Step 3: the next step was converting the modelled list of functionalities from step 2 into a graphical
representation by again using a functional meta-model.To graphically model these functionalities we used 3LGM² V3.3.0, a three-layer modelling tool that provides a functional (first layer) and two technical models (second and third layer)[8]. Before we modelled anything, we first identified all the
enterprise functions, sub-functions and entities that exist within the list of functionalities from step 2. In the first place we looked at each functionality as a single enterprise function. Then we checked whether some functionalities could be grouped into a super function and finally we checked what entities the functions use or generate. Eventually the modelling process resulted into a graphical functional model representing the current state at NEXUS. This resulting model is called: the
functional model of the current state.
Step 4: during this step we looked at the technical aspect of the NEXUS medication – and planning
software. When studying the software, the architecture was inspected on application level to see how the different application components (studied in step 2) are interacting with each other and how the medication- and planning software is integrated into the overall NEXUS architecture. First this overall architecture was modelled into a conceptual model to gain a general understanding on product level. Then a technical representation was modelled in 3LGM using a technical meta-model.
This technical model only contained the NEXUS medication software as this software is overall more complex and consists of more application components then the planning software. However to still provide an understanding of how the different application components and/or sub-applications for planning are interacting with each other, we created a UML sequence diagram demonstrating the process flow for planning in relation to the components.
Requirements gathering (step 5)
Step 5: once the current state was completely studied and modelled the next step was gathering
requirements for the desired cytostatics prescription module and chemotherapy planning tool. To gather the requirements we mainly used documentation of the St. Anna hospital containing
requirements for each phase of the chemotherapy process (prescription, planning etc.). We conducted an analysis on this document by extracting the prescription and planning requirements. This extraction process has resulted into a list of requirements. In addition to the St. Anna document we used the information of our interviews at the AMC and St. Anna hospital with respect to their chemotherapy modules (Baecon in AMC and Kurad in St. Anna) to expand the list of requirements. This final list of requirements was then divided into two sub-lists: one for the prescription and one for the planning of cytostatics.
The gap analysis (step 6)
Step 6: the next step taken consisted of mapping the prescription and planning requirements to the
studied functionalities of the current NEXUS medication – and planning software. Otherwise speaking we compared the current state of the medication – and planning software in functional aspect to the expected state as described in the requirements. This comparison resulted into a list of two classifications of requirements: requirements that are functionally supported by the NEXUS software and requirements that are not supported. The latter classification can be seen as the gaps. We defined ‘gap’ in this research as a requirement that is technically not supported by the
medication and planning software in any way. Once the gaps were identified we verified them with NEXUS product experts. The aim of this verification process was to strengthen our results in reliability by including the interpretation of domain experts at NEXUS as well. Besides the gaps, we also verified the requirements that are supported by the medication – and planning software. The final result of this step was a functional model in the form of a list containing all the gap
functionalities (i.e. functionalities that are not supported in the current state) found in the gap analysis.
Future state description (step 7 & 8)
Step 7: after the current state was fully modelled and the gaps were found we focused on the
description of the future state, which is the state where chemotherapy can be prescribed and planned by NEXUS customers. One of the steps taken here was the expansion of the functional model of the current state (see step 3) containing all functionalities observed at NEXUS. We
expanded the model of the current state with the gap functionalities resulting from the gap-analysis. Likewise in step 3 we first identified all the sub – and super functions and all the entities that the functions use and generate before we actually modelled anything in 3LGM. The resulting functional model was then named: the functional model of the future state.
Step 8: in this last step the technical model of the future state was modelled. In order to model this
new technical model, we used two things: the technical model of the current state (the architecture) and the functional model of the future state (see step 7). We then mapped the functional model of the future state to the technical model of the current state to identify to what extent the current application components of prescription and planning support the future functionalities. If a
functionality is not supported by an application component then a new application component was introduced leading to an expansion of the current technical model using 3LGM. In any other cases no changes were made to the current technical model.
Results
The medication process
This paragraph presents the medication prescription and treatment planning process observed at two levels: in general and specific for chemotherapy. For the purpose of simplification we will refer in this paragraph to the two processes as the medication process in general and for chemotherapy. We present these two medication processes in the form of a UML activity diagram. First we will discuss the general medication process, then the medication process for chemotherapy.
Note: during interviews with both the AMC and the St. Anna hospital we came to the conclusion that
the medication process for chemotherapy at the St. Anna hospital is clearly less mature then the one of the AMC. Especially with respect to the chemo treatment planning process which consists of more business processes than the AMC hospital. The reason for this difference is the fact that the business processes at the AMC are completely supported by digital software whereas in the St. Anna hospital a major part of the business processes are subjected to paperwork. As our goal is to describe a future state where planning and prescription of chemo is completely digitalized, we decided to use the AMC as the golden standard for this thesis only with respect to the description of the medication process for chemotherapy.
The general medication process
Figure 5 below shows the general medication process as described by the NICTIZ reference model.
As noticeable this is not the entire NICTIZ model, but because NICTIZ does not limit their model to only prescription and planning, we decided to only present the first three lanes. For the rest of the model please see Appendix B. The general medication process starts at the first lane where the patient arrives at the care provider after being diagnosed with a condition. In the doctor’s clinic the medication usage of the patient is being verified. Then the prescription process starts in the second lane beginning with an evaluation of the desired (drug-based) treatment by the prescriber (the treating physician). Note that the prescriber and care provider have been modelled as two separate actors in Figure 5’ model, but in reality this does not have to be the case; the care provider can be the prescriber as well. Furthermore the evaluation by the prescriber leads to a couple of actions: the creation, continuation, interruption, cancellation or alteration of a medication treatment or
medication appointment. The prescription phase ends with the decision whether immediate stock for the medication is needed or not. If a stock is needed then the prescriber requests a medication provision to the pharmacist. The prescription phase end by making all the previous generated information building blocks (medication appointments, medication provision requests, medication usage information etc.) public for the fellow practitioners and patients (see the last lane). These information building blocks can then be received, consulted, send or provided.
We can notice that Figure 5 does not contain a clear planning process for the medication usage nor is planning mentioned in the complete model in Appendix B. Although NICTIZ does speak of
medication – and administration ‘appointments’, the term ‘appointment’ does not refer to planning but to agreements made over medication prescription and administration. Some examples of prescription and administration agreements are the drug to be used, the suitable dosing, the length of the treatment etc. The reason why NICTIZ discarded planning is because the reference model is originally designed to serve as a communication tool between health institutions enabling exchange of medication information. NICTIZ does not see planning related information as a building block that can be exchanged between hospitals and therefore planning is discarded from their model.
Additionally NICTIZ claims that it is difficult to model planning due to an historic gap between the first and second line care with regard to planning. Planning in second line hospitals have been and is still often subjected to paperwork whereas in the first line care this is less the case.
The medication process for chemotherapy
The medication process for chemotherapy is presented in Figure 6 on the next page and is the result of mapping the information gathered at the oncology department of the AMC to the NICTIZ
reference model. Generally up to the prescription lane the medication process for cytostatics looks visually the same as the general medication process but in essence this is not the case. The model that is been shown in Figure 6 is heavily subjected to a big complex protocol where all the
agreements have been registered regarding prescription, planning and administration. This means that the medication- and administration appointments as we know them from the general
medication process result from this chemotherapy protocol.
A medication appointment for instance is a drug-based treatment strategy that the oncologist selected from the chemotherapy protocol. At the AMC the oncologists however do not speak of a ‘medication appointment’ but rather a ‘treatment plan’. In essence these terms are the same, but the use of the word ‘treatment plan’ could be confusing as it can be interpreted in several ways. Generally speaking a treatment plan consists of all the care steps that have to be taken in order to adequately treat a patient. This plan is not limited to medication, but also includes consultation hours with the physician, lab tests etc. The chemotherapy protocol as described earlier can be seen as an overall treatment plan. The treatment plan as seen in Figure 6 on the other hand is a drug-based treatment plan, an instance of the overall treatment plan.
Regarding planning, we added an extra activity for the prescriber in comparison with the general medication process which is the ‘create planning request’ activity. Once the cure of desire has been prescribed by the oncologist, he places an order for the planner to plan the patient for
chemotherapy. The planner, in this case the doctor’s assistant, then plans the patient for the treatment.
Figure 6 - The medication process for chemotherapy as observed at the AMC
The functional description of the NEXUS software applications
Within this paragraph we will first present the functional model of the current state describing the software functionalities that exist within NEXUS regarding the medication prescription and
treatment planning. In addition, we will also present the sequence diagram of the NEXUS planning tool as an illustration of the NEXUS planning functionalities.
Note: The functionalities that we will discuss are only the functionalities that are of relevance within
our research scope. Therefore these functionalities do not truly describe the current state of the entire NEXUS organization regarding medication.
Figure 7 – Functionalities supported by the current NEXUS medication – and planning applications (functional model
represented with the first layer of the 3LGM²-tool)
One thing that is noticeable about Figure 7’s model is the inclusion of the third group of
functionalities as they concern medication administration which is something we originally discarded from our research. However, we found out during our observations at NEXUS that these
functionalities are still noteworthy to mention as they share common ground with regard to treatment planning which is in our scope. To explain the previous stated: according to our observation when medication is prescribed in the NEXUS EPS, the prescription is automatically forwarded to the drug administration application of NEXUS leading to a time schedule of the moments when the patient needs to be seen for medication treatment. In our views this could be seen as form of (automatically) treatment planning and therefore we did not discard these functionalities from our model.
What is also noticeable about Figure 7 is the lack of entities; not every function updates or generates an entity. The reason for this lack of entities is the depth to which these functionalities have been
studied. Some functionalities have been observed in more depth than others due factors such as the availability of in-depth documentation and the limited amount of study time.
Another thing that we would like to highlight in Figure 7 are the planning functionalities (the second super function at the left). To do this we want to present a sequence diagram (see Appendix C) which illustrates the use of these functionalities in a natural planning flow. This illustration is partly a precursor of the next paragraph as the sub-applications named in this diagram will then be further explained. However it is a good addition to Figure 7 as this gives more insights to the current planning capabilities of NEXUS.
The NEXUS architecture
In this section we will discuss the NEXUS architecture at the level of software applications. We will start looking at the architecture from a very conceptual perspective in Figure 9 to a very technical representation focusing specifically on the NEXUS medication applications in Figure 11.
Figure 9 - A conceptual representation of the NEXUS architecture on product level
Given the conceptual architecture from Figure 9 we can tell that that the NEXUS architecture is divided into two main compartments containing products. In reality there are more products in each compartment but as these products are not relevant for our research nor is the purpose of this model to highlight rich details, we discarded these products from the model. In the left
compartment we see products for specialized medical purposes, the NEXUS / EHR. At the right we see products for healthcare logistics, commonly called the NEXUS / Care logistics. Furthermore we see that processes from the NEXUS / Care logistics can be used within the NEXUS / EHR.
Planning is part of NEXUS / Care logistics and is handled by the Agenda application component seen in Figure 9. The Agenda consists of several sub-applications from which two have been introduced earlier in Figure 8 in Appendix C: the Order Management system and the Planning Assistant. The Order Management system is used to order planning items: these items can be a single
appointment, multiple appointment or a package of both in the form of an appointment protocol. These protocols can be created using the Planning Assistant which then uses the protocol to generate appointment propositions. These propositions can ultimately be confirmed by the person
who processes the planning orders done in the Order Management system. It should be noted though that Planning Assistant is not in production yet in any organization.
With regard to the NEXUS EHR we can notice that the products come within a framework. This framework is called the H3 framework and products developed in this framework are called H3 desktops. We will discuss this framework and the H3 desktops later in more details. Furthermore we see that both NEXUS / EHR as NEXUS / Care logistics share one Oracle database where the data is stored and retrieved. However to keep the data organized each product or product group comes with its own database schema where the data is stored to.
Regarding the medication software, these products are implemented as smaller components inside the H3 desktops. To understand this, we need to understand the H3 framework first. To get more insights in the H3 framework we present Figure 10 which gives a technical representation of the framework.
Figure 10 - The technical model of the H3 framework (an implementation of the second layer of the 3LGM²-tool)
In Figure 10 we see that the H3 framework consists of several important main components. These components are:
H3 desktop: an executable written in the C# programming language that can be runned on an
operating system or in a web browser. The H3 desktop can be configured to the wishes of the NEXUS customers using screen containers. Each of these containers can be configured using a series of web
based components to generate dynamic content, the so called portlet panels. Portlets are basically the building stones of the H3 desktop and enable direct interaction with the user.
We distinguish five types of portlets in Figure 10. The first type of portlets are the eForms portlets which display customer specific forms for data that is not supported by database table structures. An example of an eForm is an intake form. The second type of portlets are the Factsheets portlets that are being used to present factsheets which is a query mechanism to quickly generate overviews of data. The third type of portlets is the H2 portlet which is responsible for presenting components related to the previous generation of the H3 framework, the H2 framework. An example of typical H2 content are the lab results or work lists. The fourth type of portlets are the native H3 portlets responsible for presenting H3 related content and at last the web portlets present web-related content.
With regard to software development NEXUS always speaks of H3 desktops or WorkSpaces. WorkSpaces are basically H3 desktops but designed to serve a specific working environment, for example the NEXUS/Intensive Care WorkSpace in Figure 9.
JBoss Enterprise Application Platform: an application server used to build, deploy and host java
applications and services. Practically the JBoss server holds the logical backbone of the H3 desktop. As seen in Figure 10 the eForms, factsheets and H2 components are hosted as web applications inside JBoss and are used by the portlets in the H3 desktop. The other portlets however use another compartment of the JBoss server called the H3 services. The term ‘service’ refers to software functionalities or groups of software functionalities that can be reused by different applications and are regulated using policies. The H3 services compartment holds all these services defined at NEXUS in the form of scripts. Portlets can then access these services in the H3 desktop.
Batch Daemon: an application component that serves as a task scheduler to schedule H3 services,
reports, database procedures etc. An example of a Batch Daemon process is creating back-ups of the data daily at 02:00.
xConnect: an application component that serves as a communication pipeline with external
applications in hospitals and so enables exchange of medical data. xConnect generates mainly HL7 messages on the base of events in NEXUS applications and can also receive HL7 messages from external applications.
NEXUS Database Management System: an application component used for creating and managing
databases. It provides programmers and users the ability to create, update, retrieve and manage data. Currently NEXUS only uses one database for all their applications.
To understand how the EPS and other medication tools are integrated into the H3 framework, please see the technical model in Figure 11.
Figure 11 - The technical model of the H3 framework incorporating the medication applications (an implementation of the second layer of the 3LGM²-tool)
From Figure 11 we can notice a couple of things. First of all the technical architecture of NEXUS-Germany and NEXUS-Netherlands are quite different. Whereas NEXUS-Netherlands uses an application server to host and deploy their applications, NEXUS-Germany does not have an application server at all. In fact NEXUS-Germany uses a typical client-server architecture where software clients communicate directly to their database management system using a physical server. Another thing noticeable is the fact that MediChart includes more than just an EPS. MediChart is actually a software package containing three main products: the EPS, the (drug-) Administration Registration System (ARS) and the Patient Data Management System (PDMS). All of these
applications work together to adequately deliver a drug-based treatment. The EPS is generally used to prescribe medication whereas the ARS uses the prescription information from the EPS and converts this to an agenda schedule for nurses. The PDMS ultimately manages the information used and generated by the EPS and the ARS.
What is also noticeable from Figure 11 is that NEXUS-Netherlands is not using the German client-server directly. As explained earlier the medication applications in the NEXUS architecture are implemented as smaller components inside the H3 desktops. These components are medication portlets. The portlets however are only functioning as the front-end of the MediChart clients. The complete software package including the logics of the applications are situated and hosted in Germany and their components are integrated inside NEXUS portlets using ActiveX integration. ActiveX is an object-oriented technique of Microsoft that enables the integration of application-specific components of other software vendors. Moreover each integrated application component in
an ActiveX connection comes with its own parameters and context which makes it possible for example to attach a specific patient to the component that you have integrated.
Furthermore we see that MediChart uses its own database to query or store data. This database contains all the database schema definitions regarding MediChart such as the definition of a patient. Germany exposes these database schema definitions through view interfaces. These interfaces are then queried by NEXUS-Netherlands to their own database in order to use the German definitions. Generally speaking it is difficult for the Dutch branch of NEXUS to expand functionalities themselves within MediChart given the differences between the architectures. Though a newly introduced module focused on usage outside MediChart such as NEXUS pharmacovigilance or the NEXUS National Exchange Point (in Dutch: Landelijk Schakel Punt) integration would not be a problem, as the functionalities of these modules support MediChart but are in essence not part of MediChart. Therefore NEXUS-Netherlands can create these kind of functionalities themselves. However, the main reason that NEXUS is developing certain products themselves is not because of architectural problems, but because of the differences in law regulations and medication processes between The Netherlands and Germany. These differences forces the Dutch and German branch of NEXUS to develop products that are conform the prevailing regulations and medication process of their countries.
The gap identification
In this paragraph we present both the results of the requirements gathering as the gap analysis. The results include the requirements for the chemotherapy planning tool and a cytostatics prescription module as well as the gaps that we identified using the requirements. First we will present the gap-analysis to show which requirements are supported and which not. Then we will present a list wise functional model containing only the gap requirements.
We managed to gather 30 prescription requirements and 12 planning requirements in total. These requirements are set out in Table 1 and 2. As we can see in the source lists of Appendix D most of the requirements originate from the internal document provided by the St. Anna hospital. This however does not mean that we did not find as much requirements during the interviews at the AMC. Most of the requirements gathered from the AMC interview were overlapping the ones in the St. Anna document. Therefore we only reported unique requirements from the interviews. However this did not result in any unique requirements from the AMC interview.
For the gap analysis please see Table 1 and 2 below that show which requirements are supported by the NEXUS medication – and planning software and which are not.
Table 1 - The gap analysis for the prescription requirements
Requirement Supported by:
1. The cytostatics module must contain an interface with the EHR that can be
used to retrieve the following basic patient data automatically: Patient ID
Patient name (first name, last name and initials) Date of birth
Citizen Service Number (CSN) Hospitalization date
Multiple births (yes/no) Sex
Length
Lab results (renal function, blood count, level of HB, leucocytes and thrombocytes)
2. From within the EHR the cytostatics module should be accessed in a
context sensitive matter H3 desktop
3. The cytostatics module supports both the clinical and outpatient process,
as well as singular and multiple cures NEXUS EPS
4. The cytostatics module must contain the ability to create a treatment plan NEXUS EPS
5. The cytostatics module must be able to signal abnormal values of basic
patient data on the basis of a treatment protocol -
6. The cytostatics module must be able to automatically adjust the
to-be-prescribed cure based on observed patient data deviations. -
7. The prescriber must be able to verify adjustments to cures by the
cytostatics module NEXUS EPS
8. The cytostatics module must contain an interface with the electronic
medication record so that automatic pharmacovigilance can be executed on the prescribed cure
-
9. The cytostatics module must be able to generate a historic overview of
(risky) prescribed cytostatic cures tracked in cumulative dosages -
10. The cytostatics module must provide a cure overview for the physician
and fellow practitioners containing the first needed cure with the shortest shelf life at the top
-
11. The cytostatics module must be able to establish an indication for add-on
medicines based on pre-filled indications for a cure NEXUS EPS
12. The cytostatics module must be able to calculate dosage on the basis of
patient parameters and selected treatment protocol NEXUS EPS
13. The cytostatics module must be able to calculate dosage based on the
AUC and the clearance -
14. The cytostatics module must be able to calculate clearance using the
Cockcroft Gault and/or the Modification of Diet in Renal Disease (MDRD) formula
-
15. When calculating the dosage using clearance or AUC, the cytostatics
module should set maximum limits for obese patients using the BMI or ideal body weight
-
16. If dosages need to be rounded, the cytostatics module should round the
dosage to max. 10% or up to whole vials -
17. The cytostatics module should base rounding on the amount of active
substance per vial and per ml -
18. When deviating from treatment protocols, the user should be able to
textually justify his decision in the cytostatics module NEXUS EPS
19. Deviations from protocols by the user including textual explanation should
be visible in the cytostatics module to third parties such as the pharmacist NEXUS EPS
20. In emergent situations the cytostatics module must provide specialists the
ability to change the dosage by adjusting the percentage of the medication -
21. If cures have been modified, the cytostatics module must be able to
automatically adjust the current and future treatment cycles at which the medical specialist receives a notification that this is happening and gives his approval
NEXUS EPS
22. The cytostatics module should be able to prescribe a cure with reservation
(e.g. due missing patient data) NEXUS EPS
23. The cytostatics module must be able to register a postponed or cancelled
Table 2 - The gap analysis for the planning requirements
24. The cytostatics module must allow the user to choose between
medication units (gram, liters etc.) NEXUS EPS
25. The cytostatics module must allow the user to select the route of
administration (systematic or local) and formulation (e.g. intravenous, solid etc.)
NEXUS EPS
26. The cytostatics module must cluster the cures on disease profiles to
maintain an overview NEXUS EPS
27. The cytostatics module must allow the user to assign user roles so that
only authorized persons can prescribe medications NEXUS EPS
28. The cytostatics module must be able to create or alter dosing schedules NEXUS EPS
29. The cytostatics module must be able to define new cures NEXUS EPS
30. The cytostatics module should remind the user that if the bodyweight as
registered in the EHR is older than 3 months then the prescriber should weigh the patient again
-
Requirement Supported by:
1. The chemotherapy planning tool must be able to plan cure appointments
with a planning window of at least 4 hours
Planning Assistant
2. The chemotherapy planning tool must be able to cope with a shifted
appointment by automatically rescheduling the appointment and the subsequent appointments
Planning Assistant
3. If rescheduling is needed due to an appointment change, the
chemotherapy planning tool must provide a choice between complete or partially automatic rescheduling
Planning Assistant
4. The chemotherapy planning tool must be able to generate a plannable
order in which automatically the most suitable planning window is searched incorporating the following organizational factors:
Available seats/beds Holidays and weekends
Pre-and post-treatment activities (cold-cap), pre-and post-hydration Protocol needs (infusion time, time between multiple infusions of 1
cure, dosing schedules, blood pressure temperature check)
Planning Assistant
5. If a patient somehow is not planned yet in the system, the chemotherapy
planning tool must show this to the physician without additional reporting -
6. The chemotherapy planning tool must provide an agenda-overview for the
nurses in which it is clear which patient will arrive on which day in what room for which cure
NEXUS ARS
7. If a cure is planned, then the chemotherapy planning tool must show to the
pharmacy when the first cure treatment will take place so that it can be prepared and subsequently released
NEXUS EPS
8. Cures that have been prescribed with reservation should be able to be
planned and gain the status of ‘draft’ until the prescriber approves it -
9. The chemotherapy planning tool must be able to either plan the cure
entirely or partially
Planning Assistant
10. If the chemotherapy planning tool plans a cure entirely, then the tool
must pre-fill in all treatment cycles and plan them in draft -
11. If the chemotherapy planning tool plans a cure partially, then the tool
must make clear in percentages which part of the cure is not prescribed and planned
Table 1 and 2 show that there are 17 gaps identified in total: 12 gaps with regard to prescription and 5 gaps regarding planning. From the 18 supported requirements for the cytostatics prescription module, 15 requirements are fully integrated in the medication software meaning that the functionalities are already available to NEXUS. Only 3 prescription requirements (requirement 1, 3 and 21) require a configuration in the H3 framework (desktop, container or portlet (-panel) configuration). Regarding the 7 supported requirements for planning, a configuration in H3 is not needed as they are all fully implemented in the NEXUS planning software.
Note that when we speak of a ‘fully implemented’ requirement we do not mean that NEXUS can use these functionalities directly to achieve the desired future state. Fully implemented only indicates that the functionalities are technically available in the software. However, to achieve the desired state these functionalities have to be complemented with the missing functionalities (gaps) and have to be connected through H3 configurations. We will focus on this in the next paragraph.
In concrete terms these are the functionalities that the current NEXUS medication – and planning software is missing according to the gap analysis. Please see the functional model below:
Prescription
31. Detect abnormal patient parameter values on the base of a protocol (in NEXUS terms: medication set).
32. Automatically adjust cures based on the detection of abnormal patient parameter values. 33. Execute pharmacovigilance on the medication profile of a patient.
NOTE: NEXUS is already developing this.
34. Generate an overview of administered cures based on the cumulative dosage.
NOTE: According to NEXUS the cumulative dosages are not practical, because it not possible
to track the dosage of a medication that the patient received in different hospitals.
35. Generate an overview of prescribed cures in ascending order of shelf life and in prioritizing order of need.
36. Calculate dosage based on the Cockcroft or MDRD formula.
NOTE1: This is a hospital dependent functionality. Commonly the Body Surface Area
formulas (Haycock, Dubois etc.) are used to calculate cure dosage and not clearance.
NOTE2: The Cockcroft formula for clearance is outdated and is likely to be replaced by the
CDK-epi formula.
37. Set limit on dosage calculation for obese patients based on the BMI or ideal body weight. 38. Round the calculated dosage to max. 10% or up to whole vials.
NOTE: This is likely a hospital dependent functionality.
39. Round the calculated dosage on the base of the amount of active substance per vial and per ml.
NOTE: This is likely a hospital dependent functionality.
40. Adjust the dosage of a cure in terms of percentage.
41. Express in percentage what part of a prescription is not prescribed due reasons.
NOTE: This is likely a hospital dependent functionality.
12. The chemotherapy planning tool could have the ability to plan lab and
Planning
13. Check which appointment rule in a specific appointment protocol could not be planned due reasons.
14. Plan an appointment as a draft.
15. Express in percentage what part of the appointment protocol is not planned due reasons.
NOTE: This is likely a hospital dependent functionality.
16. Plan laboratory tests.
17. Show the status of ‘draft’ to the appointment that the user has planned as a draft. Note that the amount of gap requirements (i.e. requirements that are not supported by the medication – and planning software) for prescription (11) is not the same as the amount of prescription gaps (12) in Table 1. This is caused by the fact that some gap requirements serve the same functionality and therefore these requirements are merged into one functionality leading to a decrease of the total number of prescription requirements.
The future state
In this last section we will describe the future state at NEXUS. We will first describe the functional model of the future state which includes functions from the gap-analysis. This model will be presented in the same way as the functional model of the current state using a graphical
representation. Furthermore we will describe the architecture of the future model in the form of a technical model. Overall the essence of this paragraph is to give meaning to the results of the gap-analysis.
Fundamentally the future state can be seen as the state where chemotherapy is supported by the NEXUS medication- and planning software in terms of cytostatics prescription and chemo treatment planning. A graphical representation in the form of a functional model of all the chemo functions regarding planning and prescription can be consulted in Figure 12 on the next page.
NOTE: the numbering used in this figure is consistent with the model from Figure 7 and not with the
functionalities discussed in the previous paragraph as this model is an expansion of Figure 7. Therefore Figure 12’s numbering should not be confused with the numbering seen in the previous paragraph.
Figure 12 - Functionalities supported by the future NEXUS medication – and planning applications (functional model represented with the first layer of the 3LGM²-tool)
As seen in Figure 12 the 16 introduced gap functionalities from the previous paragraph have led to 18 newly introduced functionalities in the functional model above. The reason for the higher number of functionalities in the model in comparison to the amount of gap functionalities can be explained due to the extraction of the sub-and super functions; the function ‘’Round the calculated dosage to
max. 10% or up to whole vials” has been split in two sub-functions creating one extra function.
Functions regarding the planning of the appointment protocol have been super ordinated into one super function creating another extra function which brings the total to 18. Though for the purpose of simplification and because the differences are not relevant for our end result but only for this model, we will stick to the number of 16 new functionalities for the rest of this thesis.
Moreover, just like in the current state functionalities regarding drug administration are not discarded from the model. With regard to planning we think that the NEXUS Agenda discussed in previous paragraphs could have the potential to serve as the desired chemotherapy planning tool. Especially the Planning Assistant because of its advanced algorithm to create complex appointment protocols which is very suitable for the field of chemotherapy.
Giving the complete functional model above, we will now present the architecture of the future state in Figure 13.
Figure 13 - The technical model of the future state (an implementation of the second layer of the 3LGM²-tool)
As we can judge from Figure 13 the architecture for the future state looks quite similar to the architecture of the current state. In fact, the only application component added in the future state is a MediChart application server at NEXUS-Germany. The reason for this minimal change is the fact that the gaps resulting from the gap-analysis only require changes on the level of software services or factsheets. For this reason we do not see many visually changes to the future architecture as the changes lie beneath the JBoss application server or in a newly introduced application server at the German branch of NEXUS. Before we go into the addition of the German application server, we would like to present the changes giving the newly introduced functions presented in the paragraph
Table 5 - The technical implementation of the newly introduced functionalities
Prescription
New functionality Implementation
31. Detect abnormal patient parameter values on the
base of a protocol (in NEXUS terms: medication set).
Introduction of a new service and/or expansion of existing services
32. Automatically adjust cures based on the detection
of abnormal patient parameter values.
Introduction of a new service and/or expansion of existing services
33. Execute pharmacovigilance on the medication
profile of a patient.
Introduction of a new service and/or expansion of existing services
34. Generate an overview of administered cures based
on the cumulative dosage. Introduction of a new factsheet
35. Generate an overview of prescribed cures in
ascending order of shelf life and in prioritizing order of need.
Introduction of a new factsheet
36. Calculate dosage based on the Cockcroft or MDRD
formula.
Introduction of a new service and/or expansion of existing services
37. Set limit on dosage calculation for obese patients
based on the BMI or ideal body weight. Expansion of existing services
38. Round the calculated dosage to max. 10% or up to
whole vials. Expansion of existing services
39. Round the calculated dosage on the base of the
amount of active substance per vial and per ml. Expansion of existing services
40. Adjust the dosage of a cure in terms of percentage. Expansion of existing services
41. Express in percentage what part of a prescription is
not prescribed due reasons.
Introduction of a new service and/or expansion of existing services
Planning
New functionality Implementation
13. Check which appointment rule in a specific
appointment protocol could not be planned due reasons.
Introduction of a new service and/or expansion of existing services
14. Plan an appointment as a draft. Introduction of a new service and/or
expansion of existing services
15. Express in percentage what part of the appointment
protocol is not planned due reasons.
Introduction of a new service and/or expansion of existing services
16. Plan laboratory tests. Introduction of a new service and/or
expansion of existing services
17. Show the status of ‘draft’ to the appointment that
the user has planned as a draft.
Introduction of a new service and/or expansion of existing services
In all the cases where a service is expanded or introduced, a portlet should be created to support the new functionality in the H3 desktop. Moreover we see above that most of the new functionalities require a change on the service level except for two prescription functions (34 & 35). Now the question raises which party is responsible for the implementation of the new services. To explain this we make a distinction in two different future states.
Future state #1: the ideal future state
In an ideal future state we expect NEXUS-Netherlands to develop all the functionalities themselves, being completely independent from the development at Germany. This can be realized by an architecture such as the one presented in Figure 13 where NEXUS-Netherlands develops and hosts the H3 services and factsheets into the JBoss application server. NEXUS-Germany can then access
these services and factsheets using a Representational State Transfer (REST1) protocol and
implement them into the MediChart clients using their own MediChart application server which communicates with the JBoss application server in the Netherlands. Ultimately the changes will be noticeable in the Netherlands by implementing the updated components again via the ActiveX integration. Of course all of this only applies to the medication software (MediChart) as the Planning Assistant is a tool that is developed by NEXUS-Netherlands meaning that the tool can be updated without having to take NEXUS-Germany into account.
A big advantage of this ideal future state is the total control that the NEXUS-Netherlands has as they can independently create all the desired functionalities. This enables NEXUS-Netherlands to develop their own Oncology WorkSpace in which MediChart and the Planning Assistant function as one super system. Even though the Planning Assistant is part of a different software component (Figure 9) as the NEXUS medication module, NEXUS makes it possible to use NEXUS / Care Logistics processes inside the H3 framework using a complex integration via a so called Component Object Model (COM2). This means that a WorkSpace containing H3 portlets and NEXUS / Care Logistics related
content is technically possible.
Future state #2: the realistic future state
Even though the ideal future state seems possible, it is still the question whether NEXUS-Germany is willing to build their own MediChart application server. It is more likely that NEXUS-Germany will not develop a sort like application on the short term because of prioritization issues. Therefore it is more realistic that NEXUS-Netherlands will have to suggest to the German parent company to develop the functionalities regarding MediChart. Functionalities that are independent of MediChart such as the planning functionalities can be developed by NEXUS-Netherlands. The same thing is true for functionalities that are only supporting MediChart but are not part of the software such as prescription function 33, 34 and 35. However this does mean that the idea of an Oncology
WorkSpace is not realistic on the short term in this version of the future state as NEXUS-Netherlands has to wait until NEXUS-Germany updates MediChart with the desired functionalities so that the components can be integrated via ActiveX. Conclusively, NEXUS-Netherlands will be able to fully develop a chemotherapy planning tool in the form of an updated Agenda application component including the Planning Assistant. With regard to the cytostatics prescription module, this will take time and good coordination with NEXUS-Germany in order to adequately produce the desired module.
Discussion
Our research has successfully identified the gaps in the current NEXUS medication – and planning software leading to 11 newly introduced software functionalities for cytostatics prescription and 5 functionalities for chemo treatment planning. These functionalities should be implemented by introducing new services and factsheets.
Strengths & limitations
A strength of this research is the reliability of the results as this research was conducted using domain knowledge from experts at NEXUS, the AMC and St. Anna hospital. In addition to these
sources we used an evidence-based reference model to describe the medication process. Moreover, intermediate results have been validated with the domain experts throughout most of the steps taken in this research which also adds to the high reliability of the results. Another strength of this research was the high detail level at which the gap analysis was conducted. For instance, we did not purely limit our final advice to the gaps but we also gave meaning to the gaps in the form of a description of the technical implementation. As a result the final advice formed a steady base for NEXUS to build further on.
However, there are limitations to this research. First of all it was difficult to interview many hospitals as most of the hospitals were not willing to participate in the research or were difficult to contact. As a result there is a low diversity of sources used outside NEXUS to describe the medication process for chemotherapy and to gather the requirements. Only two oncology departments have been interviewed from which one (St. Anna hospital) provided the most input used in this research. This could lead to an inaccurate list of requirements since a part of the requirements could be hospital-dependent. Another limitation is the extent to which chemotherapy is covered in this thesis. This research only focused on the prescription and planning phase which covers the prominent aspects of chemotherapy but not the entire landscape of chemotherapy.
Comparison with literature
The approach of NEXUS discussed in this research is certainly not new as various studies in the US have reported the concept of modifying existing EPS’s to allow electronic prescribing of
chemotherapy [17 – 22]. The studies of Hoffman, Meisenberg, Harsberger and Brockstein discussed a modification for the prescription of infusional chemotherapy while the studies of Weingart and Collins focused on oral chemotherapy. All studies however integrated chemotherapy prescribing into an EHR system infrastructure by programming chemotherapy regimens into an existing EPS. This integration had led to several positive outcomes such as real-time access to patient information, reduction of dose calculation/adjustment errors and evaluation of chemotherapy utilization for safety and cost-containment monitoring. Therefore our approach could have the potential to create the same impact in hospitals of NEXUS customers. However one should take in note that these studies came from an American setting where the healthcare is different than the Dutch healthcare. This means that the chemotherapy process as defined in the US could differ in certain ways from the Dutch process.
Implication of the results
The results of this research has provided new insights to NEXUS regarding their medication – and planning software. Because of our research we added new knowledge to the company opening new doors to the field of electronic medication prescription and treatment planning in the context of chemotherapy. With the results of this research NEXUS should be able to at least fully develop the chemotherapy planning tool as they have complete control over this development without any dependencies on German developments. The development of the cytostatics prescription module however is generally a bit more complex but still feasible as this requires constructed talks with NEXUS Germany. Our results are also valuable for the customers of NEXUS as they indirectly will benefit from the development of the chemotherapy tools thanks to the base that we provided with this research.
Recommendations for future study
Although our study did provide a steady base for NEXUS-Netherlands to build further on, the results of this research cannot directly be used for development. A future study should focus on tackling the other phases of chemotherapy such as the preparation and declaration process. Namely the role of the pharmacist should be taken more into account as the pharmacist is almost completely discarded from our research.
The design of the future study could look something like the design of the current study but with some additions to it. First of all we recommend to interview more hospitals. By including more hospitals in the research we believe that a more reliable and more complete view will form of the chemotherapy landscape. Besides, more research participants could also result in a bigger and more accurate list of requirements. As discussed earlier contacting hospitals was problematic in this research, especially because of the busy schedules of the hospital staff but also because we did not had an intermediate contact person at the beginning of this project. Therefore we recommend NEXUS to look into their customer base for hospitals that maintain a strong relationship with NEXUS and contacting them using someone with strong connections inside the institution. Furthermore we recommend NEXUS to prioritize the found requirements with a formalism such as the MoSCoW technique to gain an understanding of the level of importance for each requirement. Next we would recommend NEXUS to validate the gap functionalities that have been highlighted in the thesis as ‘dependent’ at another hospital to study whether the functionalities are truly hospital-dependent or not. Our final recommendation to NEXUS is to also validate the technical
implementations that we described for each gap functionality as these implementations could be slightly doubtful since they were gathered from interviews with a single expert on software
architectures. It would strengthen our results more to validate our implementation suggestions with a technical designer of the prescription and planning software.
Conclusion
To expand the overall NEXUS-system to enable chemotherapy prescription and planning, NEXUS has to implement 16 new functionalities to their medication – and planning software.
To implement these functionalities we recommend NEXUS-Netherlands to introduce new or expand existing software services and factsheets. Depending on the willingness of NEXUS-Germany there are two scenarios possible to reach the desired future state: an ideal scenario and a realistic scenario. In the ideal scenario NEXUS-Netherlands is completely in control over the development of the desired functionalities without having to take NEXUS-Germany into account by developing all the functionalities themselves. This will only require one architectural change: the introduction of an application server in Germany that will collaborate with the application server at NEXUS-Netherlands in order to implement the new MediChart functionalities developed by the Dutch. This scenario would even open doors to a possible Oncology WorkSpace comprising the updated medication module with the ability to prescribe cytostatics and the updated Agenda tools enabling chemotherapy planning.
However, in the more realistic scenario NEXUS-Germany will need to take most of the responsibility with regard to the development of the prescription functionalities. Surely NEXUS-Germany will not implement an own application server due prioritization issues and therefore NEXUS-Netherlands will
Netherlands can expand these functionalities independently of the development at NEXUS-Germany as the planning tool is originally a Dutch product. Conclusively, NEXUS-NEXUS-Germany and NEXUS-Netherlands have to adequately work together and reach agreements about the
responsibilities of the two company branches with regard to the development of the cytostatics prescription module. A good coordination is needed for this development.
References
1. SearchHealthIT. E-prescribing (electronic prescribing) [Internet]. Available from:
https://searchhealthit.techtarget.com/definition/e-prescribing [Accessed: December 19th 2018] 2. Computerized provider order entry systems. Health Devices 2001, 30(9-10): 323 – 359
3. Kim GR, Chen AR, Arceci RJ. Error Reduction in Pediatric Chemotherapy: Computerized Order Entry and Failure Modes and Effects Analysis. Arch Pediatr Adolesc Med. 2006, 160(5): 495 – 498 4. Collins CM, Elsaid KA. Using an enhanced oral chemotherapy computerized provider order entry
system to reduce prescribing errors and improve safety. International Journal for Quality in Health Care 2011, 23(1): 36 – 43
5. Radley DC, Wasserman MR, Olsho LEW, Shoemaker SJ, Spranca MD, Bradshaw B. Reduction in medication errors in hospitals due to adoption of computerized provider order entry systems. Journal of the American Medical Informatics Association 2013, 20(3): 470 – 476
6. Cancer Society of Finland. Cytotoxic drugs or cytostatics [Internet]. Available from:
https://www.allaboutcancer.fi/treatment-and-rehabilitation/cytostatics/ [Accessed: December 3rd 2018]
7. NICTIZ. Mp: V9.0.7 Ontwerp medicatieproces [Internet]. Available from:
https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces [Accessed: December 3rd 2018]
8. 3LGM²-Team. 3LGM²: Three-layer Graph-based meta model to describe, evaluate and plan health information systems [Internet]. Available from: http://www.3lgm2.de/en/index.jsp [Accessed: April 3rd 2019]
9. Winter A, Brigl B, Wendt T. Modeling Hospital Information Systems (Part 1): The Revised Three-layer Graph-based Meta Model 3LGM². Methods of Information in Medicine 2003, 42 (5): 544 – 551
10. Cruz-Cunha MM, Miranda IM, Gonçalves P. Handbook of Research on ICTs and Management Systems for Improving Efficiency in Healthcare and Social Care 2013.
11. Techopedia. Module. Available from: https://www.techopedia.com/definition/3843/module [Accessed: December 19th 2018]
