Definition

The Patient Filter Options data model represents various patient attributes and status indicators used for filtering and segmentation within healthcare organizations. This model includes comprehensive information about patient registration status, consent preferences, and clinical identifiers, designed to provide accurate and reliable patient filtering capabilities for reporting and analytics.

In flavours, the Patient Filter Options model either named as “patient_scope” or “patient_optout_status”.

Information

The data model captures patient attributes and status indicators across various dimensions. Each patient record includes standardized flags and dates that enable precise filtering based on registration status, vital status and consent preferences.

Overview

flowchart TD
    n01["Patient Records"]@{ shape: rect}
    n02["Registration Status"]@{ shape: rect}
    n03["Consent Flags"]@{ shape: rect}
    n04["Demographics"]@{ shape: rect}
    n1["Patient Attributes"]@{ shape: rect}
    n91["Patient Filter Options"]@{ shape: extract}
    n92["ETL"]@{ shape: event}
    n93["Patient Filter Options Model"]@{ shape: internal-storage}

    n01 --> n1
    n02 --> n1
    n03 --> n1
    n04 --> n1
    n1 --> n91
    n91 --> n92
    n92 --> n93

    classDef nodeStyle stroke:#9961a4;
    linkStyle default stroke:#117abf,fill:none;

What’s changing in iPCV v2

Deceased Flag Logic Improvement

What

In iPCV v2, the logic for determining whether a patient is deceased has been refined and unified. The logic now uses all available fields from EMIS Web, such as patient status and date of death. Because the date of death is optional in EMIS Web, it will be used in calculations when present; if not, other available fields will be used.

Why

Previously, iPCV v1 used inconsistent logic between patient and patient opt-out models, leading to potential discrepancies. The previous logic sometimes missed deceased patients due to missing date of death values. The new approach provides a more reliable and consistent method.

Customer benefit

This change provides the following benefits:

• 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

Refined Registration Status Logic

What

iPCV v2 includes only patients with actual registration status as “registered”; pre-registration statuses are excluded. This differs from iPCV v1, which included both actual registration and pre-registration statuses.

Why

This change ensures that only genuinely registered patients are counted, avoiding premature inclusion of pre-registered patients.

Customer benefit

This change provides the following benefits:

• 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

Updated Active Status Logic

What

In iPCV v2, the active patient flag is now set only for patients who are truly active at the practice. This explicitly excludes deceased patients—administrative or notification status changes after death no longer affect the active flag. Additionally, the definition of “active” now includes patients with a pre-registration status, not just those fully registered.

Why

This change prevents deceased patients from being incorrectly counted 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

This change provides the following benefits:

• Improved Accuracy: Prevents deceased patients from being incorrectly marked 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 is_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

Refined Patient Left Status Logic in Patient Data Model

In iPCV v1, the logic for identifying patients who had left the practice could include deceased patients or be affected by inconsistent status handling, leading to inaccurate counts.

iPCV v2, the “left” status is now assigned only to patients whose caseload or patient status indicates they have left, explicitly excluding deceased patients. The logic is now standardized to ensure only appropriate patients are marked as “left,” improving data consistency.

Why?

This change is to avoid misclassifying deceased patients as having simply left the 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

Standardised Observation-Based Attribute Logic

What

iPCV v2 introduces a standardized and prioritized approach for selecting the most recent observation:

1. Effective date (if available)
2. Availability time
3. Observation ID (as a fallback)

This method is now consistently applied across key patient attributes, including:

• Opt-outs (data consent)
• Email/SMS consent
• Ethnicity
• Sexual Orientation
• Language

Why

This results in a more accurate and reliable representation of patient data, particularly for systems with historical or migrated records.

Customer benefit

This change provides the following benefits:

• 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

Schema updates for data maintenance

What

iPCV v2 includes schema updates to support improved data maintenance and tracking:

• The is_deleted column has been added to indicate whether a patient record has been marked as deleted
• The registration_organisation_id column has been added to identify the organization where the patient is registered
• The patient_id column has been added as a primary identifier for patient records
• Removed _ingest_time column from this model as it is no longer required in v2
• Removed _update_date and _update_hour columns as the changes tracked differently in v2
• Removed _record_version as only the latest records are presented in the model, it is no longer required in v2

Why

These schema changes enhance data lineage tracking, improve data maintenance capabilities, and provide better organizational context for patient records from iPCV v1.

Customer benefit

This change provides the following benefits:

• Enhanced Data Maintenance: Improved tracking and management of patient record lifecycle
• Better Organization Context: Clearer patient-organization relationships for multi-practice environments
• Improved Data Quality: More reliable patient identification and record tracking
• Consistent Data Handling: Aligns with iPCV v2’s standardized approach to data modeling

Customer action

• Review any logic or queries that filter patient records and update them to incorporate the is_deleted flag as needed
• Update queries to leverage registration_organisation_id, patient_id for organisation and patient filtering
• Validate downstream systems or dashboards to ensure they handle the new schema appropriately
• Update any queries or logic that reference the deprecated columns (_ingest_time, _update_date, _update_hour, _record_version) and remove these references, as they are no longer available in v2
• No immediate action required if consuming the fields directly from the v2 model

Examples

Get active registered patients

SELECT
  *
FROM hive.explorer_ipcv.srv_patient_filter_options
WHERE is_active = true
  AND is_registered = true

Get patients who have left (excluding deceased)

SELECT
  *
FROM hive.explorer_ipcv.srv_patient_filter_options
WHERE is_left = true
  AND is_deceased = false

Get deceased patients with accurate age at death

SELECT
  patient_id,
  age,
  date_of_death
FROM hive.explorer_ipcv.srv_patient_filter_options
WHERE is_deceased = true

Get patients with carers

SELECT
  *
FROM hive.explorer_ipcv.srv_patient_filter_options
WHERE has_carer = true

Get patients by specific ethnicity codes

SELECT
  *
FROM hive.explorer_ipcv.srv_patient_filter_options
WHERE ethnicity_code IN ('397731000', [other SNOMED codes])