OHDSI Home | Forums | Wiki | Github

Converting database tables to OHDSI: Whats the logical order to follow?

Developers
#1

Hi everyone,

My friend Maurya and I are working on converting the OpenMRS [openmrs.org] database into CDM format. We’re doing this in an iterative way that sees us converting the minimum number of tables that we need to support each OHDSI application.

Right now, we have OHDSI person and observation_period tables populated. Using these, we implemented the OHDSI Achilles application.

We’d like some guidance on which tables we must convert to move toward supporting other applications. Looking at the following slide, it seems that we need condition_ocurance, death, visit and provider next. (a) which applications can we use after implementing these conversions, and (b) are all four tables mandatory? Also, what tables should we look at next?

1 Like
#2

Hi @suranga:

Ultimately, all applications make use of data from across the CDM, but as
long as the tables exists (even if they have no data), all applications
should work without issue. So, no tables are ‘mandatory’ to populate, but
populating the tables will provide you more capabilities in the analytical
toolset.

In terms of using OHDSI tools to derive value for the OpenMRS community,
I’d imagine the next tool you may want to try to make operational is CIRCE
and CALYPSO. This would allow you to construct cohorts of patients that
satisfy specific inclusion criteria, and then use these cohorts for future
analysis. CALYPSO could let you assess the impact of each inclusion
criteria on the total number of persons eligible to be in your cohort.
CIRCE provides a user interface for defining the inclusion criteria, which
is then persists as JSON and compiles into SQL for your platform (here,
postgresQL). CIRCE allows for inclusion criteria to be constructed based
on any table of the CDM, but if you are thinking about building out a
staged approach to your ETL implementation, you could tackle specific
tables and then only use those features within CIRCE, and you shouldn’t
have any issues. In your case, as the slide suggests, if you were to
complete VISIT_OCCURRENCE and CONDITION_OCCURRENCE next, then you could
conduct analyses like: ‘how many patients came to clinic and diagnosed
with respiratory infection who had a prior diagnosis of HIV?’ If you take
the next step and populate the DRUG_EXPOSURE, you’ll be able to break that
down further by prior treatments.

Once you have CIRCE/CALYPSO working, you could then apply front-end tools
like HERACLES to characterize your cohorts (to answer questions like:
‘what are the demographics, comorbidities, concomitant medications of the
patients in my cohort?’), or back-end statistical analysis methods like
CohortMethod and SelfControlledCaseSeries for population-level estimation
if you have specific safety surveillance or comparative effectiveness
questions, or you could use PatientLevelPrediction to create individualized
risk estimates for the cohort.

1 Like
#3

My experience with translation was the following.
NO OR FEW TERMINOLOGY STEPS

  • Another simple table (like person) is a death table
  • next - do your VISIT table (if you have nice data)
  • you can do those above steps without dealing with terminology mapping

STEPS THAT REQUIRE TERMINOLOGY WORK

  • consider at least implementing the XXX_occurrence tables. (e.g., condition_occurrence). You can worry about the XXX_eras tables at a later stage

  • for some minimal work - you need Diagnoses, Procedures and Lab results (table:measurements)

  • take top 10 laboratory codes and map them to LOINC (to have some demo lab content) (do full mapping later)

  • think about your source terminologies and CDM core terminologies (SNOMED, RxNorm, for procedures - I wish we would use SNOMED as well but most sites seem to be using proprietary CPT :frowning: ). In the long run, you will need mapping to those core terminologies.

  • if you want to be a star in OHDSI - populate your NOTE table !

  • if you want to cheat, just populate always only the XXX_source_value column and put value 0 in the XXX_concept_id (for CONDITION, PROCEDURE, MEASUREMENT tables)

2 Likes
#4

Thank you @Patrick_Ryan and @Vojtech_Huser, this was really helpful!

#5

@Suranga @pbiondich I was doing some research on OpenMRS.

Has there been a successful mapping from OpenMRS to OMOP?

t