FHIR's popularity for clinical care data leads to a desire to use it for clinical research. FHIR Custom Resources are being hand-crafted to capture elements of interest for a particular study. Likewise, OMOP's basis in SQL encourages the development of custom tables and views to aggregate other OMOP tables. Tying these to metadata standards like DDI or SDMX allows these use cases to leverage the governance, tooling and mindshare allocated to these standards.
Misc notes on tying FHIR Custom Resources and OMOP-like SQL tables to DDI metadata.
The popularity and mindshare of FHIR leads to the use of FHIR Custom Resources for study-specific data. FHIR element naming constraints prevent two resources from sharing a unique identifier for a common variables. In order to produce computably equivalent elements, we need connect element definitions to common names for study variables.
An analogous practice in OMOP stores doesn't require such formalization because SQL already provides the syntax and semantics for defining additional tables.
In order to minimize dual entry and improve integrity, it makes sense to compose schemas that embrace clinical care, clinical accountability and clinical research. For example the example FHIR Colorectal resource (example data) includes study variables like tumourType and tumourLocation as well as elements unlikely to be used in study, e.g. performer and requester.
These aggregations typically include a lot of data which could be captured in core FHIR Resources. For example the example FHIR Colorectal resource (example data) is mostly observations (histologicalGrade) on a single specimen (tumourSite from Specimen.bodySite).
An SQL schema designed to capture the same information would contain eight nine tables; one to capture the colorectal report and the rest to capture the one-to-many relations implied by each FHIR element with a max cardinality > 1. Some of these one-to-many tables associate a single value with the report record (natureOfPerforation, tumourLocation, distanceNearerProxOrDistal, noLymphNodesPerCassette, natureAndSiteOfBlocks, involvedMargins) and others capture nested structures (lymphNodesDetails, relCoexistPathabnorm).
FHIR uses its schema to describe itself. This makes it easy for a person who understand how to read e.g. a logical table for Observation to then read the definition for the schema itself. Likewise, the schema for DDI's Disco can be expressed as a FHIR resource.
While FHIR's schema is an abstract language which is reallized in format-specific schema languages like XML Schema and ShEx, OMOP's use of SQL (DDL) demands no additional OMOP-specific schema. SQL does define introspection tables, but they are not widely implemented or exploited.