LoginSign Up
← Back to all sparks
O

omopsketch

ANALYTICS
Velocity0.0

Characterise Tables of an OMOP Common Data Model Instance

github.com/ohdsi/omopsketch ↗

Health-data characterisation tooling maturing through steady issue-by-issue tightening.

omop-cdmhealth-datadatabaser-packagedata-quality
◆Current state
OmopSketch summarises and characterises OMOP Common Data Model databases — clinical records, observation periods, concept counts and missing data. Recent releases have tightened the semantics of those summaries: only records within observation are counted, study ranges are trimmed consistently, and a collect() was removed so more of the work stays in the database. Development is dominated by a single contributor working through numbered issues.
◆Where it's heading
The package is moving from producing summaries toward producing defensible ones. Interval-based arguments replaced the narrower year argument, table output gained a datatable option, and the vignette now demonstrates a full characterisation feeding a Shiny app. The pattern is refinement of existing summarise* functions rather than new analytic surface.
◆Prediction
Expect continued tightening of the summarise* family and its table output options; with only three releases visible, the cadence itself is hard to read.

◆Recent moves

  1. 1y ago

    Keeps clinical-record summaries in the database

    Drops a dplyr::collect() from summariseClinicalRecords(), fixes a time-interval bug in the missing-data summary and improves concept-ID count tables. Removing a collect() keeps computation on the database, which matters at OMOP scale.

    View source ↗
  2. 1y ago

    Interval arguments replace year; counts restricted to observation

    Adds an interval argument across the missing-data and concept-count summaries while deprecating year, adds a datatable output type, handles int64, and restricts concept counts to records in observation. The release that set the current semantics for what gets counted.

    View source ↗
  3. 1y ago

    Bug fixes and dateRange semantics clarified

    Minor bug fixes plus a clarification that dateRange constrains where the table's start_date must fall. Documentation of existing behaviour rather than a change to it.

    View source ↗