Sidebar
Meeting Notes
M: we map to staging table, and then to OMOP
H: why do you need a mapping table?
M: our use cases involve using FHIR as a data feed for research … data coming from different sources … CSV raw, database dump … we have a staging table that we map to, then map to OMOP … put all external data sources to staging table.
H: what's the staging table format?
M: more OMOP-friendly than FHIR-friendly … i have mapping to staging table … staging table is closer to OMOP … idea: could use FHIRbase <http://fhirbase.github.io/> (psql database) with concpets and functions for FHIR resources … i'm working with adata person; i asked if we could use FHIR-base to map it, and use ETL from there … we could ETL FHIRbase to a staging table or directly to OMOP … doesn't solve gaps, but solves some pipeline probs. … there are still some resources i can't map to OMOP
H: which resources?
M: workflow-related stuff like Care plan, Appointment … also elements in Device that we can't map into OMOP
E: OMOP defines the area that folks need for research … we don't need OMOP to be an EMR
M: not using care plan much … map as much as you can … FHIR wrapper on OMOP
E: Let' see if we're on the same page for Use Cases [reads UC, below] after doing research, we want to profit from discoveries. Evidence-based medical practices that emerge from research, be it widely-published or just clinic-wide, can leverage the same queries and heuristics to aid in enforcement of clinical practice. … does that sound like we're on the same page? [agreement] … staging table has extra workflow stuff?
M: FHIR populated by EHR, with arbitrary coding system … we use the stating table to standardize codes, e.g. NDC … staging table useful for review.
E: could others implement the mapping without your staging table?
M: we map *Georgia Tech* FHIR to OMOP. … when i search in the concept table, and i can't find the right entry, what do i do? … i have to have a concept ID. … i use the source column to preserve the FHIR data
E: so it's good to have something in the role of staging table
M: the staging table is customizable. … if there is data we need to preserve but we can't map it, we can create a table.
E: but we don't need data we can't map
M: but we may have a VA-specific coding
E: there are: … 1 (information model) FHIR resources that don't have an analog in OMOP. … 2 (terminology model) resources that map but don't use required terminologies. … are you buying commodity terminology mappings?
M: at Georgia Tech, we force folks to use the OMOP codings
E: are OMOP terminology requirements almost universally tighter than in FHIR?
M: LOINC, SNOMED, CPT, ICD … i don't know how many folks will follow that.
E: for a high bar, we could say “though shalt use this terminology for X” … for a low bar, we could say “both FHIR and OMOP accept these terminologies”
H: OMOP and FHIR allow you to define code sets equivalence. … could be useful but tricky … they line up mostly … there's a vocabulary table in OMOP. … likewise in FHIR, but in coding objects … we could say that there's a coding X FHIR and import that into OMOP … the UC is: many FHIR resources have a wide variety of code sets
E: i guess the proposal is to exchange FHIR and OMOP terminology definition structures. … let's do the easy stuff first [structural transformation]. … enable terminological transformation if use cases warrant. … depends on level of non-coordination we want to enable.
H: I can speak with Daniella about that.
– -ericP
office: +1.617.599.3509 mobile: +33.6.80.80.35.59
(eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.
There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.
