Caladrius

Inspiration

Every year, more than 150 million people enter U.S. emergency departments (National Center for Health Statistics, 2025), and each of these patients must go through triage. Triage is the process of conducting a preliminary assessment of a patient’s condition to determine the urgency and nature of their treatment. To do so, nurses must quickly assess symptoms, vitals, and medical history, and a single error can be the difference between a life saved and a life lost.

Despite this, recent research shows nearly “a third of triage decisions are erroneous,” and that, “quality assurance measures currently in place to correct triage practice errors may be insufficient” (Kingswell, Calleja, & Sahay, 2025). This can lead to delayed treatment, wasted resources, and overlooked emergencies that could be fatal.

Our conversations with medical practitioners, students, and EMTs (emergency medical technicians) along with analysis of published literature guided us to two main factors causing these errors that can be improved: limited access to patient history in emergency situations and inefficiencies in existing triaging systems.

Caladrius closes this gap.

• To address the first factor, we’ve devised a privacy-first, portable medical passport, allowing patients to truly own their medical files, having them easily accessible wherever they go.
• To address the second factor, we’ve designed an assistance model to ease triage workload and increase triage accuracy.

What it does

Caladrius is a privacy-first, HIPAA compliant AI triage assistant. It is both a portable medical history storage system and AI-powered medical assistance system designed to help healthcare providers during the triaging process. Patients are able to store their full medical history (allergies, prescriptions, surgeries, insurance, prior hospitalizations, etc.) on their own device in a sort of “Medical Passport,”rather than some vendor controlled central system such as Epic Systems. This:

1. Reduces aggregation of data in a centralized server space, reducing the risk of a singular critical bug exposing thousands—if not hundreds of thousands—of identifiable protected healthcare information (PHI)
2. Allows for patients to see their medical records easily and for zero monetary cost
3. Enables emergency medical services (EMS) and hospitals/healthcare providers outside of a patient's typical environment to quickly and easily view patient information, significantly decreasing file transfer times and potentially saving lives.

The second part of Caladrius is the triaging assistance system. When a patient arrives, a triage nurse/HCP generates a short lived QR code. The patient scans the code, consents to sharing the data within their Medical Passport, then sends it to the healthcare provider’s client. Patient data never persists on any third party systems and is end-to-end encrypted to eliminate the risk of interception.

Once the health care provider’s client gains the data, we analyze it to dynamically generate targeted questions and ask these to patients. After the patient answers these questions, we consciously determine which new questions to ask in order to further a diagnosis. This continues for a finite number of questions and potential diagnoses are ranked with a confidence score and metrics supporting that score. Finally, the model generates an estimated priority ranking of treating the patient which the nurse/HCP can rearrange in real time.

Caladrius has a strong emphasis on patient data privacy. No patient data is stored within internal triaging systems for longer than necessary; immediately after patients are treated from the priority queue, their data is wiped.

How we built it

Caladrius is divided into three main ideological components:

1. The Patient Medical Passport: Stores health data locally with patients, giving them control and speeding up inter-health-system document transfer

2. Optimizing Triage Patient Processing: A localized, off-cloud LLM process that scores triage processes and suggests follow-up questions.

3. Healthcare Provider (HCP) Assistance: Helps HCPs effectively decide the order in which triage patient processing takes place

Due to time constraints, rather than a robust encryption scheme we decided to store a rotating identifier within the QR code that changes every 60 seconds and directs the patient client toward a unique, short-lasting S3 bucket to temporarily cache data. While this isn’t as effective as our initially desired AES-256-GCM scheme, it prevents malicious actors from exploiting old identifiers and limits the exposure window to an intercepted identifier.

The overall pipeline is as follows:

We can decompose the whole process down into essentially 5 separate chunks:

1. Flashing the Medical Passport with new information from electronic medical records (EMR) within the healthcare system the patient is currently receiving care from, and (potentially post-visit) labs/x-rays, etc.
   • In other words, we are updating the patient’s Medical Passport from
2. Transferring patient information from the Medical Passport to the Internal Triage System
   • A core tenet of our design principle is adhering to the Principle of Least Exposure (PoLE). In our implementation, there is only one open endpoint in the entire system, the S3 Bucket:
     • The Internal Triage System will only read from the S3 Bucket if the patient’s medical passport sends a POST request with the session ID (SID) corresponding to the QR code that is generated every minute.
     • Additionally, the Medical Passport has exclusively write access to the S3 Bucket, whereas the Internal Triage System has exclusively read/delete access. This eliminates sources of potential data interception and malicious data embedding, protecting patient privacy.
3. Continuously prompting our Localized LLM with context from the triage system and external input
   • It is essential to realize that we are implementing only LOCALIZED LLMs which inherently are impossible to access from an outside source such as the internet or a third party—even us as owners are unable to see within the LLM and data it is handling.
   • To further break down this process, we have created another diagram to represent the internal model loop. Per our current implementation, we are using LangGraph with two agents to create new agents.
   • Our initial patient questions are generated by the LLM based on collected vitals during triaging, past patient records, and current symptoms
   • Future questions draw from past inferences and patient replies to questions. These replies can be short answer, multiple choice, yes/no/not sure/no answer; the idea is continual prompting for fast, extensive diagnosis
   • Once we reach our desired number of questions, the question agent exerts the EndOfLoop signal and passes the Patient Medical Record to the Final Diagnosis Agent (FDA). The FDA then outputs the Final Differential Diagnosis as a structured .json file which may be pushed to the HCP system. In our case, we are implementing a MongoDB as a proof-of-concept NoSQL database in place of a real HCP system. Of course, in practice, we would work within the local HCP system. A sample structure of the Final Differential Diagnosis is provided after bullet 5.
4. Sending our differential diagnosis list to the healthcare provider system once patient questioning finishes and pushing this data to nurses
   • Patient differential diagnoses are ranked in a priority queue by confidence scores estimated based on context and reasoning when presented to nurses. Nurses or authorized healthcare providers can view this information extensively through the interface, and, separately, are freely able to re-order patients within the priority queue based on their medical expertise.
5. Using nurse input and this differential diagnosis to prep doctor consultants on necessary labs, tests, etc.
   • Our adherence to PoLE allows us to minimize unnecessary exposure throughout the system. As mentioned earlier, by implementing a closed system with only one (encrypted and secure) open endpoint we eliminate unsafe external access. Furthermore, we only send the personal medical passport at the beginning of the system, and afterwards, delete it. At the end of a visit, a doctor can write to the passport; future revisions of our system may have the doctor reading the passport again, but this would be only if extremely necessary. This ensures that we, again, adhere strictly to the PoLE.

Sample Differential Diagnosis .json output:

{
  "_id": {
    "$oid": "68d88979d50f1f3be06d2ed0"
  },
  "name": "Jane Doe",
  "age": {
    "$numberInt": "47"
  },
  "symptoms": "Severe chest pain radiating to the left arm, shortness of breath, sweating",
  "differential_diagnosis": [
    {
      "rank": {
        "$numberInt": "1"
      },
      "diagnosis": "Acute Myocardial Infarction",
      "probability_percent": {
        "$numberInt": "70"
      },
      "reasoning": "Classic presentation with chest pain, radiation, and autonomic symptoms",
      "key_features": [
        "Severe chest pain",
        "Left arm radiation",
        "Diaphoresis",
        "Shortness of breath"
      ],
      "next_steps": [
        "ECG",
        "Cardiac enzymes",
        "Immediate cardiology consult"
      ]
    },
  "clinical_summary": "47-year-old female presenting with acute chest pain and associated symptoms most consistent with myocardial infarction. Pulmonary embolism and GERD are less likely but remain considerations.",
  "urgency_level": {
    "$numberInt": "1"
  },
  "urgency_level_text": "Emergency",
  "disclaimer": "This output is for informational purposes only and is not a substitute for professional medical advice, diagnosis, or treatment.",
  "priority_order": {
    "$numberInt": "1"
  }
}

Challenges we ran into

• One of the biggest challenges our team faced in our ideation phase was determining the right balance between the convenience of a medical passport and security of protected health information. Initially, we wanted to rely on NFC chips for proximity-based transfers in emergency situations. Our idea was to use these chips so that we could transfer data even if patients were unconscious, unresponsive, or impaired.
  • Unfortunately, we quickly ran into the issue of NFC “flippers” that can lift data off of NFC tags. This means our implementation of a “secure” personal storage was exceedingly vulnerable to attacks; as such, this approach turned out to be counterintuitive. Another point that we came across is that NFC tags cannot store large amounts of data. Most commercially available NFC tags can only store around 4-8kb of data, which for large items such as MRIs becomes unfeasible as a solution.
• Another challenge we encountered surrounding the issue of security of PHI and PoLE was implementing Local Models. In our development process, we wanted to use Google Cloud’s VertexAI’s medgemma model to run the LLM processing loop. This would show how, in our MVP, PHI was not submitted to external systems. However, we did not have API credits or monetary value on hand in order to use these services for our purposes. None of our team has a computationally powerful machine or dedicated server, so running a local open source model was not feasible, even though an on-prem solution at a major hospital would be the default.
  • Thus, after many hours of exploring other options, we ended up using OpenAI’s gpt5 model for our implementation.
  • In the future, it is imperative that we implement all model running and PHI processing within a model local to the current HCP system.
• The last issue that we wanted to touch on was solving the issue of PHI exposure to external systems. This issue builds off of the other two issues we faced. During the process of determining how to move patient data from their “Medical Passport” to the Internal Triaging System. This introduced the additional challenge of sharing encryption keys safely and efficiently.
  • An asymmetric scheme like RSA seemed promising, but was too slow for larger files and thus would reduce efficiency. As a result, we finally decided on our AES-256-GCM scheme, where we share the key via a QR code and change it every 60 seconds. Unfortunately, due to the complexities associated with unit testing across platforms, we decided to focus our time on developing other features, and opted to just use the rotating Session ID detailed in “How we built it.”

Accomplishments that we're proud of

• We are proud of our flexibility in requirements engineering. As a specific example, we had a brief conversation with a sponsor software engineer through which we realized that our original plan—gearing the app toward emergency services through NFC chip data transfers—posed large security risks, as touched on before. After realizing this, we were able to change our application’s focus within the hour, restructuring our data flow and beginning development on schedule.
• We are also happy with our effective division of labor. At each step of our iterative development process, we tried to minimize dependencies between tasks, so we very rarely had to wait on one team member's code and were able to develop independently and efficiently before consolidating our work. Everyone was contributing effectively and efficiently.

What we learned

• This was our first time building a React Native application from the ground up so it gave us valuable experience with cross-platform development.
• Due to the nature of this application, we had to carefully consider healthcare throughout development, and design our data flows around this. As a result, we learned a lot about software development while staying in line with HIPAA requirements, and other regulatory requirements.
• We worked a lot with cloud services like Google Cloud and AWS during our development period, and attempting to integrate and pivot away from Vertex AI was a steep and difficult learning curve
• We worked with LangGraph agents, especially through the rarely-used user interrupt functionality, which engages with the LLM mid chain-of-reasoning. This was a powerful tool that served us well with our agentic system.

What's next for Caladrius

• One of the major components that we initially intended to implement alongside Caladrius was a patient-doctor interface. In essence, this would be a similar system to the triage system. The data flow would be as follows:
  • The output of the current triaging system would be provided to doctors for an initial lookover of patient symptoms and potential diagnosis.
  • Once the patient and doctor were sitting face to face, our model would transcribe the patient-doctor interaction in real time and feed it to a LangGraph interface that would use both the patient’s medical history and the triaging system output to make real time suggestions to doctors to further medical diagnosis. In the future, we would like to implement this system, especially since we have most of the components built already; working speech-to-text interfacing using AWS’s Amazon Transcribe Medical API is located in our GitHub’s awstranscription branch, along with some sample transcripts.
• Additionally, our model selection and implementation could see great improvements, especially since there exist specialized inference models for many medical records such as MRIs, CT scans, X-Rays, etc., that test for specific diseases. Integrating these into our pipeline would increase the efficacy of our differential diagnosis output.
• Another idea our team had was to interact with the inventory hospital systems in order to perform a more extensive analysis of patient urgency ranking and ultimately improve the accuracy of the ranking Caladrius provides to triage systems. Since this opens up a whole other region of data analysis and inferencing, this addition has the potential to improve our system by magnitudes and is definitely something we want to look into implementing in the future.

As a whole, Caladrius has the potential to reduce errors that take place during triage, shorten wait times, and assist medical practitioners, all while giving patients ownership of their own data. Through Caladrius, we aim to make emergency care safer—and smarter.

Built With

• agenticai
• amazon-web-services
• css3
• express.js
• fastapi
• javascript
• langgraph
• mongodb
• next.js
• openai
• python
• react
• tailwindcss
• typescript