Well, I can’t speak for @David_Dorr, but I am certainly mixed up. I hope I am not hijacking his thread with something unrelated, but is seemed related to me. His comment above struck a nerve with me.
In essence, some sources - especially EHRs - capture all kinds of ‘visits’ that occur in ambulatory or outpatient settings and have important data associated with them, but don’t represent the archetypal care team-patient interaction that might be thought of as an outpatient visit. E.g., a visit to the office of a provider; or even a telephone call with the team or a secure electronic message. In most research that involves tracking / measuring these visits, it is important to separate these kinds of visits from other interactions. For instance, we have documentation or chart abstraction visits.
This is true in Epic. There are many encounter types which DO represent visits (like Inpatient, Outpatient, Office Visit, etc). However, there are other, non-visit encounter types (Refill, Orders Only, Clinical Support, Lab Draw, Appointment, Documentation Only, etc.) which have important information associated with them, but are not “visits” in the sense that David described.
That leaves some questions:
Do I put these non-visit encounters in the Visit_Occurrence table
If so, what do I put in the visit_concept_id field?
If I put zero (0) in the visit_concept_id field, is that sufficient to distinguish those from real visits? (Which I believe was David’s question.)
If I don’t put these non-visit encounters in the Visit_Occurrence table, I lose the relationships between Visit_Occurrence and the Standard Data tables (measurement, observation, etc.) I create orphaned records which strike me as a data validation nightmare. For instance, if I have a Refill encounter for Prednisone, and I don’t record that encounter in Visit_Occurrence, how can I validate it against my EMR? How can I be sure it isn’t an artifact created by a previous query?
So I don’t really see how the changes to the visit_type_concept_id apply. As you said (somewhere) it is really the visit provenance rather that visit type. Visit_concept_id is really what the real-world thinks of as a visit type.
Can you advise me on how to address this issue? If it’s with Type concepts, I’m not seeing how that works.