|
 
 |
| ORIGINAL ARTICLE |
|
| Year : 2020 | Volume
: 5
| Issue : 1 | Page : 22-32 |
|
On triage system
Mohanad Abdulhamid1, Wekesa Elijah2
1 Department of Electrical Engineering, AL-Hikma University, Baghdad, Iraq
2 Department of Electrical Engineering, University of Nairobi, Nairobi, Kenya
| Date of Submission | 11-Jul-2019 |
| Date of Acceptance | 27-Sep-2019 |
| Date of Web Publication | 30-Dec-2019 |
Correspondence Address:
Dr. Mohanad Abdulhamid
Department of Electrical Engineering, AL.Hikma University, Baghdad
Iraq
 Source of Support: None, Conflict of Interest: None  | Check |
DOI: 10.4103/ijas.ijas_15_19
Introduction: Triage is the process of categorizing patients in emergency situation according to the severity of their injuries or sickness. This is done in order to give medical attention to those who need it first, to minimize loss of life from injuries.
Aims: This article aims to create an electronic triage system based on the Raspberry Pi computer and Arduino microcontroller. The Raspberry Pi computer wirelessly receives data measured by the Arduino and analyses the data after which it automatically categorizes patients with minimal human intervention.
Results: The Raspberry Pi runs a graphical user interface-based system that is used to display results and allow for users to input data into the database. The system contains two functionalities, emergency mode (MODE 1) and emergency department mode (MODE 2). MODE 1 is used for urgent outdoor emergency scenarios such as motor vehicle accident with multiple casualties, to determine the seriously injured victims. MODE 2 can be integrated in a medical center where it is used to determine which patient needs immediate attention in a scenario where there are so many patients waiting. In MODE 2, patient's recent vitals readings can be graphically viewed for further analysis and medical doctors can comment on each patient's progress for future reference. This data is then uploaded to an online server.
Conclusion: The article focuses on the design and implementation of triage system which is based on Raspberry Pi.
Keywords: Medical system, Raspberry Pi, triage
How to cite this article:
Abdulhamid M, Elijah W. On triage system. Imam J Appl Sci 2020;5:22-32 |
| Introduction | |  |
Triage is the process of prioritizing or sorting sick or injured people for treatment according to the seriousness of the condition or injury. The purpose of this is to ration patient treatment efficiently when resources are insufficient for all to be treated immediately. This system is employed in a mass casualty incident such as on a battlefield or terror attack in the civilian domain to increase the chances of patients' survival. Triage may also be used for patients arriving at the medical center in large numbers, thus overwhelming the available resources.[1]
Refugees or internally displaced person camps require constant health-care services due to acute health risk associated with large movements of refugees. For this reason, medical clinics within the camps or local areas are flooded with patients seeking medical attention. In such a situation, a triage system may assist in categorizing patients from most critical to the less critical ones. The system involves medical personnel performing structured tests and reading vital signs from each and every patient or casualty in order to determine their severity of their condition.[2]
Modern-day triage system employs color coding techniques to easily identify patients who require immediate medical services from the ones who can wait. The colors used are: Red for critical, Yellow for less critical, and Green for minor health issues. More than one medical personnel has to go through the patients in order to determine the category the patient belongs to.[3],[4]
Use of triage system to ration medical services is time- consuming and requires a lot of workforces. This is because a single medical practitioner has to perform a variety of tests on one patient, which might take more than 5 min per person. Considering the number of patients, this process might take a while for all patients to be attended to. This might lead to loss of life. Second, due to the large number of patients, the medical center requires more than one medical personnel to categorize patients faster. This results in the use of useful medical skills in triage instead of giving treatment.[5]
This article tries to address the problem of wastage of medical skills in triage and time consumption in performing test and analysis of a patient's condition.
| Design and Implementation | | |
Architectural design
The triage system hardware is designed with two main sections, the sensor and the controller section. The sensor section comprises of multiple wireless units each connected with sensors to measure patients vitals. These units are each strapped to individual patients, and their vitals are sent wirelessly to the controller section. The controller receives the data and processes it for other macrosection within the design. Architectural design of triage system is shown in [Figure 1].
System functionalities
The Raspberry Pi-based triage system is created to be operated in two modes to cater for two kinds of incidents.
MODE 1: Emergency
When an accident occurs, there are always casualties. At times, the number of casualties can be more than what first responders can handle. This system can be used in such a scenario where the sensor units are strapped on to the casualty's body and the first responders/medical personnel can monitor each casualty from a central point through the main controller unit and determine who is to be attended to or transported first.
Due to the high tension environment of the incident, casualties/victims can only be identified using the unit ID, since most of the casualties are probably new to the system and their information does not exist in the system's database. In this mode, the sensor data are used for categorizing purposes only. In this mode, the sensor units only measure temperature and heart rate. Weight value in this mode is disabled.
MODE 2: Emergency department
In the case of a medical center receiving a large number of patient's everyday, thus sorting and categorizing is required, then this system can be used in this mode.
In this mode, all the patients' details and treatment records are stored locally onto the main controller unit. When a large number of patient are waiting for treatment, and the Raspberry Pi based triage system is employed, then each sensor unit strapped onto a patient will be linked to a specific name in the database. Unlike mode one, the sensor data are not linked to any specific person but only differentiated using the units ID. Weight value in this mode is enabled.
Hardware design
Sensor unit
[Figure 2] shows the hardware architects of a single sensor unit.
The sensor unit contains:
- Microcontroller: Processing readings from the sensors and major control function of the unit
- A power supply: Provide the microcontroller with power
- Temperate sensor: Output voltage value to the microcontroller that vary with temperature
- Heart rate sensor: Causes an interrupt to the microcontroller if a heartbeat is detected
- Radiofrequency wireless link module: Send data wirelessly to the controller unit
- Audio jack-AUX (weighing scale): Provide an interface for connecting a weighing scale
- Unit ID: This is the unit's identity that it should be referred with (Will be printed on the sensor unit). Each sensor unit has a unique ID on its surface. The unit ID will be represented with two characters only.
Main controller unit
The main controller unit shown in [Figure 3] does most of the main functions of the system. It mainly contains:
- Raspberry Pi: Minicomputer performs all the systems software functions
- User input devices: Keyboard and mouse to allow the user to control the Raspberry Pi
- SD card: Memory for the minicomputer, used to store the minicomputers operating system and system's local database
- RF link module: Receive sent data by the sensor unit
- Wi-Fi Dongle: Connects the Raspberry Pi to the internet through Wi-Fi.
System operation
Initial stages of the system
It is assumed that for mode 2, all patients who are under the triage system are all already registered into the system and their details stored in the database the first time they came to the medical center. When they are registered, the system generates a unique patient ID number for each patient. This ID is printed on a card and the patient is given to always walk around with it.
Setting up the system
Mode 1/2: One or two medical officers go round strapping the sensor unit onto the casualties' upper arms, making sure that the temperature sensor is well placed under the armpit and the pulse sensor strapped onto the person's finger.
Mode 2: Once the sensor unit is strapped onto the patient's arm, the medical personnel takes the patient ID and the unit ID and inputs it into the system, to link the patient to the sensor they are strapped onto.
Software design
General concept flow diagram of both sections of the triage system is shown in [Figure 4] and [Figure 5].
Circuit design
Sensor unit circuitry
The design of sensor unit circuitry is shown in [Figure 6].
Main controller unit circuitry
The design of controller unit circuitry is shown in [Figure 7].
Weighing scale circuitry
The design of weighing scale circuitry is shown in [Figure 8].
System implementation
Hardware
Wireless Communication
The unit sensor transmits data wirelessly to the microcontroller using a radiofrequency module (NRF24 L01+). The module is interfaced with the Raspberry Pi using Serial Peripheral Interface communication protocol. Each sensor unit transmits a string of 11 characters to which contains information of the patient's vitals.
The wireless network configuration is a master-slave type, where the sensor unit is the slave and the Raspberry Pi main unit is the master. The slaves continuously send the 11 character string that changes with patient's vitals each using different pipes (channels) to avoid interference. The Raspberry Pi receives the string, and it is able to differentiate which string is from which sensor unit by the first two characters of the string which contain the unit's ID.
Sensor unit circuitry
The sensor unit circuit is initially tested on a prototyping board and later on soldered on to a stripboard. The Arduino is the microcontroller of the sensor unit. [Figure 9] and [Figure 10] show images of the sensor unit soldered on a stripboard.
Main controller unit circuitry
The main controller unit consisting of the Raspberry Pi and an RF module as the main components as shown in [Figure 11].
Software
The system's software part is divided into two sections, where each section is programmed with different programming languages. The two sections are:
- Sensor unit software
- Main unit software.
Sensor unit Software
The sensor unit is programmed using the language C++, which is normally used to program Arduino microcontrollers. Arduino manufacturers provide an integrated development environment (IDE) where we can easily program and directly upload our code to the microcontroller. IDE consists of a source code editor, build automation tools, and a debugger. Although Universal Serial Bus serial ports, the IDE is able to send the code to the Arduino which is used to program the microcontroller.
The sensor unit uses a number of libraries that help the microcontroller easily interface with the sensor and provide functions for their operations. To include a specific library to our system, the “include” command is used.
Sensor unit code used to encode the three sensor value data into an 11-character string for transmission.
Main controller unit software
The Raspberry Pi software is mainly coded using python. The system on the Raspberry Pi is a graphical user interface (GUI) programmed using a python framework called Flask.
Flask is a microweb framework written in Python and uses the model–view–controller architecture. In this system, it is used to build a web server that runs locally on the Raspberry Pi. In other words, the system is a web application using the Raspberry Pi as a local server.
The systems GUI (front-end) is written in HTML, CSS, and JavaScript. While the backend is written in python (flask) mainly. The following are the files that contain the program that the system runs on:
- Static Folder: Holds all the none dynamic files (images, CSS, javascript file)
- Template folder: Holds all the HTML files (web pages)
- Health_value_calc.py: Contains method used to determine a patient's health value
- App.py: Main file that runs the program, it links different web pages together
- Forms.py: Contains all the form objects, used to create form elements in HTML
- Models.py: ORM program. Contains object representation of all the database tables
- Radio.py: Control the RF module
- Radio_test.py: Used to test if the RF modules is working
- Triage.db: SQLite database (system's database).
Object-relational mapping (ORM) is used to communicate with the systems database. Here, a python-based ORM called Peewee is used to connect to SQLite (relational database). Peewee is one of Flasks extensions as discussed in the theory.
The SQLite tables system uses SQLite database and contains five tables. These tables are:
- User table: Contains all users saved in the database, for mode 2
- Patient link: Saves all links created between patient and sensor unit in mode 2
- ED patient data: Stores all vital reading of a linked patient (Connected to a sensor unit)
- Emergency sensor data: Stores all vital readings of casualties with sensor units
- Doctors comments: Stores comments from doctors for each patient.
| Results | | |
This section entails the operation of the completed system. The main controller unit is first connected to a screen, keyboard, and mouse then powered on. The Raspberry Pi is operated in desktop mode on an operating system called Raspbian that is UNIX based as shown in [Figure 12].
Using the Rasbian OS command-line interpreter (terminal), the server is started by running the main file app.py. When the server starts, the Chromium web browser is opened up and the IP address generated by the server is loaded (http://127.0.0.1:5555) as shown in [Figure 13].
System web pages
Home page
The home page shown in [Figure 14] contains an option of selecting either mode 1 of the system or mode 2. When “Emergency” is selected, the system redirects the user to the mode 1 section of the system. When “Emergency Department” is selected, it goes to mode 2.
Depending on the medical team requirement, either mode 1 or mode 2 can be used. When any of the mode is selected, the system immediately starts reading any data sent to it though the RF module.
Mode 1 page
In Mode 1 page shown in [Figure 15], we can see that the data being transmitted from the unit sensor is being displayed in real-time. The health value is calculated and a color tag assigned to the patients.
This page has a script (JavaScript) that runs after every 0.5 s. The scripts read, analyse, and records data received by the NRF24 L0+ module. It also updates the web page HTML elements, e.g., temperature, heart rate, health value, and the category color tag.
Mode 2 page
This is the mode 2 of the system [Figure 16]. Here, the data being read from the sensors are linked to a specific patient. A medical personnel is required to load the patient's ID and the unit ID to be able to view and monitor a specific patient's condition. Only data from linked patients are stored in the database.
Patient data page
A specific patient's data can be viewed in order to deeply analyze their progress or view their history data such as doctor comments. From Mode 2 page, a medical personnel can click on the green button (patient data) of any patient to access the patient's page as shown in [Figure 17].
In this page, we can view the patient's last temperature and heart rate readings, patient's information, and doctor's comments. Within this same page, there is a form for doctors to add comments for each patient. The comments displayed above the form are sorted from the latest to the oldest.
Register patient page/patient database
Medical personnel can view patients logged into the database, and they can also add new patients through this page as shown in [Figure 18].
The table displayed in this page can be used to view patient's details: date of birth, blood type, personal phone number, next of kin phone number, or address as shown in [Figure 19].
The forms in this system contain form validation features as shown in [Figure 20], that would not allow certain user input when the form is submitted. This feature comes with Flask-WTF extension.
SQLite database
To view the contents of the triage system database (triage.db), a software called SQLite browser is used. The image in [Figure 21] shows all the existing tables:
Just to choose some of the tables, we are able to view the data stored into the tables.
Patient's table
The patient's table is shown in [Figure 22].
Emergency sensor data table
This table is shown in [Figure 23].
ED patient data table
This table is shown in [Figure 24].
| Conclusion | | |
The paper was established to design and implement a basic triage system that is Raspberry Pi based and demonstrate that it works. The article highlighted the theoretical principles that guided the design choices and selection of components and gave images of the system working. The only challenge experienced during the implementation of the work was RF module incompatibility with the heart rate sensor. The sensor provided for heart rate is a pulse sensor that detects a pulse and causes an interrupt in the microcontroller for every heartbeat. This interrupts are timed and counted to be able to determine beats per minute. During timing of this interrupts, the RF module concurrently has its own timing code that affects that of the pulse sensor. Thus, for the two to operate simultaneously became a challenge. The options of resolving this challenge are to get a better heart rate sensor that has its own timing circuit or run the RF module code and the pulse sensor code alternately. The second option will require the heart rate code to run first, which might take 30 s or less than followed by the RF module. This means the rate at which the RF module will transmit data will have reduced, thus reducing the systems real-time functionality. Due to time constraints, a second challenge was not being able to connect the Raspberry Pi to the internet using the Wi-Fi dongle. For this reason, uploading data to an online server was not done. Other than those two challenges, generally, the work was successful and the main objectives of the paper were met.
Financial support and sponsorship
Nil.
Conflicts of interest
There are no conflicts of interest.
| References | | |
| 1. | Sakanushi K, Hieda T. Electronic triage system: Casualties monitoring system in the disaster scene. International Conference on P2P, Parallel, Grid, Cloud and Internet Computing. Spain; 2011.  |
| 2. | Sakanushi K, Hieda T. Electronic triage system for continuously monitoring casualties at disaster scenes. J Ambient Intell Humanized Computing 2013;4:547-58. |
| 3. | Cuttance G, Dansie K, Rayner T. Paramedic application of a triage sieve: A paper-based exercise. Prehosp Disaster Med 2017;32:3-13. |
| 4. | Saeed A, Al-Fayyadh F. Validating the implementation of the triage system in an emergency department in a university hospital. J Health Spec 2017;5:73-9. [Full text] |
| 5. | Engan M, Hirth A, Havard T. Validation of a modified triage scale in a Norwegian pediatric emergency department. Int J Pediatr 2018;2018:1-8. |
[Figure 1], [Figure 2], [Figure 3], [Figure 4], [Figure 5], [Figure 6], [Figure 7], [Figure 8], [Figure 9], [Figure 10], [Figure 11], [Figure 12], [Figure 13], [Figure 14], [Figure 15], [Figure 16], [Figure 17], [Figure 18], [Figure 19], [Figure 20], [Figure 21], [Figure 22], [Figure 23], [Figure 24]
|
Search Pubmed for