[USE CASE] CHoRUS Multimodal Phenotyping of Post-Stroke Atrial Fibrillation in ICU Patients

[jshoughtaling]

Description

This use case demonstrates multimodal analysis of clinical and physiological data represented in the OMOP Common Data Model and the OMOP Waveform Extension. The objective is to identify ICU patients with stroke who subsequently develop atrial fibrillation during or after the index stroke event, using rhythm abnormalities detected from physiological waveforms as the primary outcome evidence.

Research Question

Among adult ICU encounters with an index stroke event and no prior clinical or waveform evidence of atrial fibrillation, which patients have atrial fibrillation first detected from ECG waveform-derived features after the operational stroke index datetime and before ICU discharge?

The analysis requires integration of:

• patient and encounter data;
• ICU stay information;
• stroke diagnoses and an operational stroke-onset timestamp;
• historical atrial fibrillation diagnoses or waveform findings;
• ECG waveform recordings;
• waveform channel metadata;
• waveform-derived atrial fibrillation features;
• temporal relationships among stroke onset, ICU admission, waveform monitoring, and AF onset.

A qualifying patient should meet all of the following criteria:

• The patient has a qualifying stroke event associated with an ICU encounter.
• A stroke index datetime can be established using a documented operational definition.
• Atrial fibrillation is detected in an ECG waveform after the stroke index datetime.
• No atrial fibrillation is documented before the stroke index datetime within the defined lookback period.
• The AF finding occurs within the predefined observation window, such as during the ICU stay or before ICU discharge.

The use case should support both positive and negative test scenarios, including:

• stroke followed by new-onset AF
• stroke with pre-existing AF
• stroke without AF
• AF occurring before stroke onset
• AF without stroke
• AF occurring outside the ICU observation window
• AF detected in a later waveform segment or recording
• patients without an interpretable ECG channel.

The expected output is a patient-level cohort containing:

• person_id
• index stroke event and timestamp
• ICU encounter identifiers
• first qualifying post-stroke AF timestamp
• waveform occurrence, file, and channel references
• AF detection method and provenance
• exclusion status or reason
• time from stroke onset to AF onset

Infrastructure

The use case is implemented using:

• OMOP CDM v5.4 clinical tables
• OMOP Waveform Extension tables
• OHDSI Standardized Vocabularies
• MIMIC4 custom vocabulary content
• WAVEFORM custom vocabulary content
• MIMIC-IV clinical data
• MIMIC-IV waveform metadata and synthetic waveform fixtures
• OHDSI ATLAS for interactive concept-set development, clinical cohort design, and phenotype review
• OHDSI Capr for readable, version-controlled, and executable cohort definitions in R
• custom SQL or extension-aware analytical code for linking stroke events, ICU stays, waveform records, ECG channels, and waveform-derived AF features
• selected HADES packages for cohort generation, diagnostics, reproducible study execution, and downstream analysis
• automated referential, temporal, vocabulary, and use-case QA

Relevant OMOP CDM tables may include:

• PERSON
• VISIT_OCCURRENCE
• VISIT_DETAIL
• CONDITION_OCCURRENCE
• PROCEDURE_OCCURRENCE
• MEASUREMENT
• OBSERVATION
• CONCEPT
• CONCEPT_ANCESTOR
• CONCEPT_RELATIONSHIP

Relevant Waveform Extension tables include:

• WAVEFORM_OCCURRENCE
• WAVEFORM_REGISTRY
• WAVEFORM_CHANNEL_METADATA
• WAVEFORM_FEATURE

The intended analytical linkage is:

PERSON
↓
VISIT_OCCURRENCE
↓
VISIT_DETAIL - ICU stay
↓
CONDITION_OCCURRENCE - stroke index event
↓
WAVEFORM_OCCURRENCE
↓
WAVEFORM_REGISTRY
↓
WAVEFORM_CHANNEL_METADATA - ECG channel
↓
WAVEFORM_FEATURE - atrial fibrillation interval

The analytical implementation should preserve:

• stable identifiers
• valid parent-child relationships
• consistent patient and encounter context
• temporal ordering
• source and target file provenance
• vocabulary provenance
• algorithm provenance
• reproducible cohort logic

Timeline

Phase 1 - Use-case specification

• Define the qualifying stroke phenotype.
• Define whether the cohort includes ischemic stroke, hemorrhagic stroke, or both.
• Define the operational stroke-onset timestamp.
• Define the ICU inclusion criteria.
• Define the prior-AF lookback period.
• Define the post-stroke observation window.
• Define acceptable waveform-derived evidence of AF.
• Define exclusion criteria and expected outputs.

Phase 2 - Vocabulary and data-model preparation

• Validate required stroke and atrial fibrillation concepts.
• Validate MIMIC4 and WAVEFORM vocabulary mappings.
• Define ECG channel concepts and source-value mappings.
• Define AF feature concepts, algorithms, and result representation.
• Validate units, file formats, metadata concepts, and relationships.

Phase 3 - Synthetic data generation

• Create synthetic patient and encounter records.
• Create linked ICU visit details.
• Create stroke index events.
• Create prior-AF and no-prior-AF scenarios.
• Create waveform occurrences and registry files.
• Create ECG channel metadata.
• Create waveform-derived AF feature intervals.
• Create a machine-readable expected-result table.

Phase 4 - ETL and QA

• Load clinical and waveform synthetic data.
• Validate primary-key uniqueness.
• Validate foreign-key completeness.
• Validate patient and encounter consistency.
• Validate waveform and clinical timestamp alignment.
• Validate channel and feature mappings.
• Validate absence of unresolved mandatory concepts.
• Validate expected file and channel counts.

Phase 5 - Analytical query development

• Identify qualifying ICU stroke patients.
• establish the stroke index datetime.
• exclude pre-existing AF.
• identify the first post-stroke waveform-derived AF interval.
• calculate time from stroke onset to AF onset.
• produce patient-level and event-level outputs.

Phase 6 - Use-case validation

• Compare query results with the synthetic truth set.
• Confirm expected true positives and true negatives.
• Investigate false-positive and false-negative cases.
• Test edge cases involving multiple visits, recordings, channels, and segments.
• Document final phenotype and implementation decisions.

Phase 7 - Analysis, Interpretation, and Dissemination

• Execute the validated study on MIMIC-IV and, where appropriate, additional CHoRUS-compatible OMOP databases.
• Estimate the incidence and timing of new-onset atrial fibrillation after stroke.
• Describe AF burden, episode duration, recurrence, and relationship to ICU stay and waveform-monitoring coverage.
• Compare patients with post-stroke AF, pre-existing AF, and no AF.
• Evaluate associations with relevant outcomes, such as mortality, ICU and hospital length of stay, recurrent stroke, anticoagulant initiation, and bleeding events.
• Perform sensitivity analyses using alternative definitions of stroke onset, AF evidence, prior-AF lookback, and observation windows.
• Assess missing waveform coverage, channel availability, mapping completeness, and potential selection bias.
• Conduct clinical and methodological review of the findings.
• Produce reproducible analytical outputs, including cohort definitions, concept sets, SQL, Capr code, diagnostics, and result summaries.
• Prepare study documentation, figures, tables, and manuscripts or conference submissions.
• Publish reusable code, synthetic test data, vocabulary dependencies, and implementation guidance where permitted.
• Clearly distinguish findings derived from synthetic data, MIMIC-IV, and any external validation datasets.

Credit

This use case is being developed within the OHDSI Waveform Working Group and the CHoRUS Bridge2AI project to support multimodal ICU analytics and waveform data harmonization.
Contributors: Brian Gow (MIT), Manlik Kwong (Tufts CTSI), Marty Alvarez (Tufts CTSI), Jared Houghtaling (Tufts CTSI), Daniel Smith (Emory University), Polina Talapova (SciForce/Tufts CTSI).

Other contributors should be credited for:

• clinical use-case definition
• OMOP and Waveform Extension modeling
• vocabulary development and mapping
• MIMIC-IV ETL
• synthetic-data generation
• waveform feature engineering
• cohort implementation
• analytics
• results dissemination
• quality assurance
• clinical and technical review

Support

Questions, implementation issues, and proposed changes should be discussed through the relevant project repositories and OHDSI Waveform WG.
Primary support channels may include:

• OHDSI MIMIC repository issues
• OHDSI Waveform WG repository issues
• CVB repository issues (for MIMIC4 and WAVEFORM custom vocabularies)

Issues should clearly identify whether they concern:

• clinical phenotype logic
• Waveform Extension representation
• source-data extraction
• vocabulary coverage
• ETL behavior
• synthetic-data generation
• feature derivation
• analytical query logic
• quality assurance

Datasets of Interest

MIMIC-IV

MIMIC-IV provides the clinical context required for:

• patient identification
• hospital and ICU encounters
• stroke diagnoses
• historical atrial fibrillation diagnoses
• procedures and interventions
• temporal linkage to waveform recordings
  Relevant MIMIC-IV components may include:
• hospital admissions
• ICU stays
• diagnosis data
• procedure data
• charted events
• waveform linkage metadata
• matched waveform records

MIMIC-IV Waveform Database

The waveform dataset provides:

• ECG waveform recordings
• waveform files and segments
• signal-channel definitions
• sampling frequency
• gain and unit metadata
• recording intervals
• input data for AF detection or feature extraction.

Synthetic Data

Synthetic data is required to provide deterministic, non-sensitive test cases for development and validation.
The synthetic dataset should include:

• linked OMOP patient, visit, and ICU records
• stroke index events
• pre-existing AF scenarios
• post-stroke AF scenarios
• waveform occurrences
• registry files
• ECG channels
• waveform-derived AF features
• expected cohort membership
• expected exclusion reasons
• expected AF onset timestamps
  Synthetic data should be designed as a test fixture rather than as statistically representative simulated clinical data.

Depends On

This use case depends on:

• a defined and reviewed stroke phenotype
• an operational definition of stroke onset
• a defined new-onset AF phenotype
• a prior-AF lookback rule
• a defined ICU observation window
• valid OMOP CDM clinical data
• valid VISIT_DETAIL representation of ICU stays
• the OMOP Waveform Extension schema
• successful population of WAVEFORM_OCCURRENCE
• successful population of WAVEFORM_REGISTRY
• successful population of WAVEFORM_CHANNEL_METADATA
• representation of AF findings in WAVEFORM_FEATURE
• stable linkage between waveform and clinical records
• MIMIC4 vocabulary content
• WAVEFORM vocabulary content
• reviewed channel mappings
• reviewed file-format and metadata mappings
• valid unit concepts
• an AF detection algorithm or manually assigned AF truth
• algorithm provenance
• a machine-readable synthetic truth set
• automated temporal, referential, semantic, and cohort-level QA
• resolution of the design and ETL issues identified in the related Waveform Extension and synthetic metadata pull requests

[p-talapova]

Updated the use case based on the Waveform Working Group meeting held on June 26, 2026.