Current Projects We're Working On

Project Overview

We are developing an AI-powered CPR Analyzer prototype as part of the Emergency Medicine AI Research Initiative (EMARI). The project focuses on combining computer vision, signal processing, and machine learning to analyze CPR performance, quantify compression patterns, identify interruptions, and generate data-driven feedback for CPR training and research.

The system is being designed with a modular architecture that separates currently implemented functionality from planned capabilities and future research objectives.

1. Current Prototype Capabilities

The following describes the initial development scope and intended baseline functionality.

Features should be marked as implemented only after they have been built and tested.

• Python-based development: Establishing the software foundation for video processing, data analysis, and model integration.
• Video-processing pipeline: Developing the ability to ingest CPR training footage and extract video frames for analysis using OpenCV.
• Computer vision integration: Evaluating pretrained models, including MediaPipe, for detecting relevant body landmarks and movement patterns.
• Compression-cycle analysis: Developing algorithms to identify repeated movement patterns, estimate compression timing, count compressions, and detect potential interruptions.
• Performance metrics: Establishing a framework for calculating compression rate and summarizing observed CPR activity.
• Streamlit interface: Developing a dashboard for displaying analysis results, performance metrics, and session summaries.

2. Planned Capabilities

The following capabilities are planned for subsequent development and are not assumed to be operational in the current prototype.

• Real-time CPR analysis: Process live webcam footage and provide feedback during simulated CPR training.
• Sensor integration: Connect to a sensor-equipped training manikin to obtain reference measurements for compression depth, recoil, and other physical parameters.
• Validated depth assessment: Compare video-derived movement estimates with sensor measurements to investigate whether compression depth can be assessed reliably.
• Hand-placement assessment: Develop and validate computer vision models that identify hand positioning relative to the recommended compression area.
• Expanded performance analysis: Calculate interruption duration, compression consistency, and the proportion of compressions meeting defined training criteria.
• Automated feedback engine: Generate structured, evidence-based feedback based on measured performance and established CPR training guidance.
• Confidence and uncertainty reporting: Distinguish reliable measurements from uncertain estimates and identify when additional sensors or improved camera positioning are needed.
• Session history and trend analysis: Track performance across multiple training sessions and visualize changes in measured metrics.
• Research evaluation: Test the system against reference equipment under controlled conditions and document measurement accuracy, reliability, and limitations.

3. Technical Architecture

The proposed architecture consists of five major components:

1. Input layer: Recorded CPR videos, with live webcam input planned.
2. Computer vision layer: Video-frame processing, landmark detection, and movement analysis.
3. Measurement layer: Compression-cycle detection, timing calculations, and future sensor-based depth and recoil measurements.
4. Analysis layer: Comparison of validated measurements against applicable adult CPR training targets.
5. Presentation layer: A Streamlit dashboard for displaying results, uncertainty, performance trends, and feedback.

4. Initial Performance Metrics

The system is being designed to evaluate the following metrics, subject to measurement feasibility and validation:

The reference target for adult CPR is generally 100–120 compressions per minute and a compression depth of approximately 5–6 cm. The system must be validated against appropriate reference measurements before its estimates are treated as accurate.

5. Development Roadmap

Phase 1 — Baseline Prototype

Develop the video-processing workflow, compression-cycle detection, initial rate estimates, interruption detection, and dashboard.

Phase 2 — Measurement Validation

Compare the system's output against reference measurements from CPR training equipment and quantify its limitations.

Phase 3 — Expanded Capabilities

Investigate real-time analysis, sensor integration, hand-placement detection, recoil assessment, and automated feedback.

Phase 4 — Research and Evaluation

Conduct controlled testing, document results, assess performance across recording conditions, and determine which capabilities warrant further development.

6. Intended Outcome

Our objective is to develop a research-oriented AI CPR Analyzer that can quantify CPR training performance and provide interpretable, evidence-based feedback. The immediate focus is on building a reproducible prototype and validating its measurements before expanding into real-time analysis or more advanced clinical applications.

Development status distinction: Current capabilities refer to features actually implemented and tested. Planned capabilities describe proposed work and must not be represented as completed functionality. The prototype is intended for research and educational use and is not a clinically validated medical device.

Project Overview

We are developing an AI-powered Patient Care Report (PCR) Analyzer as part of the Emergency Medicine AI Research Initiative (EMARI). The project focuses on using large language models (LLMs), natural language processing, structured data extraction, and retrieval-augmented generation (RAG) to analyze EMS patient care reports, identify documentation gaps, evaluate clinical documentation consistency, and generate structured feedback for educational and quality-improvement purposes.

The system is being designed to support the review of prehospital documentation by organizing clinical information, identifying potentially missing elements, and comparing documented care against applicable EMS protocols and documentation standards.

The architecture will separate currently implemented functionality from planned capabilities and future research objectives.

1. Current Prototype Capabilities

The following describes the initial development scope. Features should be marked as operational only after implementation and testing have confirmed their functionality.

• Python-based development: Establishing the software foundation for document processing, text analysis, and AI model integration.
• Patient care report input: Developing a workflow for submitting report text for analysis, with support for additional document formats to be evaluated.
• Natural language processing: Exploring methods for extracting relevant clinical information from narrative documentation, including patient complaints, assessment findings, vital signs, interventions, and patient disposition.
• LLM integration: Evaluating language models for summarizing report narratives, organizing clinical information, and generating structured analysis.
• Structured output framework: Designing a consistent format for presenting extracted information, documentation observations, and potential areas for improvement.
• Interactive interface: Developing a web-based interface, potentially using Streamlit, for submitting reports and reviewing AI-generated outputs. These items describe the baseline development scope; they do not imply that every capability has already been implemented or validated.

2. Planned Capabilities

The following capabilities are planned for future development and are not assumed to be operational in the current prototype.

• Automated documentation completeness analysis: Identify potentially missing or insufficiently documented elements, such as pertinent negatives, reassessment findings, response to treatment, and patient disposition.
• Clinical timeline reconstruction: Organize documented events into a chronological sequence, including initial assessment, vital-sign measurements, interventions, reassessments, and transfer of care.
• Vital-sign trend analysis: Extract repeated measurements and identify documented trends, changes, or inconsistencies across the encounter.
• Clinical consistency checks: Flag potential contradictions between the narrative, recorded vital signs, assessment findings, interventions, and disposition.
• Protocol-based documentation review: Compare relevant report elements against configured EMS protocols and documentation standards, with source citations and version tracking.
• Treatment documentation analysis: Evaluate whether interventions, treatment timing, patient responses, and reassessments are adequately documented relative to the applicable protocol.
• Structured clinical data extraction: Convert narrative reports into standardized fields suitable for review, research, and quality-improvement workflows.
• AI-generated feedback: Produce a structured report highlighting documentation strengths, missing information, potential inconsistencies, and suggested areas for clarification.
• Confidence and uncertainty reporting: Distinguish directly extracted information from inferred interpretations and flag ambiguous or unsupported findings.
• Batch report analysis: Evaluate multiple de-identified reports to identify recurring documentation patterns and potential areas for training.
• Quality-improvement analytics: Aggregate validated documentation metrics to help identify educational needs and opportunities to improve report completeness.
• RAG-based evidence retrieval: Retrieve relevant passages from approved EMS protocols, documentation policies, and clinical guidance to support traceable analysis. The analyzer will be designed to distinguish a missing documentation element from an action that was not performed. An omission in a report alone does not establish that the corresponding clinical action was omitted.

3. Technical Architecture

The proposed architecture consists of six major components.

1. Input layer: Accept patient care report text and, in future iterations, supported document formats.
2. Document processing layer: Normalize text, segment report sections, and identify relevant clinical entities.
3. Information extraction layer: Extract structured fields such as patient complaints, vital signs, assessments, interventions, reassessments, and disposition.
4. Analysis layer: Evaluate completeness, consistency, chronology, and alignment with configured documentation requirements.
5. Evidence retrieval layer: Retrieve relevant protocol passages and documentation standards to support traceable findings.
6. Presentation layer: Display the structured analysis, identified issues, supporting evidence, confidence indicators, and suggested documentation improvements.

4. Initial Analysis Categories

5. Development Roadmap

Phase 1 — Baseline Prototype

Establish report submission, text processing, LLM-based analysis, structured output, and an initial web interface.

Phase 2 — Structured Extraction and Validation

Develop standardized field extraction for assessments, vital signs, interventions, reassessments, and disposition. Evaluate extraction accuracy against manually reviewed reports.

Phase 3 — Documentation Quality Analysis

Implement completeness checks, timeline reconstruction, consistency detection, and configurable documentation criteria.

Phase 4 — Protocol-Grounded Analysis

Integrate a retrieval-augmented generation system using approved EMS protocols and documentation standards. Add source citations, protocol version tracking, and safeguards against unsupported clinical conclusions.

Phase 5 — Research and Evaluation

Evaluate the analyzer using appropriately de-identified reports and expert-reviewed reference annotations. Measure extraction accuracy, false-positive rates, consistency, source-grounding accuracy, and usefulness of the generated feedback.

6. Intended Outcome

Our objective is to develop a research-oriented AI Patient Care Report Analyzer that transforms unstructured EMS documentation into structured, reviewable information and identifies potential documentation gaps, inconsistencies, and opportunities for improvement.

The immediate focus is on building a reproducible prototype, validating the accuracy of extracted information, and ensuring that findings are traceable to the original report or an approved reference source.

The system is intended to support EMS education, documentation review, and quality-improvement research rather than replace clinician judgment, medical direction, or formal quality-assurance processes.

Development Status and Safety Considerations

Current capabilities refer only to functionality that has actually been implemented and tested.

Planned capabilities describe proposed work and must not be presented as completed functionality.

Patient care reports may contain protected health information. Development and evaluation must use appropriately de-identified data or an approved, secure environment with suitable access controls and privacy safeguards.

The analyzer must not invent undocumented patient findings, assume that an undocumented intervention was not performed, or treat an AI-generated observation as a definitive clinical error. Clinical and protocol-related findings should be reviewed by qualified personnel before being used for education, quality assurance, or operational decisions.

The prototype is intended for research and educational use and is not a clinically validated medical device or a substitute for professional clinical review.

Project Overview

We are developing a machine learning–based Arrival Time to Hospital prediction prototype as part of the Emergency Medicine AI Research Initiative (EMARI). The project focuses on using historical EMS transport data, geographic information, transport characteristics, and time-related variables to estimate the time required for an ambulance to arrive at a receiving hospital.

The system is being designed to support EMS transportation planning, estimated time of arrival (ETA) prediction, and prehospital operational research. By analyzing relevant historical patterns, the model aims to produce data-driven arrival-time estimates and evaluate factors associated with transport duration.

The architecture will distinguish currently implemented functionality from planned capabilities and future research objectives.

1. Current Prototype Capabilities

The following describes the baseline development scope. Features should be identified as implemented only after they have been built and tested.

• Python-based ML development: Establishing the foundation for data preprocessing, feature engineering, model training, and evaluation.
• Transport-time prediction framework: Developing a workflow to predict hospital arrival time or transport duration from available input variables.
• Historical data processing: Establishing methods to organize transport records, timestamps, and relevant operational variables for model development.
• Feature engineering: Exploring variables such as departure time, day of the week, transport distance, origin location, destination hospital, and available traffic-related information.
• Regression modeling: Evaluating machine learning algorithms for predicting continuous outcomes such as transport duration in minutes.
• Prediction output: Designing a consistent output format for displaying estimated transport duration and predicted hospital arrival time when a valid departure timestamp is provided.
• Model evaluation: Establishing a framework for comparing predictions with actual recorded arrival times. These items describe the intended baseline functionality and do not establish that the model has already achieved a particular level of accuracy.

2. Planned Capabilities

The following capabilities are planned for subsequent development and are not assumed to be operational in the current prototype.

• Real-time ETA prediction: Incorporate current departure times, available traffic conditions, and updated route information to generate more context-sensitive estimates.
• Geographic route analysis: Integrate mapping and routing data to estimate transport duration between an incident location and a receiving hospital.
• Traffic-aware prediction: Investigate how congestion, time of day, road conditions, and route variability affect transport duration.
• Hospital destination comparison: Estimate transport times to multiple potential receiving hospitals when appropriate destination options are provided.
• Time-dependent ML models: Evaluate whether models that account for temporal patterns improve predictions during peak traffic periods, overnight hours, weekends, and holidays.
• Prediction intervals: Estimate a plausible range of arrival times rather than presenting every prediction as an exact time.
• Model benchmarking: Compare machine learning predictions with simple baselines, such as historical average transport times and mapping-service estimates.
• Operational analytics dashboard: Develop a Streamlit interface to visualize predicted versus actual arrival times, error distributions, and performance across different transport conditions.
• Model monitoring: Evaluate prediction drift as traffic patterns, road networks, operating conditions, and data distributions change.
• Research and generalization testing: Assess model performance across different routes, hospitals, time periods, and EMS operating environments.

3. Technical Architecture

The proposed architecture consists of six major components.

1. Data input layer: Accept historical transport records containing appropriate timestamps, locations, destinations, and available operational variables.
2. Data preprocessing layer: Validate timestamps, handle missing values, remove invalid records, and standardize input formats.
3. Feature engineering layer: Derive transport duration, departure hour, day of the week, geographic distance, and other relevant predictors.
4. Machine learning layer: Train and compare regression models, such as Random Forest, Gradient Boosting, and XGBoost, where appropriate.
5. Prediction layer: Generate estimated transport duration and calculate the expected hospital arrival time from the departure timestamp.
6. Presentation layer: Display predictions, uncertainty ranges where supported, model performance, and relevant explanatory information through a dashboard.

4. Initial Model Inputs and Outputs

Potential input variables

The final feature set will depend on data availability, quality, and whether each variable is known at the time the prediction is made.

Predicted outputs

• Estimated transport duration: Predicted number of minutes between the defined departure event and hospital arrival.
• Estimated arrival time: Calculated by adding predicted duration to the recorded or current departure timestamp.
• Prediction uncertainty: A range of plausible transport durations, if supported by model calibration and validation.
• Model performance metrics: Mean absolute error (MAE), root mean squared error (RMSE), and other appropriate measures comparing predictions with recorded outcomes. The project must define the prediction interval precisely—for example, ambulance departure from the scene to arrival at the hospital—so that training labels and evaluation results measure the same event.

5. Development Roadmap

Phase 1 — Baseline Prototype

Establish the data-processing workflow, define the prediction target, prepare available historical records, train an initial regression model, and generate transport-time predictions.

Phase 2 — Model Evaluation

Compare candidate models against simple baselines using time-based train/test splits. Measure prediction error and assess whether performance varies across routes, hospitals, and time periods.

Phase 3 — Geographic and Traffic Integration

Investigate routing data, geographic distance, and time-dependent traffic information. Evaluate whether these additional variables improve ETA accuracy compared with historical transport-time predictions alone.

Phase 4 — Dashboard and Uncertainty Analysis

Develop an interactive interface for displaying predicted arrival times, uncertainty ranges, model performance, and comparisons with actual arrival records.

Phase 5 — Research and Generalization

Evaluate the model using appropriately de-identified transport data, document its limitations, test performance on unseen time periods and locations, and assess its suitability for further operational research.

6. Intended Outcome

Our objective is to develop a research-oriented ML system that predicts EMS transport duration and estimated hospital arrival time using relevant historical, geographic, temporal, and operational data.

The immediate focus is on building a reproducible prediction pipeline, defining reliable outcome labels, establishing meaningful performance benchmarks, and determining which features contribute to useful ETA estimates.

Future iterations may incorporate real-time traffic and routing data to improve context-sensitive predictions. The system is intended to support transportation planning and operational research rather than independently determine clinical destination decisions or replace dispatcher, EMS clinician, or medical-control judgment.

Development Status and Safety Considerations

Current capabilities refer only to functionality that has actually been implemented and tested.

Planned capabilities describe proposed development and must not be presented as completed functionality.

Historical timestamps and location records must be validated for accuracy, consistency, and appropriate use. Training and evaluation should prevent data leakage, including the use of information that would not have been available when the prediction was made.

Performance should be evaluated on data from later time periods or otherwise unseen journeys, not solely on records used for model training. Reported accuracy must reflect actual test results rather than assumed performance.

The prototype is intended for research and operational decision support. Its predictions are estimates, not guarantees, and should not override clinical urgency, appropriate destination selection, emergency driving requirements, or established EMS protocols.

Project Overview

We are developing an AI-powered Dispatch-to-Patient Needs Analyzer as part of the Emergency Medicine AI Research Initiative (EMARI). The project focuses on using natural language processing (NLP), large language models (LLMs), and machine learning to transform emergency dispatch call information into structured summaries of reported patient conditions, potential care needs, and relevant prehospital assessment considerations.

The system is being designed to analyze information provided during emergency calls, extract relevant symptoms and incident details, identify potential clinical concerns, and organize the information into a structured format that can support EMS preparation and pre-arrival situational awareness.

The goal is to bridge the information gap between emergency dispatch and prehospital patient assessment by converting unstructured caller descriptions into organized, interpretable information for EMS personnel.

The architecture will distinguish currently implemented functionality from planned capabilities and future research objectives.

1. Current Prototype Capabilities

The following describes the baseline development scope. Features should be marked as operational only after they have been implemented and tested.

• Python-based AI development: Establishing the software foundation for processing dispatch information, extracting relevant details, and generating structured outputs.
• Dispatch information input: Developing a workflow for submitting dispatch narratives, call summaries, or other supported text-based information.
• Natural language processing: Exploring methods for identifying reported symptoms, chief complaints, incident circumstances, patient demographics when provided, and relevant contextual details.
• LLM integration: Evaluating language models for summarizing caller descriptions and organizing reported information into standardized fields.
• Structured patient-needs framework: Designing an output format that separates reported symptoms, potential assessment priorities, possible resource considerations, and information requiring confirmation.
• Analysis output: Establishing a consistent format for presenting extracted information, potential concerns, and unresolved information gaps.
• Interactive interface: Developing a web-based interface, potentially using Streamlit, for submitting dispatch information and reviewing AI-generated results. These items represent the baseline development scope and do not establish that every component is currently operational.

2. Planned Capabilities

The following capabilities are planned for subsequent development and are not assumed to be operational in the current prototype.

• Automated symptom extraction: Identify and categorize symptoms reported by callers, such as difficulty breathing, chest discomfort, altered mental status, bleeding, trauma, or loss of consciousness.
• Patient-needs classification: Map dispatch descriptions to structured categories of potential assessment needs, such as airway and breathing assessment, circulation and hemorrhage assessment, neurological evaluation, trauma assessment, or other complaint-specific considerations.
• Clinical urgency indicators: Investigate methods for identifying dispatch information that may indicate time-sensitive clinical concerns, while preserving the distinction between reported information and confirmed findings.
• Missing-information detection: Identify potentially important details that are absent or unclear in the dispatch narrative and may warrant clarification through established dispatch procedures.
• EMS resource considerations: Explore whether documented incident characteristics can support suggestions for reviewing appropriate personnel, equipment, or additional-resource needs under applicable dispatch protocols.
• Protocol-grounded analysis: Integrate retrieval-augmented generation (RAG) to retrieve relevant, approved EMS dispatch procedures and prehospital guidance with traceable source citations.
• Structured pre-arrival briefing: Generate concise summaries containing the reported complaint, key symptoms, incident circumstances, potential assessment priorities, and information that remains unknown.
• Dispatch-to-assessment comparison: In future versions, compare initial dispatch information with subsequent EMS findings to evaluate which reported details were confirmed, changed, or remained uncertain.
• Confidence and uncertainty reporting: Distinguish information explicitly stated by the caller from AI-generated interpretations and flag ambiguous descriptions.
• Data analytics and model evaluation: Analyze appropriately de-identified dispatch records to evaluate extraction accuracy, classification performance, and the reliability of generated summaries.
• Dashboard and reporting: Develop an interface for reviewing structured outputs, category distributions, model performance, and quality-improvement findings.

3. Technical Architecture

The proposed architecture consists of six major components.

1. Input layer: Accept dispatch call summaries, structured call details, or supported text-based narratives.
2. Text-processing layer: Normalize text, identify relevant phrases, and prepare the dispatch narrative for analysis.
3. Information extraction layer: Extract reported symptoms, patient information when available, incident circumstances, and other relevant details.
4. Classification and analysis layer: Organize the extracted information into potential patient assessment needs and relevant operational categories.
5. Evidence retrieval layer: Retrieve applicable dispatch procedures and approved EMS guidance to support traceable, protocol-grounded outputs.
6. Presentation layer: Display a structured pre-arrival briefing, reported concerns, potential assessment priorities, uncertainty indicators, and information requiring confirmation.

4. Initial Analysis Categories

5. Development Roadmap

Phase 1 — Baseline Prototype

Establish dispatch narrative input, LLM-based information extraction, structured patient-needs categories, and an initial web interface.

Phase 2 — Structured Classification

Develop a standardized classification framework for reported symptoms, incident types, potential assessment priorities, and missing information. Evaluate model outputs against expert-reviewed reference annotations.

Phase 3 — Protocol-Grounded Analysis

Integrate approved EMS dispatch procedures and clinical guidance. Add source citations, protocol version tracking, and safeguards against unsupported clinical conclusions.

Phase 4 — Pre-Arrival Briefing

Develop a concise briefing generator that organizes reported information into a format suitable for EMS review before patient contact.

Phase 5 — Research and Evaluation

Evaluate the system using appropriately de-identified dispatch data and qualified reviewer annotations. Measure extraction accuracy, classification performance, false-positive rates, uncertainty calibration, and consistency across different call types.

Future evaluation may also investigate how well the system distinguishes the caller's reported information from subsequent patient findings.

6. Intended Outcome

Our objective is to develop a research-oriented AI system that transforms unstructured emergency dispatch information into structured, interpretable patient-needs summaries.

The immediate focus is on building a reproducible processing pipeline, developing reliable symptom extraction and classification methods, and evaluating whether AI-generated summaries accurately represent the original dispatch information.

Future iterations may integrate protocol-grounded reasoning, additional operational data, and comparisons between dispatch reports and subsequent patient assessments.

The intended use is to support EMS preparation, pre-arrival situational awareness, education, and operational research. The system is not intended to independently diagnose patients, determine definitive treatment, or replace emergency dispatch protocols or clinician judgment.

Development Status and Safety Considerations

Current capabilities refer only to functionality that has actually been implemented and tested.

Planned capabilities describe proposed work and must not be represented as completed functionality.

The system must distinguish between symptoms reported by a caller, findings confirmed by EMS personnel, and AI-generated interpretations. Missing information must not be treated as evidence that a symptom or condition is absent.

AI-generated classifications should be traceable to the source narrative and, where applicable, approved dispatch procedures. Uncertain or ambiguous information should be explicitly identified rather than converted into definitive clinical conclusions.

Development and evaluation must use appropriately de-identified data or an approved secure environment with suitable privacy safeguards.

The prototype is intended for research and educational use. It is not a clinically validated medical device and must not delay emergency dispatch, override established dispatch protocols, or replace professional assessment and clinical decision-making.