Users Online: 380
Home Print this page Email this page Small font size Default font size Increase font size
Home About us Editorial board Search Ahead of print Current issue Archives Submit article Instructions Subscribe Contacts Login 


 
 Table of Contents  
ORIGINAL ARTICLE
Year : 2020  |  Volume : 5  |  Issue : 1  |  Page : 22-32

On triage system


1 Department of Electrical Engineering, AL-Hikma University, Baghdad, Iraq
2 Department of Electrical Engineering, University of Nairobi, Nairobi, Kenya

Date of Submission11-Jul-2019
Date of Acceptance27-Sep-2019
Date of Web Publication30-Dec-2019

Correspondence Address:
Dr. Mohanad Abdulhamid
Department of Electrical Engineering, AL.Hikma University, Baghdad
Iraq
Login to access the Email id

Source of Support: None, Conflict of Interest: None


DOI: 10.4103/ijas.ijas_15_19

Rights and Permissions
  Abstract 


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

How to cite this URL:
Abdulhamid M, Elijah W. On triage system. Imam J Appl Sci [serial online] 2020 [cited 2020 Jun 1];5:22-32. Available from: http://www.e-ijas.org/text.asp?2020/5/1/22/274292




  Introduction Top


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 Top


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].
Figure 1: Architectural design of triage system

Click here to view


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.
Figure 2: Hardware architecture – sensor unit

Click here to view


The sensor unit contains:

  1. Microcontroller: Processing readings from the sensors and major control function of the unit
  2. A power supply: Provide the microcontroller with power
  3. Temperate sensor: Output voltage value to the microcontroller that vary with temperature
  4. Heart rate sensor: Causes an interrupt to the microcontroller if a heartbeat is detected
  5. Radiofrequency wireless link module: Send data wirelessly to the controller unit
  6. Audio jack-AUX (weighing scale): Provide an interface for connecting a weighing scale
  7. 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:
Figure 3: Hardware architecture – controller unit

Click here to view


  1. Raspberry Pi: Minicomputer performs all the systems software functions
  2. User input devices: Keyboard and mouse to allow the user to control the Raspberry Pi
  3. SD card: Memory for the minicomputer, used to store the minicomputers operating system and system's local database
  4. RF link module: Receive sent data by the sensor unit
  5. 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].
Figure 4: Sensor unit flow diagram

Click here to view
Figure 5: Controller unit flow diagram

Click here to view


Circuit design

Sensor unit circuitry

The design of sensor unit circuitry is shown in [Figure 6].
Figure 6: Sensor unit circuitry

Click here to view


Main controller unit circuitry

The design of controller unit circuitry is shown in [Figure 7].
Figure 7: Main controller unit circuitry

Click here to view


Weighing scale circuitry

The design of weighing scale circuitry is shown in [Figure 8].
Figure 8: Weighing scale circuitry

Click here to view


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.
Figure 9: Sensor unit circuit image 1

Click here to view
Figure 10: Sensor unit circuit image 2

Click here to view


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].
Figure 11: Main controller unit circuit image

Click here to view


Software

The system's software part is divided into two sections, where each section is programmed with different programming languages. The two sections are:

  1. Sensor unit software
  2. 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:

  1. User table: Contains all users saved in the database, for mode 2
  2. Patient link: Saves all links created between patient and sensor unit in mode 2
  3. ED patient data: Stores all vital reading of a linked patient (Connected to a sensor unit)
  4. Emergency sensor data: Stores all vital readings of casualties with sensor units
  5. Doctors comments: Stores comments from doctors for each patient.



  Results Top


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].
Figure 12: Raspberry Pi desktop

Click here to view


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].
Figure 13: Chromium web browser

Click here to view


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.
Figure 14: Home page

Click here to view


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.
Figure 15: Mode 1 page

Click here to view


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.
Figure 16: Mode 2 page

Click here to view


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].
Figure 17: Patient details

Click here to view


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].
Figure 18: Patient database/register patient

Click here to view


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].
Figure 19: Patient table

Click here to view


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.
Figure 20: Form validation feature

Click here to view


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:
Figure 21: System tables – SQLite browser

Click here to view


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].
Figure 22: SQLite patient table

Click here to view


Emergency sensor data table

This table is shown in [Figure 23].
Figure 23: SQLite emergency sensor data table

Click here to view


ED patient data table

This table is shown in [Figure 24].
Figure 24: SQLite emergency department patient sensor data table

Click here to view



  Conclusion Top


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 Top

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.  Back to cited text no. 1
    
2.
Sakanushi K, Hieda T. Electronic triage system for continuously monitoring casualties at disaster scenes. J Ambient Intell Humanized Computing 2013;4:547-58.  Back to cited text no. 2
    
3.
Cuttance G, Dansie K, Rayner T. Paramedic application of a triage sieve: A paper-based exercise. Prehosp Disaster Med 2017;32:3-13.  Back to cited text no. 3
    
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.  Back to cited text no. 4
  [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.  Back to cited text no. 5
    


    Figures

  [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]



 

Top
 
 
  Search
 
Similar in PUBMED
   Search Pubmed for
   Search in Google Scholar for
 Related articles
Access Statistics
Email Alert *
Add to My List *
* Registration required (free)

 
  In this article
Abstract
Introduction
Design and Imple...
Results
Conclusion
References
Article Figures

 Article Access Statistics
    Viewed874    
    Printed71    
    Emailed0    
    PDF Downloaded109    
    Comments [Add]    

Recommend this journal


[TAG2]
[TAG3]
[TAG4]