Enhancement: Filter cohort data based upon visit_detail_id and visit_detail_concept_id

[TomWhite-MedStar]

Expected behavior

Within EHR data, visit_detail is often used to represent a patient's physical location. Multiple quality measures need to focus upon (or exclude) data from particular physical locations. For example:

• Hospital Harm - Opioid Related Adverse Events: Must exclude opioids given during operations (and possibly in PACU)
• Quality measures focusing solely on time the the patient is in the Emergency Department (even if ultimately admitted)
• Quality measures focusing on care delivered in the ICU (or other measures excluding time in ICU)

Atlas should have the ability to:

1. Restrict data to specific visit_detail_concept_ids (either only including drug/measurement/procedure/etc. data from a set of visit_detal_concept_id values - or specifically excluding data from a set of visit_detail_concept_id)
2. Restrict data to specific visit_detail_id (similar to how one can check the box to "restrict to same visit occurrence"

Actual behavior

This is not adequately supported with the current visit_detail options:

• For a given drug/condition/procedure/measurement, it is not possible to specify an an allowed list of visit_concept_ids
• Although it is possible to use nested criteria and include visit_detail options there, there is no ability to restrict the initial drug/condition/procedure/measurement to the same visit_detail_id. The Date filters may not be adequate, since patients can be in more than one location on a given day.
• The option to select exactly 0 occurrences of a given visit_detail (as a nested criteria) doesn't meet this need. We want to analyze situations where the patient may have needed to get an operation, or go to ICU, but want to focus just on clinical events that occurred (or did not occur) in those settings.
• Reversing the approach and using visit_detail as the top-level criteria and using drug/condition/procedure/measurement as nested criteria also do not work, since there is no ability to restrict to the same visit_detail_id.

[chrisknoll]

At least on the topic of 'same visit checkbox', the visit details should all share the visit_id (of the parent) so it should be the case that when you select a visit->visit_detail or visit_detail->visit_detail, the visits/details belonging to the same visit should be exposed throughout such that if you say 'same visit' it checks that the 'index' visit is the same as the associated visit/visit_detail. This should also work with condition -> drug or procedure-> measurement in that if there is a visit associated to it, then the query should expose the visit_id across all of those, and the 'same visit' checkbox checks that they are equal.

I don't think we use (and I don't think we should) use visit_detail_id, insofar as it is just a row identifier and not used in any relationships.

[chrisknoll]

About the ability to restrict the domain criteria (measurement, drug, condition for example) there is an option to specify the Visit criteria, which should cause a join back to the visit (based on visit_id) and look for visit_concept_id:

However, this goes back to the parent visit, not a particular visit_detail, but I don't think the CDM links procedures to visit_details.

[TomWhite-MedStar]

@chrisknoll , per my read of the CDM 5.3.1 data model, visit_detail_id is used in relationships. All of the main clinical event tables (condition, procedure, measurement, drug, observation, device) do include an optional visit_detail_id field.

We use visit_occurrence to represent a full hospital stay, but the patient may move across settings (e.g. from ED, specific wards/units within the hospital, or specific operating rooms or intensive care units). So, our plan was to use visit_detail to track patient movements within the hospital, and then include/exclude clinical events based upon that patient location. By enabling a "restrict to same visit_detail", we'd be able to support much of the desired logic.

[chrisknoll]

I see. Certainly complicates matters: My understanding was the same as you say about 'how a patient moves around' within a visit, for example, visit only supports one provider, but visit detail allows you to associate different providers within the same visit_detail. I thought that Visit_Detail was about giving more context to the visit, and not breaking down where specific conditions were identified. But, that's what they are trying to support in the model.

So, this complicates things a bit, that we need to say 'same visit' and also 'same visit detail'? Currently we have the Query elements return the Visit_ID that this record is associated with, is it a matter of returning the visit_detail_id too? and then adding the option to not only check same visit, but an additional option of 'same visit detail' (ie: another checkbox)?

[TomWhite-MedStar]

@chrisknoll , yes, adding another checkbox for "same visit detail" would solve some of this.

For example, for looking at data only from the Emergency Department, I could use either of these tactics:

Say I'm looking for use of rocuronium for rapid sequence intubation in the ER, this might work if we had "same visit detail"

This might also work, and would capture the administration datetime of rocuronium (instead of ED visit detail start time):

Adding that additional checkbox might also support some negation examples. For example, for the Hospital Harm Opioid Related Adverse Event measure, perhaps I could do the following. The measure is looking for any cases where Narcan had to be used outside of the OR.

So, adding the additional checkbox would be great start.