OHDSI Home | Forums | Wiki | Github

ETL High-Level Ventilator, Dialysis, CVVH Data

Implementers
#1

On the CDM all this week I had suggested that we should put ventilator information in the procedure b/c I was looking at procedure codes that I get from our system; however, based on the vocabulary, vent start and stop easily go into the device table. I had missed this, @Christian_Reich! I’m now trying to do the same w/ dialysis and cvvh (Continuous Veno-Venous Hemofiltration). What code do you think is the best one I should use if I want to capture the start and end time of these events? All the codes that sound right are in the procedure domain.

Technically, vent, dialysis, and cvvh are things being performed on the patient, but I think that debate might take too long to get into and I need to figure out what’s the best way to get this information into OMOP that makes the most sense so we can share what we’ve done :slight_smile:

@clairblacketer @MPhilofsky @Christian_Reich @mvanzandt any thoughts.

#2

Is there any chance you could capture ventilator settings?

I have a suspicion that the bad CoViD19 outcomes on ventilators are in part iatrogenic, which is consistent with the finding that overweight is such a huge risk factor for young people.

#3

Vent settings are next, but need to figure out how to extract that information correctly. Right now, just focusing on duration…

#4

Well, most devices actually come with a procedure applying the device. Unless it’s just talking (counseling). We have that problem. So, don’t sweat it. Either one is fine. The cohort definition will have to pick up either choice.

That’s an interesting one. Currently, we don’t have anything of that nature. We cannot represent it. Almost sounds like a table DEVICE_SETTING, with Concepts like "Assist/Control Ventilation (A/C) ", “Pressure Support Ventilation (PSV)” and “Synchronized Intermittent Mandatory Ventilation (SIMV)”. And even EAV type settings like setting_concept_id=“Flow” and setting_as_number=60 and unit_concept_id=‘L/min’ (well, the UCUM Concept for it).

Thoughts?

#5

The EHR data I have seen for these Procedures/Devices are present in two distinct areas of the EHR.

There are the Procedure codes for Initiation of the Device. Such as intubation or catheter placement. And then there are the “maintenance” Procedure codes for the Person and Device management while the Person is receiving the therapy. The problem with these codes is that they are usually at the hospital account/billing account level and there aren’t times associated with the event. Another issue is the ICD10PCS codes have generic time periods, < 24 hours or 24 to 96 hours, > 96 hours, etc. which isn’t granular enough for the questions you seek to answer.

The other area for these data are where the Providers (doctors, nurses, therapists and technicians) record Device settings, a Person’s vital signs, and 1000’s of Measurements & Observations (the line becomes very blurry). Within Epic, these data are highly customized and NOT attached to an OMOP supported vocabulary. There are standard concepts to represent some of these data, generally in the LOINC vocabulary, but all the data from this area will require custom mapping. And I’m unsure how much coverage LOINC provides for this area.

As for the Device table, the vocabulary is fairly generic. There are ventilators, but I wonder if researchers will want the more granular ventilator data including Device name, brand, style, etc. as a standard concept_id.

Would the Episode table be able to incorporate the Procedure, the Device and the Device settings as an invasive, mechanical ventilation Episode?

#6

A key indices is PEEP - post endo expiratory pressure - which provides insight as to the severity of ARDS (perhaps peak PEEP), also reviewing the following may be helpful in terms of the different presentations and management of COVID-19 lung disease profiles:

#7

Hi all,

I am trying to extract the vent data, but unsure about where to land the data in the OMOP table. I have a few specific questions about how to ETL Endotracheal Tube and I am hoping any of you could shed some light on this.

Which domain table for vent data?
I am under the impression from reading the replies above that I could do either device_exposure or procedure_occurrence and a well-defined concept set should be able to pick it up from either domain. However, I am wondering if I should populate both device_exposure and procedure_exposure just to be safe?

Which concept for vent data?
I don’t have a clinical background if I make any outrageously wrong statements please correct me. My understanding is that Endotracheal Tube should infer the patient was intubated and therefore on a ventilator,

For device_exposure, should I use

  1. Ventilator
  2. Endotracheal Tube (4097216)
  3. or both?

For procedure_exposure, should I use

  1. Endotracheal respiratory assistance (4080957)
  2. Intubation of respiratory tract (40487536)
  3. or both?

I am personally inclined to use both concepts in both domain tables, which means, I would create 4 records for one Endotracheal Tube encounter. Please share your thoughts and give me some guidance on this. Many thanks in advance!

Cheers,
Chao

#8

Is your data already in the OMOP CDM? Or is the beginning of the journey?

The above have a concept_class_id = ‘Physical Objects’ and a domain_id = ‘Devices’ and will map to standard concept_ids in the Device table.

No, only populate the Procedure table with Procedures. Billed Procedures will give you the CPT4, ICD10PCS, HCPCS, etc. codes for intubation, ventilation, etc. Also, ordered and completed Procedures will give you the data, but most likely it is coded with internal Epic codes. You will need to custom map these codes.

Most likely, but don’t do it this way because you are making assumptions about the data. Procedures will tell you a Person was intubated and also approximately how long they were on the ventilator. See the links I posted above. Flowsheets should give you data with finer granularity.

Use the code from the billed Procedure data. Or the data from the Flowsheets. Work from source to target. Not the other way around. The source data will tell you where they live in the CDM. Read more in The Book of OHDSI, it’s invaluable!

If I were you, I would enlist the help of a person who has written reports off of mechanical ventilation, invasive ventilation, artificial ventilation and someone with clinical experience. The nuances of the semantics are fine and it’s very easy to make an honest mistake.

#9

Hi @MPhilofsky

Sorry I don’t think I introduced myself, I am one of the data engineers from Karthik’s group.

Thanks for the advice, and I really appreciate that you took the time to answer my questions! You are 100% correct about not making assumptions about data, sorry about the rookie mistakes, I have been in the rabbit hole too long and forgot the basic principle of OMOP ETL. I am still in the middle of trying to understand the data and finding where the data is located.

The reason I mapped the description to the OMOP concept id for procedures is that the information seems very scattered and some of the expected procedures could not be found the ordered procedure table, I am currently talking with several people who are down the same rabbit hole to try to understand this discrepancy.

For procedures, this is crystal clear and I will use the CPT4/HCPCS codes to get to the standard concepts. As for the discrepancy I described before, I still need to figure this out to make sure we are not missing any procedures.

For devices, this is still a bit of question mark to me, I mapped internal codes such as ETT ane ECMO to the device concept ids based on the descriptions, do you think this would be a sufficient approach for mapping devices?

Cheers,
Chao

#10

@cukarthik I heard your story of trying to get ventilator data into the CDM a few weeks ago on the EHR workgroup call and now we’re right behind you trying to get it into our instance as well. Do you have any updates/lessons learned so far you can share?

Our use case at the moment is “who was/is on a ventilator?”

So far, we’re attempting to start with device_exposure and looking at some concepts from the vocabulary @MPhilofsky mentions below.

We’ve narrowed on some concepts to help us get more granular than just “ventilator” and get at some to broad categories invasive (trach,endotrach etc) and non-invasive (bipap,cpap).

We’re already getting questions around settings and will probably need something like this soon @Christian_Reich. EAV sounds appropriate to be able to capture the changes to the settings that can occur.

#11

@burrowse, @ChaoPang, @cukarthik and other collaborators trying to fit ventilator/dialysis/ECMO Device & Procedure data into the CDM

Have you found the appropriate concepts? Are they standard? Which domain/s did you chose to use? There are many ways to represent this data. I am curious what others have chosen to do. Would you share your concept sets and conventions? I am assisting others on this journey and would like to see if we could develop some standardization around these critical needs, test them out with the covid-19 use cases and queries, then perfect the vocabulary & conventions so we all aren’t creating the same thing separately. The EHR data I have seen is present in many different source domains of varying granularity and structure.

#12

Am in the same boat. We seem to have three domains of interest: Device Exposure - a macro view of the patient and devices; Device related procedures such as implantation, maintenance, removal; and Device settings and physiologic measurements such as pressures, bpm, etc. And these answer different questions and are composed of wildly different elements. Right now I am trying to deal with device exposures - which devices for which people for what time intervals. And the “device” type choices are not clear to me - they frequently mix device and usage. We are also doing the “billed procedures” which may take care of the first category. As to the settings and measurements - these are complex and not standard from EMR to EMR. So ultimately we do all three - right? But there is no real connection between them except patient, encounter and time.

#13

We are still trying to figure this out. We are struggling with the device settings. We could put it in the observation table like @MPhilofsky suggested and using the fact-relationship table. My struggle is that it is not easy to query for analysis. What have others done? @burrowse @acoltri @gschadow

#14

In the data I am working with - it is difficult to get exact exposure date/time when a device was actually used and ended. So I map at the highest level of device exposure in procedures and device_exposure using SNOMED codes. Both procedure and device_exposure records are tied to the person_id and visit_occurrence_id. Typical queries so far don’t get into any more details than “how many visits the person was exposed to a certain device”. This covers catheters to machines from our invoice data source.

Since we capture complete 12-lead electrocardiograph records from our ECG management system - this is one case where we can populate device_exposure (with accurate start/end times), procedure, and observations and measurements as the 12-lead ECG contains machine generated measurements and computerized interpretation statements.

My strategy has been include the high level device and procedure concepts so you can find these patients. Test it against some use cases and validate against the EHR data. Then add more details if needed - its an iterative process driven by use case needs. With limited resources, I find it efficient to deal with current needs and be sure to write your ETLs so they are extensible to deal with future needs.

#15

Just pointing out that in CDM 6 the Observation table has the observation_event_id and obs_event_field_concept_id. These two fields can, sort of, replace the Fact_Relationship, allowing you to reference the Observation record back to say the ‘billed procedure’. If you are in CDM 5 I would still not hesitate to add these ‘non-standard’ fields since they are in CDM 6. Also, I think similar fields will be added to Measurement in the near future.

#16

Hi guys! I created a separate post with the proposal of storing flowsheet data to OMOP CDM. Please have a look at it. @cukarthik, @gschadow, @Christian_Reich, @MPhilofsky, @nigehughes, @ChaoPang, @burrowse, @acoltri, @mkwong, @DTorok

t