Mapping and Visualisation of the Patient Flow from the Emergency Department to the

(1)

INOM

EXAMENSARBETE TEKNIK, GRUNDNIVÅ, 15 HP

STOCKHOLM SVERIGE 2020,

Mapping and Visualisation of the Patient Flow from the Emergency Department to the

Gastroenterology Department at Södersjukhuset

QUOC HUY MARTIN TRAN

CARL RONSTRÖM

(2)

(3)

This project was performed in collaboration with Södersjukhuset AB

Supervisors at Södersjukhuset AB: Bengt Lavö and Rebecca Stjärnfeldt Rosenqvist

Mapping and Visualisation of the Patient Flow from the Emergency Department to the Gastroenterology

Department at Södersjukhuset

Kartläggning samt visualisering av patientflöden från akuten till gastroenterologiavdelningen på

Södersjukhuset

QUOC HUY MARTIN TRAN CARL RONSTRÖM

Degree project in medical engineering First level, 15 hp

Supervisor at KTH: Tobias Nyberg, Mattias Mårtensson Examiner: Mats Nilsson

(4)

ii

(5)

Abstract

The Emergency department at Södersjukhuset currently suffers from very long waiting times.

This is partly due to problems within visualisation and mapping of patient data and other information that is fundamental in the handling of patients at the Emergency department. This led to a need in the creation of improvement suggestions to the visualisation of the patient flow between the Emergency department and the Gastroenterology department at Södersjukhuset.

During the project, a simulated graphical user interface was created with the purpose of mim- icking Södersjukhusets current patient flow. This simulated user interface would visualise the patient flow between the Emergency department and the Gastroenterology department. Addi- tionally, a patient symptoms estimation algorithm was implemented to guess the likelihood of a patient being admitted to a department. The result shows that there are many possible improvements to Södersjukhusets current hospital information system, TakeCare, that would facilitate the care coordinators work and in turn lower the waiting times at the Emergency department.

Keywords: Electronic health record, EHR, TakeCare, Emergency Room, ER, Gastroentero- logy department, ICD-10, Algorithm, Graphical User Interface, GUI, Södersjukhuset, SöS

(6)

iv

(7)

Sammanfattning

Akutmottagningen på Södersjukhuset har i dagsläget väldigt långa väntetider. Detta beror till viss del utav problem inom visualiseringen och kartläggning av patient data och annan fundamental information för att hantera patienter på akutmottagningen. Detta ledde till att det finns ett behov att skapa förbättringsförslag på visualiseringen av patientflödet mellan akutmottagningen och gastroenterologiavdelningen på Södersjukhuset.

Under projektets gång skapades ett simulerat användargränssnitt med syfte att efterlikna Söder- sjukhusets nuvarande patientflöde. Denna lösning visualiserar patientflödet mellan akutmottagningen och gastroenterologiavdelningen. Dessutom implementerades en enkel sorteringsal- goritm som kan bedöma sannolikheten om en patient skall bli inlagd på en avdelning. Resultatet visar att det finns flera möjliga förbättringar i Södersjukhusets nuvarande elektroniska journ- alsystemet, TakeCare, som skulle underlätta vårdkoordinatorernas arbete och därmed sänka vän- tetiderna på akutmottagningen.

Nyckelord: Elektronisk journalsystem, TakeCare, Akutmottagningen, Gastroentrologiavdel- ning, Gastro, ICD-10, Algoritm, Användargränssnitt, GUI, Södersjukhuset, SöS

(8)

vi

(9)

Abbreviations

API Application Programming Interface ER Model Entity-Relationship Model

GDPR General Data Protection Regulation

GUI Graphical User Interface

ICD-10 10th revision of the International Classification of Diseases

IDE Integrated Development Environment

MVC Model-View-Controller

Patient Data Act Patient Data Act [Patientdatalagen]

SQL Structured Query Language

SöS Södersjukhuset

(12)

(13)

1 Introduction

During 2018 around 94 000 people sought out emergency medical treatment at Södersjukhuset (SöS) down in central Stockholm where the median waiting time per patient was 338 minutes [1]. While in contrast, the shortest median waiting time within the Stockholm Regional Council was at Capio S:t Görans hospital with a median time of 182 minutes [2]. Thus there is a need to reduce the waiting times for emergency treatment at SöS.

One of the existing departments that patients are allocated to from the Emergency department is the Gastroenterology department. Today at SöS the visualisation of patients that have arrived at the Emergency department is not intuitive enough which leads to a loss of time. This is due to the current processes for coordinating patients from the Emergency department to the Gastroenterology department [3]. It would help a lot if the hospital information system used today by SöS visualised patients in a way that makes it easier to detect all the patients that could be sent to the Department of Gastroenterology or sent home almost immediately. Examples of such cases are patients that have earlier received care from recurring symptoms or have a medical letter of referral to the Department of Gastroenterology. With proper visualisation, the coordinator responsible for sending patients to different departments could send them directly to the Gastroenterology department. This would be instead of having them receive the first judgement from nurses and doctors at the Emergency department.

1.1 Aim

The aim of this project was to create a graphical user interface (GUI) to chart out and visualise the patient flow from when a patient enters the Emergency department and is then sorted into the Gastroenterology department for treatment. A subgoal of this project was to also implement an algorithm that can cross-reference current symptoms with symptoms from previous medical records. Thus aiding the coordinator using the GUI to allocate patients to the department of Gastroenterology for treating the patient.

1.2 Limitation

The project only used theoretical data when forming the sorting algorithm due to the limitations set by the patient data law [4] in Sweden. Another limitation set was to exclude all non-essential personal information such as address and telephone number from the staff and patients to keep the focus on the goal of the project.

(14)

(15)

2 Background

The following chapter will give a better insight into the hospital and the hospital logic required for understanding the project better. This includes a detailed storyboard of the processes a patient goes through when arriving at the hospital to when the patient leaves the hospital. The storyboard will give a better understanding of the purpose of the project. This is then followed up with a technical background on how to solve the problem and different aspects to consider when working with patient data.

2.1 The workflow from the Emergency department to the Gastroentero- logy department

Today at SöS the standard procedure when a patient comes to the hospital for emergency care is such that the patient first gets to talk to a nurse that makes a first evaluation [5]. This information is then added to the electronic health record system TakeCare. Depending on the severity of the condition the patient has to wait a certain amount of time before they get to meet a doctor. The doctor would then evaluate whether the patient should be admitted to a department and in this specific case the Gastroenterology department. When a decision has been made to admit a patient, a specific care coordinator at the Emergency department contacts the department coordinator to make sure there are available beds at the department.

2.2 Problems in the workflow from the Emergency department to the Gast- roenterology department

The problem today in the Emergency department is that a lot of the processes in TakeCare, such as the registration of the patient’s identification number, could be done either at the Emergency department or the Gastroenterology department. This creates an uncertainty of whether a patient has been registered or not when arriving at the Gastroenterology department. Additionally, patients who have received a medical letter of referral has to wait in the Emergency department instead of being sent to the specialist even though an initial assessment of the patient’s symptoms has already been conducted [3].

Another problem is the fact that a care coordinator is required. Thus a lot of time could be saved if doctors and nurses could easily get the information in TakeCare that is needed to admit a patient themselves to a department from the Emergency department. Today this information is mainly used by the care coordinator at the Emergency department and not well integrated with the list of patients at the Emergency department [5]. The problem is highlighted by figure 1 which shows that due to a lot of time spent taking care of patients there is not enough time for the administration to admission the patients into TakeCare. This is why the curve peaks mainly in the afternoon once the workflow has settled down according to Lavö [3].

(16)

Figure 1: Number of admissions to the Gastroenterology department during a 24 hour period.

The image was used with permission from Bengt Lavö [3].

2.3 Laws and regulations

When considering further development of this project several laws and regulations must be followed both on an international and national level to ensure the protection of patient data.

The most relevant laws to consider when developing patient journal software in Sweden are the Patient Data Act (Patient Data Act) [4] and the General Data Protection Regulation (GDPR) [6].

Patient Data Act

The Patient Data Act(2008:355) was implemented in 2008 by the Swedish parliament in order to have a governing process when handling personal data within health and medical care. The most crucial parts of the Patient Data Act for this project are chapters 4 and 6 [4].

Chapter 4 provides the groundworks to ensure inner secrecy [4]. This means that the information about a patient can only be given to authorised personnel who is need of the information in his or her work in health and medical care. This chapter also provides the patient with the possibility to block the usage of his or her care documentation which means that care providers will not have the possibility to access it [4].

Chapter 6 of the Patient Data Act provides the basis for a unified electronic health record which connects several care providers patient records if the records meet the Patient Data Act requirements which include the approval from the patient [4]. By making the records available for other care providers it makes it possible to see the patients previous medical history.

General Data Protection Regulation

The General Data Protection Regulation is implemented throughout the European Union with the purpose to have a uniformed set of guidelines to ensure the protection of personal data [6].

The GDPR also ensures that any personal information gathered must be approved by the person as well as it can only be used for the explicitly stated purpose as well as when it is no longer needed the data must be deleted. As well as it grants people the ability to request the collected data about themselves and have wrongful information updated or even remove all data about themselves. Another principle of the GDPR is to ensure true anonymous data is collected and that it can not be linked back to an identifiable individual.

3

(17)

2.4 TakeCare

TakeCare is the electronic health record system used by SöS and all the other hospitals within The Stockholm Regional Council today [7]. The systems main functionality lies in the fact that each patient has all their information from the entire care process stored in a single health record.

This information is then available and easily accessible by anyone that has access to TakeCare unrelated to physical location and organisation within the TakeCare system. TakeCare as a system is built as a server that stores information, this information is then accessible by clients, systems and services connected to the server [8]. Whenever a client uses TakeCare they can access and write in any patient journal stored on the TakeCare server. The client PC also has access to information stored in the TakeCare server through services that can only be accessed from the web.

2.5 NetBeans IDE

NetBeans IDE is an IDE that supports many different programming languages such as Java, C++, PHP, JavaScript and many others. For this project, it was only used to develop Java programs.

NetBeans IDE is a sort of text editor with a built-in compiler that helps with indenting of lines and highlights code syntactically and semantically [9]. It also has a few other features that help in the writing of code in the chosen programming language.

2.6 The database

MySQL is an Open Source relational database based on the programming language Structured Query Language, (SQL). MySQL allows for structured storage in different relational tables and easy extraction and combining of data from different tables by running queries in SQL within the database [10]. To interact with the database, MySQL Workbench was used within this project.

MySQL Workbench is a visual tool specifically made for SQL development [11]. MySQL was used to store all the data within the simulated electronic health records.

2.7 Medical code

The International Classification of Diseases (ICD) was created by the World Health Organisa- tion in 1893 [12]. Since then there have been revisions of the ICD where today the 10th revision (ICD-10) is used. The ICD was introduced to identify health trends and gather statistical information by introducing a standardised method of diagnostic classification. This would enable an easier and more comprehensive analysis of health information for evidence-based decision- making. Additionally, the unification behind the ICD-10 made it possible for easier sharing and comparing of health information and statistics between hospitals. Furthermore, the application of the ICD-10 makes it easier to group different diseases to their respective groups. With this, it helps with identifying the disease when patients visit the hospital and have to describe their symptoms.

(18)

(19)

3 Methods

The project is based on a simulated environment which was replicated with simulated patients and staff. This is a project suggestion for how the system could look like to help the patient flow. To make the simulated environment the project was divided into five different sections.

The first part was to study the flow of patients coming from the Emergency department to the Gastroenterology department. The second part was to analyse historical data and get a better understanding of room for improvement. The third part was to create the database and have it structured similarly to what TakeCare currently presents. The fourth part was to implement the database in the java environment and program the required functionality to meet the aim of the project. Lastly, the fifth part is to use the code provided from part four and implement it with a GUI. The aforementioned sections are described in the following subheadings.

3.1 Understanding the patient flow

Gathering of information

At the start of the project, research about the Emergency department at SöS and the Stockholm Regional Council was conducted. This was done to grasp a better understanding of the current environment that each hospital works with. This was complemented by explanations of the situation at SöS today from the supervisors, Bengt Lavö and Rebecca Stjärnfeldt Rosenqvist.

With this information, it was possible to get an insight into what types of patients came to the Emergency department and would be sent to Gastroenterology. As well as the problems that SöS has to deal with today were highlighted.

Interviewing employees within the workflow

To be able to know what functionalities within TakeCare have potential to be improved, interviews with employees within the workflow between the Emergency department and Gastroen- terology department had to be conducted. The questions were different depending on what role the person being interviewed had. The interviews were conducted over phone, e-mail or at the hospital in person. List of questions to employees at the Emergency department:

1. What roles exist at the Emergency department and how do they interact with the current visualisation of the patient flow?

2. What information is recorded within TakeCare when a patient seeks care at the Emergency department and are there any standards to how this information is registered?

3. How does the patient flow differ between patients that have a medical letter of referral and those who do not?

4. What kind of improvements to TakeCare would make it easier to handle patients with a medical letter of referral.

(20)

7. If TakeCare had the possibility to suggest an action based on the patient’s current search reason and earlier journal entries, how would you want that information visualised?

List of questions to employees at the Gastroenterology department:

1. How do you get the information that a patient is being admitted to the department?

2. How are other departments informed of how many available hospital beds you have?

3. What is the routine when discharging a patient from the department?

4. What role has the authority to discharge a patient from the department?

5. How long does it take before other departments are informed that there are available beds when a patient has been discharged from the department?

6. What kind of improvements in TakeCare would facilitate the care coordinators work?

3.2 Historical data analysis

Another part of the project was to find out whether the improvements could be implemented by TakeCare. The main point that was analysed here was whether TakeCare could use old digitalised journals from Stockholm Regional Council. This could then be implemented in a statistical machine learning algorithm to the patient list at the Emergency department. This usage of algorithms is purely hypothetical and Stockholm Regional Councils archive was contacted to find out what kind of restrictions apply to usage of patient journals.

3.3 Building the database

After having a better understanding of the structure of TakeCare and its database it had to be replicated for the simulated electronic health record. This led to building a database that stores all the data existing in electronic health records that were relevant to this project. The process of deciding on the relevant data was done in the earlier process of gathering information from the hospital. The database was written in MySQL 8.0 by using the unified visual tool application MySQL Workbench 8.0 CE.

3.4 Programming the application

To program the application, Netbeans version 8.0.2 was used as an IDE for the programming language Java version 1.8.0_51. The first step to construct the application was to generate a connection to the earlier constructed database. With the application connected to the database, the next step was to create methods that can extract and change the necessary information within the database. Down below are the necessary methods that were used as a foundation in programming the application. Apart from the methods below, methods to add information to the database through the application had to be created as well to allow for proper testing of the application.

• getAllPatients: Returns a list of all patients at a specific department.

• updatePatient: Updates any patient information.

• updateBedStatus: Updates whether a bed is occupied or not.

6

(21)

• departmentExists: Returns true if a specific department exists in the database.

• searchDepartment: Returns department information from a specific department ID.

• removeBed: Removes a specific bed.

• getNrOfEmptyBeds: Returns the number of empty beds at a specific department.

• getAllDepartments: Returns a list of all departments in the database.

• updateStaff : Updates any staff information.

• staffExists: Returns true if a specific staff member exists in the database.

• getAllStaff : Returns a list of all staff members in the database.

• updateJournal: Updates any patients Journal information.

• journalExists: Returns true if a specific journal entry exists in the database.

• getAllJournals: Returns a list of all Journal entries in the database.

• searchJournal: Returns a list of all Journal entries for a specific patient.

• admissionProbability: Returns a list of all the ICD-10 codes that match the patient’s symp- toms as well with the probability of it.

All of these methods were chosen with consideration to the visualisation requirements of the GUI. As well as the information available in SöS current electronic health record system Take- Care. In order to test all the methods in the application and later on also the functionality of the GUI another method that added fictive data to the database was added as well.

3.5 Building the sorting algorithm

When considering how to code the probability algorithm for the patient several conditions had to be considered. These were how much patient data would be available for the project, for which diseases the focus would be on, and finally which symptoms should be used for each disease.

After consultation with Bengt Lavö and Rebecca Stjärnfeldt Rosenqvist a list of 11 diseases with their most common symptoms was procured. These lists can be found in Appendices 4 and 5.

With a list of ICD-10 codes and their respective symptoms, the algorithm would cross-reference any searchable word in the patient’s described condition. The algorithm would then compare the number of words that matched a symptom with how many times the most occurring ICD-10 code occurs from the patient’s described condition. This probability was then compared to the probability of how many times the most occurring ICD-10 code occurred compared to the total number of occurring ICD-10 codes. The result would be a probability of the most potential disease that the patient might have. In addition, in the cases where the patient had been given a medical letter of referral, the algorithm would assign the patient with the highest probability to inform the user.

3.6 Building the GUI

The GUI was built within the same Netbeans project in accordance to the Model-View-Controller, (MVC), design pattern where the application is represented by the model and the GUI is represented by the view while the controller is the connection between them. The interface was just as the application created with Java through Swing which is an API for providing a GUI for Java

(22)

between the Emergency department and the Gastroenterology department. This was in the hope of coming to a better solution than what TakeCare offers today.

The list of system requirements which was used as a guideline to build the GUI can be seen below:

• Visualise a patients likelihood of getting admitted to the Gastroenterology department.

• Visualise detailed patient information in the same view as the patient list.

• Visualise current occupancy in a department through the Emergency department patient list.

• Visualise different departments patient lists in the same view.

• Visualise the number of patients about to be discharged of each department.

• Functionality to change department of a patient through the same view as the patient list.

Apart from these requirements the system also had to keep the original functionality that the Emergency department patient list in TakeCare has while adding the new functions to it. The current structure of the patient list in TakeCare can be seen in Appendix 1 with the only exception that identifiable patient information has been redacted.

8

(23)

4 Results

The result is divided into three parts. The first part is the results from gathering information from hospital employees and Stockholm Regional Council archives. The second part consists of the results related to the database while the third part are the GUI results.

4.1 Information gathering

Interview with Emergency department nurse

The interview was conducted with Jenny Delin who works as a specialist nurse at the Emergency department. She was asked the questions from the form devised for Emergency department employees. The answers to each question are listed below.

1. There are nurses, physicians and care coordinators that interact with the visualisation of the patient flow.

2. When a patient seeks care, all necessary patient information is registered such as search reason, location, arrival time, priority and actions taken by a nurse. This information is registered to the patient’s information within the patient list at the Emergency department.

3. Patients with a medical letter of referral get to meet a relevant doctor faster if it is noticed in the system that they have a medical letter of referral, however, this tends to be an issue.

4. Some visualisation in the patient list so that the care coordinator notices these patients easier would help a lot.

5. This question was not answered due to the fact that it is the care coordinator that checks the number of available beds at different departments.

6. Actions differ a lot between different search reasons and patients, it is very hard to gen- eralise actions depending on just the search reason.

7. It would have to be visualised together with the information it is based on such as previous medication, diagnoses and symptoms. This would make it easy for the doctor or nurse looking at it to make their own judgement.

Interview with Gastroenterology department physician

Bengt Lavö who works as an attending physician specialised within the area of gastroenterology at SöS answered the questions to the Gastroenterology department as follows:.

1. The Emergency department care coordinator contacts the Gastroenterology department care coordinator and notifies that they have a patient that needs to be admitted. The Gast- roenterology department care coordinator then admits the patient and notifies the rest of

(24)

3. If the patient has a planned date that they will be discharged from the department it is registered into TakeCare and on the date and time that they are discharged. This would be done by a doctor who registers them as discharged from the department.

4. Doctors are the ones that discharge patients from departments.

5. That depends on whether the doctor that is supposed to discharge a patient has the time to register it right away. Normally this is something that takes longer than usual and amounts to extra time spent for patients at the Emergency department. Since they can not be admitted to a department as soon as the actual bed is available. This is because the care coordinator does not know that the bed is available until it is registered into the system.

6. The system needs to be more intuitive and a lot of functions that the care coordinators use are in different views. So a better solution would be to have them accessible from the same view.

Contact with Stockholm Regional Council archives

In order to be able to construct a statistical machine learning algorithm using patient journal data, there are two different ways to go about it. The first one is to get consent from each patient that is part of the data you want to use. As well, you would also need the consent of the Stockholm Regional Council. This would be very impractical and would probably not get enough viable data. The second way is to be the company that is hired by the Stockholm Regional Council to supply them with an electronic health record system, that company today is CGM which supplies them with the product TakeCare. Since TakeCare is supposed to be the system that all hospitals within the region use when they need to have access to the digitalised journals. With this access, there is the potential to create an anonymous journal database that only uses the relevant data for the machine learning algorithm. This would mainly rule out names of patients. With proper consent from the Stockholm Regional Council, this is a viable solution [14].

The database consists of five different tables with different columns. A simplified entity-relationship model, (ER Model), can be seen in figure 2 where the full ER Model can be seen under Appendix 2. Accompanied with the ER Model there is the relation model which can be seen in figure 3.

These models laid the foundation for programming the database. The full structure of the tables in the database can be seen in Appendix 3.

10

(25)

Figure 2: The entity-relationship model for the database within the simulated electronic health record system. The attributes in each relation represent the relevant information for this project that the current electronic health record system at SöS already records and visualises in a sub- optimal way. The rectangles represent the entities such as the patient, department, staff, journal, medCodes and symptoms which collect data. The ovals represent the attributes which help with describing the qualities or characteristics of the entities and help distinguish them from one and another. The diamond represents a relation among the entity instances and often is named with a connecting word to show the relation between two entities. The entities and relations are connected by lines where the 1 represents one instance of the entity and M represents many instances of the entity. For example, one patient has one journal or one patient seeks many departments (which can be interpreted as a patient seeks help from a hospital).

(26)

Figure 3: The relational model for the database within the simulated electronic health record system. The arrows show the relation of the primary keys and the tables where they act as a foreign key.

The first table was called T_Patient, which is where the patient information would be stored.

This table was created to keep track of patients that are currently in the hospital. Thus why information regarding when the patient was visited by a member of staff was added. The primary key for this table was set to the patient’s social security number, patientID, since it is a unique identifier for every patient. Additionally, the patient table takes in the information of what department the patient is in, and staff members who are responsible through the foreign keys from each respective table.

The second table was called T_Department. This table contains information regarding the de- partment and a specific bed at the department. The primary key for this table was the composite key of the department ID and bed ID. This means that a new table is created for every bed that is in the department.

The third table was called T_Staff. This table consists of the staff information such as which department the person belongs to. The primary key for the table was set to the staff ID. This

12

(27)

primary key was used to identify the staff member in T_Patient to know the responsible staff members of the patient. It is also used in T_Journal to know which doctor signed the patient out.

The fourth table was called T_MedCodes. This table consists of information about the ICD-10 and each medical codes name. The list of ICD-10 codes used can be found in Appendix 4. The primary key for this table is the ICD-10 code which is used as a foreign key in the journal and the fifth table, T_Symptoms. The table T_Symptoms uses this foreign key from T_MedCodes to be able to relate the disease with the most common symptoms. The list of symptoms with its respective ICD-10 code can be found in Appendix 5.

4.3 Graphical user interface

The final version of the application consists of two main windows where the first is focusing on the main view that the emergency department coordinator would see. The second window is the view that the department coordinator would see in order to know the current patients at the department.

Emergency department view

This section of the results will go into the structuring of the emergency department part of the GUI. When the program boots up the application main view is shown which is the view of the emergency department as seen in figure 4. This table consists of the following columns; time of arrival (Ank), the location of the bed (Plats), the name of the patient (Namn), the nurse who is responsible for the patient (Ssk), the patients reason for coming to the hospital (Besökor- sak), comments on the patients history using the notation SBAR which stands for Situation Background A/Current Recommendation (Kommentar), the priority is based on the urgency of the patients need to see the doctor (P), the activities the patient has been through (Aktivitet), the doctor who is responsible for the patient (Läk), when the doctor visited the patient (Läk-in), if the patient has gone home or not (Gått hem), and finally the probability if the patient should be admitted into the hospital (Inläggning Sannolikhet).

The colour coding for the priority (P) is what is used today in TakeCare which follows the Triage model [15]. The colours represents how urgent the patient needs attention from the doctor and is presented in the following bullet points.

• Red(1): The patient is severely ill.

• Yellow(2): The patient needs to be viewed by a doctor.

• Green(3): The patient is currently in the ambulance.

• Blue(4): The patient can wait before being viewed by a doctor.

• Pink(5): The patient is non-urgent and can wait to see a doctor.

(28)

• Red: If the probability is greater or equal to 0.75.

• Yellow: If the probability is less than 0.75 but greater or equal to 0.50.

• Green: If the probability is less than 0.50 but greater than 0.25.

• Blue: If the probability is less or equal to 0.25.

Figure 4: The main view of the application showing the current occupancy of the emergency department with the addition of the admission probability. The last column named ”Inläggning Sannolikhet” represents the probability of admission.

When highlighting a patient row in the table a new view is presented showing a tab with a more detailed list of information about the selected patient is presented. As well as information regarding the probability is presented underneath giving the general physician a suggestion of potential diseases that the patient might have. This detailed view of the patient can be seen in figure 5 where it shows a patient with several potential diseases. Additionally figure 6 shows when the patient has been given a medical letter of referral.

The colour coding for the priority (P) is what is used today in TakeCare which follows the Triage model [15]. The colours represents how urgent the patient needs attention from the doctor and is presented in the following bullet points.

• Red(1): New patients at the department and will be visited first at the rounds.

• Yellow(2): The patient will be visited during the rounds.

• Green(3): The patient is in stable condition but will be visited by the doctor at rounds.

• Blue(4): No need to be visited by the doctor at the rounds.

• Pink(5): The patient will be leaving the department soon.

14

(29)

Figure 5: The interface when highlighting a patient showing a more detailed information about the patient. This view shows several probabilities for different ICD-10 codes for the patients admission.

Figure 6: The interface when highlighting a patient showing a more detailed information about the patient. This view shows that the probability is the highest value of one which is due to that the patient has received a medical letter of referral.

When in the detailed patient view a row of selectable buttons is presented to the user. These are the following; ”Show current occupancy” (Visa nuvarande beläggning), ”Admit the patient

(30)

a drop-down table, this is seen in figure 7. The ”Admit the patient to a department” button shows the popup window in figure 8 which asks for which department and bed the patient will be appointed at the department. The ”Discharge the patient” presents a pop-up dialogue window as presented in figure 9 where the information regarding what comments, activities, actions that are taken, disease the patient had and the doctor who is signing the patient out. The ”Close window” button brings the user back to the main window, see figure 4.

Figure 7: The popup window that shows the user the current occupancy of the different departments.

16

(31)

Figure 8: The pop-up window that appears when the button named ”Admit the patient” (”Skriv in patient”) on figure 5 and 6 is pressed.

Figure 9: The pop-up dialogue window when the user clicks on ”Discharge the patient” (”Skriv ut patient”).

Gastroenterology department view

When changing the view of the main window through the drop-down options at the bottom of figure 4 the option of swap to another window brings the user to the main occupancy window, see figure 10. This view has a different focus of columns compared to the emergency department.

This table consists of the following columns; time of arrival (Ank), the location of the bed (Plats), the name of the patient (Namn), the nurse who is responsible for the patient (Ssk), the patient’s reason for coming to the hospital (Besökorsak), comments of the patient’s history using the SBAR notation as previously mentioned (Kommentar), the priority based off the needs of the patient (P), the activities the patient has been through (Aktivitet), the doctor who is responsible for the patient (Läk), when the doctor visited the patient (Läk-in), when the patient is estimated to leave the hospital (Uppskattad utskrivning), and if the patient has gone home or not (Gått hem).

(32)

Figure 10: The main view of the application showing the current occupancy of the Gastroenter- ology department. The colour coding in the column ”P” is a visualisation of the number in ”P”, the numbers represent the patients current need of care at the department with 1 (red) being the highest priority and 5 (pink) being the lowest priority.

When selecting a patient from the list more detailed information about the patient is presented this is presented in figure 11. This is similar to figure 5 but when compared to the emergency department view there is a different set of buttons for the user. These buttons includes; ”Update the patients expected sign out date” (”Uppdatera patients uppskattade utskrift”), ”Send the patient home” (”Skriv ut patient”), and ”Close window” (”Stäng fönstret”).

Figure 11: The main view of the application showing the current occupancy of the Gastroenter- ology department with the patient information in focus.

18

(33)

5 Discussion

In this chapter the result are discussed and interpreted, the potential for future application in a hospital information system as well as the future development of the presented solutions are also analysed. This project has been done during the COVID-19 pandemic which means that most of the work has been done in a way that promotes social distancing. Social distancing has impacted the quality of the project as a whole on a large scale since it was not possible to conduct necessary studies and interviews at SöS. Instead, everything had to be done by either e- mail or phone. Since SöS is a hospital that played a big part in taking care of COVID-19 patients this meant that getting necessary information from employees took longer time than what was initially planned, considering their number one priority was to treat their patients.

5.1 Future development and application

The interviews conducted with hospital employees resulted in valuable information that could be used as a help to develop the simulated application. Additional research was conducted to see whether reasonable solutions can be put into practice. One of the purposes of the project was to reduce the patient waiting times at the Emergency department. This meant the main focus was placed on the interview responses related to reducing the waiting times. With that said, we concluded that TakeCare’s Emergency department patient list should implement new features such as access to a list of available beds in other departments. TakeCare should also implement a statistical machine learning algorithm based on patient journals to aid caregivers in their choice of action. TakeCare as a system should also implement better design solutions to help SöS remove the position of care coordinator at the Emergency department. With a better system, the work that the care coordinator does could be done by the doctors and nurses that work at the Emergency department instead.

When it comes to implementing a machine learning solution we found that it is a very new type of solution. However, there are a few different types of algorithms such as Logistic regression, Naive Bayes and Deep Learning. For this type of solution, Deep Learning is the most effective one in terms of accuracy [16]. As for the development of this simulated solution, it could have been written in other languages that is easier to integrate into the Take Care such as in C. Ad- ditionally, since Java Swing is quite outdated when it comes to developing solutions we looked into using JavaFX. However, the reason we ended up using Java Swing was the simplicity of it and access to a well-documented API.

During the project, we created a database to store the same information that is normally being stored within the database in TakeCare to make our application more realistic. This would mean an easier integration to an actual hospital database. Figure 2 and figure 3 illustrate the relational structure within the created database and the stored information within these relations. All of the

(34)

high developing potential. Since TakeCare uses a database different than SQL this database would not be compatible with TakeCare. In the case that this project would be implemented into TakeCare changes of the SQL query questions would be required. This would be done in order to adapt it into the new database language.

5.3 The GUI

The GUI was made with the MVC design pattern which meant that we first constructed the model and tested its functionality with the database. This meant that we had to figure out what kind of functions the GUI should have without actually working with the functions for the GUI.

In hindsight this made us create some unnecessary methods for this project. However, this opens up for easier future development of the GUI since there are functionalities within the model that have not been fully utilised by the view.

The view of the GUI is represented by figure 4-11. As can be observed in the figures we have added some functionality that supports visualisation of a statistical machine learning algorithm that returns a probability of admission for specific causes. It is also possible to select a single patient and see more detailed patient information in the same view which TakeCare does not support today. This is supposed to make it easier for the person working with the patient list to keep track of all patients. The detailed patient information could be developed even further by adding functionality that displays earlier journal entries or relevant journal entries. Apart from this the GUI also has all the system requirements that were mentioned in the method section.

The GUI could be developed further by using the same language as TakeCare is currently written in to make it compatible, however for it to be compatible with TakeCare this solution would also have to receive a CE marking since it qualifies as a medical technology product. It means it has to follow regulations set by both the GDPR and the Patient Data Act. If this is done the project would no longer be a simulation of how to visualise a patient flow, it would instead be something that can be implemented. This is what we hope SöS can show to the developers of TakeCare.

5.4 The Probability algorithm

The sorting algorithm that was used was a very basic algorithm for the purposes of this project.

So when analysing the results different advantages and disadvantages of the method can be determined. The advantages of the method are that the physician is given a quick overview of the probability which also highlights the patients with a medical letter of referral. As well as it gives the user the ability for a cross-referenced suggestion of the patient’s condition and thus aiding the user in the decision making.

The disadvantages of this method is that the algorithm uses the causes to seek medical care given upon arrival at the emergency department, it then compares that with a list of symptoms. The algorithm begins with executing a SQL query which checks if a word from the patient’s statement matches any part of the column symptom in T_Symptoms. After closer inspection there were problems with this method as words with no correlation to any symptom would come through as a match. This would further affect the probability even more due to how the system calculated the probability. This means that the chances for false positives are very high with the current method.

20

(35)

6 Conclusions

In conclusion, the project has resulted in a GUI that implements all the needed system requirements and visualises the patient flow from the Emergency department to the Gastroenterology department. Therefore the main goals of the project were achieved. The developing of an algorithm that can cross-reference symptoms from previous medical records has only been partly achieved. This was because the algorithm created only has a limited number of ICD-10 codes and symptoms. This had to be done due to the project’s lack of access to any sort of historical medical records. Instead, the project showed the possibility of implementing such an algorithm and visualising the results together with other patient information in the Emergency department patient list.

(36)

(37)

7 References

[1] Södersjukhuset. Fakta om Södersjukhuset [Facts about Södersjukhuset]. Apr. 2019. : https : / / www . sodersjukhuset . se / om - sos / fakta - om - sodersjukhuset/ (visited on 13th Feb. 2020).

[2] Region Stockholm. Antal besök per akutmottagning på akutsjukhus [Number of visits per emergancy room at hospitals]. 2018. : https://www.sll.se/globalassets/1.-halsa- och- vard/bilagor--- nyhet/bilagor- nyheter- 2018/statistik- vecka- 21_nya- akuta- varden.pdf (visited on 13th Feb. 2020).

[3] Bengt Lavö. Leg. Överläkare, Sektionschef internmedicin, Södersjukhuset. Interview March 2020.

[4] Riksdagsförvaltningen. Patientdatalag (2008:355) Svensk författningssamling 2008:2008:355 t.o.m. SFS 2019:1299. Dec. 2014. : https : / / www . riksdagen . se / sv / dokument - lagar/dokument/svensk-forfattningssamling/patientdatalag-2008355_sfs-2008-355 (visited on 3rd Apr. 2020).

[5] Jenny Delin. Verksamhetsutvecklare Specialistsjuksköterska akutsjukvård, Södersjukhu- set. Interview May 2020.

[6] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). May 2016. : https://eur- lex.europa.eu/legal- content/

ENG/TXT/PDF/?uri=CELEX:32016R0679&rid=1 (visited on 4th Apr. 2020).

[7] TakeCare. The Stockholm Case. : https : / / profdoccare . se / the - stockholm - case/

(visited on 4th Apr. 2020).

[8] Compugroup Medical. Bruksanvisning[Instruction manual]. 2020. : http://tchelp.

sll.se/utb/Bruksanvisning.pdf (visited on 4th Apr. 2020).

[9] Apache Software Foundation Oracle Corporation. NetBeans IDE. : https://netbeans.

org/features/ (visited on 4th Apr. 2020).

[10] Oracle Corporation. MySQL 8.0 reference manual. : https : / / downloads . mysql . com/docs/refman-8.0-en.pdf (visited on 7th Apr. 2020).

[11] Oracle Corporation. MySQL Workbench. : https : / / www . mysql . com / products / workbench/ (visited on 7th Apr. 2020).

[12] World Health Organisation. Classification of Diseases (ICD). : https://www.who.

int/classifications/icd/en/ (visited on 11th May 2020).

[13] Javatpoint. Java Swing Tutorial. : https://www.javatpoint.com/java-swing (visited on 11th May 2020).

[14] Anders Söderlind. Enhetschef Arkiv- och informationsförvaltning, Regionarkivet Stock- holm. Interview May 2020.

(38)

Appendix 1: Emergency department occupancy list

Image was used with permission from Bengt Lavö [3].

1

(39)

Appendix 2: The Entity-Relation Model, ER Model

(40)

Appendix 3: The database SQL code

1 CREATE TABLE IF NOT EXISTS T_Department (

2 departmentID VARCHAR( 2 0 ) ,

3 bedID VARCHAR( 2 0 ) ,

4 b e d L o c a t i o n VARCHAR( 2 0 ) ,

5 b e d S t a t u s ENUM('Empty', 'F i l l e d ') NOT NULL,

6 departmentName VARCHAR( 2 0 0 ) NOT NULL,

7 totalNoOfBeds INT NOT NULL,

8 PRIMARY KEY ( departmentID , bedID )

9 ) ;

10

11 CREATE TABLE IF NOT EXISTS T_Staff (

12 s t a f f I D VARCHAR( 2 0 ) ,

15 s_fname VARCHAR( 1 0 0 ) NOT NULL,

16 s_lname VARCHAR( 1 0 0 ) NOT NULL,

17 PRIMARY KEY ( s t a f f I D ) ,

18 FOREIGN KEY ( departmentID , bedID ) REFERENCES ...

T_Department ( departmentID , bedID ) ON DELETE CASCADE

19 ) ;

20

21 CREATE TABLE IF NOT EXISTS T_MedCodes (

22 medCode VARCHAR( 6 ) ,

23 m e d D e s c r i p t i o n VARCHAR( 1 0 0 0 ) NOT NULL,

24 noOfAdmissions INT NOT NULL,

25 PRIMARY KEY ( medCode )

26 ) ;

27

28 CREATE TABLE IF NOT EXISTS T_Symptoms (

29 symptomNo INT,

30 symptom VARCHAR( 3 0 0 ) ,

31 medCode VARCHAR( 6 ) NOT NULL,

32 PRIMARY KEY ( symptomNo , medCode ) ,

33 FOREIGN KEY ( medCode ) REFERENCES T_MedCodes ( medCode ) ON DELETE CASCADE

34 ) ;

35

36 CREATE TABLE IF NOT EXISTS T_Patient (

37 p a t i e n t I D VARCHAR( 1 2 ) , - - s s n

38 s e a r c h R e a s o n VARCHAR( 1 0 0 0 ) NOT NULL,

39 comments VARCHAR( 2 0 0 0 ) NOT NULL,

40 a c t i v i t i e s VARCHAR( 2 0 0 0 ) NOT NULL,

41 p_fname VARCHAR( 1 0 0 ) NOT NULL,

42 p_lname VARCHAR( 1 0 0 ) NOT NULL,

45 p r i o r i t y INT,

46 r e s p o n s i b l e N u r s e VARCHAR( 2 0 ) ,

47 r e s p o n s i b l e D o c t o r VARCHAR( 2 0 ) ,

48 a r r i v a l M e t h o d ENUM('Ambulance ', 'ER', 'NA') NOT NULL,

49 i d e n t i f i c a t i o n M e t h o d ENUM('ID', 'NA') NOT NUll,

50

1

(41)

51 a d m i s s i o n D a t e DATE NOT NULL,

52 admissionTime TIME NOT NULL,

53 appointedBedDate DATE NOT NULL,

54 appointedBedTime TIME NOT NULL,

55 n u r s e V i s i t D a t e DATE NOT NULL,

56 n u r s e V i s i t T i m e TIME NOT NULL,

57 d o c t o r V i s i t D a t e DATE NOT NULL,

58 d o c t o r V i s i t T i m e TIME NOT NULL,

59 e s t i m a t e d D i s c h a r g e D a t e DATE,

60 e s t i m a t e d D i s c h a r g e T i m e TIME NULL,

61

62 news INT,

63 e r g a n c y INT,

64 h o s p i t a l i s a t i o n ENUM('Yes ', 'No', 'NA') ,

65 wentHome ENUM('Yes ', 'No', 'NA') NOT NULL,

66 r e f e r r a l ENUM('Yes ', 'No', 'NA') NOT NULL,

67 PRIMARY KEY ( p a t i e n t I D ) ,

T_Department ( departmentID , bedID ) ON DELETE SET NULL,

69 FOREIGN KEY ( r e s p o n s i b l e N u r s e ) REFERENCES T_Staff ( s t a f f I D ) ,

70 FOREIGN KEY ( r e s p o n s i b l e D o c t o r ) REFERENCES T_Staff ( s t a f f I D )

71 ) ;

72

73 CREATE TABLE IF NOT EXISTS T_Journal (

74 p a t i e n t I D VARCHAR( 1 2 ) ,

75 a d m i s s i o n D a t e DATE NOT NULL,

76 d i s c h a r g e D a t e DATE NULL,

77 admissionTime TIME NOT NULL,

78 d i s c h a r g e T i m e TIME NULL,

79 s e a r c h R e a s o n VARCHAR( 1 0 0 0 ) NOT NULL,

80 comments VARCHAR( 2 0 0 0 ) NOT NULL,

81 a c t i v i t i e s VARCHAR( 2 0 0 0 ) NOT NULL,

82 actionTaken VARCHAR( 1 0 0 0 ) NOT NULL,

83 medCode VARCHAR( 6 ) ,

86 s t a f f I D VARCHAR( 2 0 ) ,

87 PRIMARY KEY ( p a t i e n t I D , admissionDate , d i s c h a r g e D a t e ) ,

T_Department ( departmentID , bedID ) ,

89 FOREIGN KEY ( s t a f f I D ) REFERENCES T_Staff ( s t a f f I D ) ,

90 FOREIGN KEY ( p a t i e n t I D ) REFERENCES T_Patient ( p a t i e n t I D ) ,

91 FOREIGN KEY ( medCode ) REFERENCES T_MedCodes ( medCode )

92 ) ;

(42)

Appendix 4: The list of medical codes in Swedish

medCode medDescription noOfAdmissions

K922 Gastrointestinal blödning, ospecificerad 1

D649 Anemi, ospecificerad 1

D509 Järnbristanemi, ospecificerad 1

K703 Levercirros orsakad av alkohol 1

J189 Pneumoni, ospecificerad 1

R104X Buksmärtor UNS 1

K590 Obstipation (förstoppning) 1

K263 Sår i tolvfingertarmen, akut utan blödning eller perforation 1 K210 Gastroesofageal refluxsjukdom med esofagit 1

K625 Blödning i anus och rektum 1

A099 Gastroenterit och kolit av icke specificerad orsak 1

1

Mapping and Visualisation of the Patient Flow from the Emergency Department to the

Mapping and Visualisation of the Patient Flow from the Emergency Department to the

Gastroenterology Department at Södersjukhuset

QUOC HUY MARTIN TRAN

CARL RONSTRÖM

Mapping and Visualisation of the Patient Flow from the Emergency Department to the Gastroenterology

Department at Södersjukhuset

Kartläggning samt visualisering av patientflöden från akuten till gastroenterologiavdelningen på

Södersjukhuset

Abstract

Sammanfattning

Contents

Abbreviations

1 Introduction

2 Background

3 Methods

4 Results

5 Discussion

6 Conclusions

7 References

Appendix 1: Emergency department occupancy list

Appendix 2: The Entity-Relation Model, ER Model

Appendix 3: The database SQL code

Appendix 4: The list of medical codes in Swedish