RUNSHEET

1. Introduction

RUNSHEET is a web-based educational platform designed for EMT and paramedic students. The application combines several different learning and decision-support features into a single interface, including patient assessment, symptom-to-impression matching, ECG rhythm recognition, medication reference information, and an AI-powered copilot.

The website describes itself as a study tool rather than a clinical protocol. It emphasizes that its recommendations are based on general EMS reference material and that users should follow their local protocols, treatment guidelines, and medical direction.

This study examines the publicly observable functionality of RUNSHEET and proposes how the system could have been architected and implemented. Because the application's private source code, database, deployment configuration, and development history are not publicly available, implementation details that cannot be directly observed are identified as likely architectural approaches rather than confirmed facts.

2. Purpose of the Application

The primary objective of RUNSHEET appears to be providing EMS students with an interactive environment for practicing patient assessment and reviewing common emergency-care concepts.

Instead of presenting information as a traditional static reference manual, the application allows the user to construct a patient scenario.

The main workflow can be summarized as:

Patient information → Clinical findings → Vitals/ECG → Assessment → Ranked impressions → Educational treatment reference

The homepage describes the central assessment feature as allowing users to enter vital signs and select signs, symptoms, and risk factors. The system then ranks conditions that best match the selected findings and displays associated field-treatment information, oxygen targets, and medication doses.

This makes the application more interactive than a conventional medical reference website.

3. Major Components

The public interface exposes several major components.

3.1 Patient Assessment

The Patient section allows users to enter clinical findings and vital signs.

The application indicates that vital signs are optional and that abnormal values can automatically be added as findings. This suggests that the application contains a rule-based preprocessing layer that interprets numerical inputs before running the assessment.

For example, conceptually:

User enters vital signs

↓

Validate input

↓

Identify abnormal values

↓

Convert abnormalities into findings

↓

Combine with selected symptoms

↓

Calculate condition matches

↓

Rank possible impressions

This is an important design decision because it allows the user to provide information in numerical form while the assessment engine works with higher-level clinical findings.

4. Symptom-to-Impression Engine

One of the most important components appears to be the Symptom → Impression engine.

The user selects signs, symptoms, and risk factors. The application then determines which conditions are most compatible with those findings.

A likely implementation would represent each condition as a collection of associated findings.

For example, a simplified internal structure could look conceptually like:

Condition A

finding_1

finding_2

finding_3

Condition B

finding_2

finding_4

finding_5

When a user selects findings, the application can compare the patient's findings against the condition definitions.

A simple scoring approach could be:

score =

number of matching findings

/ number of relevant findings

The conditions could then be sorted from the highest score to the lowest score.

This would allow RUNSHEET to produce a ranked differential-style educational result without requiring a complex machine-learning model.

The website describes the results as conditions that "best match" the information entered, which is consistent with a matching or scoring architecture.

5. Full Scenario Builder

RUNSHEET also provides a more comprehensive Full Scenario workflow.

The public interface states that users can enter:

• Demographics
• Chief complaint findings
• Vital signs
• ECG information

The system then combines the information and produces a ranked impression with field-treatment information.

A conceptual architecture would therefore be:

┌─────────────────┐

│ Patient Profile │

└────────┬────────┘

│

▼

┌──────────────┐ ┌───────────────┐

│ Chief │──►│ Assessment │

│ Complaint │ │ Engine │

└──────────────┘ └───────┬───────┘

│

┌──────────────┐ │

│ Vital Signs │───────────┤

└──────────────┘ │

▼

┌──────────────┐ ┌──────────────┐

│ ECG Reading │───►│ Ranked │

└──────────────┘ │ Impressions │

└──────┬───────┘

│

▼

Treatment Reference

This architecture allows information from multiple parts of a patient presentation to be considered together.

6. Vital Sign Processing

The application supports several common vital-sign measurements.

The public interface exposes heart rate and SpO₂ information and indicates that abnormal vital signs can automatically become assessment findings.

A likely implementation uses predefined ranges or thresholds.

For example, conceptually:

if heart_rate < lower_limit:

findings.append("bradycardia")

if heart_rate > upper_limit:

findings.append("tachycardia")

if spo2 < oxygen_threshold:

findings.append("low oxygen saturation")

The resulting findings can then be passed to the same assessment engine used for manually selected symptoms.

This design avoids having two separate assessment systems.

7. ECG Rhythm Recognition

Another major feature is the cardiac rhythm reference.

The website provides a Cardiac Monitor & Rhythm Reference section containing a live monitor-style interface and a rhythm library. Users can select a rhythm and view a corresponding monitor trace along with associated vital signs.

The site specifically explains that the rhythm strips are stylized for pattern recognition and are not calibrated clinical tracings.

This suggests that the ECG component was designed primarily as an educational visualization rather than as an actual ECG analysis system.

A likely implementation would use predefined rhythm objects containing information such as:

Rhythm

├── Name

├── Heart rate

├── SpO₂

├── ECG pattern

├── Clinical description

└── Treatment reference

The front end can then render the selected rhythm dynamically.

8. ECG Visualization

The live monitor is likely implemented using browser-based graphics rather than displaying a collection of static images.

A web application could generate an ECG-like waveform using:

• HTML Canvas
• SVG
• CSS animation
• JavaScript rendering

A simplified conceptual process would be:

Selected rhythm

↓

Rhythm configuration

↓

Waveform parameters

↓

JavaScript rendering

↓

Animated monitor display

Different rhythm configurations could produce different waveform shapes.

For an educational application, this approach has the advantage of allowing the same visualization component to display many rhythms without requiring a separate image for every scenario.

9. Medication Reference System

RUNSHEET also contains a medication dosage guide.

The site describes this section as a reference containing common adult emergency doses and provides search/filter functionality.

A likely implementation would store medication information in a structured data source.

For example:

Medication

├── Name

├── Category

├── Adult dose

├── Route

├── Indications

├── Contraindications

└── Notes

The user interface can then filter the dataset when a medication name or category is entered.

The site explicitly warns that the displayed doses are common adult reference ranges and that pediatric dosing, contraindications, routes, and maximum doses can vary.

This is particularly important because medication information is safety-critical.

10. AI Copilot

RUNSHEET includes a Paramedic AI Copilot.

The public page indicates that the copilot provides decision-support answers using the same knowledge base referenced throughout the site.

Interestingly, the publicly visible page embeds the AI component separately rather than displaying the entire AI interface as native page content. The page contains an iframe pointing to a Streamlit application.

This suggests an architecture similar to:

RUNSHEET Website

│

│ iframe

▼

AI Copilot Application

│

▼

Knowledge Base / AI System

Using an iframe allows the main website and AI application to be developed and deployed separately.

The visible page also identifies the AI component as a demonstration copilot and emphasizes that it is not a replacement for training, protocols, or medical direction.

11. Front-End Architecture

Based on the publicly observable interface, RUNSHEET appears to use a modern single-page web application approach.

The interface contains multiple interactive sections:

• Patient assessment
• Full scenario
• Rhythm recognition
• Medication search
• AI Copilot

The page dynamically updates controls and results rather than requiring a separate page for every individual clinical condition.

A likely front-end architecture could therefore consist of reusable components such as:

App

├── Navigation

├── PatientAssessment

│ ├── VitalInputs

│ ├── FindingSelector

│ └── AssessmentResults

├── ScenarioBuilder

├── RhythmReference

│ ├── Monitor

│ └── RhythmLibrary

├── MedicationGuide

└── AICopilot

This component-based architecture would make it easier to maintain and extend the application.

12. Data Architecture

The application requires structured clinical knowledge rather than relying entirely on free-form text.

The knowledge base likely contains relationships between:

Symptoms

↓

Conditions

↓

Treatment References

↓

Medications

For example:

Finding

│

├── Condition A

│ ├── Treatment

│ └── Medication

│

└── Condition B

├── Treatment

└── Medication

This structure allows the same underlying information to be reused by several features.

For example, the assessment engine can use condition data while the AI Copilot can use the same knowledge base to answer educational questions.

The website explicitly states that the AI Copilot uses the same knowledge base referenced throughout the site.

13. Likely Technology Stack

The exact private technology stack cannot be established from the public interface alone. However, some components can be identified directly.

The AI Copilot is embedded from a Streamlit application, indicating that at least that component uses Streamlit.

A plausible overall architecture is therefore:

Layer	Likely Technology/Approach
Main website	Modern HTML/CSS/JavaScript web application
Interactive UI	JavaScript-based components
Clinical knowledge	Structured JSON/database
Assessment engine	Rule-based scoring/matching
ECG visualization	Browser-based graphics/animation
Medication search	Structured searchable dataset
AI Copilot	Python/Streamlit application
AI knowledge	Shared/reference knowledge base
Hosting	Web hosting + separate AI application hosting

The items described as "likely" cannot be confirmed without access to the project's source code or deployment configuration.

14. Why a Rule-Based System Makes Sense

A particularly important architectural observation is that the core patient assessment does not necessarily need machine learning.

For an educational EMS application, a transparent rule-based system has several advantages.

A rule can be inspected:

If finding X is present,

increase the score for condition Y.

This is much easier to explain than an opaque prediction.

It also allows the developer to control exactly which findings are associated with each educational impression.

A simple scoring system could therefore be sufficient:

score = 0

for finding in patient_findings:

if finding in condition_findings:

score += condition_findings[finding]

The conditions can then be ranked according to their scores.

This approach also makes it easier to update educational content when reference material changes.

15. User Experience Design

The application appears to have been designed around the workflow of an EMS student.

Rather than presenting hundreds of pages of reference information, the application organizes information around tasks:

Assess → Interpret → Review → Learn

The user can start with symptoms, build an entire patient scenario, practice rhythm recognition, search medications, or ask the AI Copilot a question.

This modular design makes the website useful as both a reference tool and a study environment.

The homepage also repeatedly labels the system as a study tool rather than a protocol, which establishes an important boundary between educational software and clinical decision-making.

16. Safety Considerations

Because the application deals with medical information, safety is a central part of its design.

The website repeatedly warns users that the information should not replace:

• Training
• Certification standards
• Local protocols
• Medical direction
• Professional clinical judgment

The medication section also specifically warns users to confirm doses against their agency's protocols before administering medication.

This type of disclaimer is particularly important when an application provides medication doses or treatment recommendations.

The application should therefore be understood as an educational reference rather than a medical device or autonomous clinical decision-making system.

17. Proposed Development Process

A project similar to RUNSHEET could be developed in the following stages.

Stage 1 — Requirements

Identify the target audience and define the major features:

• Patient assessment
• Scenario builder
• ECG library
• Medication reference
• AI Copilot

Stage 2 — Knowledge Base

Create structured datasets for:

• Clinical findings
• Conditions
• Treatments
• Medications
• ECG rhythms

Stage 3 — Assessment Engine

Implement the symptom-to-impression matching system and scoring logic.

Stage 4 — Front-End

Build the interactive user interface and connect the controls to the assessment engine.

Stage 5 — ECG Visualization

Create reusable waveform/monitor components for the rhythm library.

Stage 6 — Medication Search

Implement searchable and filterable medication information.

Stage 7 — AI Integration

Develop the AI Copilot separately and connect it to the site's reference knowledge.

The publicly visible Streamlit iframe suggests that the AI component can be deployed independently from the main website.

Stage 8 — Testing

Test:

• Input validation
• Assessment results
• Ranking behavior
• ECG rendering
• Medication searches
• AI responses
• Mobile responsiveness
• Safety messaging

Stage 9 — Deployment

Deploy the main website and AI application and connect the components through the web interface.

18. Example System Architecture

The overall system can be represented as:

RUNSHEET

│

┌──────────────┼──────────────┐

│ │ │

▼ ▼ ▼

Patient Tool Rhythm Tool Medication Tool

│ │ │

▼ ▼ ▼

Assessment Rhythm DB Medication DB

Engine │ │

│ │ │

└───────────────┼──────────────┘

│

▼

Shared Knowledge

│

▼

AI Copilot

│

▼

Educational Response

This architecture separates the major responsibilities while allowing them to share a common clinical knowledge base.

19. Strengths of the Design

Several aspects of the observed design are particularly effective.

Interactive learning

Users actively construct scenarios instead of simply reading information.

Modular architecture

Assessment, ECG, medications, and AI are separate functional areas.

Reusable knowledge

The same clinical information can support multiple features.

Visual learning

The ECG monitor provides a visual way to practice rhythm recognition.

Clear safety boundaries

The application repeatedly explains that it is a study tool and not a replacement for protocols or medical direction.

AI integration

The AI Copilot provides a conversational interface for exploring the same educational knowledge base.

20. Limitations of This Study

This study is based on publicly observable behavior and content from RUNSHEET.

The private source code, database schema, version-control history, backend implementation, AI model configuration, hosting infrastructure, and developer documentation were not available for inspection.

Consequently, statements about specific frameworks or algorithms beyond what can be directly observed should be considered proposed or likely implementations rather than confirmed facts.

The publicly visible site does, however, provide enough information to identify the major functional architecture and to develop a reasonable technical model of how the application could have been constructed.

21. Conclusion

RUNSHEET demonstrates how an EMS educational application can combine structured clinical knowledge, interactive assessment, visualization, searchable references, and artificial intelligence into one web-based platform.

Its core architecture can be understood as several interconnected components: a patient assessment engine, a scenario builder, an ECG rhythm visualization system, a medication reference database, and an independently embedded AI Copilot.

The assessment functionality appears well suited to a rule-based matching architecture, while the ECG system can use predefined rhythm data and browser-based visualization. The medication guide can operate from a structured searchable dataset, and the AI Copilot can be deployed as a separate application connected to the site's educational knowledge.

The result is a system that transforms a conventional EMS reference guide into an interactive learning environment.

Most importantly, RUNSHEET illustrates that an effective medical education application does not necessarily require a complex machine-learning model at its core. A carefully structured knowledge base, transparent rules, intuitive user interface, and appropriately bounded AI system can together provide a powerful educational experience.

Source examined: RUNSHEET — EMS Field Reference, publicly available at runsheet.website. The site identifies itself as an EMS study tool and states that its information should be verified against local protocols and medical direction.

Abstract

Background

Clinical decision-support systems and artificial intelligence (AI)-assisted tools are increasingly being evaluated for their ability to recognize clinical presentations and generate appropriate treatment recommendations. Accurate identification of emergency medical conditions is particularly important because errors in recognition or treatment recommendations may have significant consequences.

Objective

This study evaluated the accuracy of an AI-assisted clinical decision-support software system in identifying appropriate medical treatments across a standardized set of emergency and medical scenarios.

Methods

A benchmark consisting of 50 clinical questions was developed across eight medical conditions representing respiratory, cardiovascular, allergic, gastrointestinal, and abdominal presentations. The conditions evaluated were bronchospasm/asthma, spontaneous pneumothorax, respiratory failure, impending cardiac arrest, severe allergic reaction/anaphylaxis, appendicitis, gastrointestinal bleeding, and gallstones/cholecystitis. Five questions were evaluated for each condition. The software's responses were graded for medical treatment accuracy.

Results

The software achieved a treatment accuracy of 100% across all 50 questions. No treatment recommendation was graded as incorrect in the evaluated benchmark. The system therefore achieved a 50/50 correct treatment-recommendation score, corresponding to an observed accuracy of 100%.

Conclusion

Within the conditions and questions included in this benchmark, the evaluated software demonstrated complete agreement with the predetermined treatment-answer criteria. These findings support further investigation of the system as a potential clinical decision-support tool. However, the results represent performance on a limited 50-question benchmark and should not be interpreted as evidence of clinical safety, efficacy, or readiness for independent use in patient care. Larger, independently developed, clinically representative, and prospectively validated studies are required.

1. Introduction

Artificial intelligence and computer-assisted clinical decision-support systems have the potential to assist healthcare professionals in recognizing medical conditions and selecting appropriate interventions. In emergency and prehospital medicine, rapid recognition of clinical patterns and appropriate treatment selection are particularly important because clinical deterioration may occur rapidly.

Respiratory emergencies such as asthma/bronchospasm, spontaneous pneumothorax, and respiratory failure require recognition of characteristic clinical findings and prompt selection of appropriate interventions. Similarly, cardiovascular emergencies, anaphylaxis, gastrointestinal hemorrhage, appendicitis, and biliary disease require clinicians to distinguish potentially serious presentations and determine appropriate management.

Despite increasing interest in AI-assisted medical decision support, demonstrating performance requires systematic evaluation against predefined clinical criteria. A system that performs well on a controlled benchmark may still perform differently when confronted with more complex patients, incomplete information, atypical presentations, comorbidities, medication interactions, or situations outside the benchmark.

The present study was designed as an initial benchmark evaluation of treatment recommendation accuracy. The objective was to determine whether the evaluated software could provide medically appropriate treatment recommendations across a predefined set of 50 clinical questions.

The primary outcome was the proportion of questions for which the software's treatment recommendation was graded as medically accurate according to the predetermined evaluation criteria.

2. Materials and Methods

2.1 Study Design

This investigation was conducted as a structured benchmark evaluation of an AI-assisted clinical decision-support software system. The evaluation consisted of 50 clinical questions distributed across eight medical conditions.

Five questions were evaluated for each condition.

2.2 Clinical Conditions

The benchmark included the following conditions:

• Bronchospasm/Asthma
• Spontaneous Pneumothorax
• Respiratory Failure
• Impending Cardiac Arrest
• Severe Allergic Reaction/Anaphylaxis
• Appendicitis
• Gastrointestinal Bleeding
• Gallstones/Cholecystitis

These conditions were selected to represent a range of respiratory, cardiovascular, allergic, gastrointestinal, and abdominal clinical presentations.

2.3 Clinical Presentation Domains

The questions incorporated characteristic clinical findings associated with the target conditions.

For bronchospasm/asthma, the benchmark included findings such as prolonged expiration and bilateral wheezing.

For spontaneous pneumothorax, scenarios included sudden shortness of breath and chest pain with diminished breath sounds on the affected side.

Respiratory failure scenarios incorporated findings such as altered mental status, inability to speak in complete sentences, and respiratory arrest requiring positive-pressure ventilation.

Cardiovascular scenarios included symptoms associated with impending cardiac deterioration, including dyspnea, unusual fatigue, chest discomfort, nausea/vomiting, and back pain.

Anaphylaxis scenarios incorporated findings including acute respiratory difficulty, chest tightness, swelling involving the tongue, face, or neck, and urticaria.

Abdominal and gastrointestinal scenarios included characteristic findings of appendicitis, gastrointestinal hemorrhage, and gallbladder disease. These included right-lower-quadrant abdominal pain, melena, hematochezia, hematemesis, and right-upper-quadrant or epigastric pain with characteristic radiation.

2.4 Evaluation Procedure

Each clinical condition was represented by five questions, producing a total of 50 evaluated questions.

The software was provided the clinical questions and its treatment recommendations were evaluated against the predetermined medical answer criteria.

The primary evaluation metric was treatment recommendation accuracy.

A response was classified as correct when the treatment recommendation satisfied the predefined medical-treatment criteria for the corresponding question.

2.5 Outcome Measure

The primary outcome was calculated as:

Treatment Accuracy=Number of Correct Treatment RecommendationsTotal Number of Questions×100\text{Treatment Accuracy} = \frac{\text{Number of Correct Treatment Recommendations}} {\text{Total Number of Questions}} \times 100

The maximum possible score was 50 correct treatment recommendations out of 50 questions.

3. Results

3.1 Overall Performance

The software achieved a 100% treatment recommendation accuracy rate across the 50-question benchmark.

Metric	Result
Total questions	50
Questions graded correct	50
Questions graded incorrect	0
Overall treatment accuracy	100%

The observed accuracy was therefore:

5050×100=100%\frac{50}{50}\times100 = 100\%

No incorrect treatment recommendations were identified within the evaluated benchmark.

3.2 Performance by Clinical Category

Five questions were evaluated for each of the eight clinical conditions.

Clinical condition	Questions	Correct	Accuracy
Bronchospasm/Asthma	5	5	100%
Spontaneous Pneumothorax	5	5	100%
Respiratory Failure	5	5	100%
Impending Cardiac Arrest	5	5	100%
Severe Allergic Reaction/Anaphylaxis	5	5	100%
Appendicitis	5	5	100%
Gastrointestinal Bleeding	5	5	100%
Gallstones/Cholecystitis	5	5	100%
Total	50	50	100%

The system therefore maintained the same observed accuracy across every clinical category represented in the benchmark.

4. Discussion

The principal finding of this benchmark evaluation was that the evaluated software achieved 100% treatment recommendation accuracy across all 50 questions. Every question included in the evaluation received a treatment recommendation that met the predetermined grading criteria.

The finding is notable because the benchmark included multiple clinical domains rather than a single disease category. Respiratory emergencies, cardiovascular deterioration, anaphylaxis, gastrointestinal bleeding, appendicitis, and biliary disease present substantially different clinical management considerations. The software nevertheless achieved complete observed accuracy within the tested question set.

However, the interpretation of a 100% benchmark score requires caution. A perfect score on 50 questions does not establish that the software will achieve 100% accuracy in real-world clinical practice. The benchmark represents a finite sample of possible clinical presentations, and the performance estimate may change substantially with a larger or independently constructed question set.

In addition, clinical cases frequently contain ambiguity, incomplete information, conflicting findings, multiple simultaneous diagnoses, medication contraindications, allergies, age-related considerations, pregnancy, comorbid disease, and rapidly changing patient status. These factors may not be adequately represented by a controlled benchmark.

The distinction between benchmark accuracy and clinical effectiveness is therefore important. The current results demonstrate that the software successfully answered the questions included in this evaluation according to the specified grading criteria. They do not independently establish patient outcomes, clinical safety, diagnostic performance, or superiority over qualified healthcare professionals.

Another important consideration is potential benchmark bias. If the questions, expected answers, or evaluation criteria were known to the system developer or closely reflected the information used to develop the software, performance could overestimate generalization to previously unseen cases. Future studies should therefore use independently constructed test sets and, where possible, blinded external evaluation.

5. Limitations

Several limitations should be considered.

First, the sample size was limited to 50 questions. Although the system achieved perfect observed accuracy, a relatively small benchmark cannot establish reliable performance across the full range of clinical scenarios.

Second, only eight clinical conditions were evaluated. Many important emergency and medical conditions were not included.

Third, the questions may not represent the complexity of actual patient encounters. Real-world patients frequently present with incomplete histories, multiple simultaneous conditions, atypical symptoms, and clinically relevant comorbidities.

Fourth, the evaluation measured treatment recommendation accuracy rather than patient outcomes. The study therefore cannot determine whether use of the software would improve morbidity, mortality, time to treatment, or other clinical outcomes.

Fifth, the grading criteria and question construction may influence the measured accuracy. Independent replication using externally generated cases would provide stronger evidence of generalizability.

Finally, the results do not establish that the software should be used autonomously to diagnose or treat patients. Clinical decision-support systems should be evaluated within appropriate clinical, regulatory, and professional frameworks.

6. Recommendations for Future Research

Future evaluations should expand the benchmark substantially and include a larger number of clinical conditions and patient presentations.

Particularly valuable next steps would include:

• Independent external validation using questions not used during system development.
• Evaluation on several hundred or thousands of clinical cases.
• Inclusion of atypical and ambiguous presentations.
• Evaluation of pediatric and geriatric cases.
• Testing cases involving multiple simultaneous diagnoses.
• Evaluation of medication contraindications and clinically important comorbidities.
• Comparison with practicing physicians, paramedics, nurses, or other appropriate clinicians.
• Assessment of inter-rater agreement among clinical evaluators.
• Prospective evaluation in simulated clinical environments.
• Measurement of sensitivity, specificity, positive predictive value, and negative predictive value where the study design supports these measures.
• Evaluation of treatment omissions, harmful recommendations, and inappropriate treatment escalation separately from simple correctness.
• Assessment of whether the system appropriately recognizes when a case requires emergency escalation or human clinical judgment.

These studies would provide substantially stronger evidence regarding the system's generalizability and clinical utility.

7. Conclusion

In this 50-question benchmark evaluation, the assessed AI-assisted clinical decision-support software achieved 100% treatment recommendation accuracy, with 50 of 50 evaluated questions receiving recommendations that satisfied the predetermined grading criteria.

The system achieved 100% observed accuracy in each of the eight evaluated clinical categories: bronchospasm/asthma, spontaneous pneumothorax, respiratory failure, impending cardiac arrest, severe allergic reaction/anaphylaxis, appendicitis, gastrointestinal bleeding, and gallstones/cholecystitis.

These findings demonstrate strong performance on the evaluated benchmark. Nevertheless, a perfect score on a limited question set should be interpreted as an initial validation result rather than evidence of universal clinical accuracy or safety. Independent, larger-scale, clinically representative validation is necessary before conclusions can be made regarding real-world clinical effectiveness or autonomous clinical use.

8. Data Availability

The underlying benchmark questions, scoring criteria, and complete software outputs should be made available to reviewers or readers where permitted. Providing the complete evaluation dataset would facilitate independent replication of the reported findings.

9. Conflict of Interest

The authors should disclose any financial, employment, ownership, development, or other relationship with the software evaluated in this study.

10. Ethics Statement

Because this evaluation involved a benchmark of clinical questions rather than direct intervention with human patients, formal human-subject research requirements may not apply. The applicable institutional and regulatory requirements should nevertheless be reviewed and reported by the investigators.

11. References

The final manuscript should include authoritative clinical references supporting the diagnostic features and treatment standards used to construct and grade the benchmark. Educational websites or question-bank materials may be useful for identifying source material, but treatment recommendations in a scientific manuscript should preferably be supported by current professional guidelines, peer-reviewed literature, and authoritative clinical references.

RUNSHEET: Development of a Self-Contained, Browser-Based Reference Tool for Medication Reconstitution and Clinical Reasoning in Paramedic Education

Medication reconstitution — combining a powdered drug with a diluent to reach an administrable concentration — sits at the intersection of mathematics, pharmacology, and fine motor skill, and represents a persistent source of error in prehospital and hospital care alike. Paramedic students in particular have been shown to struggle with drug calculation generally, and reconstitution adds a further layer of concentration math, drug-specific technique, and infrequent practice on top of that existing weakness. This paper describes the development and design rationale of RUNSHEET, a free, self-contained, browser-based educational reference tool built to help paramedic students and EMS providers practice symptom-to-condition reasoning alongside medication dosing, reconstitution, and field treatment information. The tool uses a weighted matching system that takes user-entered signs and symptoms and returns ranked likely conditions, each linked to associated risk factors, field treatment steps, oxygen therapy guidance, and — where applicable — medication dosing and reconstitution instructions. This paper situates the tool's design within the existing literature on paramedic dosage calculation performance, the effect of stress on calculation accuracy, and the role of e-learning in supplementing hands-on skills training. No formal evaluation of student outcomes has yet been conducted; this paper is intended as a descriptive account of the tool and a foundation for future pilot evaluation.

emergency medical services; paramedics; education; medication systems; dosage calculation; drug compounding; patient safety; e-learning; clinical decision support; point-of-care systems

Introduction

Medication administration errors in the prehospital setting are well documented. In a survey of paramedics in San Diego County, 9.1% of respondents reported committing a medication error in the previous 12 months, with dose-related errors accounting for the largest share (63%) and contributing factors including infrequent use of the medication in question and dosage calculation error [1]. Reconstitution — the process of mixing a powdered medication with a diluent to reach a usable concentration — compounds these risks, since an error introduced at the preparation stage propagates into every subsequent calculation and administration step even when later arithmetic is performed correctly.

Hospital-based research illustrates how substantial these preparation-stage errors can be. A prospective observational study at a Dutch university hospital found errors in well over half of intravenous admixtures observed, with incorrect preparation technique and incorrect diluent volume among the most frequent problems identified before the medication reached the patient [2]. A separate Brazilian study of drug preparation and administration errors identified instances in which medication was diluted to a volume below the manufacturer's recommendation, directly compromising the intended dose [3]. While these studies were conducted in hospital rather than prehospital settings, the underlying mechanism — an error at the mixing stage undermining every downstream step — applies directly to EMS medication preparation as well.

Two additional factors specific to EMS education make reconstitution a persistent challenge. First, dosage calculation is already a documented area of difficulty for paramedic students independent of reconstitution: research examining mathematics anxiety and numerical ability among paramedic students found that math education prior to university entry and numerical ability were significant predictors of drug calculation performance, and that many students experience measurable anxiety around calculation tasks [4]. Second, calculation accuracy has been shown to deteriorate under stress. In a simulator-based study, paramedics' accuracy in calculating drug dosages fell substantially in stressful scenarios compared to calm conditions, regardless of the participant's level of experience [5]. Reconstitution in EMS practice is rarely performed under calm, unhurried conditions — it typically occurs mid-call, alongside patient assessment and communication demands, which is precisely the kind of environment shown to degrade calculation performance.

Taken together, these findings suggest that reconstitution-related error in EMS is not attributable to any single deficiency, but to the layering of several factors: baseline calculation difficulty, infrequent practice of drug-specific mixing steps, and performance degradation under operational stress. Traditional paramedic education typically addresses reconstitution through a single skills-station demonstration, which offers limited opportunity for the repeated, low-stakes practice that these findings suggest is needed. Digital tools may help close this gap: a recent randomized, quasi-experimental study of paramedic students found that a blended online-and-classroom model produced significantly greater improvement in dosage calculation scores than video-based e-learning alone, suggesting that structured digital practice can meaningfully improve this specific skill set [6]. This paper describes RUNSHEET, a browser-based tool developed to provide this kind of repeatable, self-directed practice.

Tool Description

RUNSHEET is a self-contained HTML, CSS, and JavaScript application that runs entirely in a web browser, requiring no server, account creation, or installation. It was designed for paramedic and EMT students to reference and practice medication and clinical reasoning content outside of scheduled lab or classroom time. Content included in the tool — specific medications, dosing ranges, and treatment protocols — was developed with reference to the National EMS Scope of Practice Model published by the National Highway Traffic Safety Administration (NHTSA), which outlines the knowledge, skills, and medication categories associated with each EMS provider level. Because actual scope of practice, medications carried, and specific protocols vary by state regulation, medical director approval, and local EMS agency, the tool is intended as a general study reference rather than a substitute for an individual program's protocols.

Core Features

Search functionality: Users can search directly for a medication, symptom, or condition rather than browsing a static list, mirroring the speed with which information typically needs to be retrieved in the field.

Condition calculation based on signs and symptoms: The core function of the tool is a weighted matching system. Users enter observed signs and symptoms along with vitals, organized across these categories (respiratory, cardiac/circulatory, neurological, skin/allergic, and gastrointestinal/general) (heart rate, blood pressure systolic/diastolic, respiratory rate, spO2, temperature, and blood glucose level) , and the system returns a ranked list of likely underlying conditions. This is intended to give students practice with the less-rehearsed half of clinical reasoning — working backward from a presentation to a probable cause — rather than only reviewing information about a condition that has already been named.

Medication cards: Each medication is presented in a consistent card format listing indications, contraindications, standard dosing, and route of administration, so that information remains scannable and comparable across the full medication set.

Reconstitution instructions: For medications requiring reconstitution, each card includes step-by-step instructions specifying the correct diluent, volume, and resulting concentration, allowing repeated review of the exact process for infrequently used drugs such as glucagon.

Dosage calculation practice: The tool includes built-in dosage calculation exercises tied to specific medications, giving users a low-stakes setting in which to repeatedly practice the underlying arithmetic rather than only reading about it.

Risk factors: Each condition and medication entry lists relevant patient-specific risk factors (e.g., age, weight, comorbidities, contraindicated combinations) that may increase the likelihood of an adverse outcome or point toward a specific diagnosis.

Field treatment: Each condition entry includes a recommended sequence of field interventions, from initial assessment priorities through medication administration, linking diagnostic reasoning to a concrete treatment pathway.

Oxygen treatment: Relevant condition entries include oxygen therapy guidance — target saturation range, delivery method, and flow rate — reflecting that even high-frequency interventions require patient-specific decision-making.

Potential Benefits for Paramedic Education

Because reconstitution and dosage calculation are skills that appear to decay with infrequent use [1], a resource that students can access repeatedly and without cost may help provide the kind of low-stakes repetition that a single in-person skills station cannot. The symptom-to-condition matching feature is intended to give students additional practice with diagnostic reasoning specifically, rather than only pharmacological recall, and the integration of risk factors, field treatment, and medication information into a single workflow is intended to mirror how these elements are used together on an actual call rather than as isolated topics of study.

Limitations

This tool has several limitations that should be considered. It is a static, browser-based application and therefore cannot replicate the physical component of reconstitution, such as drawing up fluid, mixing technique, or needle handling — skills that require hands-on laboratory practice. The symptom-matching algorithm reflects general clinical patterns encoded by the developer and is not a validated diagnostic instrument; it is intended solely as a study aid. The tool was developed and is maintained by a single individual rather than a clinical education team or institution, and its content has not undergone formal peer review, multi-site testing, or validation against paramedic education outcomes. Most importantly, no formal evaluation of student performance or learning outcomes with this tool has yet been conducted; the benefits described above are proposed based on alignment with existing literature rather than demonstrated empirically.

Future Directions

Planned future work includes formal pilot evaluation of the tool — for example, comparing dosage calculation or condition-recognition performance among paramedic students who use the tool against those who do not, following a design similar to prior blended-learning research [6]. Additional planned enhancements include timed or scenario-based practice modes intended to introduce a controlled degree of time pressure, given that stress has been shown to degrade calculation accuracy even among experienced providers [5]; periodic expansion and updating of the medication and condition library to remain aligned with evolving protocols; and the addition of performance tracking to identify individual students' recurring areas of difficulty.

Conclusion

Medication reconstitution occupies a difficult intersection of mathematics, pharmacology, and physical technique, compounded by the infrequency with which many relevant medications are used and by the performance-degrading effects of operational stress. Existing literature indicates that dosage calculation is already a measurable weak point among paramedic students, that preparation-stage errors are linked to serious patient harm, and that infrequent practice is a recurring contributing factor in real-world medication errors. RUNSHEET was developed as a freely accessible, self-contained tool intended to provide the kind of repeatable, low-stakes practice suggested by this literature, combining diagnostic reasoning, risk factor review, field treatment, and medication dosing and reconstitution practice into a single workflow. It is intended as a supplement to — not a replacement for — hands-on laboratory instruction and clinical supervision, and its educational value remains to be formally evaluated.

Conflicts of Interest

None declared

Funding

The authors received no specific funding for this work.

References

• 1. Vilke GM, Tornabene SV, Stepanski B, Shipp HE, Ray LU, Metz MA, et al. Paramedic self-reported medication errors. Prehosp Emerg Care. 2007;11(1):80-84. doi:10.1080/10903120601021358. PMID: 17169883.
• 2. Jessurun JG, Hunfeld NGM, van Rosmalen J, van Dijk M, van den Bemt PMLA. Prevalence and determinants of intravenous admixture preparation errors: a prospective observational study in a university hospital. Int J Clin Pharm. 2022;44(1):44-52. doi:10.1007/s11096-021-01310-6. PMID: 34363192.
• 3. Mendes JR, Lopes MCBT, Vancini-Campanharo CR, Okuno MFP, Batista REA. Types and frequency of errors in the preparation and administration of drugs. Einstein (São Paulo). 2018;16(3):eAO4146. doi:10.1590/S1679-45082018AO4146. PMID: 30231142.
• 4. Khasawneh E, Gosling C, Williams B. The correlation between mathematics anxiety, numerical ability and drug calculation ability of paramedic students: an explanatory mixed method study. Adv Med Educ Pract. 2020;11:869-878. doi:10.2147/AMEP.S258223. PMID: 33235536.
• 5. LeBlanc VR, MacDonald RD, McArthur B, King K, Lepine T. Paramedic performance in calculating drug dosages following stressful scenarios in a human patient simulator. Prehosp Emerg Care. 2005;9(4):439-444. doi:10.1080/10903120500255255. PMID: 16263679.
• 6. Baran L, Öztürk H. The effects of video-based and blended learning on medication dosage calculation skills of paramedic students: a randomized, quasi-experimental study. Medicine (Baltimore). 2025;104(31):e43651. doi:10.1097/MD.0000000000043651. PMID: 40760542.
• 7. National Highway Traffic Safety Administration. National EMS Scope of Practice Model. Washington (DC): U.S. Department of Transportation; [edition/year to be confirmed and cited directly from NHTSA.gov].