Data Model¶
This page captures the main conceptual distinctions in the current library.
The important distinction¶
Three different things are easy to blur together:
- Semantic object What kind of OMOP thing are we talking about? Examples:
OmopConceptOmopGroup-
OmopEnum -
Profile What generic OMOP row shape are we using? Examples:
observation_simpleobservation_codedmeasurement_numeric
A profile is structural. By itself it is not yet a full semantic mapping unit.
- Template A template is the semantic object plus the profile becoming the meaningful mapping unit.
In practice this means: - a role - an entity concept scope - an optional value concept scope - a CDM profile
Profile groups¶
Profile groups represent admissible families of row shapes.
Examples from the shipped instance file:
ObservationProfilesMeasurementProfilesProcedureProfilesConditionProfilesDrugExposureProfiles
These are broader than individual templates:
- a profile says what a row looks like
- a profile group says which row shapes are valid in a family
- a template says which semantic task uses one of those shapes
Registry groups versus profile groups¶
There are multiple meanings of "group" in the codebase:
-
OmopGroupSemantic grouping or anchor grouping of OMOP concepts. -
RegistryGroupOrganizational grouping of templates in a registry fragment. -
Profile group A
RegistryGroup-shaped symbolic object used to describe valid families of profiles.
This is one of the areas that benefits from cleanup, but the important thing for current users is simply to keep the meanings distinct.
Portable versus DB-expanded semantics¶
omop-semantics itself is intended to remain portable.
That means the runtime artifacts published here should be thought of as:
- anchor ids
- named semantic scopes
- row-shape constraints
They are not the same thing as a DB-expanded descendant set from a live OMOP vocabulary graph.
DB-aware systems such as groundworkers or omop-constructs can derive those
expanded scopes separately.