Skip to content
Partner Developer Portal

Changes in iPCV v2

1. Removal of Columns

Section titled “1. Removal of Columns”

The data_filter and _mkb_version columns have been removed in all data models.

Why?

  • data_filter was removed because it is no longer used for filtering in v2.
  • _mkb_version was removed because v2 always provides data for the latest available MKB version and any updates can be identified by the transform_datetime column.

Customer benefit

  • Elimination of unused column references

Customer action

  • Review and remove any references to the deprecated data_filter and _mkb_version columns from existing queries and ETL processes

2. NULL value columns

Section titled “2. NULL value columns”

The processing_id returns NULL value in all data models and have been retained for backward compatibility.

These decommissioned NULL value columns will be removed in a future iPCV release; plan migrations accordingly.

Why?

  • This column exists only due to migration from legacy applications and doesn’t provide any value.
  • Retained to maintain backward compatibility while returning NULL values to ensure consistent behavior in downstream processes.

Customer benefit

  • The data model is streamlined by removing deprecated columns, resulting in a cleaner and more efficient structure

Customer action

  • Review queries and remove any references to the deprecated processing_id columns to align with the updated schema.

3. Additions in V2

Section titled “3. Additions in V2”

emis_code_category_id and national_code_category_id have been added to the Clinical Code data model to provide richer code-category metadata.

is_deleted column has been added to indicate that the source record has been deleted.

Why?

The category columns improve category-level context and make it easier to link Clinical Code records to reference datasets for consistent category reporting.

The deleted column preserves the essential relational context for downstream joins, lineage, and audit use cases.

Customer benefit

  • More precise code-category analysis and reporting
  • Easier joins to category reference data using stable identifiers
  • Reduced reliance on descriptive text fields for filtering and grouping
  • Clearer deletion semantics without losing key model relationships

Customer action

  • Downstream queries and ETL pipelines can be updated to use emis_code_category_id and national_code_category_id where category-level joins or reporting are required.

4. Improved SNOMED CT mapping approach

Section titled “4. Improved SNOMED CT mapping approach”

In the Codeable Concept model, the SNOMED CT description ID mappings are now better represented in the Codeable Concept model by using official SNOMED CT mappings rather than legacy mappings. The source of the mappings have been changed from variation_codesnomed to variation_snomedinteropoutgoing

Why?

The previous mapping approach used was based on legacy mappings created during the Read v2 to SNOMED CT transition in 2020. This provided a granular 1:1 mapping of code IDs to description IDs as found in the EMIS clinical code database, but didn’t align with current SNOMED CT standards

The v2 implementation now uses official SNOMED CT mappings that better represent the intended clinical concepts

Customer benefit

This change provides the following benefits:

  • Better alignment with industry-standard SNOMED CT mappings
  • Improved consistency between Codeable Concept and Clinical Code models
  • Enhanced interoperability with external systems using standard SNOMED CT
  • More accurate representation of clinical concepts

Customer action

  • Review any analyses or queries that rely on SNOMED description IDs, as the values may have changed.
  • Update any workflows that depend on specific description ID values to accommodate the new official mappings.

5. Removing duplicate and nullified SNOMED codes

Section titled “5. Removing duplicate and nullified SNOMED codes”

In the Sensitive Snomed Code model, any records with NULL code_id that represents SNOMED concepts that do not map to an EMIS code ID have been removed. These records are not usable for standard joins, because code_id is required to link sensitive SNOMED codes to other models. Any duplicates codes have also been removed.

Why?

This change removes unmappable and duplicate sensitive SNOMED records so the dataset contains only joinable, relevant mappings.

Customer benefit

  • Cleaner and more reliable sensitive SNOMED dataset
  • Fewer null and duplicate records to handle in downstream logic
  • Reduced risk of ambiguous joins and inconsistent query results

Customer action

  • Review and update queries, validation checks, and record-count logic that previously included NULL code_id values in sensitive SNOMED outputs.