OHDSI Home | Forums | Wiki | Github

ICU data, anyone?

(Benjamin Skov Kaas Hansen) #1

Hi everybody,

We’re working with i.a. ICU data in our group. We currently didn’t OMOP our data—although it’s on the drawing board for later—but were wanted to reach out to the community to understand how many OMOP’ed ICU data set exist, and if anyone might be interested running a validation study eventually?


(Jose Posada) #2

Hi Ben,

There are two outstanding sources of ICU data publicly available:


Which has public code to transform to OMOP-CDM

And a newly released Chinese database


Which follows the MIMIC schema thus the ETL should in theory work

(Benjamin Skov Kaas Hansen) #3

Hi Jose,

Thanks for the link. I’m aware of MIMIC, and it is indeed a great resource. I was curious, however, to understand if there are OMOP’ed ICU data sets which

  1. cannot be shared publicly (as ours) and, thus, would be well-suited for the local-analysis-central-synthesis (privacy-by-design) philosophy of OHDSI; and/or
  2. come from other hospitals, regions and countries than MIMIC (e.g., European or Asian), for richer external validation.

I’m not super familiar with the nature of claims data, but I reckon ICU data are a different creature compared to the “typical OMOP data”. I’d imagine—and hope—that e.g. the EHDEN project might help OMOP’ed ICU to come about.

If others stumble into this post and have OMOP’ed ICU data, I’d been keen to get in touch.


(Melanie Philofsky) #4

How do you define “ICU data sets”? Many hospital EHR data sources contain ICU data. What exactly do you seek from the ICU dataset?

(Benjamin Skov Kaas Hansen) #5

Right. Good question, @MPhilofsky. I suppose I’d define ICU data as comprising high-frequency data from machines (e.g. ventilators, infusion pumps and continuous monitoring apparatus) and more “low-frequency” data (e.g. manual observations and biochemistry) than other hospital wards.

Thus, in our context “ICU data” are considered somewhat distinct from EHR data, and since we’re trying to leverage the additional information of the data types mentioned above, we were keen to understand if others in the OHDSI community are as well.

(Melanie Philofsky) #6

You should ask about this in the Device WG.

Colorado doesn’t record data directly from many devices. Some are interfaced to the EHR, but most data are input or approved for input into the UI by the bedside Provider. For devices that continuously monitor (EKG, HR, arterial BP), I wonder how often this data is recorded into an EHR. Every second, every 10 seconds, every minute, every 5 minutes, etc…

(Manlik Kwong) #7

Hi - this is a good question for the Device Working Group.

At Tufts we are currently capturing 12-lead ECG data (10 seconds at 500sps) and mapped to an ECG_OMOP database instance. We are starting to explore and develop ways to manage continuous data from patient monitors in collaboration with folks in the MIMIC and commercial vendors. While we have developed OMOP mapping for ECG measurements and computerized interpretation statements for the more common 12-lead ECG machines - I expect the support of continuous patient monitoring data to be derived from the current work/mapping dictionary.

Regarding frequency of data capture - it depends on your device integration solution/method and ultimately what is the clinical or informatics needs. In general I prefer to capture diagnostic resolution data and take the storage hit, maybe not directly in the EHR but as part of our research data warehouse. You would have to run a literature search to see what seem to be a useful data resolution and whether continuous or episodic sampling will be sufficient.

(Jose Posada) #8

Hi @mkwong,

Did you developed an extension of OMOP for ECG data? if yes, do you have any resource you could point me?

Thanks in advance!

(Manlik Kwong) #9

Hi - no extensions to the CDM design at all - used LOINC and SNOMED standard concepts and mapped all 12-lead ECG measurements (LOINC) and computerized interpretation statements (SNOMED and LOINC) to OMOP. For patient monitors - I anticipate doing the same thing for its data. For practical implementations - I am leaning toward a) Using OMOP.note table to reference file sets that represent and contain the full continuous data stream; or b) Embed blocks of patient monitor data in a series of OMOP.note records.

Staging is handled by a 1-N lead XML schema to handle different commercial native data source/format/sample rates/signal resolutions.

If you are using GE12SL, Philips, or GLASGOW 12-lead ECG measurements/interpretation statements I can share these mappings with you.

(Jose Posada) #10

Hi Manlik,

We are in early phases with waveform data so anything you can share will be more than welcome. My email is jdposada at stanford.edu. Thanks!

(Benjamin Skov Kaas Hansen) #11

Hi guys,

Thanks for your responses. I agree with your notion, @mkwong, that it’s better to capture all data and afterwards wind ways to operationalise it in a way useful for the analytic problem at hand.

It does seem from the response rate (and the nature of your responses) that essentially no sites have plugged “ICU data” into their OMOP CDM’s, but I’ll ask in the Device WG as well.

A lot of the data coming out of ICU machines has exact low-frequency equivalents: blood pressure, drug exposure (with continuous infusion), saturation. Mapping that should be quite straightforward, I’d argue. Other data types coming from e.g. ventilators might be more tricky because you also get settings data as well as observations.

Anyway, thanks a bunch! And if other people with ICU data stumble across this post and are interested in collaborating, please give me a shout.