Changes in iPCV V2

1. Filter and Opt-out Changes

a. Consolidation of Patient-level Filters and Opt-out Flags

In iPCV v2, the Patient model is now the single source of truth for all patient-level registration filters and opt-out flags. These columns have been removed from all other care record models (observation, allergy, immunisation, consultation, medication, recall) to eliminate data duplication and establish a clear separation between patient-level attributes and record-level attributes.

Patient Filter and Opt-Out Columns Now in Patient Model:

• is_regular
• is_dummy
• is_dissent_9nu0
• is_dissent_93c1
• is_dissent_9nu4
• is_dissent_9nd1
• is_dissent_9nd1_and_9nu0
• is_dissent_9nd1_and_9nu0_and_9nu4
• is_national_data_opted_out / is_ndop
• is_confidential
• is_sensitive
• is_registered
• is_active
• has_left
• has_died

Where a customer flavour included composite flags e.g. regular_and_current_active these have also been moved to the patient model. Some flavours like Vanilla and Themis where these flags were also included in a patient_optout model these will still be visible there too but removed from all other models.

Why?

Before v2, these patient-level flags were duplicated across multiple clinical models, creating:

• Data redundancy and storage overhead
• Risk of inconsistencies when patient opt-out status changed
• Maintenance complexity (updating patient status in multiple models)
• Customer confusion about which source was authoritative

By consolidating into the Patient model:

• Single source of truth ensures consistency across all clinical data
• Reduced duplication lowers processing costs and storage requirements
• Simplified maintenance - patient status changes in one place only
• Clear architecture - patient-level vs record-level attributes are distinct

b. Consolidation of Observation Opt-out into Patient

In iPCV v2, the Patient model also enables customers to understand why a patient has dropped out of scope for their customer schema or Data Sharing Agreement (DSA). Non-sensitive and non-identifiable patient information is retained for all patient records, together with the relevant filter columns, to support historical tracking of changes in scope.

the observation OptOut status model has been removed from all customer flavours. The Patient model now provides the patient-level filter and opt-out information previously available through that model.

To restrict results to patients relevant to a DSA, filter out NULL records or join the Patient model to Patient Scope which only holds the patient list within scope of the customer schema.

Why?

Consolidating this information into the Patient model provides a single place to understand current and historical patient scope, while avoiding a separate model that duplicated patient-level status information.

c. Patient NDOP data Refresh

In IPCV V2, for an organisation with a future close date we will be processing patient’s NDOP data up until the closed date of that organisation. This is in line with V2 processing data for organisations up until their actual closed date.

In V1 we stopped processing this data as soon as an organisation had a closure date, even if it was in the future, in anticipation for the closure. Our improved processes in V2 for identifying and verifying organisation activity and closures allows us to be more specific and stop based on the specific closed date.

Additionally, as we are introducing the ability to identify merged records in IPCVs (is_merged) we are also expanding our NDOP logic to set those records to is_ndop as soon as they are merged as that record will no longer be receiving NDOP updates.

Why?

This change has been applied to further refine our NDOP data processing and give customers a more accurate window for NDOP changes.

Customer benefit

• Improved Accuracy: Further ensured the NDOP validity window.
• Timely Updates: More granularity in NDOP updates up to organisation closure date.

Customer action

• Assess if this change is relevant to your flavour schema.
• Validate downstream systems or reports.
• No immediate action required if consuming patient model directly from v2.
• Please note this change might have an impact on when patients get removed from your patient scope in V2 compared to V1.

d. Local opt-out flags changed to be consent based

:::note This change has no impact to customer flavours. Columns will still be derived as opt-out flags, same as in V1. :::

In IPCV V2 core models, the underlying logic for patient local opt-out flags has been reversed to indicate consent rather than highlight dissent for a specific local opt-out i.e. they are opt-in.

has_9nu0 → is_consent_9nu0

has_93c1 → is_consent_93c1 etc.

is_ndop → is_national_data_opted_in

However, the final logic with which we present opt-outs has not changed between v1 and v2 and remains as per standard practice. You will still be seeing these as dissent flags in your flavour specific views instead of consent. This is only to inform you of a processing change in V2 core layer and help navigate the schema pages.

As in IPCV V1, dissent needs to be explicit, meaning if no dissent code is recorded against a patient they are treated as consented for data sharing. The logic applied to all local opt-out pairs is that the date of the most recently recorded code in each pair determines the patient’s status. This will now be presented as consent based in the core models.

Why?

Presenting the core fields as consent-based clearly defines how each status is calculated. Consent is implied unless an explicit dissent code is recorded, so the fields accurately reflect the underlying default and the most recent applicable consent or dissent code.

Customer action

No action. This is highlighted here for information only as the new documentation for IPCV V2 will refer to this change of logic in the main pages.

2. Enhancements / Changes to Existing Columns

a. Refined Age Calculation Logic in Patient Data Mode

In IPCV v2 we have introduced a more dynamic and accurate approach for age calculation:

• Age is now calculated using either the current date or the date of death (if populated), ensuring correct age representation for all patients at all times.
• The age field is updated not only when the patient record changes, but also when the patient’s birthday passes, ensuring age remains current without manual intervention.

Why?

In iPCV V1 of the patient data model, the ‘age’ field was derived from a source calculation, and only updated when there was a change in a patient’s record. Because of this limitation customers were previously advised where applicable to dynamically calculate age as part of their processes, this will no longer be necessary for V2.

Additionally, data quality issues identified over the time V1 has been running, whereby in some instances a patient’s age continued to increment after a patient was marked as deceased have been addressed with this change.

Customer benefit

• Improved Accuracy: Ensures age is correctly calculated for both living and deceased patients
• Timely Updates: Automatically reflects age changes as time progresses, reducing stale data
• Better Analytics: Enhances age-based reporting and segmentation, especially in longitudinal studies

Customer action

• Review any logic or filters that rely on the ‘age’ field and ensure they align with the updated calculation method
• Validate downstream systems or reports that use age to confirm they reflect the new logic
• No immediate action required if consuming the age field directly from the v2 model

b. Refined Registration Status Logic in Patient Data Model

In IPCV V2, we have further refined the scope of registration status to only include patients that are fully “registered” and their health care record has migrated over. This approach was adopted to better reflect the real-world patient registration flow in primary care.

This is slightly different from IPCV v1 where under “registered” we were also including “active” patients, i.e. patients that were pre-registered and could use practice services.

Why?

This change is to ensure that only patients who have fully completed their registration are counted, avoiding premature inclusion of pre-registered patients, and further clarifying the distinction between registered and active patient.

Customer benefit

• Improved Accuracy: More precise identification of registered patients
• Better Segmentation: Enables clearer distinction between registered and pre-registered patients
• Enhanced Reporting: Supports more reliable registration-based metrics and analysis

Customer action

• Review any logic or filters that rely on is_registered and update them to reflect the new definition
• Validate downstream systems or reports that use registration status to ensure consistency with v2
• No immediate action required if consuming the field directly from the v2 model

c. Refined Registration Start & End Date in Patient Data Model

In iPCV v2, following from the registration changes above, we have updated the Registration start date to more accurately reflect the actual registration date of a patient, i.e. when their record is fully registered with a practice, and not when the record is first created (pre-registered). This follows the same logic with ‘registered’ status above, where it creates a better separation between pre-registered and registered patients. Similarly registration end date now reflects the date when the patient record fully leaves the practice, and not when the process of de-registration is initiated, ensuring a more accurate lifecycle tracking.

Why?

In iPCV v1, the registration start date could be set to the patient record creation date (taken from source), and remained reflected in records even when registration was never completed. Similarly for registration end date when the patient record move was not completed.

Implementing this change, provides a more accurate tracking of patient registration periods, as it accounts for the data quality issues of incomplete registrations by removing premature date assignment.

Customer benefit

• Improved Accuracy: Eliminates false positives for registration start dates
• Cleaner Data: Reduces noise in registration-related reporting and analysis
• Better Insights: Supports more meaningful metrics around patient onboarding and registration timelines

Customer action

• Review any logic or reports that rely on registration_start or registration_end and ensure they reflect the updated definition
• Validate downstream systems or dashboards to confirm they exclude unregistered patients from registration-based metrics
• No immediate action required if consuming the field directly from the v2 model

d. Standardised Deceased Flag Logic

In iPCV v2 of the patient data models, the logic for determining whether a patient is deceased or not, has been refined and unified.

The logic now uses all available fields at source, such as patient status and date of death, instead of both directly using the source system deceased_flag and separately checking patient status and date of death.

Why? Because of potential data quality and timing issues with adding date of death to a record (a non mandatory field at source), or external health authorities triggering a patient status change when a patient is deceased we have updated our derivation for the deceased / has_died flags to use all available information to derive status. This better ensures we don’t rely on optional fields, or fields based on procedures triggered by source system data changes (e.g. deceased flag).

In V1 both exposing the deceased_flag from source, and deriving the logic from status and date of death was found to be confusing for customers and could be seen to have discrepancies between the 2 fields while the changes to a patient’s status were being processed through primary care.

Customer benefit

• Improved Accuracy: More reliable identification of deceased patients across datasets
• Simplified Integration: Unified logic reduces the need for custom handling or cross-referencing multiple fields
• Better Reporting: Enhances downstream analytics and reporting consistency

Customer action

• Review any custom logic or filters that rely on deceased status and update them to align with the new unified logic in v2
• Validate downstream systems or dashboards to ensure they reflect the updated logic

e. Standardised Active Status Logic in Patient Data Model

In iPCV v2, following our approach of better defining different statuses within registration, the logic for an ‘active’ patient has also been refined so that the flag is now set for all patients who can actively engage with the practice. The definition of “active” now includes patients with a pre-registration status, not just those fully registered, ensuring that patients in the process of joining the practice are appropriately flagged as active too. Additionally, the updated definition explicitly excludes deceased patients i.e., administrative or notification status changes after death will no longer affect the active flag.

Why?

This change was implemented to follow our adoption of better defined status of registration and activity for a patient, and align them to the real-world patient engagement steps in primary care.

Additionally, we have deviated from the assumption in IPCV V1 that a patient record that stills received status updates should be considered as ‘active’. This change prevents deceased patients from being periodically marked as active due to post-mortem administrative updates, and ensures that the active flag accurately reflects patients who are either currently registered or in the process of registration, but are alive and associated with the practice.

Customer benefit

• Improved Accuracy: Prevents deceased patients from being incorrectly marked as active. Marks pre-registered patients as active.
• Operational Clarity: Aligns active status with real-world patient engagement stages
• Better Filtering: Supports more meaningful segmentation for active caseloads

Customer action

• Review any logic or filters that rely on the active field and update them to reflect the new definition
• Validate downstream systems or dashboards to ensure deceased patients are excluded from active patient views
• No immediate action required if consuming the field directly from the v2 model

f. Standardised Patient Left Status Logic in Patient Data Model

iPCV v2, following similar approaches above, the “left” status is now assigned only to patients whose caseload or patient status explicitly indicates they have left, excluding deceased patients. The logic is now standardised along with status described above to ensure only appropriate patients are marked as “left,” improving data consistency.

Why?

This change is, similarly to the above, to make V2 patient status fields more resilient to data quality discrepancies and therefore avoid misclassification of patients due to inconsistent status handling or delayed status changes across practices that could cause a deceased patient to be flagged as both deceased and having left a practice.

Customer benefit

• Improved Accuracy: Clearer distinction between patients who have left and those who are deceased
• Reliable Reporting: Enhances service exit metrics and patient flow analysis
• Operational Clarity: Supports better caseload management and follow-up processes

Customer action

• Review any logic or reports that rely on the left field and ensure they reflect the updated definition
• Validate downstream systems or dashboards to confirm deceased patients are excluded from “left” status views
• No immediate action required if consuming the field directly from the v2 model

g. Expanded Ethnicity Classification in Patient Data Model

Ethnicity is a patient attribute derived from care record observation entries, where the latest recorded entry is surfaced in the patient model. In IPCV V2, the ethnicity code list that is used to look for ethnicity recorded entries has been enhanced to include more SNOMED and EMIS clinical codes.

In iPCV v1, ethnicity was determined using national codes under ‘Ethnic Group’ category , as per the NHS data dictionary.

iPCV v2 enhances this by adding to:

• Adding all concepts under the SNOMED concept 397731000 (Ethnic group) hierarchy.
• Adding all EMIS code ids under EMIS code id 141291000000111 hierarchy.

Why?

Expanding ethnicity code list, allows for a more granular and clinically relevant classification of ethnicity, improving alignment with different terminologies and improving data coverage.

Customer benefit

• Improved Accuracy & Coverage: Captures a broader and more precise range of ethnic classifications
• Enhanced Interoperability: Aligns with SNOMED and EMIS standards for better integration across systems
• Better Reporting & Insights: Supports more detailed demographic analysis and equity monitoring

Customer action

• Review any logic or filters that rely on ethnicity codes and ensure they accommodate the expanded SNOMED and EMIS hierarchy
• Validate downstream systems or dashboards to confirm they reflect the enhanced classification
• No immediate action required if consuming the field directly from the v2 model

h. Standardised Observation-Based Attribute Logic in Patient Data Model

V2 introduces a standardised and deterministic approach to identifying the most recent entry for all observation-based attributes in the patient model.

The prioritised approach utilised the Effective date, followed by availability timestamp and observation ID (as a fallback) for all observation based attributes such as: patient consent(Type 1 & 2 Optouts), ethnicity, language, sexual orientation and patient contact preferences (via email/sms.

:::note Following standardisation, observation_optout model is now deprecated as the patient filter attributes are now available in the patient model and/or patient filter model. :::

Why?

This results in a deterministic, more accurate representation of patient data, particularly for practices with historical or migrated records.

Customer benefit

• Improved Accuracy: Ensures the most relevant and recent observation is used
• Consistency Across Fields: Reduces discrepancies in how different attributes are handled
• Better Data Quality: Enhances trust in reporting and analytics, especially for consent and demographic data

Customer action

• Review any logic or reports that rely on observation-based attributes and ensure they reflect the updated selection method
• Validate downstream systems or dashboards to confirm they are using the latest and most accurate data
• No immediate action required if consuming the fields directly from the v2 model

i. Updated logic for Usual GP and External Usual GP in Patient Data Model

In IPCV V2, following the pattern above, we will only be providing usual_gp_user_in_role_id and external_usual_gp_id to be joined to the user in role model for GP information.

For the external usual GP, this is also an update in logic from V1, as we were previously joining to dedicated source tables for external GP user id mapping, and now will be joining to the main user tables utilised in user in role model.

In iPCV v1, the model attempted to provide the GUID for both Usual GP and External Usual GP. However, this approach was incorrect for External Usual GP, leading to mismatches or missing links when joining to user data.

iPCV v2 corrects this by:

• Providing the EMIS ID - usual_gp_user_in_role_id and external_usual_gp_id for both Usual GP external_usual_gp_id and External Usual GP respectively
• These IDs are designed to be joined to the User in Role model, ensuring accurate linkage and representation

Why?

This change from V1 was necessary to address inconsistencies and missing data between the user tables and the external GP user source tables due to mismatched user GUIDs in these tables. Switching to EMIS IDs aligns the model with the actual data structure used in downstream systems, enabling more dependable joins and ensuring that the representation of GP relationships reflects real-world practice configurations.

Customer benefit

• Improved Accuracy: Ensures correct identification and linkage of external GP records
• Better Integration: Supports reliable joins to user data for reporting and analysis
• Reduced Errors: Eliminates mismatches caused by incorrect GUID usage

Customer action

• Update any joins or lookups that previously relied on GUIDs to use EMIS IDs instead
• Ensure downstream systems or reports referencing GP data are aligned with the new identifier logic
• No immediate action required if consuming the field directly from the v2 model and joining via EMIS ID

j. Simplified Carer Representation in Patient Data Model

In IPCV V2, we are introducing a simplified more scalable approach to carer information where we are combining all carer information to a single flag.

has_carer flag indicates whether a patient has one or more carers, and the previous V1 fields of carer_name, and carer_relation have been removed.

In iPCV v1, the model attempted to provide either carer details or a carer flag, but this approach was limited to a 1-to-1 relationship between carer and patient and did not reflect fully the data for patients with more than one main carer.

A separate carer model is being considered for future release in V2 which will include carer details and relationships to patients independently from the patient model and would allow us to accurately represent this information.

Why?

The previous approach of storing carer name and relation directly on the patient record was insufficient for patients with multiple carers and introduced unnecessary complexity into the core patient model. A simple boolean flag (has_carer) provides a reliable indicator of carer presence, while keeping detailed carer relationships out of scope until a dedicated carer model can represent them accurately.

Customer benefit

• Improved Accuracy: Reflects the presence of carers without oversimplifying or misrepresenting relationships
• Scalability: Prepares the data model for future enhancements with a dedicated carer structure
• Cleaner Design: Reduces ambiguity and clutter in the patient view

Customer action

• Review any logic or reports that previously relied on detailed carer data and adjust to use the has_carer flag
• Prepare for future integration with a separate carer model if detailed carer data is required
• No immediate action required if consuming the field directly from the v2 model

3. Additions in V2

a. Expanded Patient Identifier Coverage in Patient Data Model

In IPCV V2, we are introducing into the patient model additional identifiers for healthcare services beyond a patient’s NHS number (where available) to support broader interoperability and regional coverage. The new identifiers introduced are:

• CHI Number (Scotland)
• HC Number (Northern Ireland)
• Hospital Number (secondary care)
• SSD Number (Jersey)
• GHA Number (Gibraltar)

Additionally we are introducing the columns below for NHS, CHI and HC numbers that will confirm if a healthcare identifier is a valid one i.e. follows the expected algorithmic pattern.

• is_valid_nhs_number
• is_valid_chi_number
• is_valid_hc_number

Why?

This expansion ensures that patients can be accurately identified across different healthcare systems and geographies.

is_valid_*_number columns will enable customers to enhance their data quality checks.

Customer benefit

• Improved Coverage: Supports identification across UK regions and healthcare settings
• Enhanced Interoperability: Facilitates smoother integration with external systems and datasets
• Better Data Matching: Reduces duplication and improves linkage accuracy in multi-source environments

Customer action

• Review any logic or matching processes that rely solely on NHS Number and consider incorporating additional identifiers
• Validate downstream systems or reports to ensure they can handle and benefit from the expanded identifier set
• No immediate action required if consuming the field directly from the v2 model and joining via EMIS ID

b. Addition of New Columns to the Flavours for Enhanced Data Accuracy

In IPCV v2 patient model we have introduced several new columns in the core patient models and across different flavours to improve data accuracy, provide clearer insights into data lineage, and support future enhancements.

These columns are included only where relevant to the specific flavour as presented in the schema. Some flavours would have already included these columns as part of their requirements in V1, and others might have new columns added to enhance the accuracy and interoperability of their patient data model.

The consolidated list of new columns in the core patient model and across flavours:

• is_active
• is_merged
• is_national_data_opted_in
• is_registered
• is_regular
• is_dummy
• is_consent_9nu0
• is_consent_93c1
• is_consent_9nu4
• is_consent_9nd1
• is_consent_9nd1_and_9nu0
• is_consent_9nd1_and_9nu0_and_9nu4
• sex
• postcode_no_space
• patient_uuid
• registration_organisation_id
• registration_organisation_uuid
• usual_gp_user_in_role_uuid
• external_usual_gp_uuid
• address_id
• address_uuid
• transform_datetime
• load_datetime

:::tip Consult the patient and patient filter option schema pages for details on the additions relevant to your IPCV flavour. :::

Why?

These additions provide more granular flags for patient status, consent, and data lineage. The introduction of new ID-based columns aligns the model with modern identifier practices, paving the way for deprecating older fields and improving system consistency.

The patient filter and opt-out columns (is_regular, is_dummy, is_consent_*) have been added to the Patient model only as these were previously duplicated across multiple clinical models (observation, allergy, immunisation, consultation, medication, recall). See Consolidation of Patient Filter and Opt-Out Columns for complete details. They are now presented as individual flags instead of combined ones for simplicity and ease of use.

Customer benefit

• Improved Data Lineage: The is_merged flag offers greater transparency into the history of patient records affected by organisational changes
• Enhanced Consistency: Standardises the use of identifiers and status flags across different model flavours
• Richer Analytics: Enables more precise filtering and analysis based on registration status, consent, and active status
• Future-Proofing: Adopting new ID-based columns ensures a smoother transition as older identifiers are phased out

Customer action

• Review any logic that handles patient data to incorporate the new flags and IDs for more accurate reporting
• Begin planning the migration from older identifiers (e.g., registration_organisation_guid) to their new ID-based counterparts (e.g., registration_organisation_id) in any custom queries or downstream systems
• Validate downstream systems or reports to ensure they can utilize the new columns effectively
• No immediate action required if consuming the fields directly from the v2 model

c. Addition of 2021 Geography and Deprivation Columns in Patient Model

In iPCV v2, geography and deprivation fields from the 2021 IMD have been added. Previous IMD 2011 fields have been renamed to distinguish between 2011 and 2021 reference standards.

The existing fields are renamed with a _2011 suffix:

• lsoa -> lsoa_2011
• msoa -> msoa_2011
• imd_decile -> imd_decile_2011

New 2021 fields are added:

• lsoa_2021
• msoa_2021
• imd_decile_2021

Why?

This change add the 2021 IMD information into IPCVs and enables customers to use either 2011 or 2021 geography and deprivation mappings or both based on reporting and analytical needs.

Customer benefit

• Better Clarity: Makes the underlying geography/deprivation vintage explicit in the schema
• Improved Reporting Flexibility: Supports both legacy (2011) and updated (2021) area classifications
• Reduced Migration Risk: Clear naming helps avoid accidental joins between different vintages

Customer action

• Update any queries, joins, or downstream mappings that currently use lsoa, msoa, or imd_decile to their _2011 equivalents
• Adopt lsoa_2021, msoa_2021, and imd_decile_2021 where 2021 standards are required

4. Removal of Columns

In iPCV V2, columns have been removed to streamline the data model and maintain a single source of truth for reference data.

Columns that have been removed from the patient data models, are listed below, and mapped to how the data can be retrieved from IPCV V2 extended models.

Decommissioned Column from V1	Relevant column in V2	Reason / Extended Data Model to be Referred
ethnic_category_snomed_concept_id	ethnicity_code_id	mkb_mapping_ethnicity_v2
ethnic_group_snomed_description	ethnicity_code_id	mkb_mapping_ethnicity_v2
language_preferred_snomed_concept_id	preferred_language_code_id	mkb_mapping_attributes_v2
sexual_orientation_nationalcode	sexual_orientation_emis_code_id	mkb_mapping_attributes_v2
nhs_no_status/ nhs_number_status		No longer available in v2
data_filter		No longer available in v2
_record_version		No longer available in v2
_update_date		No longer available in v2 as changes tracked differently in v2
_update_hour		No longer available in v2 as changes tracked differently in v2

:::tip Consult the patient and patient filter option schema pages for details on the removed/NULL columns relevant to your IPCV flavour. :::

Why?

This change simplifies the core patient model, making it lighter and easier to manage. By moving specific attributes to their own models, data redundancy is reduced, and maintainability is improved. This allows for more detailed and focused information within the extended models without cluttering the primary patient record, reducing the complexity of multiple joins.

Customer benefit

• Single source of truth for patient flags through the patient dimension table
• Reduced risk of data inconsistencies and synchronization issues
• Improved data lineage tracking with centralized reference tables

Customer action

• Review and update any processes or integrations that relied on the removed columns
• Use dedicated MKB reference tables for code mappings instead of inline columns
• Ensure that any necessary mappings or transformations are adjusted accordingly

5. Renamed columns

Some columns in the patient model have now been renamed. Below is the consolidated list of renamed columns. Please note that not all column renaming will apply to your customer specific schema, review ‘schema’ section for details on what is applicable to your flavour.

Column Name V1	Column Name V2	Reason
is_ndop	is_national_data_opted_out	Standardisation across models within a customer schema / flavour where NDOP was available in Patient and Patient Optout Status
optout_9nu0_flag / has_9nu0	is_dissent_9nu0	Standardisation across models within a customer schema
optout_93c1_flag / has_93c1	is_dissent_93c1	Standardisation across models within a customer schema
optout_9nu4_flag / has_9nu4	is_dissent_9nu4	Standardisation across models within a customer schema
optout_9nd1_flag / has_9nd1	is_dissent_9nd1	Standardisation across models within a customer schema
opt_out_9nd19nu0_flag / has_9nd1_or_9nu0	is_dissent_9nd1_and_9nu0	Standardisation across models within a customer schema
opt_out_9nd19nu09nu4_flag / has_9nd1_9nu0_9nu4	is_dissent_9nd1_and_9nu0_and_9nu4	Standardisation across models within a customer schema
lsoa	lsoa_2011	Introduction of equivalent columns from 2021 census
msoa	msoa_2011	Introduction of equivalent columns from 2021 census
imd_decile	imd_decile_2011	Introduction of equivalent columns from 2021 census

6. NULL value columns

Several columns in the patient model now consistently return NULL values and have been retained for backward compatibility.

Decommissioned Column from V1	Relevant column in V2	Reason / Extended Data Model to be Referred
registration_ods_code	ods_code	organisation_v2
named_gp / usual_gp_user_in_role	usual_gp_user_in_role_id	user_in_role_v2
fhir_registration_type	patient_status	Deprecated column
fhir_patient_type	patient_type	Deprecated column
carer_name	has_carer	Deprecated column, see 4.j above for more information
carer_relation	has_carer	As above
carer_name_flag	has_carer	As above
carer_relation_flag	has_carer	As above
external_usualgp_guid	external_usual_gp_id	Join to user_in_role_v2
external_usualgp_name	external_usual_gp_id	Join to user_in_role_v2
usualgp_displayname	usual_gp_user_in_role_id	Join to user_in_role_v2
emis_usualgp_userinrole_guid	usual_gp_user_in_role_id	Join to user_in_role_v2
regular_current_active_and_inactive_flag	is_regular	patient_v2
processing_id		Deprecated column

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

Why?

These columns are retained to maintain backward compatibility while returning NULL values to ensure consistent behavior in downstream processes.

Customer benefit

• User in role information is now standardized through entered_by_user_in_role_id and authorising_user_in_role_id foreign keys joined with user_in_role_v2.
• Reduced risk of unexpected behavior in downstream processes
• Clear distinction between deprecated columns and new standardized relationships

Customer action

• Identify any queries or reports that use the deprecated columns
• Update processes to use new columns like using entered_by_user_in_role_id and authorising_user_in_role_id to join with user_in_role_v2 to retrieve user in role details