Paramedic AI Scientist

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.

Development of Paramedic AI Scientist: A Python-Based Artificial Intelligence System for EMS Research, Evidence Review, and Experimental Analysis

Technical Description

Paramedic AI Scientist is a Python-based artificial intelligence research application developed to support EMS evidence review, clinical research, simulation, data analysis, and experimental investigation. The system extends an EMS-focused artificial intelligence architecture by incorporating an automated scientific research workflow capable of searching scientific literature, generating research hypotheses, selecting experimental approaches, generating executable Python experiments, analyzing experimental results, and producing a final research report.

The application is implemented as a web-based Streamlit interface. Streamlit provides the primary user interface and coordinates interaction between the research components, patient-case representation, literature-search functions, hypothesis-generation system, experimental code-generation system, result-analysis system, and report-generation system.

The system is designed as a research assistant rather than an autonomous clinical decision-making system. Its purpose is to demonstrate how artificial intelligence can assist with the research process by connecting evidence retrieval, hypothesis generation, computational experimentation, and scientific reporting within a single application.

The architecture combines several computational functions, including natural-language research-question processing, scientific literature retrieval, large-language-model-based reasoning, hypothesis generation, Python code generation, controlled experiment execution, result analysis, experiment persistence, and automated report generation.

Research Question Interface

The primary input to the system is a natural-language research question. Users enter their research question through a Streamlit text area, allowing the system to operate using ordinary language rather than requiring a predefined programming or statistical syntax.

Examples of potential research questions include questions involving machine-learning performance, EMS research, clinical prediction models, patient simulation, retrospective data analysis, and quality-improvement investigations.

The application provides several research modes:

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

The selected research mode provides contextual information about the intended purpose of the investigation, while the research question becomes the primary input for the downstream literature, hypothesis, and experiment-generation components.

A configurable experiment count is also provided through the sidebar. The current interface permits between one and five experiments, although the application recommends limiting active experiments to approximately one to three when working within current API constraints.

EMS Patient Case Representation

In addition to the research question, Paramedic AI Scientist provides a structured EMS patient-case interface.

The application imports PatientCase and VitalSigns models from the EMS software package. These models allow patient information to be represented using structured data rather than solely through free-text descriptions.

The patient-case interface includes:

• Age
• Sex
• Chief complaint
• Relevant medical history
• Heart rate
• Respiratory rate
• Peripheral oxygen saturation (SpO₂)
• End-tidal carbon dioxide (ETCO₂)
• Physical examination findings

Relevant medical history is converted from comma-separated user input into a structured list of individual history items. Physiological observations are represented through a VitalSigns object.

The resulting patient case is assembled into a PatientCase object containing the patient's demographic information, presenting complaint, medical history, vital signs, and physical examination.

This structure provides a potential interface between EMS case representation and future research workflows involving patient simulation, prediction modeling, retrospective analysis, or clinical research datasets.

Scientific Literature Retrieval

The first computational stage of the research workflow is literature retrieval.

When the user initiates research, the application passes the research question to the search_papers() function. The current implementation requests up to three relevant papers.

The retrieved literature is stored in Streamlit session state and displayed through expandable interface components. For each paper, the application can display the paper title, abstract, and available author information.

The literature-search stage provides the research system with an evidence base before hypothesis generation occurs. This creates a workflow in which the system first gathers external scientific information and subsequently uses that information as an input to the hypothesis-generation process.

The separation between literature retrieval and later experimental stages also allows retrieved papers to be preserved within the current research session and subsequently incorporated into the final research report.

Artificial Intelligence Hypothesis Generation

Following literature retrieval, the application uses the generate_hypotheses() function to produce potential scientific hypotheses.

The research question and retrieved papers are provided to the hypothesis-generation system. Generated hypotheses are stored within the application's session state for subsequent use.

Each hypothesis may contain several components:

• Hypothesis — the proposed scientific relationship or prediction.
• Reasoning — the reasoning supporting the hypothesis.
• Proposed experiment — an experimental approach for investigating the hypothesis.
• Expected result — the anticipated experimental outcome.
• Falsification — conditions under which the hypothesis could be rejected.

This structure is important because the application does not simply ask an LLM to provide an answer to the research question. Instead, it attempts to represent elements of the scientific method by generating a proposition that can subsequently be tested computationally.

The inclusion of a falsification component also introduces an explicit mechanism for considering evidence that could contradict the proposed hypothesis.

Automated Experiment Selection

After hypotheses have been generated, the system uses the choose_experiment() function to determine which hypothesis and experimental objective should be investigated.

The experiment-selection component receives:

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

The resulting decision contains a selected hypothesis and an experiment goal.

This history-aware architecture allows subsequent experiments to take previous experimental activity into account rather than treating every experiment as an isolated request.

The selected hypothesis and experiment goal are displayed to the user before experimental code is generated, providing visibility into the reasoning pathway used by the research workflow.

AI-Generated Python Experiments

Once an experiment has been selected, the system calls generate_experiment() to generate Python code intended to investigate the selected hypothesis.

The generated code is immediately passed through the clean_python_code() function before execution. This provides a preprocessing stage between AI-generated code and the experiment-execution environment.

The generated Python source code is displayed to the user through an expandable Streamlit section. This provides transparency into the computational experiment and allows the user to inspect the generated methodology before or alongside execution.

The experiment-generation architecture therefore creates a pipeline of:

Research question → Hypothesis → Experiment goal → Python experiment → Experimental results

This approach allows the system to move beyond conversational research assistance toward automated computational experimentation.

Experiment Safety and Code Validation

Because the application is capable of executing AI-generated Python code, a dedicated code-validation mechanism is incorporated into the experimental execution pipeline.

The validate_experiment_code() function examines generated Python source code for potentially unsafe operations.

The current implementation blocks patterns associated with operations including:

• os.system
• subprocess
• shutil
• socket
• requests
• urllib
• httpx
• exec()
• eval()
• __import__
• direct operating-system imports
• direct subprocess imports

If a blocked pattern is identified, execution is prevented and the user receives an explanation identifying the potentially unsafe operation.

This represents a basic application-level safety boundary between AI-generated source code and execution.

The validation system should not, however, be interpreted as a complete Python sandbox or security boundary. Pattern-based filtering can have limitations, and production deployment of autonomous code execution would require stronger isolation mechanisms, such as containerization, restricted operating-system permissions, resource controls, network isolation, filesystem restrictions, and independent security assessment.

Controlled Experiment Execution

Following code validation, the application executes the generated Python experiment in a temporary file.

A temporary Python file is created using Python's temporary-file functionality. The generated code is written to the file and executed through a separate Python process.

The execution environment explicitly sets PYTHONIOENCODING to UTF-8. This is intended to provide consistent handling of Unicode output, including symbols and characters that may occur in AI-generated experiments.

The experiment captures both standard output and standard error. Successful output is displayed to the user as experimental results, while execution errors and warnings are separately reported.

A maximum execution time of 60 seconds is imposed on each experiment. If the experiment exceeds this limit, execution is terminated and the system reports that the experiment exceeded the permitted execution period.

Temporary experiment files are removed after execution.

This execution model provides a controlled computational workflow while retaining the ability to generate and execute arbitrary research-oriented Python experiments within the limitations of the implemented validation system.

Experimental Result Analysis

After an experiment has completed, the output is passed to the analyze_results() function.

The analysis system receives:

• The original research question.
• The selected hypothesis.
• The experimental output.

The resulting analysis is displayed in the application under a dedicated Scientific Analysis section.

This creates a separation between computation and interpretation. The Python environment performs the experiment, while the AI analysis component interprets the resulting output in relation to the research question and selected hypothesis.

This separation allows the system to distinguish between generated computational evidence and the subsequent natural-language interpretation of that evidence.

Experimental records are also added to the application's session history.

Research History and Experiment Persistence

Each completed experiment is represented as a structured research record containing:

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

These records are stored in Streamlit session state during the active research session.

The application also calls save_experiment() to persist individual experiments outside the immediate interface workflow.

This creates a basic research-record architecture in which experimental methodology, generated source code, results, and analysis can be retained together.

Maintaining the experimental code alongside the output is particularly important for reproducibility because it provides a record of the computational procedure that generated the reported result.

Iterative Experimental Workflow

The application supports execution of multiple experiments within a single research session. The number of experiments is controlled through a Streamlit slider. During each iteration, the system:

1. Selects a hypothesis or research direction.
2. Defines an experiment goal.
3. Generates Python code.
4. Cleans the generated code.
5. Validates the code for prohibited operations.
6. Executes the experiment.
7. Captures experimental output.
8. Analyzes the results.
9. Stores the experiment in research history.
10. Saves the experiment record.

The history of previous experiments is subsequently supplied to the experiment-selection component.

This architecture provides the basis for iterative scientific investigation in which later experiments can be selected in the context of previous computational findings.

Automated Final Research Report

After 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.
• Experimental history.

The resulting report is displayed directly within the Streamlit application and can also be downloaded as a Markdown file named research_report.md.

The report-generation component therefore combines the major outputs of the research pipeline into a single research document.

The overall process can be represented as:

Research Question → Literature Search → Scientific Hypotheses → Experiment Selection → AI-Generated Python Experiment → Code Validation → Controlled Execution → Experimental Results → Scientific Analysis → Research History → Final Research Report

Streamlit Application Architecture

Streamlit functions as the primary application and presentation layer.

The interface is configured using a wide-page layout and provides separate sections for research configuration, research questions, EMS patient cases, literature retrieval, hypotheses, experiments, results, scientific analysis, and final reporting.

The major software components include:

• EMS models — represent structured patient cases and physiological observations.
• Safety module — provides the research disclaimer and safety-oriented messaging.
• Literature-search module — retrieves scientific papers relevant to the research question.
• Hypothesis-generation module — generates candidate scientific hypotheses.
• Experiment-selection module — determines which hypothesis and experiment should be pursued.
• Experiment-generation module — generates Python research code.
• Code-cleaning component — processes generated Python before validation.
• Code-validation component — identifies prohibited or potentially unsafe operations.
• Experiment-execution component — executes validated research code with a time limit.
• Result-analysis module — interprets experimental output.
• Experiment-storage component — saves research experiments.
• Final-report module — generates the consolidated research report.
• Streamlit application layer — coordinates the user interface and research workflow.

This modular structure separates the scientific workflow into individual computational responsibilities while allowing the Streamlit application to coordinate them.

Research Reproducibility

An important characteristic of the system is the preservation of experimental artifacts.

The application records the hypothesis, experiment goal, generated Python code, experimental output, and subsequent analysis.

This structure provides a basic foundation for computational reproducibility because the methodology and resulting output can be retained together rather than presenting only an AI-generated narrative conclusion.

The final report additionally incorporates the retrieved literature, hypotheses, and experimental history.

However, reproducibility remains dependent on factors such as the underlying AI model, external literature sources, software versions, Python dependencies, random seeds, datasets, and execution environment. Future versions could improve reproducibility by explicitly recording software versions, model identifiers, dataset versions, random seeds, timestamps, dependency manifests, and experiment configuration parameters.

Safety and Human Oversight

Because Paramedic AI Scientist operates in an EMS and healthcare research context, the application incorporates an explicit research disclaimer.

The system is intended as a research, educational, simulation, and analytical tool rather than an autonomous clinical decision-making system.

The distinction is particularly important because the system combines several inherently uncertain computational processes. Literature retrieval may return incomplete or inappropriate evidence. LLM-generated hypotheses may be scientifically weak or incorrect. Generated Python code may contain methodological errors. Experimental datasets may be inadequate or simulated. AI-generated analysis may misinterpret statistical or computational results.

The presence of a computational result therefore does not establish clinical validity.

Human review remains necessary when evaluating literature, research methodology, statistical methods, experimental assumptions, patient simulations, and conclusions.

Any future use involving real clinical decision-making or patient care would require substantially more extensive validation, clinical governance, cybersecurity assessment, privacy controls, usability testing, dataset validation, model evaluation, and regulatory review.

Relationship Between AI Components

Paramedic AI Scientist separates several forms of artificial intelligence rather than treating AI as a single computational function.

The literature-search system provides external scientific material.

The hypothesis-generation component uses the research question and retrieved evidence to construct potential scientific propositions.

The experiment-selection component determines which proposed investigation should be performed.

The code-generation component translates the selected experiment into executable Python. The Python execution environment performs the computational experiment.

The result-analysis component subsequently interprets the experimental output.

Finally, the report-generation component combines the research artifacts into a consolidated document.

This architecture creates a sequential research pipeline in which different AI and computational components perform different functions.

Overall System

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

Rather than functioning solely as a conversational chatbot, the application attempts to automate multiple stages of a research process, including evidence retrieval, hypothesis generation, experimental design, computational experimentation, result interpretation, experiment storage, and research reporting.

The system additionally incorporates structured EMS patient-case representation through PatientCase and VitalSigns, allowing research activities to be associated with demographic information, chief complaints, medical history, physiological observations, and physical examination findings.

A significant architectural feature is the connection between generative AI and executable computation. The LLM-based components can propose hypotheses and generate Python experiments, while the Python runtime performs the computational work and returns observable results for subsequent analysis.

The application consequently provides a framework for investigating how artificial intelligence could assist EMS researchers, educators, and students with evidence review, computational research, simulation, data analysis, and scientific documentation.

The system should nevertheless be regarded as a research and educational prototype. AI-generated hypotheses, code, analyses, and reports require human verification, and experimental findings should not be interpreted as clinically validated evidence without appropriate scientific and clinical evaluation.

Future development could include stronger execution sandboxing, expanded literature databases, structured datasets, statistical validation, experiment reproducibility controls, versioned research environments, formal evaluation of generated hypotheses and analyses, enhanced patient-simulation capabilities, and comprehensive governance mechanisms for healthcare research applications.