I just joined ohdsi, hop to be involved. I am involved in seversl projects about italian emr.
paoloeusebi@gmail.com
Please add me.
Hi all,
Our first meeting will be on Friday, November 2nd at 8am MT, 10am ET and UTC -07:00. The meeting link is below
The Google Doc with a very short list of issues and goals is here EHR to OMOP - Google Docs
Please add to it before our first meeting. And please reach out with any questions, comments, idea, etc
We had a good turnout for the first meeting and I know others will be joining at our next meeting on Friday, November 16th at 8am MT, 10am ET and UTC -07:00.
Meeting notes and next week’s agenda are here
Issues, assumptions, and goals document is here
Feel free to reach out about anything above or anything at all
I will like to join/contribute as well. Sandeep Kataria email - skataria@uic.edu Time zone - Central Time.
Thank you for starting this.
I would like to join/contribute as well.
Susan Zelisko: szelisk@luc.edu Time Zone - Central Time
Thanks
I’m sorry that I won’t be able to join the calls - we have a weekly team meeting at this time slot that I can’t miss.
That said, we’ve been giving some thought recently trying to figure out how to handle an issue I’d imagine a lot of you deal with as well. I’m curious to hear your thoughts: how do you handle encounter types? We get a lot of “encounters,” and some of them (office visits, telephone calls) probably belong in VISIT_OCCURRENCE, whereas others (“Results Only,” “Historical Chart Scan”) probably don’t. That said, maybe a better way to phrase that is that some of them match up to what clinicians and users think of us a “visit occurrence” and others are better conceptualized as artifacts of EHR workflows and the interface engine.
That said, the allowable terms in visit_type_concept_id are very much geared towards claims data. We don’t have any 32027s (“Visit derived from encounter on medical facility claim deferred” but we do have a whole bunch of “Telephone” encounters that occur during outpatient visits and look, to unfamiliar users, like outpatient visits that are happening while a patient is in, say, the ICU.
How are you all handling this? It seems like there are three possible approaches: generate custom 2billion+ concepts, throw your hands up and work within the allowable concept space (maybe putting metadata about the visit in visit_source_value), or militate for expansion of the Visit hierarchy to allow for better representation of EHR visit types. We are going with the second for now but I like the third best.
1 Like
I would like to add additional uncertainty about handling visit_occurrence (versus visit_details) instances that we were discussing in Colorado just yesterday. Unlike other EHR systems, Epic creates “encounters” within encounters for ancillary services. If a patient goes to interventional radiology for an angiogram or to the operating room that creates a new “encounter” in Epic, called CSNs in Epic-speak. Most of these are tied to the same billing entity. All of them have useful clinical data associated with them, especially the OR “encounters”. This is different from the series of records that are created when a patient moves from room to room, called “ADT Events” in Epic-speak.
Our conversation yesterday was “Do we keep these encounters-within-encounters” or do we flatten everything to the billing view of the world. I know of one OMOP institution that has flatten to the billing view. If we flatten, we lose the ability to ask “what labs were ordered in the OR” other than by looking at the ordering physician or timestamps. If we keep them, we inflate encounters (visit_occurrence records) and we also fragment the holistic view of the hospital stay. Our current thought (less than 24 hours old so subject to change) is to make billing encounters the visit_occurrence instance (“parent”) and these other “encounters” (CSNs) in visit_details as “children”. But this conflates these pseudo-encounters (CSNs) with room changes (ADT Events).
When in this situation, I try to go into Patrick Ryan projection mode – what are the analytic use cases that a real investigator would ask. In this case, I can convince myself that both the flatten representation and the visit_occurrence/visit_details view have cogent analytic use cases.
Melanie Philofsky is our representative on this group. She has the details. I’m the useless faculty member who only causes problems w/o offering solutions…
I would like to join . EST .
@mgkahn I think there is a very substantive issue here that might be better decided by empirical criteria than by established convention. The issue is that EHRs capture clinical events that are not billed for. The empirical question is: Are important attributes of patients’ clinical experience lost if we only capture billed services? If the answer is “yes”, then one goal of the EHR data holding community might be to develop mappings from EHR’s internal codes for unbilled services to standard OMOP vocabs. If it’s “no” then the effort to do that mapping might not be worth it. If it’s “no one knows” then we might want to get a plan together to find out. I suspect that the answer is “yes” and that there is significant addressable incompleteness in our data as a result. If so, this could be a major distinguishing advantage of EHR over claims data sources.
We are going to issue a new and improved Visit hierarchy. Should be good for EHRs.
Please don’t. We introduced the VISIT_DETAIL so you don’t have to have a flat world.
OMOP is not a model around billing. Go and play with the claims databases, if you need to do that. It is about the patient experience. So, we absolutely need the EHR-derived concepts, and if something is missing please please point it out.
Glad to hear it. I am happy to share the types we have in our data with whoever is building this out, if it’s of any use - just point me in the right direction.
Oh, could you please?
Colorado is re-visiting this as we speak. I’ll send along the visit types that are not part of an “Inpatient”, “ER”, or “Outpatient” Visit, but do result in an OMOP event.
Our next EHR WG meeting is Friday, November 16th at 10am EST/8am MST/
Agenda:
-
Discuss the different ways to map proprietary (not OMOP supported) reference terminology to OMOP supported concepts when the reference terminology maps directly to two code systems.
-
Maxim to share the issues he posted on the Issues & Assumptions Google doc re: Visits & Deaths
-
Byum to discuss Observation Period questions & concerns
Here’s the Zoom Meeting Lin:k
Very good points to bring up, @esholle!
Do the above encounters result in a clinical event record? i.e. measurement, drug exposure, etc. If not, I don’t think it belongs in the the CDM. But you probably also have telephone encounters that do result in clinical events such as an order for a Measurement or Drug Exposure. Maybe even a Condition Occurrence for the tele-health patient. And I think those do belong in the CDM. How do you decide which encounters/visits to keep?
In Colorado this week we discussed the @mgkahn example below:
during an inpatient hospitalization, the angiogram or operating room encounter should be a Visit Detail of the parent inpatient Visit.
In the Colorado EHR data, we have solo radiology, lab, etc. I view these events as “visits” because they result in a record in the CDM table. But I would NOT say a lab draw or chest x-ray is an outpatient “Visit”. An outpatient Visit is with a Provider So, we will need more visit types to cover the solo events like imaging procedures.
I would like to create/develop a standard way to map source encounters to the Visit Occurrence table. We need conventions for the EHR data holding community. Otherwise clinical events or lost or Visit records are seriously inflated.
We keep them all. The real reason is because I haven’t given it too much thought, although I hear your point. That said, let me play devil’s advocate for a bit. Not only can I envision potential use cases built around frequency of telephone encounters as one component of a proxy score for healthcare utilization, but also, if our CDM instance is ever going to serve the purposes of a data warehouse, we need to keep the notes that correspond to these visits - and as far as I know all the telephone encounters have an associated note, even if it’s 'tried to leave vm with pt - wrong #." I don’t want to get into the business of determining what notes are and aren’t useful later on down the line.
In yesterday’s EHR WG meeting we discovered the expansion of the Visit vocabulary. There are now 123 standard concepts of 421 total Visit concepts.
Colorado is working on this. I call it “improper OMOP”. Most of our requestors want custom datasets, so we’ve created extension tables to hold multiple races & procedure modifiers, added extra columns for traceability and source FKs, and created our own vocabulary with relationships and hierarchies to serve the needs of our local community. However, as we have developed our CDM word is starting to get out and more people want the data in proper CDM format.
We’re building a proper OMOP view on top of the improper CDM. This will also allow us to deliver proper CDM datasets to our community and to participate in more OHDSI activities without generating the longest Achilles list ever!
We, @mgkahn and I, are always open to discuss any of the above.
This is a fantastic idea, and we’ve been kicking around something similar, in part by offering adjunct tables to the CDM standard. For example, we include a “MEASUREMENT_LOOKUP” table that offers the equivalencies between how our EHR displays labs and how they are mapped to LOINC codes and thus to CONCEPT on the backend. As I have also mentioned in the past, per @mgkahn we have been putting JSON in the source_value columns and found it invaluable as well. I was hoping to discuss this with you at the symposium but ended up unable to make it - perhaps we can try to find a time at some point.