Clarifications on Cardiac Output (CO) Measurements in MIMIC-III WFDB and Clinical Databases
Nobody has claimed this yet.
- Dominant language
- Jupyter Notebook
- Stars
- 3.4k
- Forks
- 1.7k
- PR merge metrics
- No merged PRs in 30d
Description
I’m currently building a dataset from the MIMIC-III WFDB Matched Subset that combines ABP/ART waveforms with cardiac output (CO) values as ground truth for arterial pressure-based cardiac output (APCO) estimation. While working on this, I came across a few key points I’d like to clarify with the community:
1. Are CO values in WFDB numerics exclusively from thermodilution?
The numerics files in WFDB include CO values, but they are not explicitly labeled by measurement method. To investigate, I attempted to match WFDB CO entries with those in the MIMIC-III Clinical Database (chartevents table), using ITEMIDs for known CO measurement techniques.
In all confirmed matches (based on identical values in L/min to 2 decimal places, within ±1 hour), only TCO (220088) entries matched with WFDB numerics. This strongly suggests that WFDB CO values originate solely from thermodilution.
Question:
- Can we reliably assume that all CO values in WFDB numerics are from thermodilution? Confirmation would allow safe extrapolation to unmatched entries.
2. Timestamp discrepancies between WFDB and Clinical Database (CDB)
WFDB numerics appear to be recorded automatically from bedside monitors, which should provide accurate timestamps. However, I noticed that even when CO values match between WFDB and the Clinical Database, the timestamps often differ, sometimes by several minutes (typically within ±5 minutes, but occasionally up to an hour).
According to the MIMIC documentation: “In the case of continuous vital signs (heart rate, respiratory rate, invasive blood pressure, non-invasive blood pressure, oxygen saturation), the CHARTTIME is usually exactly the time of measurement.”
Since cardiac output is not listed among these continuous variables, and considering the discrepancies observed, it seems possible that CHARTTIME reflects the time the measurement was observed and manually entered, rather than the actual measurement time. This would explain the temporal offset.
In my application, I’m not looking for beat-level alignment — just capturing the waveform trend around the time a given CO value was recorded. As such, even small delays (a few seconds) are acceptable, but larger discrepancies (e.g., several minutes) could impact the validity of the sample.
Questions:
- Can the CHARTTIME for CO in the Clinical Database be considered reliable for waveform-to-measurement synchronization?
- Is it safe to assume WFDB CO timestamps are more accurate in this context?
Any clarification or insight on these points would be greatly appreciated! Thanks again to the community and contributors for making this dataset so valuable for research.
Best,
Vincent
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the MIMIC-III documentation and compare WFDB numerics against the Clinical Database chartevents entries, especially ITEMID 220088 and the reported timestamp offsets. Done means documenting whether the CO provenance can be confirmed and which timestamp is appropriate for waveform synchronization.
Written by the indexing model from the issue text.
Assessment
- Domain
- data, databases, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100