TriTag

A modern, digital approach to Triage.

Comment

Inspiration

Members of our team either are a part of or know members of the EMS system, and are well aware of the lack of research and development in prehospital care, especially compared to advancements in the hospital setting. In particular, we found that the current system of triage tagging had significant drawbacks that could be improved with new digital technologies. We sought to overhaul the system to not only better sort patients based on triage needs, but to also standardize the process of triaging to remove potential biases and improve patient tracking during mass-casualty incidents (MCIs). By pursuing such a goal, we hoped to not only develop a new product for the market, but also to increase EMS efficiency and, as a result, improve patient quality, safety, and care.

What it does

TriTag is an efficient patient marker and tracking system for patients in Emergency and Mass Casualty events. It consists of three steps: 1) Initial assessment and assignment of severity and hash code, 2) HIPAA - compliant cloud database of important medical data for remote retrieval, and 3) ambulatory tracking of patients through cloud database. When EMT's arrive at a mass casualty incident (MCI), they assess each patient twice, but each assessment is based on subjective assessment of symptoms. The severity equation takes the questioning out of patient organization. By inputting Simple Triage and Rapid Triage (START) vitals (heart rate, respiratory rate, and capillary refill), age range, and primary impression. There is a deterministic number that identifies the patient’s condition, and the associated tagging color. Each patient also gets assigned a trauma name that develops a unique hash code that gets printed out as a barcode for fast patient identification and easy trackability. These hash codes, which are connected to the patient’s data, are sent to a secure cloud which can only be accessed by EMT’s and medical professionals, and follow HIPAA laws in regards to encryption/authentication. After the patient has been tagged and placed in an ambulance, the tag is updated when scanned by the EMT stationed at the ambulance, sending information to the cloud for the specific code and updated with time-stamped data. When the patient is received at the hospital, not only is the hash again updated, but the receiving medical professionals have data about the patient before they even walk in based off the cloud data. Constant updates on vitals and symptoms from first impression to hospital arrival paint an accurate picture of the patient’s condition to better patient care by streamlining data collection and retrieval.

How we built it

The system consists of three technologies: the tablet app where the first information is uploaded, the hardware ID tag, and the cloud back-end software.

The iPad app was developed using the React Native framework which makes it easy to add Android support in the future while using most of the existing codebase. The data is stored in a Google Firebase server in the human-readable JSON format which makes it easy to update and access at any time.

The ID tag is similar to the normal tags used today, but will have a severity index, as well as the key vital signs that contributed to that decision. The barcode will also be present to ensure proper tracking and identification. There is also a possibility of integrating these into reusable data storage devices for local storage of data, as well as the use of RFID tags for identification as well. For the model, we made a 3D printed case and arduino board connected to multiple buttons. The display shows the color of the patient based off of their severity, as well as patient ID and ambulance identifier for tracking

The cloud software is where all the patient data is stored. The tablet and medical professional receiver devices with have sign-in authentication to allow for rapid retrieval of medical information. Eventual linking of the medical data to an MRN allows for good documentation of an event, as well as safe storage of data to comply with the 7 year mandatory storage.

Challenges we ran into

There was a lot of miscommunication as to the exact nature of the project. For example, half the team though we were aiming for electronic tagging while the other half believed we were sticking with an updated form of the traditional paper tagging. These misunderstandings slowed down our hacking, but once everyone was on the same page, we caught up relatively quickly. Another obstacle was the software heavy aspect of our project. Our team consists of all sophomore undergraduates, and only two team members have a decent understanding of coding. The “language barrier” proved to be a major setback because of the difference between what we have done for this project and what it could be. For example, the QualComm DragonBoard has WiFI connectivity for an IoT application. Our project, with the need for receiver units to be connected to the cloud, would be a perfect application of IoT or BlueTooth connectivity, but we just did not have enough experience to pursue a project with that large of a Wow-Factor.

Accomplishments that we're proud of

We completed the base functionality of our project, which included an app interface for EMT’s, a cloud for data storage, and a model of an identifier that would be used in the field. Each aspect of the project pushed the limits of what we already knew about medicine and computer science, and everyone learned something new. The model of the identifier was made with Arduino, and coded by someone who never touched code before. We interviewed many different EMS providers to find out how this new system would be best implemented, and modified our final product to fit what they felt was needed in emergency medicine.

What we learned

We learned that there is a lot to consider when making something new for EMS providers. Considerations needed to be made for not only the EMTs on the ground, but the entire Incident Command Chain, the receiving hospitals, and the patients themselves. Furthermore, we learned that prehospital innovation is often hampered by field protocols, as well as added training and maintenance costs new technologies often come associated with. However, we also learned how to adapt other systems in healthcare to create a proto-patient tracking system for MCIs, as well as taking the first step to create a standard algorithm for patient sorting during rapid triage. On the CS end, we were able to develop a hash-code generator that could create a unique, HIPAA compliant identifier for each triage patient in the field, vastly improving upon current methods of on-field patient data collection.

What's next for TriTag

Currently, TriTag was built as a standalone system with its record-keeping database using Virginia as a model. In the future, we hope to integrate TriTag to feed directly into standardized EMS databases rather than our own database, to provide real time updates. After integration into EMS databases, TriTag can expand to integrate into hospital systems and work with transferring data to hospital care providers and the MRN system. For the physical tagging system, we hope to be able to tag patients with a device that can also change colors to reclassify their condition during re-triaging. Furthermore, our system operates heavily on access to the cloud and bluetooth. TriTag would also be exploring alternative tagging methods and fixes for triage in dead-zones.

Share this project:

Updates