Changes in iPCV V2

1. Model renamed

The runs_status model is now called data_freshness. The new name more accurately describes the model’s purpose: showing how current the data is.

Why?

• data_freshness is clearer and makes the model easier to find and understand.

Customer benefit

• Customers can identify the model’s purpose without relying on technical knowledge of the previous name.

Customer action

• Replace runs_status with data_freshness in queries, pipelines, dashboards, alerts, and documentation.

Example:

SELECT
  table_name,
  last_updated_datetime
FROM hive.explorer_ipcv_vanilla.data_freshness
WHERE table_name = 'patient';

2. Additions in V2

a. Addition of timestamp columns

The model now includes start_datetime, end_datetime, and last_updated_datetime:

• start_datetime and end_datetime show the period covered by the data.
• last_updated_datetime replaces the V1 _execution_date field and shows when processing finished. In V1, _execution_date was a varchar value in yyyyMMddHHmmss format. In V2, last_updated_datetime is a timestamp(6) with time zone column and does not exactly match the transform_datetime column that exists in each model.

Why?

• These fields separate the data coverage period from the processing completion time, making each timestamp easier to interpret.

Customer benefit

• Customers can check both the data period and the time the model was updated.

Customer action

• Replace _execution_date with last_updated_datetime in queries and integrations. Convert any logic that expects the V1 yyyyMMddHHmmss varchar format to use the V2 timezone-aware timestamp.
• Use start_datetime and end_datetime for the data coverage period.
• Use last_updated_datetime only to check when processing finished, not for joining tables.

3. Removal of Columns

The mkb_version, mkb_execution_date, and status columns have been removed. In V1, these fields did not provide meaningful or actionable information. The status column was hardcoded to complete, so it did not provide useful processing status information.

Why?

• The model is now smaller and focused on information that customers can use.

Customer benefit

• The model is easier to understand and maintain.

Customer action

• Remove references to these columns from queries, reports, integrations, and data quality checks.

4. Renamed Column

The ipcv_table column is now called table_name.

Why?

• table_name is a clearer and more descriptive name.

Customer benefit

• Customers can identify the model being monitored more easily.

Customer action

• Replace ipcv_table with table_name in queries, pipelines, dashboards, integrations, and field mappings.

5. Changed grain

V1 contained a new row for each model and execution date. V2 contains one current row per model, with the data coverage period in start_datetime and end_datetime.

Why?

• One current row makes the model easier to query and avoids confusion with older daily records.

Customer benefit

• Customers can retrieve the current freshness information without filtering or aggregating historical daily rows.

Customer action

• Remove logic that expects historical daily rows or uses _execution_date as part of the grain.
• Update dashboards, alerts, and checks to use one current row per model.