OHDSI Home | Forums | Wiki | Github

VISIT_OCCURRENCE table decision time

CDM Builders
#1

We have had many good discussions about the need to represent micro-visits/encounters. Please see the links to the Use Cases and Discussions @Gowtham_Rao posted here. The gist of it is that there can be many different micro-visits/encounters per a visit_occurrence_id. And these micro-visits/encounters need to be linked to the clinical tables and individually represented for Outcomes research and CER. If you have a horse in the race, please provide feedback.

Example for EHR data: an entire inpatient stay in one hospital may be one ‘higher level’ visit which is represented in the VISIT_OCCURRENCE table. This higher level visit contains several micro-visits/encounters within the hospital. Example: patient is admitted to the hospital in the ICU transfers to the medical floor then to the rehabilitation floor, etc.
Example for the claims record: US claims data generally has header/summary data and line/detail level data. The higher level visit is the header/summary data and the line/details are the micro-visits/encounters.

We have narrowed down the options to represent this data with the following:

  1. Should we leave the VISIT_OCCURRENCE table as is and create a new micro-visit/encounter (we will also vote on a new name) table? Both the VISIT_OCCURRENCE table and the PROPOSED table will have FKs to all clinical tables.

  2. Similar to #1 Gowtham’s proposal. The VISIT_OCCURRENCE table becomes a VISIT_OCCURRENCE_ERA table and a new table for micro-visits/encounters is created? Both the VISIT_OCCURRENCE table and the PROPOSED table will have FKs to all clinical tables.

  3. Or should we put everything into one table?

We need to wordsmith the new table name. Some ideas that have been tossed around: ENCOUNTER_OCCURRENCE, EVENT_OCCURRENCE, MICROVISIT_OCCURRENCE. We are open to any and all ideas.

In order to represent this data we need a field for the micro-visit/encounter. The field care_site_name in the CARE_SITE table is the appropriate place. From the CARE_SITE table: “The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.)”. Since every hospital is different with different wards, units, beds, departments, this field will not have a standard OMOP vocabulary or concept_id.
Considerations for the CARE_SITE table:

  1. Level of granularity of the care_site_name. This would be the care_site_type_id and would detail the level of granularity for the care_site_name. Example concepts for care_site_type_id: bed, ward, department, hospital, office, clinic, HMO, etc.

  2. Care_site_name are hierarchical in nature. A bed is part of a ward which is part of a department which is part of a hospital which is part of a health care system and so forth. How do we represent the hierarchies? CONCEPT_RELATIONSHIP table? Recursive key to the CARE_SITE table? Other ideas?

I think that sums up the decisions that need to be made. @Christian_Reich, @Gowtham_Rao, @Daniella_Meeker, @bailey, @hripcsa Anything else?

visit_detail / visit_occurrence domains
#2

@MPhilofsky:

I think it is good to bring it to the “big” meeting. No use in rolling the problem any longer. Thanks for the good work.

#3

Just a comment on ERA. The other era tables are truly derived from other primary evidence. This table is not really derived from hospital locations but comes as it own primary data. I.e., I don’t pull out a bunch of locations or services from our registration system and then try to figure out the hospitalization. I get the hospitalization directly. So I would hold off on calling it era, even though I do understand the analogy.

VISIT_COMPONENT is what we would call the micro table in our old CDR.

George

#4

I think we said fact relationship. Care site id, is a fact_id not a concept_id. So I think the relationship between facts goes to fact relationship table.

However, the type_id proposed, care_site_type_id, is a concept_id that is maintainable by the community, and these may have relationship to each other, this relationship may be in concept_relationship table

#5

I would prefer not to rename the current table.
From the presented options - I like the EVENT variant (proposal 3) (second best is proposal 4)

#6

I would prefer not to rename the current table.

From the presented options - I like the EVENT variant (proposal 3) (second best is proposal 4)

If we name it “event,” can we put in all kinds of events, or only those under visit? Might be confusing if only the latter.

George

#7

I do appreciate the desire not to rename the VISIT_OCCURENCE table but I am really struggling with this term. A visit in my head is quite granular and without reading the definition of this entity that is currently used in the CDM, my automatic assumption of what data goes in here aligns very well with what are being called micro visits. To me, they are visits.

The current definition for VISIT_OCCURENCE is really an EPISODE of treatment (or care). A patient is admitted, treated and discharged at a primary care site. This is one single episode of care which may involve any number of encounters or visits to different providers in different departments or treatment areas. Today, I am using VISIT_OCCURENCE to track episodes of care (akin to a billing episode) but I do not externalize the name VISIT_OCCURENCE as the language does not really reflect what I am storing here. I represent this data externally as an EPISODE (of treatment).

Appreciating the fact that it is does have technical implications from an implementation perspective, I propose that VISIT_OCCURENCE is renamed to EPISODE_OF_CARE and the new micro entity is called VISIT_OCCURENCE ( or ENCOUNTER). This is not significantly different to the approach taken in FHIR.

Apologies for the late arrival with this but only just joined into this group.

Regards,
Colin

#8

I think episode of care would be misleading. Episodes are often multiple visits for the same acute clinical condition (e.g., hospitalization and follow up visits).

Visits are exactly what they purport to be – an encounter with a provider on a specific day, time and place. The problem is that there are components of a visit that need to be retained because they are related within the visit. The current structure loses these “within visit” relationships.

Visit_component communicates this the most clearly, in my opinion.

#9

For reasons stated by @hripcsa and @Mark_Danese, I like

  • Keeping the visit_occurrence table’s name and definition
  • Adding a micro table named visit_component

The intent matches what we did in our initial ETL efforts.
Thanks to all involved for the effort to sort this out.

#10

Friends:

As much as the nomenclature gets folks up and going: Right now the consensus of the group (we voted) is:

  • VISIT_OCCURRENCE: Macrovisits. Patient goes to hospital, stuff happens, he gets discharged, usually home.
  • VISIT_DETAIL: Microvisits. Individual activities wihtin the Visit. Usually, time spent in the same bed in a hospital ward or department.

Can we live with that?

#11

Here is the updated proposal. Please read and provide input

http://www.ohdsi.org/web/wiki/doku.php?id=documentation:next_cdm:visits_microvisits

#12

Eventually we will be getting rid of *_DATE in tables, I think, but for now we keep them in current tables to maintain the current software. So when a new table like VISIT_DETAIL is added, should we also include *_DATE fields or just the *_DATETIME fields? I.e., should we make all our tables consistent (include DATE and DATETIME) or let the new tables stick to the future? Will any installations find themselves using mostly *_DATE fields but writing extra code to accommodate VISIT_DETAIL?

Honestly, I cannot decide myself, but I suspect I missed the conversation about this.

George

#13

Apologies if I missed this discussion also but here are my thoughts.

Theoretically, DATETIME is an extension of DATE. In reality, every database vendor treat them with somewhat of a different respect plus have other related date and time types. I think we need to try to be practical e.g. only introduce time portion where needed.

First option, use what needs to be used in each case e.g. where we need DATE, keep it this way. Where we need a time portion - go for DATETIME / TIMESTAMP. If a database dialects do not support DATE directly - go for DATETIME / TIMESTAMP.

Alternatively - not a bad choice and probably would be better for compatibility yet one one more field to worry about - keep DATE and TIME portion separately. Keep DATE columns and introduce a new field with TIME element, but again - where it is needed. And use TIMESTAMP where database dialect does not have a DATE or TIME type, but as an exception only.

I will see if we can create a matrix for different database dialects and their support for DATE, DATETIME / TIMESTAMP and TIME.

It is messy, no doubt about it.

#14

We went through the DATETIME versus TIME discussion in the past and moved forward with DATETIME, so we should not redo that one. But the comments about implementation are good, and would point to including both DATE and DATETIME for now. (DATE is implemented more consistently among vendors.)

George

#15

Agreed - will go back and read past discussions.

Yes. There is always a tradeoff, but being in v5 and with a large amount of known and unknown code written - I believe that compatibility should be our priority. I would also consider (unless it is already done) to start introducing an explicit “deprecated” field concept to allow for re-factoring and give time for migration.

#16

Thank you @Gowtham_Rao for continuing to move this forward!

I have a couple minor comments:

I don’t think the admitting_source_concept_id and discharge_to_concept_id fields are necessary in this table since it is a child of the visit_occurrence table and present in the visit_occurrence table. I think the preceding_visit_detail_id field in the visit_detail table will link the visit_details correctly.

Naming conventions: Should we change visit_source_value to visit_detail_source_value? And visit_source_concept_id to visit_detail_source_concept_id? This would avoid confusion with those fields in the visit_occurrence table.

t