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.
Hi all,
Our presenter for tomorrow, Steve Lyman, will be traveling. Therefore, I am cancelling the meeting. We will reconvene on Friday, December 14. If anyone has any topics they would like to discuss on 12/14, please email so we can discuss.
The Google Doc with a very short list of issues and goals is here https://docs.google.com/document/d/12ELmThYhw6TJ_FoQpMWVDJ3rMlB5_6BkjPye1W20yUU/edit
Melanie
Friends. I started a new Forum post on this issue. Please discuss there. Havenāt looked your expansion, yet.
The EHR WG will meet tomorrow at 8am PST/11am EST (note the time change). @Christian_Reich will be presenting proposed changes to the Visit, Care Site and Provider domains.
Hereās the Zoom meeting link
EHR WG meeting is tomorrow, Friday, January 11th at 10am EST. Steve Lyman will lead the discussion on incomplete data and the impact of analytics. The Zoom meeting details remain the same as above.