Implementing the Visit Occurrence and Details, I noticed that the column for discharge_to_concept_id uses the Place of Service vocabulary, as well as a few others. There are many different clinics that have a specialty but units are placed as observation. How are others implementing transfers between units, i.e. ED to ICU to Telemetry? I want to insure that I am following the best and consistent practices. Are others bending the rules on the Place of Service, or adding it to observation? It looks like âIntensive Care Unitâ is an Observation domain instead of a Place of Service. I have the desire to put the at a the Visit Occurrence Facility Level but go down to the unit in the details to document elevations in care, and bed to bed transfers.
We have not implemented this table, yet. It is on our road map. My current plan (Iâm open to other collaboratorâs pov) is to use the care_site_id to hold specific information about each unit/ward/floor/department. We are not using the generic concepts from the Observation domain because the Intensive Care Unit at a critical access hospital and the ICU at the metropolitan level 1 hospital do not share the same attributes besides the name. This is how I envision using the Visit Detail table for our EHR data:
Note: I have added in the missing fields to the above doc. Also, the fields are in a different order.
The ED visit is separate from an Inpatient visit. They will have separate rows in the Visit Occurrence table. The movement within an Inpatient hospital or within an ED (to Cath lab, Nuclear Medicine procedure, etc.) will be noted in the Visit Detail table. You can use the Care Site table to represent any level of granularity necessary for your use case. We are not going to the individual bed level, at this time, but if the use case arises a couple more times, we may implement Care Sites down to the bed level.
Clarification of conventions should be added to a Themis group @Asha_Mahesh
@MPhilofsky to me there is a problem with your implementation: visit_concept_id, visit_type_concept_id, admitting_from_concept_id, discharge_to_concept_id are from Visit vocabulary and then are duplicate information from visit_occurrence table. This is no relevant information since one can join the tables to get the same information.
=> they should be specific vocabulary for visit_detail such: visit_type_concept_id = âwardâ or âbedâ and so on to be able to distinguish what kind of detail this table offers.
Are others bending the rules on the Place of Service, or adding it to observation?
The way we did right now is extending the ICU place of services with observation codes. Then the care_site.place_of_service_concept_id is the place where the kind of ICU is defined.
About beds, dependently of the data, the visit_detail_id is a ward, or a bed or whatever level of physical place. Then it is linked to care_site table. Then the fact_relationship tells in which ward the bed is.
Finally, in the admitting_from_concept_id, and discharge_to_concept_id of the visit_detail table, we extended the dictionary in order to track bed transfers and ward transfers.
fields in the Visit Detail table because these are repetitive fields from the parent Visit_Occurrence table. We only need admission & discharge once at the Visit level. Letâs just get rid of them, unless @gowthamrao has a use case?"
You donât need to do the above (and it goes against the conventions) because the Visit Detail table allows for transfers. Per my GitHub postings linked above:
âEvery row in the visit_detail table has the care_site_id field and preceding_visit_detail_id field. We are able to string together the visit_detail_id and the care_site_ids to track transfers within the Visit. The conventions for the admitting_______ fields and the discharge_to________ fields state that Place of Service codes are to be used. The Place of Service code set does not offer the granularity required to track inpatient transfers.â
We store ICU visit_detail at bed level. In some cases, patient are going in an other bed because they are mooving to an other ward (ICU1->WARD2). Fine.
In other cases, they are changing bed but within the same ward (ICU1->ICU1).
All those 4 rows are link to care_site that describe the bed>ward hierarchy.
But the point is, how one can figure out how many ICU stays the patient have. If you count the number of ICU rows, he is 3. However, there were one ward transfer, and one bed transfers. And the patient had actualy 2 ICU stays. Storing that way is the only easy way I found to ease that kind of query.
So,
When a patient transferred to the inpatient ward from emergency department, we should add âvisit detailâ for a single parent visit rather than adding another 'visit_occurrence '.
Visit_detail is used to store the detail of Visit_occurrence, only if needed. i.e. you cant have Visit_detail without a corresponding Visit_occurrence parent record.
The use of Visit_detail is mostly determined by your source data. If your source data is ânestedâ, i.e. it has a record that covers the entire Visit, and then separate âmicro-visitsâ, âmini-visitsâ, âeventsâ etc - then it should be in Visit_detail
In the USA (and hence in OMOP), a visit to the ER is not considered part of a hospitalization. Probably for administrative reasons. In other countries, ER is just another department in a hospital.
So, for a hospital stay in different wards of departments, create one VISIT_OCCURRENCE and many VISIT_DETAIL records, one for each department the patient stayed in (had a bed). For an ER visit, just create one VISIT_OCCURRENCE record.
Because visit_occurrence table has preceding visit, I used to make two visit_occurrence for ER and hospitalization
(As you said, ER is considered as a part of hospitalization in Korea).
Our team has created the current visit_occurrence and visit_detail table.
When we read the issues,
if we would like to hear your comment that we understood well about the difference between the two tables
and the meaning of preceding_visit_detail_id and visit_detail_parent_id.
Not sure if youâve found an answer elsewhere or @Christian_Reich has an idea of where this is better answered in another thread, but hereâs my stab at it:
I believe visit_detail_id âAâ is not needed and will cause confusion. With OMOP v5.3.1 at least, the visit_occurrence to visit_detail relationship is 1:n where n can be 0. I think that visit_occurrence_id 1 is a perfect example of where further detail is not needed, and so should not exist (the n = 0 case).
visit_occurrence_id 2 should really be split into 2 and 3 given what @Christian_Reich was saying about OMOPâs structure:
By splitting 2 into instead: 2 (Emergency room) and 3 (inpatient visit), you would then again make visit_detail_id redundant with the visit_occurrence table and so the n can be 0 rule applies here too.
After splitting 2 into 2 and 3, the prior 3 (outpatient visit) would become 4. Wouldnât need visit_detail_id as indicated for 1, 2, and 3 above.
I think that the following case would warrant visit details being populated, and is the case that Iâm dealing with in ETLing our EHR:
In plain English, the scenario is as follows: A patient admits to the emergency room (1). While there, is assessed and moved to the inpatient unit (2) for emergency surgery. While in the inpatient unit, they are first brought to bed A (A) to wait for 2 hours. They are then first taken to a pre-op waiting area A (C) to begin their surgery encounter (B). After waiting 3 hours in Waiting Area A, they have an 8 hour operation in operating room A (D). Following the operation, they are taken to Recovery Room A (E) for observation overnight. They then leave the Recovery Room A the next morning and transferred back to Inpatient Unit, Bed A (F). This completes their inpatient visit, as they are discharged the day afterward at 12pm (completing the inpatient encounter (2). They recover at home for a few weeks before coming back in for an outpatient post-op visit (3).
