Replies: 4 comments
-
|
Beta Was this translation helpful? Give feedback.
-
Cases presented at Thursday's meeting
|
Beta Was this translation helpful? Give feedback.
-
@tompollard, @bemoody, and I have organized and updated the waveform requirements for each use-case story. We tried to limit the requirements to only things that may affect the waveform format / specification. @hulab-ucsf, @del42, @manlik-brownsrdr, @tcpan, @wa6gz please let me know if we missed anything or if you have any suggested edits.
|
Beta Was this translation helpful? Give feedback.
-
The requirements above were refined, categorized, and discussed at meetings to determine which of the requirements were considered mandatory. A summary of those decisions is posted below. CHoRUS requirements for a waveform formatThis document outlines CHoRUS requirements for a waveform format, based on the set of user stories identified previously. Note that these requirements relate to the format for distributing the data (i.e. made available to researchers via the CHoRUS platform), rather than intermediate formats used for acquisition, transfer, etc. SignalsThere are several core needs that relate directly to the storage of signals. A file format meeting the requirements below should be able preserve all key information in a source file. The format should support:
*time intervals > 15 minutes = low resolution - > suitable for a relational database. time intervals < 15 minutes but longer than waveform = medium resolution. MetadataBy “metadata”, we mean any information that does not form part of the core signal data. The format should enable storage of (or a link to):
AnnotationsAnnotations are a type of metadata, but they are distinct from metadata because they may be contributed by many independent users and may not be considered as “ground truth”. The format (or a linked annotation format) should support:
EfficiencyThe format should be both efficient in terms of storage and data-loading, primarily to (a) minimize storage and transfer costs and (b) enable rendering of waveforms using browser-based tools. The format should support:
UsabilityImportantly, the format should be easy for the AI research community to use and understand. It should have:
|
Beta Was this translation helpful? Give feedback.
-
Please use this discussion to submit stories of use-cases for waveform data from CHoRUS. These stories will be used to develop a comprehensive list of requirements for the CHoRUS waveform format / specification. Please see an initial set of stories with associated requirements below.
When submitting a new story please fill out the "As a:", "I need to:" , and "So that:" fields. If you also know of associated requirements for the waveforms, based on your story, please provide them. If your requirement overlaps with a requirement term already posted to the table, please use the phrasing from the one that is already posted (i.e. use "Signal availability by time" instead of "Know signal types at a given time"). If you aren't sure about the waveform requirements for your story, feel free to leave this field blank and we will fill it in. Please add a new post below and I will update the table.
I need: to identify all patients within CHoRUS that meet the following criteria: 1) Have at least ECG, ABP, and ICP waveforms, 2) ICP measured from brain ventricles, 3) Having at least XX hours of ICP where pulsatile waveform exists,
So that: I can determine if there are enough matching subjects in CHoRUS to power the study I want to conduct
Multi-channel support,
Signal availability by time,
Standardized naming conventions,
Standardized units,
Cached/precomputed statistics
I need: to select a patient who went into septic shock - identify an instance of vasopressor administration - visualize waveforms within XX minutes of administration,
So that: I can train residents on the relation between monitor waveforms and septic shock
Random access,
Efficient rendering
I need: to search for a cohort of patients who each have at least XX number of PVC beats,
So that: I can compute heart rate turbulence
Numerics support,
Cached/precomputed statistics
I need: a plugin/toolbox which allows me to compute sample entropy on HR time series,
So that: I can create a presentation on sample entropy analysis of heart rates
I need: analyze EEG and ICP waveforms,
So that: I can determine if EEG + ICP waveforms may predict disease X
Multi-channel support
I need: monitor waveform data at the original sample rate with the resolution specified,
So that: I can compare monitors roles in disease algorithm prediciton models
Metadata support(w/resolution)
I need: waveform data to take up as little storage space as possible,
So that: we can afford to pay for cloud storage and provide waveform data in CHoRUS to the community
Efficient gap storage
I need: efficient decompression of waveforms,
So that: I can provide a performant waveform viewer which can quickly jump to waveform locations
I need to be able make RESTFul API call to get given chunk of the continues waveform file to build waveform panning/zooming/streaming features,
So that: researchers/investigators can do physiological time series analysis and tagging clinical events
File needs to be imputed+uncompressed, OR chunked(short)+compressed+non-imputed
Note: do not care for time value, if there is startTime and frequency for imputed files
I need to build various types of interactive waveform tagging features,
So that: users can build their ML labels for projects like Signal Quality Index, Signal classification, ARDS dashboard, Chart review, NLP NER and many more
File needs to be imputed+uncompressed, OR chunked(short)+compressed+non-imputed
Optional sort channels
Select channels/signals
Data can be preprocessed
Up/down sampling ability
I need: to rapidly access blocks of the signals, corresponding to segment/time periods, sequentially within blocks, and in parallel across blocks, and concurrently access multiple channels, with minimal overhead for decompression if present,
So that: I can minimize random IO and IO/Bandwidth while processing part or whole waveforms
Rapid block location of multiple channels,
Sufficient metadata in each block,
Simple compression that are independent between blocks
I need: to be able to parse the data with minimal documentation and tool stack,
So that: I can read and process waveforms with minimal software dependencies
I need: identify episodes of acute cardiac ischemia, infarction, arrhythmia, and cardiac arrest events,
So that: I can associate treatments and identify degradation in patient condition during the ICU stay
Ability to identify cardiac events (onset of acute ischemia, ST elevation events, tachycardia, etc) then query treatment events before and after cardiac event onset/offset,
Ability to identify study cohorts via OMOP, then identify cardiac events (or lack of) in disease and control groups,
Ability to re-analyze or apply predictive analytics models on waveform data before and after event date/times
I need: an interface for implementing interpolation,
So that: I can easily build pipelines from source data that is captured at site-specific frequencies while maintaining control over the interpolation mechanism
I need: the ability to ingest data with multiple sample rates,
So that: I can store data with different input sample rates into a single patient record
I need: be able to update QRS annotations in the CHoRUS data because I noticed that the pre-calculated RR intervals for some of the patients in my cohort of CHoRUS patients were based on incorrect QRS locations. I have found the associated ECG waveform data and corrected the QRS locations with a different algorithm. I manually reviewed the updated QRS locations,
So that: I can share the corrected QRS annotations and therefore the CHoRUS community can benefit from corrected R-R intervals
I need: 1) be able to engage with the CHoRUS community; 2) test and benchmark sepsis prediction models; 3) assign a resource ID to a cohort of CHoRUS patients that I selected using the CHoRUS/OHDSI computational phenotyping in the Integrated Viewer / IVe app. I finalized the cohort by performing a chart review using the CHoRUS CADA app. The patients in this cohort include those from data recently added to CHoRUS,
So that: we can build a system in CHoRUS for continuously benchmarking models on specified cohorts
I need: be able to convert from the native format of my waveforms to the CHoRUS waveform format,
So that: I can provide waveforms in the desired format.
I need: to identify patients with a radial arterial pressure waveform recorded with a bandwidth of at least 40 Hz,
So that: I can determine the systolic upslope with adequate precision
I need: to identify sets of patients that used different monitoring equipment,
So that: I can determine if my algorithm performance is affected by the monitoring devices that were used
I need: to identify waveforms recorded at different anatomical locations,
So that: I can evaluate if the algorithms performance varies at the different locations
Anatomical placement,
Make/model of sensor and patient monitor
I need: check for things such as: 1) monitoring time with at least one ECG lead on should be the longest among all available waveform channels; 2) average heart rate calculated for a given file should be within a physiologically sound range; 3) I expect ECG, impedance, and SPO2 channels to be always available,
So that: I can alert the submitter of the uploaded files of issues in a timely manner if the quality/completeness checks fail.
I need: be able to easily identify and access any potential protected health information (PHI) in waveform files even if they have already been converted to the final CHoRUS waveform format,
So that: we can identify sources of PHI prior to releasing the data, and work with local sites to further de-identify the waveforms as needed
Beta Was this translation helpful? Give feedback.
All reactions