Artificial Intelligence In Prehospital Care Isn't Science Fiction — It's Becoming A Practical Clinical Tool

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

PARAMEDIC AI: Development of a Browser-Based Artificial Intelligence and Machine-Learning Decision-Support Tool for Paramedic Education

Artificial intelligence (AI) and machine learning (ML) are increasingly being incorporated into healthcare education and decision-support systems, creating opportunities for paramedic students to interact with clinical information in ways that extend beyond traditional static reference materials. Paramedic education presents a particularly relevant environment for exploring these technologies because learners must integrate vital-sign interpretation, clinical reasoning, evidence retrieval, communication, and rapid decision-making while maintaining awareness of protocol and scope-of-practice limitations. This paper describes the development and design rationale of Paramedic AI, a browser-based educational and decision-support demonstration designed for EMS learners. The application combines a demonstration machine-learning risk assessment with an AI-powered clinical copilot, voice input, text-to-speech functionality, and a document-based knowledge-management system. Users can enter patient age and vital signs, obtain an estimated ML risk probability and classification, and ask the Paramedic Copilot questions using typed or spoken input. The Copilot retrieves information from an authorized knowledge base and provides responses accompanied by references when available. The Knowledge Manager permits authorized PDF and Word documents to be uploaded, assigned source metadata, and incorporated into the searchable knowledge index. The application is explicitly designed as an educational demonstration rather than a diagnostic or treatment system, and its interface emphasizes that outputs should not replace local EMS protocols, medical direction, scope of practice, or clinical judgment. No formal evaluation of student learning outcomes, diagnostic performance, or clinical safety has yet been conducted. This paper presents the tool's design and educational rationale and provides a foundation for future evaluation of AI-supported learning in paramedic education.

artificial intelligence; machine learning; emergency medical services; paramedic education; clinical reasoning; decision support; EMS education; generative AI; medical education; e-learning; knowledge retrieval; patient assessment

Introduction

Paramedics are required to synthesize multiple sources of information rapidly, including patient history, physical examination findings, vital signs, clinical presentation, protocols, and medical direction. Traditional EMS education provides learners with structured clinical knowledge and hands-on skills practice, but the increasing availability of artificial intelligence creates additional possibilities for learners to interact with clinical information and practice reasoning in a more dynamic environment.

Machine-learning systems and generative AI systems represent two different but potentially complementary approaches to educational support. Machine-learning models can identify patterns in structured data and produce classifications or probability estimates, while generative AI systems can interact with users through natural language and retrieve or synthesize information from reference materials. In paramedic education, these capabilities may provide opportunities for learners to explore the relationship between patient assessment data and predicted risk while simultaneously practicing clinical questioning and evidence evaluation.

The educational value of these technologies depends heavily on how they are implemented. A system that simply produces an answer risks encouraging automation bias, in which users place excessive confidence in an automated recommendation. This is particularly important in EMS, where patient presentations are often incomplete, information can change rapidly, and treatment decisions are governed by local protocols, medical direction, scope of practice, and regulatory requirements.

Paramedic AI was therefore designed as an educational demonstration rather than as an autonomous clinical decision-making system. The application combines structured patient-vital input, a demonstration ML risk model, a retrieval-supported AI Copilot, voice interaction, text-to-speech, and a source-management system. The design intentionally places the learner in the role of evaluator rather than passive recipient of an automated answer.

This paper describes the development and functionality of Paramedic AI, its potential applications in paramedic education, its limitations, and potential directions for future evaluation.

Tool Description

Paramedic AI is a browser-based Streamlit application developed as an EMS education and decision-support demonstration. The application presents a single interface through which users can enter patient vital signs, run a machine-learning risk assessment, interact with an AI Copilot, access retrieved reference information, and manage authorized EMS reference documents.

The application collects seven structured patient variables:

• Age
• Heart rate
• Systolic blood pressure
• Diastolic blood pressure
• Respiratory rate
• SpO₂
• Temperature

These variables are displayed in a patient-vital-sign summary before the learner runs the ML assessment.

The application then passes the entered values to a machine-learning model that generates an estimated risk probability and assigns the result to one of three categories: LOWER RISK, INTERMEDIATE RISK, or HIGHER RISK. The interface explicitly identifies this as a demonstration prediction and states that it is not a clinical diagnosis.

The second major component is the Paramedic Copilot. Users can ask questions using either typed text or speech recognition. Speech input is transcribed and presented to the learner for review before submission, allowing the user to correct transcription errors. The submitted question is then processed through a knowledge-search function before being provided to the Copilot. The application limits both the retrieved context and conversation history before generating the response.

The Copilot response may include references to the sources retrieved from the knowledge base. This design provides an opportunity for learners to evaluate not only the AI-generated answer but also the evidence supporting it.

Core Features

Structured patient assessment: Users enter age and vital-sign information through dedicated assessment fields. The values are then displayed in a standardized patient-vital-sign summary, providing a consistent starting point for ML assessment activities.

Machine-learning risk assessment: The application uses a demonstration ML model to process the seven entered patient variables. The output includes an estimated probability and a categorical risk classification. The system is designed to demonstrate how structured clinical information can be processed by a predictive model rather than to provide a diagnosis.

Risk classification: The model output is translated into three categories: lower risk, intermediate risk, and higher risk. This gives learners an opportunity to examine how continuous probability estimates can be translated into categorical outputs.

Patient-data review: After an assessment is run, the application provides an expandable view of the patient data submitted to the model. This allows learners to verify that the intended values were actually entered and used.

Paramedic Copilot: The Copilot provides a conversational interface through which users can ask EMS-related questions. Rather than functioning solely as a general-purpose chatbot, the implementation first searches the application's knowledge base and supplies retrieved context to the AI response system.

Medication dosing and pharmacology support: The Paramedic Copilot can retrieve medication-related information from the application's authorized EMS knowledge base. Learners can ask questions about medication dosing and related pharmacological information and receive an AI-generated response based on retrieved reference material. This feature is intended to support medication knowledge review and clinical reasoning practice rather than replace agency-specific medication protocols, medical direction, or independent dose verification. Because medication dosing can vary according to patient characteristics, medication formulation, route, jurisdiction, and local protocol, users should verify any dosing information against the current authoritative source before applying it in practice.

Medication-related clinical reasoning: Medication questions can be incorporated into broader patient scenarios, allowing learners to connect patient presentation, vital signs, clinical considerations, and medication information. Rather than treating medication dosing as an isolated memorization exercise, the Copilot can be used to prompt learners to consider why a medication may be indicated, what patient-specific factors could affect its use, and what information should be verified before administration.

Reference-supported medication information: When the Copilot retrieves medication information from the application's knowledge base, associated references can be displayed with the response. This provides an opportunity for learners to compare AI-generated dosing information against the underlying source and reinforces the importance of source verification in medication administration.

Knowledge-grounded responses: The Copilot searches the application's authorized knowledge base before generating an answer. Retrieved material is formatted as context and supplied to the Copilot, creating a mechanism for grounding responses in designated reference material.

Reference display: When available, references associated with retrieved knowledge are appended to the Copilot response. This allows learners to examine the source material behind an AI-generated answer rather than treating the generated response as an independent authority.

Voice input: Users can speak questions through the application's speech-to-text interface. The resulting transcription is displayed for review before submission, allowing users to identify and correct transcription errors.

Response review: The application preserves Copilot conversation history within the current session. This allows learners to review previous questions and answers and observe how conversational context influences subsequent interactions.

Text-to-speech: The application can convert the latest Copilot response into audio. This provides an additional interaction modality and may support accessibility and alternative learning preferences.

Knowledge Manager: Authorized users can upload PDF and Word reference documents. Each source can be associated with metadata including title, jurisdiction, document type, effective date, version, authority, status, and review requirements.

Source-status management: Registered sources can be categorized as active, draft, inactive, retired, or superseded. Sources can also be flagged as requiring review, providing a basic mechanism for communicating the review status of educational material.

Knowledge-index rebuilding: Uploaded documents can be processed through an ingestion and indexing workflow. This allows newly authorized reference material to become available to the knowledge-search component used by the Copilot.

Educational Use Cases

Paramedic AI is designed to support several forms of formative learning.

The first is structured vital-sign reasoning. Learners can enter patient data and observe the output of a predictive model. By changing individual variables while holding others constant, students can explore how structured inputs influence model predictions.

The second is clinical-question formulation. The Copilot provides learners with an opportunity to formulate questions about patient assessment, clinical concepts, and EMS practice using natural language rather than selecting information from a predetermined menu.

The third is evidence evaluation. Because the Copilot retrieves reference material and can display associated sources, learners can be encouraged to distinguish between an AI-generated statement and the authoritative evidence supporting that statement.

The fourth is AI literacy. Students can explore situations in which an AI response may appear plausible while still requiring verification. This can support instruction on hallucination, incomplete information, automation bias, source quality, and appropriate human oversight.

The fifth is repeated low-stakes practice. Unlike a single classroom demonstration, a browser-based application can be accessed repeatedly, allowing students to experiment with patient presentations, questions, and source material without requiring a full simulation-lab setup.

Potential Benefits for Paramedic Education

One potential benefit of Paramedic AI is the integration of multiple learning activities within a single environment. Patient assessment, predictive modeling, natural-language questioning, evidence retrieval, and source evaluation are presented as connected activities rather than isolated topics.

The ML assessment may provide an accessible introduction to predictive modeling by allowing students to observe the relationship between structured patient data and model output. Importantly, the application can also be used to demonstrate why model output should not be equated with clinical diagnosis. Students can compare the information available to the model with the substantially larger information set considered during a complete paramedic assessment.

The Copilot component provides a different educational opportunity. Instead of requiring students to search a static reference manually, the system allows them to formulate questions conversationally and receive an answer grounded in the application's designated knowledge sources. This may support exploratory learning and encourage students to ask follow-up questions.

The reference component is particularly important from an educational perspective. Students can be taught that the quality of an AI answer depends not only on the language-generation system but also on the information supplied to it. Reviewing source metadata can reinforce the importance of jurisdiction, effective dates, document versions, issuing authorities, and source status.

Voice interaction and text-to-speech further expand the possible educational uses of the system. These features may allow learners to interact with educational content using modalities other than conventional keyboard input and written output.

Formative Learning Activities

The application can be incorporated into structured formative exercises.

Vital-sign manipulation: Students can establish a baseline patient assessment and then alter one vital sign at a time. They can record changes in the model's probability and classification and discuss why predictive output should not be interpreted independently of the broader patient presentation.

Clinical reasoning comparison: Students can compare their own initial assessment with the information considered by the ML model. This encourages discussion of the difference between structured numerical prediction and comprehensive clinical reasoning.

AI question formulation: Students can ask the Copilot questions related to an assigned EMS scenario and evaluate whether the response addresses the clinical question appropriately.

Reference verification: Students can identify the sources returned with a Copilot response and determine whether those sources are current, authoritative, and applicable to the relevant jurisdiction.

AI error recognition: Instructors can provide scenarios in which students must identify information in an AI response that requires independent verification.

Source-management exercise: Students can upload an authorized educational reference, enter its metadata, and discuss why document status, version, jurisdiction, and issuing authority matter when constructing an EMS knowledge base.

Safety and Clinical Boundaries

Because the application addresses clinical information, clear boundaries are necessary.

The application's ML prediction is explicitly labeled as a demonstration and not a clinical diagnosis. The Copilot likewise should not be treated as an independent clinical authority. AI-generated information may be incomplete, inaccurate, outdated, or inappropriate for a particular patient or jurisdiction.

The application therefore directs users to follow current local EMS protocols, medical direction, scope of practice, manufacturer instructions, and applicable regulations.

The educational design should emphasize that technology can support learning and information retrieval without transferring clinical responsibility from the practitioner to the software.

The system should also be used without unnecessary patient-identifying information. Educational demonstrations should use simulated or appropriately de-identified cases rather than sensitive patient information unless the environment has been specifically approved for such use.

Limitations

Paramedic AI has several limitations.

First, the machine-learning model is a demonstration model rather than a clinically validated prediction instrument. The interface does not establish that its probability estimates are calibrated for a specific EMS population, nor does it establish diagnostic or prognostic validity.

Second, the model receives only seven structured variables. Important clinical information such as chief complaint, medical history, medications, allergies, physical examination findings, mental status, mechanism of injury, clinical trajectory, and response to treatment is not represented in the ML input shown in the application. Consequently, the model cannot reproduce the full reasoning process of a paramedic.

Third, the Copilot is dependent on the quality and relevance of the knowledge retrieved from the application's source library. A reference-grounded response is not necessarily a correct response, and the presence of references does not eliminate the need for verification.

Fourth, the application depends on the accuracy of speech recognition when voice input is used. Errors in transcription may change the meaning of a clinical question and consequently affect the generated response.

Fifth, the knowledge-management system requires appropriate human oversight. Uploading a document does not by itself establish that the document is current, authoritative, applicable to a particular jurisdiction, or appropriate for clinical use.

Sixth, the current implementation does not constitute a substitute for hands-on paramedic education. It cannot reproduce physical assessment, medication preparation, airway management, patient movement, communication with other healthcare professionals, or the operational complexity of an actual EMS response.

Most importantly, no formal evaluation of student learning outcomes, clinical reasoning performance, model accuracy, usability, or patient-safety impact has been conducted as part of the development described here. Any educational benefits should therefore be regarded as proposed benefits rather than demonstrated outcomes.

Future Directions

Future development could include formal evaluation of Paramedic AI with paramedic and EMT students. Potential study designs could compare student performance before and after structured use of the application and examine outcomes such as clinical reasoning, knowledge retention, ability to identify unreliable AI output, and confidence in interpreting predictive models.

A further direction would be development of structured scenario-based learning. Instead of entering isolated vital signs, learners could be presented with complete simulated patient encounters and asked to make an initial clinical assessment before interacting with the AI system. This would allow researchers to investigate whether AI improves reasoning or instead encourages premature reliance on automated output.

Additional work could evaluate the ML model itself, including calibration, sensitivity, specificity, generalizability, and performance across relevant patient populations. Such evaluation would be necessary before any consideration of clinical deployment.

The knowledge-management component could also be expanded with more sophisticated source governance, including automated identification of outdated documents, explicit version control, jurisdiction filtering, and administrator review workflows.

Future iterations could incorporate instructor dashboards or learner-performance tracking. This could allow educators to identify recurring misconceptions, frequently asked questions, and areas in which learners have difficulty evaluating AI-generated information.

Additional accessibility features and alternative interaction modalities could also be explored.

Conclusion

Paramedic AI was developed as a browser-based educational demonstration combining machine learning, generative artificial intelligence, knowledge retrieval, voice interaction, and reference management within a single EMS-focused interface. The application allows learners to enter patient vital signs and explore a demonstration risk prediction, interact with an AI Copilot, review retrieved references, and examine how authorized source material can be incorporated into an AI-supported knowledge system.

The primary educational opportunity offered by the application is not the automation of paramedic decision-making, but the opportunity to teach learners how to interact critically with emerging technologies. Students can examine the relationship between structured data and predictive output, practice asking clinically relevant questions, evaluate AI-generated responses, inspect supporting references, and recognize the limitations of automated systems.

Paramedic AI is therefore best understood as a formative educational and AI-literacy tool, rather than a clinical decision-making system. Its outputs should never supersede current EMS protocols, medical direction, scope of practice, manufacturer instructions, applicable regulations, or professional clinical judgment. Formal evaluation is still required to determine whether use of the system produces measurable improvements in paramedic education and whether its design effectively reduces rather than reinforces inappropriate reliance on AI.

Conflicts of Interest

None declared.

Funding

The authors received no specific funding for development of this educational demonstration.

References

References should be finalized based on the literature actually used to support the claims in the completed manuscript. The references below are recommended starting points for the AI/EMS/medical-education literature review rather than claims that they were sources used during development.

• National Highway Traffic Safety Administration. National EMS Scope of Practice Model. U.S. Department of Transportation.
• American Heart Association. Guidelines for CPR and ECC. American Heart Association.
• World Health Organization. Ethics and Governance of Artificial Intelligence for Health. Geneva: World Health Organization.
• U.S. Food and Drug Administration. Artificial Intelligence and Machine Learning (AI/ML)-Enabled Medical Devices. U.S. Food and Drug Administration.
• Topol EJ. High-performance medicine: the convergence of human and artificial intelligence. Nature Medicine. 2019;25:44-56.
• Masters K. Artificial intelligence in medical education. Medical Teacher. 2019;41(9):976-980.
• Wartman SA, Combs CD. Medical education must move from the information age to the age of artificial intelligence. Academic Medicine. 2018;93(8):1107-1109.

Abstract

Background

Electrocardiography (ECG) is a fundamental diagnostic investigation used to assess cardiac electrical activity. Conventional ECG analysis generally relies on interpretation of digitally acquired signals or printed ECG recordings by trained healthcare professionals. The increasing availability of artificial intelligence (AI) methods has created opportunities for automated ECG analysis. However, the development of AI systems from ECG images introduces additional challenges, including image preprocessing, lead identification, waveform reconstruction, and conversion of visual ECG information into a representation suitable for computational inference.

Case Description

This case report describes the development of an experimental software prototype designed to process a 12-lead ECG image and subsequently perform AI-based analysis. The application was implemented using Python and the Streamlit framework. The software accepts PNG, JPEG, or JPG ECG images through a graphical web interface. Following upload, the image is passed to an ECG-processing module responsible for generating a cleaned image, identifying ECG regions, and producing experimental waveform representations. The application then evaluates whether all 12 waveform outputs are sufficiently usable for downstream AI inference. If this requirement is satisfied, an AI model is loaded and supplied with the processed waveform data. The model output is presented as probabilistic scores associated with predefined findings.

Results

The prototype provides an integrated workflow consisting of ECG image upload, visualization, image processing, lead-region detection, experimental waveform visualization, quality gating, AI-model loading, inference, and presentation of model probabilities. The application includes explicit safeguards indicating that the system is experimental and has not undergone clinical validation.

Conclusion

The developed prototype demonstrates a modular pipeline for transforming an ECG image into computational representations and subsequently applying an AI model. Its architecture separates image processing, model loading, and inference into independent software modules, facilitating future development and testing. Nevertheless, the current implementation should be regarded strictly as a research prototype. Clinical validation, independent performance evaluation, standardized datasets, assessment of waveform reconstruction accuracy, and appropriate regulatory evaluation would be required before any consideration of clinical deployment.

1. Introduction

The electrocardiogram is a widely used method for evaluating the electrical activity of the heart. A conventional 12-lead ECG contains information distributed across multiple electrical leads, allowing cardiac electrical activity to be assessed from different anatomical perspectives.

Although ECG analysis is traditionally performed using directly acquired electrical signals, ECG information is also frequently encountered in image form. Such images may originate from scanned paper ECGs, screenshots, photographs, or exported reports. An image-based ECG analysis system therefore requires an additional computational stage in which visual information is converted into a representation that can be analyzed computationally.

Artificial intelligence has increasingly been investigated for automated interpretation of ECG data. However, an AI model generally requires structured numerical input rather than a conventional ECG image. Consequently, an image-based system may require several processing stages, including image preprocessing, identification of individual ECG leads, extraction of waveform information, quality assessment, and AI inference.

The software described in this case report was developed as an experimental research prototype to investigate this complete workflow. Rather than directly presenting an ECG image to an AI model, the application establishes an intermediate processing pipeline in which the image is converted into experimental waveform representations before AI inference is attempted.

The primary objective of the prototype is therefore not clinical diagnosis, but demonstration of a computational framework capable of connecting ECG image processing with downstream artificial intelligence analysis.

2. System Objectives

The software was designed around several functional objectives:

• Accept a 12-lead ECG image from a user.
• Display the original ECG image.
• Process the ECG image using a dedicated processing module.
• Generate a cleaned version of the ECG image.
• Detect and extract individual ECG lead regions.
• Generate experimental numerical waveform representations.
• Visualize the extracted waveforms.
• Determine whether all 12 leads have usable waveform outputs.
• Prevent AI inference when the required waveform data are incomplete.
• Load an AI model when the waveform requirements are satisfied.
• Perform model inference.
• Display model findings and associated probabilities.
• Clearly communicate that the system is experimental and not clinically validated.

3. Software Architecture

The prototype follows a modular software architecture. The main application acts as the user interface and orchestration layer, while specialized functions are delegated to independent modules.

The principal software components are:

• Streamlit interface
• ECG processing module
• Model loading module
• Inference module

The main application imports three principal functions:

from ecg_processor import process_ecg

from model_loader import load_model

from inference import predict

This design separates the user-interface layer from the computational components.

Conceptually, the system can be represented as:

ECG Image

↓

Image Processing

↓

Lead/Region Detection

↓

Waveform Extraction

↓

Waveform Quality Check

↓

AI Model Loading

↓

AI Inference

↓

Probabilistic Research Output

This modular structure is advantageous because individual components can be independently modified, tested, and replaced without requiring substantial changes to the user interface.

4. Development Environment

The prototype was implemented in Python.

The principal external libraries visible in the provided source code are:

4.1 Streamlit

Streamlit provides the interactive web-based user interface. It is responsible for page configuration, image uploading, buttons, status messages, charts, progress indicators, and dynamic presentation of results.

4.2 NumPy

NumPy is imported as:

import numpy as np

Although NumPy is not directly used elsewhere in the provided interface code, its presence indicates that numerical array processing is part of the intended computational environment. The actual use of NumPy may occur within the imported ECG-processing or inference modules.

4.3 Custom Python Modules

Three application-specific modules form the computational core:

ecg_processor.py

model_loader.py

inference.py

Their apparent responsibilities are:

Module	Function
ecg_processor.py	ECG image processing and waveform/region generation
model_loader.py	Loading the trained or experimental AI model
inference.py	Applying the model to waveform inputs and producing findings

The exact algorithms used inside these modules cannot be determined from the supplied interface code alone.

5. ECG Image Acquisition

The first functional stage is ECG image acquisition.

The application provides a file uploader:

uploaded_file = st.file_uploader(

"Upload a 12-lead ECG image",

type=["png", "jpg", "jpeg"],

)

The system therefore accepts three common image formats:

• PNG
• JPEG
• JPG

The application explicitly requests a 12-lead ECG image and instructs the user to upload a de-identified ECG.

If no file has been uploaded, execution is stopped:

if uploaded_file is None:

st.info(

"Upload a de-identified ECG image to begin."

)

st.stop()

This prevents downstream processing from occurring without an input image.

6. Original Image Visualization

After successful upload, the image is retrieved as raw bytes:

image_bytes = uploaded_file.getvalue()

The original image is then displayed to the user.

This provides an important visual reference because subsequent processing results can be compared with the original ECG.

The workflow therefore maintains the distinction between:

Original ECG image

and

Processed ECG representation

which is useful during research and development.

7. ECG Image Processing

The central image-processing operation is initiated by the user through the PROCESS ECG button.

The application calls:

result = process_ecg(image_bytes)

The process_ecg() function therefore represents the principal interface between the graphical application and the underlying ECG-processing algorithm.

The returned object is expected to contain at least three components:

result["cleaned"]

result["regions"]

result["waveforms"]

These outputs correspond to three processing stages.

7.1 Cleaned ECG Image

The cleaned output is displayed as:

st.image(

result["cleaned"],

caption="Experimental grid-suppressed image",

channels="BGR",

width="stretch",

)

The interface describes this as an experimental grid-suppressed image.

This suggests that the processing pipeline attempts to reduce or suppress ECG background-grid information while preserving the waveform. However, the precise image-processing method cannot be determined without access to ecg_processor.py.

Possible operations in such a pipeline could include image normalization, color-space conversion, thresholding, grid suppression, segmentation, or noise reduction, but these should not be attributed to the current implementation without examining the actual processing module.

8. ECG Lead Region Detection

The processing function returns a collection called regions:

regions = result["regions"]

The application calculates the number of detected regions:

len(regions)

and reports:

• Detected regions

Each region contains at least an image and a name:

region["image"]

region["name"]

The regions are displayed in a three-column layout.

This functionality allows the researcher to visually inspect the portions of the ECG image identified as individual lead regions.

The system therefore introduces an intermediate representation:

Complete ECG image → detected lead regions

This is an important architectural step because individual lead waveforms can subsequently be associated with numerical waveform outputs.

9. Experimental Waveform Generation

Following region extraction, the application accesses:

waveforms = result["waveforms"]

Each waveform is evaluated individually.

The application excludes two categories of unusable output:

if waveform is None:

continue

if len(waveform) < 2:

continue

A waveform is considered usable by the interface if it is not None and contains at least two elements.

Usable waveforms are then visualized using Streamlit line charts:

st.line_chart(

waveform,

height=150,

)

The corresponding ECG lead name is displayed below each chart.

This stage is described as experimental waveform extraction because the numerical waveform is reconstructed or derived from an image rather than obtained directly from an ECG acquisition system.

The accuracy of this reconstruction is not established by the supplied code.

10. Waveform Quality Gate

One of the most important safety-oriented software mechanisms is the waveform completeness check.

The application counts the number of usable waveform outputs:

usable += 1

and subsequently reports:

Usable waveform outputs: X/12

The AI system requires all 12 waveform outputs to be usable.

The condition is explicitly implemented as:

if usable != 12:

When fewer than 12 usable waveforms are available, the application displays:

• AI inference requires 12 usable waveform outputs. Do not run the model yet.

This represents a quality-gating mechanism between preprocessing and AI inference.

The workflow can therefore be represented as:

Image processing

→ Waveform generation

→ 12-lead completeness check

→ AI inference only if 12/12 are usable

This prevents the model from being intentionally executed when the expected complete 12-lead waveform representation is not available.

It is important to note that this is a completeness criterion rather than a validated clinical quality-control measure. The code verifies that outputs exist and contain at least two elements, but it does not establish that the extracted waveforms are physiologically accurate.

11. AI Model Loading

When all 12 waveforms satisfy the basic usability criterion, the user is allowed to initiate AI analysis.

The model is loaded through:

model = load_model()

The implementation of load_model() is not included in the supplied code. Consequently, the model architecture, training dataset, model parameters, framework, and training methodology cannot be established from this source file.

The separation of model loading into its own module is nevertheless a useful design decision because it allows the underlying model to be changed without redesigning the Streamlit interface.

12. AI Inference

The loaded model and waveform data are passed to:

results = predict(

model,

waveforms

)

The predict() function therefore forms the inference interface.

The output is expected to be an iterable containing objects with at least:

item["finding"]

item["probability"]

The probability is converted to a percentage:

probability = (

item["probability"]

* 100

)

The application subsequently displays the finding and probability:

Finding — probability%

A visual progress bar is also generated:

st.progress(

min(

int(probability),

100

)

)

This allows the user to visually inspect the model's output scores.

Importantly, these values are explicitly presented as experimental model outputs rather than diagnoses.

13. User Interface and Interaction Workflow

The complete user workflow is designed as a three-stage process.

Stage 1 — Upload ECG

The researcher uploads a 12-lead ECG image.

The application then displays the original image.

Stage 2 — ECG Processing

The researcher selects PROCESS ECG.

The application:

• Sends the image to the ECG-processing module.
• Receives the processing results.
• Displays the cleaned ECG image.
• Displays detected lead regions.
• Generates and displays available waveform outputs.
• Counts usable waveforms.

Stage 3 — AI Analysis

If all 12 waveform outputs are usable, the researcher can select RUN ECG AI.

The application:

• Loads the AI model.
• Sends the waveform data to the inference function.
• Receives model results.
• Converts probabilities into percentages.
• Displays predicted findings and scores.

The complete workflow is therefore:

ECG Image

↓

Upload

↓

Image Processing

↓

Cleaned Image

↓

Lead Region Detection

↓

Waveform Extraction

↓

Waveform Visualization

↓

12/12 Quality Gate

↓

AI Model

↓

Inference

↓

Finding + Probability

14. Error Handling

The application incorporates exception handling around both major computational stages.

During ECG processing:

try:

...

except Exception as error:

st.error(

f"ECG processing failed: {error}"

)

During AI inference:

try:

...

except Exception as error:

st.error(

f"AI inference failed: {error}"

)

This prevents an unexpected processing or inference error from causing an uncontrolled application failure and instead provides a visible error message to the user.

The use of st.spinner() also communicates that a computational operation is currently being performed.

15. State Management

The processed ECG results are stored in Streamlit session state:

st.session_state["ecg_result"] = result

This allows the processed results to remain available during subsequent interactions with the application.

The interface can therefore display the processing results without requiring the ECG-processing function to be repeatedly executed every time the application reruns.

This is particularly relevant to Streamlit applications because user interactions can trigger script reruns.

16. Research-Oriented Safety Design

The application repeatedly communicates that it is not a clinical diagnostic system.

At the beginning of the interface, a warning states that the application is:

• RESEARCH PROTOTYPE ONLY

The application further states that it is not clinically validated and must not be used to diagnose patients or make patient-care decisions.

After AI inference, an additional warning explains that the scores represent experimental model outputs rather than medical diagnoses.

This is an important characteristic of the prototype because it establishes a distinction between:

Research model output

and

Clinically validated diagnostic information.

The interface also requests a de-identified ECG image, reflecting an awareness of the importance of avoiding unnecessary exposure of patient-identifying information.

17. Functional Characteristics

The principal functional characteristics of the system are summarized below.

Function	Implementation	Purpose
ECG upload	Streamlit file uploader	Accept ECG images
Original visualization	st.image()	Display source ECG
ECG processing	process_ecg()	Process uploaded image
Image cleaning	result["cleaned"]	Display processed image
Lead detection	result["regions"]	Identify ECG regions
Region visualization	st.image()	Inspect detected leads
Waveform extraction	result["waveforms"]	Obtain numerical representations
Waveform visualization	st.line_chart()	Inspect extracted signals
Quality gating	usable != 12	Prevent incomplete AI input
Model loading	load_model()	Load AI model
AI inference	predict()	Generate model outputs
Probability display	percentage + progress bar	Present model scores
Error handling	try/except	Manage failures
State management	st.session_state	Preserve processing results

18. Discussion

The prototype demonstrates an important concept in image-based ECG artificial intelligence: the AI analysis does not necessarily have to operate directly on the original ECG image. Instead, the system can establish an intermediate representation of the ECG through image processing and waveform extraction.

This architecture has several potential advantages.

First, the modular design separates image processing from AI inference. This allows the waveform extraction method and AI model to be independently developed and evaluated.

Second, the visualization of intermediate processing results provides researchers with greater transparency than a system that produces only a final prediction. Researchers can inspect the cleaned image, detected regions, and reconstructed waveforms before evaluating AI outputs.

Third, the 12-lead completeness gate provides a simple mechanism for preventing inference when the expected input structure is incomplete.

Fourth, the explicit research-only warnings help distinguish experimental software from a clinically validated medical device.

However, several limitations must be recognized.

The most important limitation is that the provided source code represents primarily the application interface and orchestration layer. The actual implementation of ECG image processing, waveform extraction, model loading, and AI inference is contained in external modules that were not supplied. Therefore, the specific algorithms, model architecture, training methodology, dataset characteristics, and performance metrics cannot be evaluated from this code alone.

Furthermore, the current waveform quality check is limited. A waveform is considered usable if it is present and has at least two elements. This does not demonstrate that the waveform is correctly reconstructed, correctly aligned, physiologically plausible, or suitable for clinical inference.

Similarly, the probability values produced by the model should not be interpreted as clinically meaningful probabilities without appropriate calibration and validation.

19. Recommended Validation Framework

Before the prototype could be considered for research involving clinical interpretation, several additional validation stages would be required.

19.1 Image-processing validation

The ability of the system to identify ECG regions should be evaluated against manually annotated ECG images.

Relevant measurements could include:

• Lead-region detection accuracy
• Localization error
• Segmentation accuracy
• Grid-removal performance
• Robustness to image quality variations

19.2 Waveform reconstruction validation

The extracted waveform should be compared with the original digital ECG signal when paired image and signal data are available.

Potential measurements include:

• Correlation
• Root mean square error
• Amplitude error
• Temporal alignment error
• Signal-to-noise ratio
• Morphological similarity

19.3 AI model validation

The model should be evaluated using an independent dataset that was not used during training.

Depending on the intended findings, relevant metrics may include:

• Sensitivity
• Specificity
• Positive predictive value
• Negative predictive value
• AUROC
• AUPRC
• Calibration
• Confusion matrices

19.4 External validation

Testing should subsequently be performed using ECG images originating from different devices, institutions, acquisition conditions, resolutions, and patient populations.

This would help determine whether the system generalizes beyond the development dataset.

19.5 Clinical validation

If the eventual goal is clinical use, prospective clinical evaluation and appropriate regulatory assessment would be necessary. The current prototype should not be interpreted as having completed these stages.

20. Reproducibility and Modularity

The separation of the application into independent components provides a useful foundation for reproducible research.

The architecture can be conceptualized as four independent layers:

Layer 1 — User Interface

Implemented through Streamlit.

Layer 2 — Image Processing

Implemented through ecg_processor.py.

Layer 3 — Model Management

Implemented through model_loader.py.

Layer 4 — Inference

Implemented through inference.py.

This architecture allows researchers to replace individual components without redesigning the entire system.

For example, an improved waveform extraction algorithm could replace the existing processing implementation while retaining the same Streamlit interface and inference interface.

Similarly, a different AI model could be incorporated through the model-loading and inference modules.

21. Conclusion

This case report describes the development of an experimental ECG AI research prototype capable of accepting a 12-lead ECG image, processing the image, identifying ECG regions, generating experimental waveform representations, evaluating waveform completeness, and performing AI inference when all 12 waveform outputs are available.

The software uses a modular Python architecture in which the Streamlit application serves as the orchestration and visualization layer while dedicated modules perform ECG processing, model loading, and inference.

A key feature of the system is its visualization of intermediate processing stages. Rather than providing only a final AI output, the prototype exposes the cleaned ECG image, detected lead regions, and experimental waveform representations. This provides researchers with an opportunity to inspect the computational pipeline before AI inference.

The implementation also incorporates basic error handling, session-state management, input restrictions, waveform completeness gating, and repeated warnings regarding the experimental nature of the system.

Nevertheless, the current software should be considered a research and development prototype rather than a clinical diagnostic system. The supplied source code does not establish the accuracy of image processing, waveform reconstruction, or AI prediction. Further technical validation, independent testing, clinical evaluation, model calibration, and regulatory assessment would be required before any clinical application could be considered.

Overall, the prototype establishes a practical software framework for investigating the transformation of ECG images into machine-readable waveform representations and subsequently applying artificial intelligence to those representations.

Abstract

Background

Patient monitors display multiple physiological measurements simultaneously, including heart rate, peripheral oxygen saturation, blood pressure, respiratory rate, and end-tidal carbon dioxide. Although these measurements are readily available on bedside monitoring equipment, transferring them into a digital record can require manual transcription. Optical character recognition (OCR) provides a potential mechanism for converting monitor photographs into structured physiological data.

Objective

This paper describes the design and implementation of an educational software prototype that uses computer vision, OCR, rule-based parsing, user verification, temporal visualization, and a machine-learning trend model to transform photographs of physiological monitors into structured vital-sign observations.

Methods

The application was implemented in Python using Streamlit for the interactive web interface, Pillow for image processing, regular expressions for structured blood-pressure extraction, Pandas for tabular data management, and Plotly for temporal visualization. The processing pipeline consists of five principal stages: image acquisition, OCR-based text extraction, physiological-value parsing, human verification, and longitudinal trend analysis. A specialized blood-pressure extraction pathway supplements general OCR because systolic and diastolic pressure are commonly represented as a paired numerical expression. Extracted measurements are assigned OCR-derived confidence values when available. Verified measurements are timestamped and stored in application session state. After at least three verified observations, a machine-learning model is invoked to estimate whether the recorded trajectory is improving, stable, or worsening. Rule-based clinical reference patterns are additionally generated from selected physiological thresholds.

Results

The implemented prototype provides an end-to-end workflow from monitor-image upload to structured vital-sign display, manual verification, longitudinal tabulation, visualization, and prototype trend classification. The system supports heart rate, SpO₂, systolic and diastolic blood pressure, respiratory rate, and end-tidal carbon dioxide. It also exposes OCR confidence information and provides rule-based reference considerations for selected abnormal physiological patterns.

Conclusions

The software demonstrates the feasibility of combining OCR, structured parsing, human verification, visualization, and machine-learning methods within a lightweight clinical-data interface. However, the implementation should be regarded strictly as a research and educational prototype. OCR errors, image quality limitations, parser assumptions, limited training data, absence of clinical validation, and potential distribution shift prevent the system from being interpreted as an autonomous clinical decision-support or diagnostic system.

Keywords: optical character recognition, computer vision, vital signs, physiological monitoring, machine learning, clinical informatics, human-in-the-loop systems, medical imaging, Streamlit

1. Introduction

Physiological monitoring is fundamental to the assessment of patients in emergency, prehospital, perioperative, and critical-care environments. Modern patient monitors commonly display several physiological variables simultaneously, including heart rate (HR), peripheral oxygen saturation (SpO₂), non-invasive blood pressure (NIBP), respiratory rate (RR), and end-tidal carbon dioxide (EtCO₂).

Despite the availability of these measurements in digital monitoring systems, photographs or screenshots of monitor displays are sometimes used for documentation, education, retrospective analysis, and software prototyping. Converting such images into structured data presents a computer-vision problem because the measurements are embedded within a graphical user interface rather than provided as machine-readable numerical data.

Optical character recognition provides a general mechanism for extracting textual and numerical information from images. However, physiological monitor displays introduce additional challenges. Multiple numerical values may be present simultaneously, labels may be separated spatially from their associated values, characters may be distorted by image perspective or illumination, and measurement formats may vary between manufacturers and device models.

The prototype described in this paper was designed to investigate a human-in-the-loop workflow in which OCR initially extracts candidate values, software parsing converts those candidates into structured physiological variables, and a human operator verifies the measurements before they are incorporated into a longitudinal timeline.

The architecture additionally incorporates temporal visualization and a machine-learning component intended to characterize the direction of recorded physiological trajectories. A rule-based reference layer provides contextual information regarding selected physiological patterns.

The primary design principle is therefore not autonomous interpretation, but automated extraction followed by human verification.

2. System Objectives

The prototype was developed around six functional objectives:

• Accept a photograph of a physiological monitor.
• Extract visible numerical information using OCR.
• Convert OCR output into structured vital-sign variables.
• Provide confidence information and allow manual verification.
• Store verified observations as a time-indexed sequence.
• Analyze and visualize temporal trends using statistical, rule-based, and machine-learning components.

The system was deliberately structured so that OCR-derived values were not automatically treated as verified clinical observations.

3. System Architecture

The application follows a modular architecture consisting of an interface layer, image-processing layer, parsing layer, state-management layer, visualization layer, and analytical layer.

The high-level processing sequence is:

Monitor Photograph

│

▼

Image Upload

│

▼

Image Preprocessing / OCR

│

├───────────────┐

▼ ▼

General OCR BP-specific OCR

│ │

▼ ▼

Vital Parser BP Candidate Filter

│ │

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

▼

Structured Vital Signs

│

▼

OCR Confidence Display

│

▼

Human Verification

│

▼

Timestamped History

│

┌───────┴────────┐

▼ ▼

Visualization ML Trend Model

│ │

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

▼

Reference Considerations

This architecture establishes a separation between extraction and interpretation. The extraction subsystem attempts to recover numerical information, whereas the user remains responsible for confirming that the extracted values correspond to the source monitor.

4. Software Environment

The prototype was implemented in Python.

The principal dependencies visible in the application include:

Component	Function
Python	Core programming language
Streamlit	Interactive web application framework
Pillow	Loading and conversion of monitor images
Pandas	Tabular data representation and timeline management
Plotly	Interactive physiological trend visualization
Regular expressions	Numerical pattern recognition, particularly blood pressure
src.ocr	Application-specific OCR functions
src.parser	Application-specific physiological-value parsing
src.ml	Machine-learning trend model

The application imports three primary custom modules:

from src.ocr import extract_text, extract_bp_candidates

from src.parser import parse_vitals

and, when sufficient historical observations exist:

from src.ml import train_trend_model, predict_trend

This modular organization allows OCR, parsing, and machine-learning components to be developed independently of the graphical user interface.

5. Image Acquisition

The first stage of the workflow is image acquisition.

The interface uses Streamlit's file-upload functionality to accept JPEG and PNG images:

uploaded = st.file_uploader(

"Upload a monitor photograph",

type=["jpg", "jpeg", "png"]

)

When an image is supplied, Pillow loads the image and explicitly converts it to RGB:

image = Image.open(

uploaded

).convert("RGB")

This normalization ensures that downstream processing receives a consistent three-channel representation regardless of the original image mode.

The uploaded image is subsequently rendered within the interface so that the operator can visually inspect the source material.

6. Optical Character Recognition

6.1 General OCR

After the operator activates the monitor-reading operation, the image is passed to the general OCR subsystem:

ocr_results = extract_text(image)

The application expects the OCR subsystem to return a list of structured objects. Each object is expected to contain at least a textual representation and an associated confidence value.

Conceptually, the OCR output can be represented as:

[

{

"text": "...",

"confidence": ...

},

...

]

The application includes defensive validation:

if not isinstance(ocr_results, list):

ocr_results = []

This prevents an unexpected OCR return type from propagating directly into later stages of the application.

The OCR results are retained in application session state:

st.session_state.ocr = ocr_results

This allows the extracted text and confidence values to remain accessible after the Streamlit application reruns.

7. Physiological Value Parsing

Following OCR extraction, the recognized text is passed to a dedicated parsing function:

vitals = parse_vitals(ocr_results)

The parser converts unstructured OCR output into a structured dictionary.

The expected variables include:

• HR
• SpO₂
• systolic blood pressure
• diastolic blood pressure
• RR
• EtCO₂

The parser is also treated defensively:

if not isinstance(vitals, dict):

vitals = {}

This establishes a clear boundary between the OCR subsystem and the user interface.

A conceptual representation of the resulting object is:

{

"hr": ...,

"spo2": ...,

"bp_sys": ...,

"bp_dia": ...,

"rr": ...,

"etco2": ...

}

The exact implementation of parse_vitals() is contained in the external parser module and therefore cannot be inferred completely from the provided interface code. Consequently, this manuscript describes the observable interface contract rather than assuming a specific internal parsing algorithm.

8. Specialized Blood-Pressure Extraction

Blood pressure receives an additional processing pathway.

This design is important because blood pressure is represented as a paired measurement rather than a single numerical value. The prototype therefore calls:

bp_results = extract_bp_candidates(image)

Candidate text is subsequently examined using a regular expression:

r"(\d{2,3})\s*[/\-]\s*(\d{2,3})"

This expression recognizes patterns such as:

120/80

120 - 80

The extracted components are interpreted as systolic and diastolic pressure.

The prototype then applies physiological plausibility constraints:

50 <= systolic <= 250

20 <= diastolic <= 150

systolic > diastolic

Candidates failing these criteria are discarded.

If multiple valid candidates are detected, the candidate with the highest OCR confidence is selected.

This creates a simple confidence-based candidate-selection mechanism:

Candidate BP values

│

▼

Regex pattern matching

│

▼

Numerical validation

│

▼

Plausible candidates

│

▼

Highest OCR confidence

│

▼

Selected BP

The resulting blood-pressure values are then inserted into the structured vital-sign dictionary.

9. Confidence Estimation

The application incorporates a confidence-display mechanism to communicate uncertainty associated with OCR extraction.

The find_confidence() function first searches for a parser-provided confidence value:

parser_confidence = vitals.get(

f"{vital_name}_confidence"

)

If a parser-specific confidence value is unavailable, the application searches the raw OCR results for a numerical match corresponding to the extracted vital.

For example, if the structured heart rate is 82, the algorithm examines OCR outputs for a numerical value matching 82 and retains the highest associated confidence.

For blood pressure, the function instead searches for OCR text containing a slash, reflecting the paired representation of the measurement.

The resulting confidence is classified into three presentation levels:

• High: ≥ 0.80
• Medium: 0.50–0.79
• Low: < 0.50

These thresholds affect presentation only. They do not constitute experimentally validated probabilities of correct physiological extraction.

This distinction is important because OCR confidence is not necessarily equivalent to clinical correctness.

10. Data Validation and Defensive Programming

The interface includes several mechanisms intended to prevent malformed data from causing invalid displays or application failures.

The safe_int() function verifies that values are numerical and fall within specified limits before converting them to integers.

For example:

safe_int(

hr,

0,

300

)

is used to initialize the manually editable HR field.

The interface similarly imposes explicit numerical limits on user-entered verification values.

Examples include:

HR: 0–300 bpm

SpO₂: 0–100%

Systolic BP: 0–300 mmHg

Diastolic BP: 0–200 mmHg

RR: 0–100/min

EtCO₂: 0–150 mmHg

These bounds are primarily software safeguards rather than validated clinical reference ranges.

11. Human Verification Layer

A central feature of the architecture is the manual verification stage.

Extracted measurements are displayed to the user before being added to the longitudinal record.

The interface explicitly instructs the operator to compare the displayed values against the physical monitor.

The user can modify:

• HR
• SpO₂
• systolic BP
• diastolic BP
• RR
• EtCO₂

Only after the operator activates the verification control is the observation added to the historical dataset.

This produces a human-in-the-loop pipeline:

OCR extraction

↓

Automated parsing

↓

Displayed candidate values

↓

Human verification/correction

↓

Verified observation

This design substantially changes the interpretation of the resulting dataset. The longitudinal history represents user-confirmed values, rather than purely automated OCR output.

12. Temporal Data Representation

Verified observations are stored using Streamlit's session-state mechanism.

Each observation contains:

{

"time": datetime.now(),

"HR": verified_hr,

"SpO2": verified_spo2,

"BP Sys": verified_sys,

"BP Dia": verified_dia,

"RR": verified_rr,

"EtCO2": verified_etco2

}

Consequently, each record consists of a timestamp and six physiological variables.

The history is subsequently converted into a Pandas DataFrame:

df = pd.DataFrame(

st.session_state.history

)

This representation allows the observations to be displayed in tabular form and passed to downstream visualization and machine-learning routines.

13. Visualization of Physiological Trends

The temporal data are visualized using Plotly.

A line-and-marker trace is generated for:

• HR
• SpO₂
• RR
• EtCO₂

Blood pressure is retained in the tabular history but is not plotted in the provided trend graph.

Each variable is added as a separate Plotly trace:

go.Scatter(

x=chart_df["time"],

y=chart_df[column],

mode="lines+markers",

name=column

)

The visualization uses a white plotting template and includes labeled axes.

The purpose of the graph is descriptive: it allows an operator to inspect temporal trajectories rather than relying exclusively on individual measurements.

14. Machine-Learning Trend Analysis

A machine-learning subsystem is activated when at least three verified observations have been recorded.

The application dynamically imports:

from src.ml import (

train_trend_model,

predict_trend

)

The model is trained through:

model = train_trend_model()

and subsequently applied to the recorded history:

prediction, confidence, probabilities = (

predict_trend(

model,

st.session_state.history

)

)

The model returns three principal outputs:

• A categorical trend prediction.
• A model confidence value.
• A dictionary of class probabilities.

The categorical output has three possible states:

Improving

Stable

Worsening

The interface presents the class probabilities separately.

Importantly, the provided code does not reveal the internal implementation of train_trend_model() or predict_trend(). Therefore, characteristics such as the machine-learning algorithm, feature engineering procedure, training-set size, class balance, validation strategy, and performance metrics cannot be scientifically established from the supplied interface code alone.

The application's own labeling appropriately identifies this component as a prototype trend estimator rather than a validated clinical deterioration score.

15. Clinical Reference Layer

The application contains a rule-based reference subsystem that evaluates selected physiological measurements against predefined thresholds.

The implementation evaluates:

• HR > 100 bpm
• HR < 60 bpm
• SpO₂ < 94%
• systolic BP < 90 mmHg
• RR > 20/min
• EtCO₂ < 35 mmHg

When a threshold is met, the corresponding pattern is displayed along with a list of possible clinical considerations.

For example, an elevated HR triggers a "tachycardia pattern" containing possible considerations such as physiological stress, fever, hypovolemia, hypoxemia, medication effects, and cardiac rhythm disturbance.

These rules are implemented using straightforward conditional statements rather than a probabilistic diagnostic model.

For example:

if (

isinstance(hr_value, (int, float))

and hr_value > 100

):

The output is therefore better characterized as a rule-based clinical reference layer rather than an automated diagnostic system.

The application explicitly communicates that these considerations are not diagnoses.

16. User Interface Design

The interface was implemented entirely within Streamlit.

The major interface sections are:

• Patient context
• Monitor image upload
• Extracted vital signs
• Verification controls
• OCR details
• Patient timeline
• Trend graph
• Machine-learning trend estimate
• Clinical reference considerations

Custom CSS is embedded through Streamlit's Markdown functionality.

The styling creates:

• high-contrast vital-sign cards,
• confidence indicators,
• warning panels,
• reference panels,
• a wide application layout,
• visual separation between functional sections.

The design therefore emphasizes rapid interpretation of structured values while preserving access to the underlying OCR results.

17. Application State Management

Because Streamlit applications rerun portions of the Python script when users interact with widgets, persistent information is maintained through st.session_state.

Three principal state variables are initialized:

st.session_state.vitals

st.session_state.ocr

st.session_state.history

They represent:

State variable	Purpose
vitals	Most recently parsed physiological values
ocr	Most recent OCR output
history	User-verified longitudinal observations

This state model allows the application to preserve the patient's recorded timeline across interface interactions during the active application session.

The supplied implementation does not show persistent database storage. Therefore, the history should be interpreted as session-level application state rather than a permanent medical record.

18. Error Handling

The principal image-processing workflow is enclosed in a try/except block.

If OCR, parsing, blood-pressure extraction, or another operation raises an exception, the interface reports the error rather than terminating the entire application.

Similarly, machine-learning execution is isolated within its own error-handling block:

try:

...

except Exception as e:

st.warning(

f"ML trend model unavailable: {e}"

)

This allows the core extraction and visualization workflow to remain usable if the optional trend-analysis subsystem fails.

19. Safety-Oriented Design

The prototype incorporates several safeguards intended to reduce inappropriate interpretation.

First, automated OCR values are explicitly presented as values requiring verification.

Second, the application separates extracted values from verified values.

Third, the machine-learning component is explicitly labeled as a prototype trend estimate.

Fourth, the clinical-reference layer is explicitly described as non-diagnostic.

Finally, the interface instructs users to compare extracted values with the original monitor and patient assessment.

These design decisions establish a decision-support boundary in which the software assists with transcription and visualization but does not replace clinical assessment.

20. Discussion

The implemented architecture demonstrates how multiple relatively simple computational components can be combined into an end-to-end physiological-data pipeline.

The first contribution is the integration of image-based extraction with structured physiological parsing. Rather than requiring manual transcription from every monitor photograph, OCR can provide candidate numerical values that are subsequently normalized into a predefined schema.

The second contribution is the use of a specialized blood-pressure extraction pathway. Blood pressure presents a different parsing problem because its two components must be identified together. Regular-expression matching and physiological plausibility filtering provide a lightweight mechanism for rejecting obviously inappropriate candidates.

The third contribution is the human-verification architecture. Instead of assuming OCR output is correct, the system explicitly inserts a human confirmation stage before measurements enter the longitudinal dataset. This is particularly important because OCR errors may result from glare, blur, image perspective, character segmentation, monitor typography, or overlapping graphical elements.

The fourth contribution is the integration of temporal visualization. Once measurements are verified, individual observations can be transformed into a time series, making changes in HR, SpO₂, RR, and EtCO₂ easier to inspect.

Finally, the prototype demonstrates how a machine-learning layer can be incorporated after data acquisition. However, the usefulness of such a model depends strongly on the quality, size, representativeness, labeling methodology, and validation of its training data.

21. Limitations

Several limitations should be considered.

21.1 OCR Performance

OCR accuracy is dependent on the quality of the input image and the underlying OCR implementation. The provided code does not specify the OCR engine, preprocessing operations, image segmentation strategy, character-recognition architecture, or benchmark performance.

Consequently, sensitivity and specificity for individual vital signs cannot be calculated from the interface code alone.

21.2 Monitor Variability

Different monitor manufacturers and models may use different fonts, layouts, colors, abbreviations, and numerical arrangements. A parser developed around one display configuration may therefore perform differently on another.

21.3 Blood-Pressure Parsing

The blood-pressure regular expression assumes a relatively conventional numerical representation. Alternative display formats may not be recognized.

The numerical plausibility constraints also prevent certain values from being selected even if they were correctly displayed by an unusual monitor configuration.

21.4 Confidence Interpretation

OCR confidence is used as a proxy for extraction reliability, but it should not automatically be interpreted as the probability that the physiological value is clinically correct.

21.5 Machine-Learning Validation

The machine-learning implementation is external to the supplied interface code. The training data, feature construction, model architecture, class definitions, cross-validation strategy, and independent test performance are not provided.

Therefore, no claims regarding model accuracy, sensitivity, specificity, calibration, generalizability, or clinical utility can be made from the supplied code.

21.6 Limited Temporal Data

The machine-learning component requires only three observations before producing an estimate. From a scientific perspective, three observations may provide very limited information about a physiological trajectory.

The minimum-observation requirement should therefore not be confused with evidence that three measurements are sufficient for reliable clinical trend prediction.

21.7 Lack of Persistent Clinical Storage

The supplied application stores historical measurements in Streamlit session state. No electronic health record integration, database layer, audit log, or durable patient-record mechanism is demonstrated.

21.8 Rule-Based Reference Thresholds

The clinical reference subsystem uses fixed numerical thresholds. Physiological interpretation can depend on age, baseline physiology, clinical context, treatment, environment, and measurement conditions. Consequently, threshold-triggered text should not be interpreted as individualized diagnosis.

22. Reproducibility and Future Evaluation

A rigorous evaluation of the prototype would require a dedicated dataset of monitor photographs with ground-truth annotations.

A suitable evaluation protocol could contain the following stages:

Stage 1: Image Dataset Construction

Collect monitor images representing different:

• monitor manufacturers,
• display layouts,
• lighting conditions,
• camera angles,
• image resolutions,
• patient-monitor configurations,
• physiological value ranges.

Stage 2: Ground-Truth Annotation

Each image should be manually annotated for:

• HR,
• SpO₂,
• systolic BP,
• diastolic BP,
• RR,
• EtCO₂.

The ground truth should be independently verified against the original monitor output.

Stage 3: OCR Evaluation

Measure:

• character-level recognition accuracy,
• numerical recognition accuracy,
• vital-sign extraction accuracy,
• false-positive rate,
• missing-value rate.

Stage 4: Parser Evaluation

Compare parsed values with ground truth and calculate variable-specific metrics.

Stage 5: Blood-Pressure Evaluation

Evaluate systolic and diastolic pressure independently and jointly, including cases containing visually ambiguous characters.

Stage 6: Human-in-the-Loop Evaluation

Measure the proportion of OCR outputs requiring manual correction and the time required to verify each observation.

Stage 7: Machine-Learning Evaluation

For the trend model, an independent dataset should be used for testing.

Potential metrics include:

• accuracy,
• precision,
• recall,
• F1 score,
• confusion matrix,
• calibration,
• class-specific sensitivity,
• temporal generalization.

Importantly, the test data should remain independent from the training data to prevent optimistic performance estimates.

23. Proposed Experimental Methodology

A formal study could compare three workflows:

Workflow A — Manual transcription

Monitor image → Human reads → Manual entry

Workflow B — OCR-assisted transcription

Monitor image → OCR → Human verification

Workflow C — Automated extraction

Monitor image → OCR → Parser → Automated record

Workflow B would be particularly informative because it reflects the architecture implemented in the prototype.

Primary outcome measures could include:

• Time required to produce a verified vital-sign record.
• Numerical transcription error rate.
• Percentage of observations requiring correction.
• Agreement between extracted and ground-truth values.
• User-reported workload.

This experimental design would permit assessment of whether OCR assistance reduces transcription burden while maintaining human oversight.

24. Ethical and Clinical Considerations

A system processing physiological information must distinguish between technical extraction and clinical interpretation.

The prototype's architecture appropriately separates these functions. OCR identifies candidate information from an image; verification establishes the values that enter the historical record; visualization represents temporal data; and the reference layer provides possible contextual considerations.

None of these operations independently establishes a diagnosis.

Before deployment in clinical environments, additional considerations would include:

• patient privacy,
• secure image handling,
• access control,
• auditability,
• data retention,
• model validation,
• clinical governance,
• usability testing,
• regulatory classification,
• human-factors evaluation,
• monitoring for systematic extraction errors.

In particular, performance should be evaluated across the diversity of monitor displays and clinical contexts in which the system is intended to operate.

25. Conclusion

This paper describes an educational prototype that combines computer vision, OCR, rule-based numerical parsing, human verification, temporal data visualization, machine-learning trend estimation, and clinical reference rules within a single Python-based application.

The architecture follows a sequential human-in-the-loop workflow:

Image

↓

OCR

↓

Structured parsing

↓

Confidence assessment

↓

Human verification

↓

Timestamped physiological history

↓

Visualization

↓

Prototype trend analysis

↓

Reference considerations

The principal engineering feature is the separation between automated extraction and verified clinical data. This approach recognizes that OCR output can contain errors and therefore should not automatically become part of a longitudinal physiological record.

The prototype demonstrates the technical feasibility of transforming photographs of physiological monitors into structured observations and subsequently analyzing those observations over time. Nevertheless, the current implementation does not provide evidence of clinical accuracy or clinical effectiveness. In particular, the OCR subsystem, parsing subsystem, and machine-learning model require independent validation before quantitative claims regarding performance can be established.

Accordingly, the system is best understood as a research and educational prototype illustrating the integration of computer vision and machine learning into physiological-data workflows rather than as an autonomous diagnostic or clinical decision-making system.

1. Project Title

Development of an Artificial Intelligence Machine Learning EMS Injury Assessment Prototype Combining Computer Vision, Machine Learning, and Protocol-Based Information

2. Project Overview

The AI EMS Assessment system was developed as an experimental software prototype designed to demonstrate how artificial intelligence could combine image classification and patient information within a single EMS-oriented interface.

The system combines three primary components:

• Computer vision for classification of injury photographs.
• Machine learning for a prototype risk estimate based on patient information and vital signs.
• Protocol-based information associated with the predicted injury category.

The system was implemented using Python and Streamlit. The computer-vision component uses a ResNet-18 neural network architecture through the timm library. The risk component uses a previously trained machine-learning model loaded through joblib.

The prototype was developed for educational and research purposes and was not designed or validated as an autonomous clinical decision-making system.

3. Development Objective

The primary development objective was to create a functional prototype capable of accepting two forms of information:

Patient information

• Age
• Pain score
• Heart rate
• Systolic blood pressure
• Diastolic blood pressure
• SpO₂
• Respiratory rate
• GCS

Visual information

• Injury photograph

The system processes these inputs and produces an integrated output containing:

• Predicted injury classification
• Model confidence
• Classification probabilities
• Patient vital signs
• Prototype risk estimate
• Screening flags
• Protocol-based considerations
• Model limitations

4. System Architecture

The prototype follows the general architecture:

USER INPUT

│

┌────────────┴────────────┐

│ │

Patient Data Injury Image

│ │

│ ▼

│ Image Preprocessing

│ │

│ ▼

│ ResNet-18 Model

│ │

│ ▼

│ Injury Classification

│ │

▼ │

Risk Model │

│ │

▼ │

Risk Estimate │

│ │

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

│

▼

Integrated Assessment

│

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

│ │ │

▼ ▼ ▼

Findings Protocol Confidence

The design intentionally separates the computer-vision model from the risk model. Each model performs a different computational task.

5. Software Development Environment

The prototype was implemented in Python.

The primary libraries used were:

Library	Function
Streamlit	Web-based user interface
PyTorch	Neural-network inference
torchvision	Image preprocessing
timm	ResNet-18 model architecture
pandas	Patient-data organization
Pillow	Image loading and conversion
joblib	Loading the risk model
protocols.py	Protocol-information system

6. User Interface Development

Streamlit was selected to provide a simple interface between the user and the underlying machine-learning models.

The application was configured with:

• Wide page layout
• EMS-themed title
• Sidebar for patient information
• Injury-image upload area
• Assessment button
• Results sections
• Warning messages
• Model limitation information

The application begins by displaying an educational/research warning indicating that the system has not been clinically validated.

This warning is an important part of the prototype design because the computational outputs are not intended to be represented as established medical diagnoses.

7. Patient Input Module

The patient-input module was developed using Streamlit input controls.

The user can enter:

Age

Pain

Heart Rate

Systolic Blood Pressure

Diastolic Blood Pressure

SpO₂

Respiratory Rate

GCS

Each variable has an appropriate numerical range within the interface.

For example, heart rate is restricted to a range of 0–300, while GCS is restricted to 3–15.

The values are collected and organized into a pandas DataFrame.

The resulting structure is:

age

heart_rate

systolic_bp

diastolic_bp

spo2

respiratory_rate

gcs

pain

This structure is passed to the trained risk model.

8. Injury Image Module

The image-analysis component allows the user to upload an injury photograph.

The application accepts:

.jpg

.jpeg

.png

When an image is uploaded, it is opened using Pillow and converted to RGB format.

This standardizes the image representation before it is passed to the neural network.

9. Image Preprocessing

Before being analyzed by the neural network, each image passes through a preprocessing pipeline.

The image is resized to:

224 × 224 pixels

It is then converted to a PyTorch tensor.

Finally, the tensor is normalized using:

Mean:

[0.485, 0.456, 0.406]

Standard deviation:

[0.229, 0.224, 0.225]

The resulting tensor is expanded to include a batch dimension before being passed to the neural network.

The preprocessing pipeline can be represented as:

Original Image

↓

RGB Conversion

↓

224 × 224 Resize

↓

Tensor Conversion

↓

Normalization

↓

Batch Dimension

↓

Neural Network

10. Computer-Vision Model

The computer-vision component uses a ResNet-18 convolutional neural network architecture.

The model is created using the timm library.

The application does not use pretrained ImageNet weights during inference. Instead, it creates a ResNet-18 architecture with the number of output classes determined by the classes stored in the trained checkpoint.

The trained model parameters are loaded from:

injury_model.pth

The checkpoint contains:

model_state

classes

The model_state contains the learned neural-network parameters.

The classes value provides the injury categories recognized by the model.

11. Model Loading

The trained model is loaded using PyTorch.

The checkpoint is loaded with:

map_location="cpu"

This allows the prototype to run inference on a computer without requiring a dedicated GPU.

After loading the trained parameters, the model is placed into evaluation mode.

This ensures that the model operates as an inference model rather than performing training operations.

12. Prediction Process

When the user selects:

RUN AI ASSESSMENT

the uploaded image is transformed into the required tensor representation.

The tensor is then passed through the injury-classification model.

The neural network produces a vector of output values corresponding to the possible injury classes.

These raw outputs are converted into probabilities using the softmax function.

Conceptually:

Model Output

↓

Softmax

↓

Class Probabilities

↓

Highest Probability

↓

Predicted Injury

The class with the highest probability is selected as the model's predicted injury.

13. Confidence Calculation

The highest probability produced by the softmax function is displayed as the model's confidence.

For example:

Abrasion 0.82

Burn 0.07

Cut 0.08

Laceration 0.03

The system would report:

Predicted Finding: Abrasion

Confidence: 82%

The application also displays the complete probability distribution as a bar chart.

This allows the user to see not only the selected prediction but also the model's relative probabilities for other classes.

14. Risk-Model Development and Integration

A separate machine-learning model is loaded from:

risk_model.pkl

The model is loaded using joblib.

The application constructs a single patient-data row containing:

age

heart_rate

systolic_bp

diastolic_bp

spo2

respiratory_rate

gcs

pain

The data are passed to the model for prediction.

The model generates:

• A predicted risk class.
• Probabilities for the available risk classes.

The application obtains these values through the model's:

predict()

predict_proba()

methods.

15. Risk-Output Display

The prototype displays the predicted risk category using three visual states:

High → Red

Moderate → Yellow

Low → Green

The probabilities for each available risk class are also displayed.

For example:

High: 15%

Moderate: 25%

Low: 60%

These values represent the output of the trained prototype model.

Because the risk model was trained using synthetic data, the output is explicitly described in the application as a prototype risk estimate rather than a validated clinical risk assessment.

16. Rule-Based Screening Layer

In addition to the machine-learning models, the system contains a simple rule-based screening layer.

The prototype checks several patient variables.

The implemented conditions include:

Heart rate > 120

Systolic BP < 90

SpO₂ < 92

Respiratory rate > 28

GCS < 13

Pain ≥ 8

When a threshold is exceeded or falls below the specified value, the system adds a corresponding screening finding.

For example:

Heart rate > 120

↓

Prototype screening flag

This component is intentionally transparent: unlike the neural network, the conditions are explicitly defined in the software.

17. Findings Module

The findings module combines the image-classification result with the rule-based screening information.

The first finding reports the image classifier's prediction and confidence.

Additional findings are generated if the patient's input values meet any of the prototype screening thresholds.

If no additional thresholds are triggered, the application reports that no additional prototype screening flags were triggered.

This creates a simple summary of the information processed by the application.

18. Protocol Module

The application includes a separate protocol-information component:

protocols.py

The predicted injury class is passed to:

get_protocol(predicted_class)

The function returns protocol-related information including:

title

considerations

The application displays the title and individual considerations.

The application also displays:

PROTOCOL_SOURCE

PROTOCOL_NOTE

This design separates protocol information from the machine-learning model itself.

Therefore, protocol content can be updated independently from the neural-network model.

19. Caching and Performance

The application uses Streamlit's resource caching mechanism:

@st.cache_resource

This is applied to the model-loading functions.

The purpose is to prevent the trained models from being repeatedly loaded every time Streamlit reruns the application.

This improves application responsiveness and reduces unnecessary model-loading operations.

20. Safety and Limitations by Design

Several limitations are explicitly incorporated into the software.

The application states that:

• The system is an educational/research prototype.
• The computer-vision model was trained on a limited wound-image dataset.
• Validation accuracy does not constitute clinical validation.
• The risk model was trained using synthetic data.
• Model confidence does not represent clinical certainty.
• Protocol considerations must be checked against current local guidance.

These statements are included to distinguish software/model performance from clinical validation.

21. Development Testing

After development, the system was evaluated using a test set of 100 injury images.

The evaluation compared the AI's predicted injury classification with the reference classification.

The results were:

Measurement	Result
Images tested	100
Correct classifications	94
Incorrect classifications	6
Overall accuracy	94%
Highest-confidence prediction correct	90%

The model therefore achieved an observed classification accuracy of:

94%

on the evaluated 100-image dataset.

22. Interpretation of Development Results

The 94% result demonstrates the performance of the implemented model on the particular test dataset used in the evaluation.

It does not demonstrate that the system will achieve 94% accuracy on all injury photographs.

The difference between the 94% classification accuracy and the 90% highest-confidence correctness rate also indicates that the model's confidence output should not be treated as equivalent to diagnostic certainty.

The six incorrectly classified images should be retained for error analysis rather than removed from the evaluation.

23. Development Workflow

The overall development process can be summarized as follows:

1. Define project objective

↓

2. Obtain/prepare injury image data

↓

3. Develop/train injury classification model

↓

4. Save trained model checkpoint

↓

5. Develop patient-input interface

↓

6. Develop risk model

↓

7. Develop protocol-information module

↓

8. Integrate components using Streamlit

↓

9. Add screening rules and output displays

↓

10. Test complete application

↓

11. Evaluate 100 test images

↓

12. Analyze accuracy and errors

24. Reproducibility

For the experiment to be reproducible, the following should be preserved:

• Model checkpoint
• Model class labels
• Test image dataset
• Reference classifications
• Image preprocessing procedure
• Software version information
• Source code
• Risk model
• Protocol file
• Evaluation results

Any changes to the model, test dataset, preprocessing method, or evaluation procedure should be documented.

25. Scientific Development Summary

The AI EMS Assessment prototype was developed as a modular Python-based system combining computer vision, machine learning, rule-based screening, and protocol information.

A ResNet-18 convolutional neural network was used for injury-image classification. Uploaded images were converted to RGB format, resized to 224 × 224 pixels, converted to tensors, normalized, and processed by the trained network. Softmax probabilities were used to identify the highest-probability injury classification.

A separate machine-learning model processed patient characteristics and vital signs to generate a prototype risk estimate. A rule-based layer independently identified predefined screening thresholds. Finally, a protocol module associated the predicted injury category with informational protocol considerations.

The integrated system was implemented using Streamlit to provide an interactive interface for entering patient information, uploading images, and viewing model outputs.

In an initial evaluation using 100 injury images, the injury classifier correctly identified 94 images (94%). The highest-confidence prediction corresponded to the reference classification in 90 cases (90%).

These results provide an initial technical evaluation of the prototype. They do not establish clinical validity, clinical safety, or effectiveness. Further testing with larger, independent, and appropriately representative datasets would be required before drawing conclusions about real-world clinical performance.

Development of Paramedic AI Scientist: An Artificial Intelligence–Assisted Platform for EMS Evidence Review, Hypothesis Generation, and Computational Research

Abstract

Artificial intelligence (AI) systems are increasingly being investigated as tools for scientific literature analysis, hypothesis generation, data analysis, and computational experimentation. Large language models (LLMs) have demonstrated potential for generating scientific hypotheses and assisting researchers with complex knowledge-based tasks, although their outputs require independent validation and expert oversight. Recent research has specifically investigated the use of LLMs for automated scientific hypothesis generation and has demonstrated both the potential and limitations of this approach [1,2].

This paper describes the development of Paramedic AI Scientist, a Python-based artificial intelligence research assistant designed for emergency medical services (EMS) evidence review, clinical research, patient simulation, clinical prediction, retrospective data analysis, and quality-improvement research. The system integrates scientific literature retrieval, AI-generated hypothesis development, experiment selection, Python code generation, controlled computational execution, result analysis, experiment storage, and automated research-report generation within a Streamlit-based web application.

The system additionally incorporates structured EMS patient-case representation using PatientCase and VitalSigns models, allowing users to enter demographic information, chief complaint, relevant history, physical examination findings, and physiological observations including heart rate, respiratory rate, SpO₂, and ETCO₂.

A distinguishing feature of Paramedic AI Scientist is its ability to generate computational experiments from natural-language research questions. Generated Python code is cleaned, inspected for prohibited operations, executed within a temporary file with a 60-second execution limit, and subsequently analyzed by the AI system. Experimental code, outputs, and analyses are retained as structured research history and can be incorporated into an automatically generated final research report.

The application is intended as a research and educational prototype rather than an autonomous clinical decision-making system. AI-generated hypotheses, software, interpretations, and conclusions require human verification. The paper describes the system architecture, research workflow, code-execution safeguards, EMS case integration, limitations, and potential future applications.

Keywords

artificial intelligence; large language models; emergency medical services; paramedic education; scientific research; hypothesis generation; computational experiments; clinical research; EMS research; Python; Streamlit; machine learning

Introduction

Artificial intelligence is increasingly being investigated as an instrument for supporting scientific research. Large language models can process large quantities of textual information, generate candidate hypotheses, summarize evidence, write computational code, and assist with analytical workflows. Recent research has specifically explored the use of LLMs for scientific hypothesis generation, including systems designed to generate hypotheses from open-domain scientific information [1,2].

Zhou et al. investigated hypothesis generation using LLMs and reported that generated hypotheses could improve predictive performance in several experimental settings while also identifying insights that were consistent with established theories or potentially novel for the evaluated tasks [1]. Yang et al. subsequently investigated automated open-domain scientific hypothesis discovery using LLMs and described a multi-module approach for generating and evaluating scientific hypotheses from broad textual information [2].

The potential role of LLMs in scientific research has also progressed beyond purely textual hypothesis generation. Recent experimental research has investigated LLM-generated scientific hypotheses followed by laboratory testing, demonstrating a workflow in which AI-generated propositions can be subjected to empirical evaluation rather than being accepted solely on the basis of language-model output [3].

These developments suggest a possible model in which AI assists with several stages of the research process while empirical experimentation remains responsible for determining whether a proposed hypothesis is supported.

Paramedic AI Scientist was developed as a prototype based on this concept, adapted specifically for EMS and paramedic-oriented research.

Rather than functioning solely as a conversational chatbot, the system provides a structured research workflow:

Research Question → Literature Search → Hypothesis Generation → Experiment Selection → Python Experiment Generation → Code Validation → Experiment Execution → Result Analysis → Research History → Final Research Report

The application is designed to demonstrate how these functions can be integrated into a single research environment.

System Overview

Paramedic AI Scientist is implemented as a Python-based web application using Streamlit.

The application provides a graphical interface through which the user can define a research question, select a research mode, configure the number of experiments, construct an EMS patient case, initiate literature retrieval, review generated hypotheses, execute computational experiments, inspect experimental results, and generate a final research report.

The system provides six research modes:

• Clinical Evidence Review
• EMS Protocol Research
• Clinical Prediction Model
• Patient Simulation
• Retrospective Data Analysis
• Quality Improvement

The research mode provides contextual organization for the intended research activity, while the natural-language research question serves as the principal input to the scientific workflow.

The application also provides an experiment-count control allowing between one and five experiments to be requested within a research session. The interface recommends one to three experiments under current API constraints.

Natural-Language Research Questions

The research workflow begins with a natural-language research question.

Users are not required to specify a programming language, statistical test, dataset structure, or experimental procedure manually. Instead, the question is provided to the AI research system, which subsequently determines potential hypotheses and experimental approaches.

This design attempts to lower the technical barrier to computational research by allowing a researcher or student to begin with a conventional scientific question.

For example, a question could investigate whether one machine-learning algorithm performs better than another on a defined dataset, whether a particular predictive feature improves classification, or whether a simulated EMS intervention produces a measurable difference under specified conditions.

The system does not assume that the generated experiment constitutes valid scientific evidence. Rather, the natural-language question serves as the starting point from which candidate research approaches are developed.

Scientific Literature Search

The first research stage is literature retrieval.

When the user initiates a research session, the application calls the search_papers() function using the research question as the search input.

The current implementation requests a maximum of three papers.

Retrieved papers are stored in Streamlit session state and presented within expandable interface components. For each paper, the application displays the available title, abstract, and author information.

This stage provides an external evidence component before hypothesis generation.

The separation is important because the application does not rely exclusively on the language model's internal knowledge. Instead, retrieved scientific literature is explicitly supplied to the hypothesis-generation function.

This general architecture is consistent with broader research into retrieval-supported language-model systems, where external information retrieval can supplement knowledge encoded within a language model [4].

The current implementation searches arXiv, meaning that the retrieved material should not automatically be interpreted as equivalent to peer-reviewed clinical literature. A future implementation could incorporate additional bibliographic databases and distinguish peer-reviewed publications, preprints, guidelines, systematic reviews, and other source types.

AI-Assisted Hypothesis Generation

After literature retrieval, Paramedic AI Scientist calls generate_hypotheses().

The function receives both the original research question and the retrieved papers.

The system is designed to produce structured hypotheses rather than a single conversational answer.

Each hypothesis can contain:

• Hypothesis
• Reasoning
• Proposed experiment
• Expected result
• Falsification criteria

The inclusion of a falsification field is particularly relevant to scientific reasoning because the system is encouraged to identify conditions under which the proposed hypothesis would not be supported.

The design therefore attempts to distinguish between:

• "What might be true?"
• "What experiment could demonstrate that it is not true?"

This structure reflects emerging research into LLM-supported scientific hypothesis generation. However, the existence of an AI-generated hypothesis does not establish novelty, plausibility, causality, or scientific validity. Independent review and empirical testing remain necessary [1–3].

Hypothesis Selection and Experiment Planning

Following hypothesis generation, the application invokes choose_experiment().

The function receives three principal inputs:

1. The original research question.
2. The generated hypotheses.
3. The history of experiments already conducted during the current session.

The returned decision identifies a selected hypothesis and an experiment goal.

The selected hypothesis and experiment goal are explicitly displayed within the interface.

This design creates an intermediate planning stage between hypothesis generation and code generation.

The architecture therefore does not immediately convert the first generated hypothesis into executable code. Instead, an experiment-selection component is used to determine which proposed investigation should be pursued.

The inclusion of previous experiment history also creates the possibility of iterative research. Subsequent experiments can be selected with knowledge of earlier computational results.

AI-Generated Computational Experiments

After an experiment has been selected, the system invokes generate_experiment().

The function receives:

• The research question.
• The selected hypothesis.
• The experiment goal.

It then generates Python source code intended to test the proposed research question.

The application immediately passes the generated code through clean_python_code().

The generated Python code is subsequently displayed to the user in an expandable code section.

This is an important transparency feature because the user can inspect the computational methodology generated by the AI rather than seeing only the final result.

The architecture consequently separates three distinct elements:

• AI-generated methodology
• Executable computational procedure
• Experimental result

This distinction is important because a computational result is only meaningful in relation to the code and assumptions that produced it.

AI-Generated Code and Scientific Reproducibility

The system retains the generated Python code as part of each experiment record.

Each experimental record includes:

• Experiment number
• Selected hypothesis
• Experiment goal
• Generated Python code
• Experimental output
• Scientific analysis

This allows the computational procedure to be retained alongside its result.

Such preservation is important for reproducibility because a research conclusion cannot be meaningfully reproduced if the computational procedure that produced it is unavailable.

Future versions could extend this functionality by storing additional metadata including Python version, package versions, dataset identifiers, random seeds, model identifiers, timestamps, and execution-environment information.

These additions would make it possible to distinguish between merely recording an AI-generated answer and creating a reproducible computational research artifact.

Generated-Code Safety Controls

A particularly significant feature of Paramedic AI Scientist is that it executes AI-generated Python code.

Because generated code can potentially contain unsafe operations, the application includes an explicit validation layer before execution.

The validate_experiment_code() function compares the generated source against a list of prohibited patterns.

The current implementation blocks operations associated with:

• os.system
• subprocess
• shutil
• socket
• requests
• urllib
• httpx
• exec()
• eval()
• __import__
• import os
• import sys
• import subprocess

If a prohibited pattern is identified, the experiment is blocked and the system reports the potentially unsafe operation.

The need for such controls is supported by emerging research on LLM-generated code security. Recent research has demonstrated that AI-generated source code can contain security vulnerabilities and that code-generation security remains an active area of investigation [5,6].

The validation system used by Paramedic AI Scientist should therefore be regarded as a basic application-level safeguard rather than a complete security sandbox.

Pattern matching cannot guarantee that arbitrary generated code is safe.

A production implementation would require stronger isolation, potentially including:

• Containerized execution
• Restricted filesystem access
• Network isolation
• Resource quotas
• Non-privileged execution
• Process isolation
• Dependency restrictions
• System-call restrictions
• Runtime monitoring
• Independent security testing

This distinction is particularly important because the current application uses Python's subprocess.run() to execute the generated experiment after the source-level validation stage.

Controlled Experiment Execution

Validated experiment code is written to a temporary Python file using tempfile.NamedTemporaryFile().

The generated program is then executed using a separate Python process.

The execution environment sets:

PYTHONIOENCODING=utf-8

This is intended to provide consistent handling of Unicode output, particularly on Windows systems.

The experiment captures standard output and standard error.

Successful standard output is returned as the experiment result.

If the experiment generates warnings through standard error, those warnings are appended to the displayed output.

If the experiment terminates with an error, the application reports the error and includes the relevant portion of the generated error output.

A 60-second execution timeout is also implemented.

If the experiment exceeds the time limit, execution is terminated and the system reports that the experiment exceeded the permitted runtime.

Temporary experiment files are subsequently removed.

The result is therefore a controlled computational workflow rather than unrestricted execution from the user interface.

Experimental Result Analysis

After execution, the experimental output is passed to analyze_results().

The analysis function receives:

• Research question
• Selected hypothesis
• Experimental output

The AI-generated analysis is then presented in a dedicated Scientific Analysis section.

This architecture separates the computational experiment from its natural-language interpretation.

The Python program produces the computational result.

The AI analysis component subsequently interprets that result in relation to the research question and hypothesis.

This distinction is important because the AI-generated analysis is not itself the experiment. It is an interpretation of the experiment's output.

A future implementation could improve this process by incorporating formal statistical validation, confidence intervals, effect sizes, hypothesis tests, model-performance metrics, assumption checking, and automated detection of common statistical errors before an AI-generated interpretation is presented.

Research History

Paramedic AI Scientist maintains research history using Streamlit session state.

Three primary session-state objects are initialized:

• history
• papers
• hypotheses

The research history contains structured records for completed experiments.

Each record contains the experiment number, hypothesis, goal, generated code, output, and analysis.

This enables the application to display previous experiments during the current session and to supply earlier experimental results to subsequent experiment-selection operations.

The history therefore acts as a lightweight research-memory mechanism within the application.

Experiment Persistence

In addition to temporary Streamlit session history, the application invokes save_experiment() after each completed experiment.

The saved record includes the original research question, experiment number, hypothesis, generated code, output, and analysis.

This provides a mechanism for preserving individual experiments beyond the immediate display of results.

Persistent experiment storage is potentially important for research auditability because it allows the researcher to examine not only what the system concluded but also what computational procedure was generated and executed.

Iterative Research

The application supports multiple experiments within a single research session.

The experiment loop repeats the following sequence:

1. Select an experiment.
2. Identify the selected hypothesis.
3. Define an experiment goal.
4. Generate Python code.
5. Clean the generated code.
6. Validate the code.
7. Execute the experiment.
8. Capture the result.
9. Analyze the result.
10. Record the experiment.
11. Save the experiment.

The experiment history is then available to subsequent iterations.

This provides the architecture for an iterative research process rather than a single-question/single-answer interaction.

The approach is conceptually related to emerging research into AI systems that connect hypothesis generation with experimental evaluation. Importantly, however, Paramedic AI Scientist performs computational experiments within a software environment and should not be represented as a fully autonomous scientific laboratory system [3].

EMS Patient Case Integration

Paramedic AI Scientist incorporates structured EMS patient information through two imported models:

• PatientCase
• VitalSigns

The interface allows the user to enter:

• Age
• Sex
• Chief complaint
• Relevant medical history
• Physical examination findings
• Heart rate
• Respiratory rate
• SpO₂
• ETCO₂

Relevant history is converted from comma-separated text into a structured list.

Vital signs are represented using the VitalSigns model.

The complete case is then represented as a PatientCase object.

This provides a structured representation of an EMS encounter that can potentially be used by future research modules.

The current code constructs the patient object independently of the experiment-generation workflow. This means that, in the implementation provided, the patient case is available within the application but is not automatically supplied to the literature-search, hypothesis-generation, experiment-generation, or analysis functions.

This distinction is technically important.

The current architecture therefore provides patient-case infrastructure, while future development could explicitly connect the patient-case object to research experiments and simulations.

EMS Research Modes

The application provides six research modes.

Clinical Evidence Review

This mode provides a framework for examining evidence related to clinical questions.

Potential future functionality could include structured evidence grading, systematic literature comparison, and citation extraction.

EMS Protocol Research

This mode is intended for questions involving EMS protocols and clinical practice.

Because EMS protocols vary by jurisdiction and agency, any future implementation should distinguish general evidence from locally applicable protocol requirements.

Clinical Prediction Model

This mode provides a conceptual environment for investigating predictive models using structured clinical variables.

The current application does not itself implement a validated clinical prediction model merely because this mode exists. It provides a research context within which an AI-generated computational experiment could potentially investigate predictive modeling.

Patient Simulation

The patient-case structure provides a foundation for simulated EMS research scenarios.

The current implementation captures demographic, complaint, history, examination, and selected physiological variables.

Future versions could use this structured representation to create longitudinal or dynamic patient simulations.

Retrospective Data Analysis

This mode provides a conceptual framework for analyzing existing datasets.

Any implementation using real patient information would require appropriate privacy, security, governance, de-identification, and research-ethics controls.

Quality Improvement

The quality-improvement mode provides a framework for research questions concerning EMS processes and performance.

Future versions could incorporate structured quality metrics, statistical process-control methods, and de-identified operational datasets.

Final Research Report

Once at least one experiment has been completed, the application invokes generate_final_report().

The final report receives:

• The research question.
• Retrieved scientific papers.
• Generated hypotheses.
• Complete experimental history.

The resulting report is displayed within the Streamlit interface.

The application also provides a download button allowing the report to be downloaded as a Markdown document named:

research_report.md

The final-report component therefore consolidates the research process into a single document.

Importantly, the final report is itself AI-generated. It should therefore be considered a draft research artifact requiring human review rather than an independently verified scientific publication.

Software Architecture

The principal architecture of Paramedic AI Scientist consists of several interconnected layers.

EMS Model Layer

Provides structured representations of patient cases and vital signs through PatientCase and VitalSigns.

Safety Layer

Provides the research_disclaimer() function used to communicate the research and educational nature of the system.

Literature Layer

Uses search_papers() to retrieve relevant scientific papers.

Hypothesis Layer

Uses generate_hypotheses() to generate structured candidate hypotheses.

Experiment-Selection Layer

Uses choose_experiment() to identify the hypothesis and experimental objective to investigate.

Code-Generation Layer

Uses generate_experiment() to produce Python experimental code.

Code-Processing Layer

Uses clean_python_code() to process generated source code before validation and execution.

Security Layer

Uses validate_experiment_code() to block predefined potentially unsafe operations.

Execution Layer

Uses a temporary Python file and subprocess.run() to execute validated experiments under a 60-second timeout.

Analysis Layer

Uses analyze_results() to interpret computational output.

Persistence Layer

Uses save_experiment() and Streamlit session state to retain experimental information.

Reporting Layer

Uses generate_final_report() to consolidate research information into a downloadable report.

Interface Layer

Streamlit provides the graphical user interface and coordinates the complete research workflow.

Research Transparency

A central design principle of Paramedic AI Scientist is that the intermediate stages of the research process are visible to the user.

The interface displays:

• Retrieved literature
• Generated hypotheses
• Hypothesis reasoning
• Proposed experiments
• Expected results
• Falsification criteria
• Selected hypothesis
• Experiment goal
• Generated Python code
• Experimental output
• Scientific analysis
• Final research report

This is preferable to an architecture in which the system provides only a final AI-generated conclusion.

Displaying intermediate artifacts allows the researcher to inspect the assumptions and computational procedures underlying the result.

However, visibility does not guarantee correctness. An AI-generated hypothesis or code sample may appear scientifically plausible while still containing conceptual, statistical, or programming errors.

Safety and Human Oversight

Paramedic AI Scientist operates in an EMS and healthcare research context, making human oversight particularly important.

The system is explicitly designed as a research assistant and includes a research disclaimer.

AI-generated hypotheses should not automatically be interpreted as scientifically valid.

AI-generated Python code should not automatically be assumed to be correct.

Computational results should not automatically be interpreted as clinically meaningful.

AI-generated analyses should not automatically be treated as expert statistical interpretation.

Final reports should not automatically be treated as publication-ready scientific manuscripts.

These limitations are consistent with emerging research showing both the potential and uncertainty of LLM-based scientific hypothesis generation [1–3].

The distinction between research assistance and clinical decision support is especially important. A computational experiment performed by the system does not constitute clinical validation, and an AI-generated conclusion should not be used as a substitute for professional clinical judgment.

Security Considerations

The ability to generate and execute Python code creates a unique security requirement.

The current implementation attempts to reduce risk through source-code pattern blocking and execution time limits.

However, the implementation should not be characterized as a secure sandbox.

The blocked-pattern approach is inherently limited because unsafe behavior can potentially be expressed in ways that do not match the predefined strings.

Furthermore, executing generated Python through subprocess.run() means that the Python interpreter ultimately has access to the permissions of the host environment.

Research into LLM-generated code has identified security vulnerabilities as an important concern, supporting the need for stronger isolation when AI-generated software is executed automatically [5,6].

A production-grade version should therefore move code execution into a dedicated sandbox with restricted privileges and no unnecessary access to the host operating system or network.

Scientific Validity and Limitations

Several limitations apply to the current implementation.

First, the application does not itself establish the scientific validity of generated hypotheses.

Second, the literature search currently retrieves a maximum of three papers. This is appropriate for a prototype but is insufficient for a systematic literature review.

Third, the current implementation searches arXiv rather than providing comprehensive coverage of biomedical and EMS bibliographic databases. Retrieved papers may therefore include preprints and should be independently assessed for peer-review status and methodological quality.

Fourth, the hypothesis-generation component is dependent on the capabilities and limitations of the underlying language model.

Fifth, AI-generated Python code may contain methodological or programming errors.

Sixth, the current code-validation approach is not a complete security boundary.

Seventh, the application does not currently demonstrate formal statistical validation of AI-generated experimental methodology.

Eighth, the structured EMS patient case is currently created within the interface but is not directly passed into the research functions shown in the provided implementation.

Ninth, no formal evaluation has yet established that Paramedic AI Scientist improves EMS research productivity, scientific reasoning, research quality, or educational outcomes.

Finally, the system should not be interpreted as a validated clinical decision-support system.

Future Development

Future development could address several areas.

Expanded Literature Retrieval

The literature component could be expanded beyond a three-paper arXiv search to include biomedical and scientific databases such as PubMed and other indexed repositories.

Future versions could also distinguish:

• Peer-reviewed studies
• Preprints
• Systematic reviews
• Meta-analyses
• Clinical guidelines
• Government publications
• Educational literature

Evidence Evaluation

A future evidence-analysis layer could evaluate study design, sample size, limitations, risk of bias, and relevance to the research question.

Improved Experiment Reproducibility

Research records could automatically include:

• Python version
• Package versions
• Dataset identifiers
• Random seeds
• Model versions
• Execution timestamps
• Hardware information
• Experiment parameters

Stronger Code Isolation

The current source-code filtering could be replaced or supplemented by a genuine sandboxed execution environment with restricted filesystem, network, process, and resource access.

Statistical Validation

Future versions could incorporate dedicated statistical-analysis tools that independently calculate model-performance measures and statistical tests before an LLM is permitted to interpret the results.

EMS Dataset Integration

Structured, de-identified EMS datasets could be incorporated for retrospective research and predictive-model development, subject to appropriate governance and research approval.

Patient Simulation

The existing PatientCase and VitalSigns structures could be expanded into dynamic patient simulations in which physiological observations change in response to simulated interventions.

Human-in-the-Loop Research

Future versions could require researcher approval between major stages:

Hypothesis → Human Review → Experiment → Human Review → Analysis → Human Review → Report

This would provide a stronger safeguard against automated propagation of an incorrect assumption through the entire research pipeline.

Conclusion

Paramedic AI Scientist represents a Python-based prototype for integrating artificial intelligence into an EMS-oriented scientific research workflow.

The application combines literature retrieval, AI-assisted hypothesis generation, experiment selection, Python code generation, controlled computational execution, result analysis, experiment persistence, and automated report generation within a single Streamlit interface.

The system additionally provides structured EMS patient-case representation through PatientCase and VitalSigns, incorporating age, sex, chief complaint, history, physical examination, heart rate, respiratory rate, SpO₂, and ETCO₂.

Its most distinctive feature is the connection between generative AI and executable computational research. The system can move from a natural-language research question through literature review and hypothesis generation to an AI-generated Python experiment, execute that experiment under defined constraints, analyze the output, and incorporate the resulting information into a research report.

This architecture reflects a broader emerging area of research into AI-assisted scientific discovery. Existing literature demonstrates that LLMs can generate potentially useful scientific hypotheses, while also emphasizing the need for validation and human evaluation [1–3].

The application should therefore be understood as a research-assistance and educational prototype, not as an autonomous scientific researcher or clinical decision-making system.

The current implementation demonstrates the feasibility of connecting AI-based reasoning with computational experimentation, but substantial future work is required before such systems could be considered reliable for high-consequence scientific or clinical applications.

Conflicts of Interest

None declared.

Funding

The author received no specific funding for the development or preparation of this work.

References

1. Zhou Y, Liu H, Srivastava T, Mei H, Tan C. Hypothesis Generation with Large Language Models. Proceedings of the 1st Workshop on NLP for Science (NLP4Science). 2024:117–139. doi:10.18653/v1/2024.nlp4science-1.10.
2. Yang Z, Du X, Li J, Zheng J, Poria S, Cambria E. Large Language Models for Automated Open-domain Scientific Hypotheses Discovery. Findings of the Association for Computational Linguistics: ACL 2024. 2024:13545–13565. doi:10.18653/v1/2024.findings-acl.804.
3. Scientific hypothesis generation by large language models: laboratory validation in breast cancer treatment. Journal of the Royal Society Interface. 2025. doi:10.1098/rsif.2024.0674. PMID:40462712.
4. Lewis P, Perez E, Piktus A, et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv. 2020;2005.11401.
5. Aldosari SS, Aldawsari LS. Securing LLM code generation: Leveraging prompt engineering to mitigate vulnerabilities across models and languages. Science of Computer Programming. 2026;251:103446. doi:10.1016/j.scico.2026.103446.
6. Ji J, Jun J, Wu M, Gelles R. Cybersecurity Risks of AI-Generated Code. Center for Security and Emerging Technology, Georgetown University; 2024.
7. Vilke GM, Tornabene SV, Stepanski B, et al. Paramedic self-reported medication errors. Prehospital Emergency Care. 2007;11(1):80–84. doi:10.1080/10903120601021358. PMID:17169883.
8. 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. Advances in Medical Education and Practice. 2020;11:869–878. doi:10.2147/AMEP.S258223. PMID:33235536.
9. LeBlanc VR, MacDonald RD, McArthur B, King K, Lepine T. Paramedic performance in calculating drug dosages following stressful scenarios in a human patient simulator. Prehospital Emergency Care. 2005;9(4):439–444. doi:10.1080/10903120500255255. PMID:16263679.
10. 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. 2025;104(31):e43651. doi:10.1097/MD.0000000000043651. PMID:40760542.
11. National Highway Traffic Safety Administration. National EMS Scope of Practice Model 2019. Washington, DC: U.S. Department of Transportation; 2019. DOT HS 812 666.