I think you meant to link to: https://github.com/OHDSI/Covid-19/wiki/Release
1 Like
Good catch! Thank you, @krfeeney! I updated the link in my post.
I am creating a WG page on the wiki. Once it has been created, I will upload the recording @Andy_Kanter and post the link on this thread.
Hello EHR friends!
Tomorrow at 10am EDT will be our follow up call on covid-19 coding in the EHR. The new CDC covid-19 recommendations for coding the Condition with ICD10CM codes was updated on April 1st. If you have run an ETL since then, you should have the new U07.1 code in your data. Covid study questions are evolving quickly. Researchers are/will be seeking data on intubation, ventilation, dialysis and ECMO. These data live in many different places of varying granularity in the EHR. And map to multiple CDM tables depending on the “meaning” of the data. If you have these data in OMOP, I would like you to share with the group. A few questions to answer: Are the data structured or unstructured, the source domains, the target domains, the research questions you think these data can answer, and any knowledge on data gaps whether there is a gap in standard concept_id representation or gap in what happens at the bedside versus what is being ETL’d to the CDM. All experiences are welcome! This will be a good learning opportunity for us all.
The link to the meeting is further up in this forum chat. I look forward to a good discussion tomorrow. And I will record the meeting for those not able to join.
1 Like
Hello EHR WG!
This Friday the topic of discussion will be
“Discussion: Drugs order/administered/dispensed/med rec how this is recorded, how well it is captured, what insights are gleaned”
The Drug Exposure domain is one of the most frequently used tables for research. If you have ETL’d Drug data into the CDM, please attend to discuss and inform our colleagues.
Meeting details can be found on our Wiki page located [here]. I look forward to talking with you on Friday @ 10am EDT!
(https://www.ohdsi.org/web/wiki/doku.php?id=projects:workgroups:ehr-wg)
Cheers!
Hello,
Could I get added to this workgroup? We are implementing an OMOP 5.3 - based COVID data mart from our Epic data and wopuld love to join/contribute where I can.
Thanks!
Rob
Hi !
@MathildeFruchart and I are working on the implementation of peroperative data into OMOP CDM. We are developping an algorithm to detect hypotension, tachycardia, etc …
We’re wondering where to store the outputs of our algorithm (Some questions here).
Would it be possible to add this point to the agenda of tomorrow meeting ?
Hi - I have both derived and non-standardized data (ex electrocardiograph measurements and statements) that do not map well to LOINC or SNOMED. These go in the same places as all other measurements and observations - just using a custom vocabulary and concepts.
@mkwong this is very interesting! Could you please share some of the ecg concepts that won’t map to loinc? We we’re able to map ours and ecgs are pretty standard, so I’m wondering what those look like
Hi - I have a daily feed of all 12-lead ECGs taken throughout Tufts Medical Center in which all the measurements and computerized interpretation statements are mapped to our OMOP_ECG warehouse. Each manufacturer - Philips, GE, GLASGOW, etc have different variations in their ECG measurements and interpretation statements they generate. They all share the usual LOINC concepts - QT/QTc, R-wave amplitude, etc. However, some manufacturers programs produce measurements that others do not. For example Philips PH100/C include Initial and Terminal wave measurements across all 12-leads, QRS Peak-to-Peak or Swing, etc. I have OMOP maps for Philips, GE, and GLASGOW programs.
When I receive the standard 12-lead data - I also derive the X-Y-Z leads and these are all non-LOINC measurements.
Same for the different interpretation statements. All these are captured for doing machine learning types of projects where all measurements and statements are possible features, not just those that were mapped to LOINC or SNOMED.
- MK
Do you mean in using only the measurement_source_concept_id, and leaving the measurement_concept_id ?
Would you have some examples of statements ?
In our case, episodes of hypotension/tachycardia/etc look like period/era more than measurement (as for condition era / drug era). That’s why we were thinking about storing them into episode (in OMOP oncology extension)
Hi - Here is an example. I would create a new vocabulary where vocabulary.vocabulary_id = “PH100C” to represent the Philips ECG program version C. One of the concept defined would be for “Electrical Alternans” so the concept entry would look like:
concept_id = 1234567890
vocabulary_id = “PH100C”
concept_name = “Isoelectric delta in lead V5”
concept_code = “V5 ISO DELTA”
measurement.measurement_concept_id = 1234567890
measurement_source_value = “PageWriter TC70: SN 11223344”
I probably would not enter anything in measurement_source_concept_id as the measurement_source_value would have the information for me to trace back to the electrocardiograph that produced the measurement.
You can use the episodes for hypotension/tachycardia/etc - my first inclination is that mapping such statements to OMOP would end up in the Condition table. Unless I know when the tachycardiac started and ended - I would not have enough information to register an episode. If it is at minimum registered in Condition_Occurrence - you can at least search on it and see within which visits (thus time) it was observed.
All my ECG statements are mapped to the Condition_Occurrence table.
Thank you for your answer !
Yes, in our case, we also have start and end date, as well as other derieved values : extreme value, mean value etc …
Hi @AntoineLamer and @MathildeFruchart,
Welcome to the EHR WG!
Yes, today is an open discussion, so we can definitely discuss your questions. The details to join the meeting are listed on the WG page and further up in this discussion thread.
Cheers,
Melanie
Hi @mkwong,
Would you please clarify? You give your source data
But then you map them to the Condition table?
I think I am missing something. Why give them “Measurement” concept_ids and source values and then put them in the Condition table?
Hi,
Sorry for the confusion in my example.
Electrocardiographic data - those that come from a standard 12-lead ECG contains measurements (ex. V4 R-wave amplitude) and computerized diagnosis statements (ex. Normal sinus rhythm) automatically generated from the electrocardiograph device. All the measurements that are numeric amplitudes, durations (ex QRS Width), and counts (ex 5 PVCs) all go into the measurements table as LOINC concepts where possible.
All computerized interpretation statements are mapped if possible to the Condition table as SNOMED concepts. For example the computerized interpretation statement from the electrocardiograph “Atrial premature complex, SV complex w/ short R-R interval” from a Philips TC70 would be mapped to the Condition_Occurrence table as:
condition_occurrence.condition_concept_id = 4141030
condition_occurrence.condition_source_value = “PH100C.Atrial premature complex”
Hope that helps.
My interest is information about the device. You say, for example, “Electrocardiographic data - those that come from a standard 12-lead ECG contains measurements (ex. V4 R-wave amplitude) and computerized diagnosis statements (ex. Normal sinus rhythm) automatically generated from the electrocardiograph device.”
Do you record the device that provides the information? If so, at what level? Is it just make and model (Philips TC70) or other information such as serial number, software version number, etc. Some of this information is encoded in the UDI on the instrument. Do you use the UDI?
Hi,
Re device - the data that comes over our interface include the device serial number, model, and analysis software version - both measurements and computerized interpretation algorithms. I don’t think the UDI information is included in the patient record. This is the same for defibrillator devices in pre-hospital settings too.
Hello EHR WG friends!
Tomorrow, Friday, May 29th, we will discuss @AntoineLamer & @MathildeFruchart use case for mapping peri-operative data into the OMOP CDM.
Please join us at 10am EST. The meeting details are found here.
Hello EHR WG friends!
Friday, June 12th we will discuss CDM V5.3 to v6 transformation experiences. I encourage all collaborators to join the call since this topic is not EHR specific. We can all learn from other’s experiences!
Please join us at 10am EST. The meeting details are found here
The next EHR WG will be held Friday, July 10th at 10am EST. We will be discussing “How collaborators map custom codes to standard concept_ids. The two main options include: Source to Concept Map table or use of Concept/Concept Relationship tables”.