Consolidated mapping decision points

[turbomam]

provenance styles

• data item instances, like GID, DOB, etc.
  • part of some data structure, like a column (which is part of a table or query result...)
    • property graphs?
  • denoted by some key
  • source value is bound with "has representation" property
• relationships
  • restated as an owl:Axiom
    • source, property, target
    • has database cross reference some provenance data item, following rules from above

denoters

• all explicit entities instantiated from OMOP tables will have a denoting key
  • these keys are used for the denotation part of the provenance above
• when a upstream source assigns stable, actively managed identifiers, those will also be modeled as CRIDs

dates

• processes have process boundaries
  • shortcutted as 'has birth' for people
• data items have time stamps
• always use datetime columns when available, even if the time component is 00:00:00

Instantiation

• all rows in a table could be instantiated with the same static class
• rows could be instantiated conditionally, based on some value
  • limited to affirmative mappings?
  • or with fall-through generic case, ie for OMOP concept codes of 0
• row could be instantiated with into coarse buckets (like diagnosis vs treatment for procedures)
  • still based on mappings from OMOP concept IDs to OBO classes in the TURBO ontology
  • still could include a fall-through case for un-mapped concept IDs

mentioning

Mentioning is used to link instances, even if they have been instantiated coarsely, to the URI for the source concept

single vs multiple vocabularies?

Concept IDs can be tied to a vocabulary via the OMOP concept table. Some mappings or mentioning situations may require examination of the vocabulary. Synthea measurements come from LOINC and SNOMED. Drug exposures come from CVX and RxNORM (although we may exclusively instantiate RxNORMs to start.)

counting RDF instances vs rows

• some of the modeling decisions will decrease the counts
  • no fall-through case for instantiating
  • required visit/encounter part-hood

---

person table

• includes RID, GID, DOB

visit_occurrence table

• rows conditionally instantiated based on their visit_concept_id
• "participation" = realization of role
• precedence
  • OMOP predetermines the ordering of visits
  • assessment of visit/encounter dates probably necessary for other sources

procedure_occurrence table

• coarse bucketing of procedure types
  • plus two 1:1 mappings: IM injection and physical exam
• "participation" = realization of role
• part-hood relative to encounters
• a provenance data item is about the procedure and mentions the source code's URI

measurement table

• visit/encounter parthood
• person/patient aboutness
• exclusively instantiating affirmatively mapped measurements
• units also require affirmative mapping and are instantiated with supporting provenance
• not modeling patient qualities or measurement processes
  • date-stamping (no process boundaries)
  • might be possible to ties the measurement datums into OMOP processes?!
• not currently instantiating categorical or ordinal measurements
• measurement itself mentions the source code's URI

condition_occurrence table

One might argue that these rows are records of disease processes that the person participated in. We are currently instantiating them statically as diagnoses.

• diagnoses themselves mention a code URI
  • SNOMED, not ICD, in the case of Synthea
• date-stamping (no process boundaries, despite availability of end date)
• visit/encounter parthood
• person/patient aboutness

drug_exposure table

In progress. Currently intending to exclusively model "prescription written" records with RxNorm codes, not "administered in outpatient setting"/CVX.