OHDSI Home | Forums | Wiki | Github

Transforming forms in OMOP

Implementers
#1

Hello everybody,

The medical record in my institution is mostly based on forms that contained both structured (blood pressure for example) and unstructured data (diagnostic and therapeutic project, for example).
We want to make all these information available in OMOP but we face some difficulties.

We first think of SURVEY_CONDUCT.
This option allow us to keep the link between all the items of a form, which is very good
However it also means:

  1. storing every data in the OBSERVATION table, while some fields are clearly supposed to end in other table (MEASURMENT, CONDITION…)
  2. some fields may contain string that are longer than the 60 caracters allowed in the OBSERVATION.value_as_string field
    Forgetting about the first issue how should we resolve the second one ?
    should the OBSERVATION.value_as_string type modified to varchar(MAX) ?
    Or should we use the NOTE table to store these information, building link between SURVEY_CONDUCT and NOTE similarly to the one between SURVEY_CONDUCT and OBSERVATION (i.e. _event_id and _event_field_concept_id) ?
    Or any other solution ?

The second option is to store each field in the corresponding table (NOTE for the free text clinical fields, OBSERVATION, MEASURMENT…) The main issue being the loss the link between all the items of a form, which is not very satisfying…

Did anybody face the same issue ? or have any idea for a good solution ?

Sincerely

Nicolas

#2

Increasing the size of Observation.value_as_string will not cause problems with OHDSI tools or conformance with OHDSI standards.

#3

This is probably not a good idea, @Rosnyni. Sorry to give you the bad news. This table is designed really for surveys, where people have precise knowledge and anticipation of the meaning of the answers. For a generic medical record system you need to populate the standard medical entity tables, like CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, etc. Because that is how all the standardized queries and tools go about analyzing them. Nobody is going to the SURVEY_CONDUCT table to find, say, all patients with Type 2 Diabetes and kidney complications. You are looking at a mapping job of your structured AND unstructured data to the standard tables and vocabulary concepts. You can ask the community to help, and if you have money you can hire specialists for doing that. Also, @MPhilofsky has a EHR workgroup, where the kinds of you come together and help each other with solutions.

#4

Welcome to OHDSI, @Rosnyni!

I agree with Christian, don’t store all your data in the Survey Conduct table. The ETL will be very easy, but the analysis and re-use of data will be very difficult and not worth the effort. And completely unusable for any network research study or with OHDSI tools.

The hardwork of getting the medical records into the OMOP CDM pays off immensely when your institution realizes the power of semantic harmonization, standardized structure, use of the many OHDSI tools, and ability to participate in network research :slight_smile:

The EHR WG is a good place to start. All OHDSI WGs and details are listed here. This week (Friday at 10am EDT) we will continue our discussion of covid-19 coding in the EHR. here is a very long and active forum post about the EHR WG.

And if you haven’t seen it already, the very first place to start your OHDSI journey is by watching the CDM and Vocabulary tutorials from last year’s Symposium. These are the basis for all things OMOP. The Book of OHDSI is a handy reference for all things OHDSI.

1 Like
#5

Thank you for the lot of information you provide. I must take some time to digest everything. But I’ll come back soon with a lot of question :slight_smile:
Sincerely

t