OHDSI Home | Forums | Wiki | Github

Save Multiple reasons for a visit in the visit_occurence_table

Developers
#1

Hi, I am having a FHIR encounter resource which has multiple FHIR questionnaire responses representing the type of services done during the particular encounter.
Now I am having the trouble of putting those all the services under visit_source_value in visit_occurrence table since it takes only varchar of 25 size and each entry in the visit_occurence_table takes only one visit_concept_id and not multiple ids.
I was thinking of solving by following two approaches:

  1. Adding the latest response reason to the visit_occurrence table and creating a custom schema to add the rest of the details.
  2. Creating a separate column in the visit_occurrence_table which will hold the other reasons and the visit_source_value will have the latest reason from the response.

I am quite confused between the above two approaches because I don’t want to deviate from the OMOP approach. I request you to give me suggestion on the two approaches. Also free feel to add any other approach other than the above two.

Thanks.

#2

Hi @AdityaKB14:

Welcome to the family.

Wait. It’s not clear what you are trying to do:

  1. A visit is just that: Some encounter between the patient and the healthcare system. For each one, you need exactly one record in the VISIT_OCCURRENCE table. The visit_concept_id says what kind of visit it was (outpatient, inpatient, etc.). The visit_source_value is the same thing, except in your source notation. It should be 50 characters long, but if you need more feel free to make it as long as you want. Source values are for convenience, they do not serve the OMOP use cases. If you have more than one source value for one actual visit, feel free to concatenate them together or just throw them away altogether.

  2. Your questionnaire seems to be telling you what happened during the visit, like diagnosed conditions, procedures, drugs, etc. That information should not go into VISIT_OCCURRENCE, but into the corresponding clinical tables (CONDITION_OCCURRENC, DRUG_EXPOSURE etc.)

Makes sense?

#3

Hi @Christian_Reich .

Yes this makes sense. Basically I wanted to know that how can I put multiple source values in the visit_source_value. As you said I can increase the number of characters and concatenate the values.

Thanks for the help.

#4

Hi @Christian_Reich .
I have one question with the approach of concatenating the values. In these case we won’t be able to keep a single visit_concept_id for the entry with multiple visit_source_value. In this case what should we do?

#5

Not sure I follow. If there is one visit there should be one visit_concept_id. You can’t have both, say, an Inpatient Psychiatric Facility and a Assisted Living Facility. You can have more than one ambulatory visits in one day, but they would all have their own concept ID.

#6

Then I feel concatenating multiple visit_source_value in a single entry is not the best approach to follow because there will be only one visit_concept_id.

#7

Do you have an example?

#8

Yes sure.
In my case I have some set of services like ANC (Antenatal care) Registration, ANC Visit, Malaria RDT, InPatient Visit, OutPatient Visit, etc… When a patient comes for the first time first the patient has to go through patient registration and then ANC Registration followed by ANC Visit and some other services can also take place during the same visit. So on same visit for the patient there can be multiple services done for the patient which will be stored in the same FHIR Encounter. In this case a single encounter is mapped to multiple services.
What I am trying to do is I want to convert this FHIR resources to OMOP and store this results in visit_detail. The current schema for visit_detail does not allow me to keep multiple visit_concept_id in the same entry and even though if I go with the approach of concatenating the multiple values in the visit_source_value it will be difficult for me to know that the visit_concept_id belongs to which one of the visit_source_value.
What do you suggest should be done in such case?

#9

I see. Here is the deal: The service is not part of the visit. It usually is a procedure. The visit is just the configuration of how a patient interacts with the healthcare system, but not the content. Which means, you should write:

Whatever happened in those visits goes into the respective tables, such as Prenatal examination and care of mother, the routine screening visits, Ultrasonic doppler for fetal heart sounds, Prenatal assessment of breastfeeding and all the other good stuff. Do you have that in the data?

#10

Apologies for the late response. Yes I do have the data. But my main question was that is there any way such that we can store multiple reasons in a single visit_source_value? We can concatenate the values and store as you had suggested previously but then we cannot keep multiple visit_concept_id in a single entry.
So my suggestion would be that the latest reason can be kept in the visit_occurrence table without changing the current schema of the table and create a custom table for my use case which can hold all the other reasons for that encounter.

#11

@AdityaKB14:

I still think you are mixing things up.

A “reason” for a visit (such as a diagnosis, procedure, device or any other medical need) is NOT what goes into the VISIT_OCCURRENCE table. There is no need to concatenate anything. Those reasons go into the other tables and are linked through visit_occurrence_id. The visit_concept_id, and therefore the visit_source_value, contains the “configuration of circumstances under which healthcare encounters occur”.

So, it sounds to be me that you put those “ANC (Antenatal care) Registration”, “ANC Visit”, “Malaria RDT”, “InPatient Visit”, “OutPatient Visit” etc. into the visit_source_value. If there are not unique, i.e. the same visit is referred to in more than one way, consider concatenation or leaving those out entirely. The OMOP CDM really does not care, the _value fields are only for convenience and QA, analytical use cases are not supported by their content.

#12

Okay. Thank you so much for the assistance @Christian_Reich .

t