Changes in iPCV V2
1. Medication Model Split
Section titled “1. Medication Model Split”In iPCV v2, medication data is delivered as separate models: drug_record,
issue_record, problem_drug_record, and problem_issue_record.
These are distinct models and are not provided as a single combined
medication_model or medication_problem_link model as provided in some
flavours in v1
Why?
- To align medication data to clear, domain-specific entities instead of a single mixed model.
- To reduce ambiguity between prescription records and problem-link records, especially when the same patient has multiple related events.
- To improve consistency across flavours in v2 by using a standard split model structure.
Customer benefit
- Clearer data ownership and semantics for each model, making queries easier to understand and maintain.
- More predictable joins and lineage between drug, issue, and problem-link records.
- Lower risk of misinterpreting fields that were previously co-located in a combined model.
Customer action
- Update downstream queries and ETL logic to consume the appropriate model
(
drug_record,issue_record,problem_drug_record, orproblem_issue_record) instead of expecting a single combined model.
2. Additions in V2
Section titled “2. Additions in V2”New columns have been added to enhance auditability, relationships, and clinical measurements. The models now include the below columns:
| drug_record | issue_record | problem_drug_record | problem_issue_record | |
|---|---|---|---|---|
local_mixture_id | ✓ | ✗ | ✗ | ✗ |
local_mixture_name | ✓ | ✗ | ✗ | ✗ |
patient_uuid | ✓ | ✓ | ✓ | ✓ |
patient_organisation_id | ✗ | ✓ | ✓ | ✓ |
patient_organisation_uuid | ✓ | ✓ | ✓ | ✓ |
drug_record_organisation_id | ✓ | ✗ | ✓ | ✗ |
drug_record_organisation_guid | ✓ | ✗ | ✓ | ✗ |
drug_record_organisation_uuid | ✓ | ✗ | ✓ | ✗ |
issue_record_organisation_id | ✗ | ✓ | ✗ | ✓ |
issue_record_organisation_guid | ✗ | ✓ | ✗ | ✓ |
issue_record_organisation_uuid | ✗ | ✓ | ✗ | ✓ |
consultation_id | ✗ | ✓ | ✗ | ✗ |
consultation_section_id | ✗ | ✓ | ✗ | ✗ |
consultation_section_uuid | ✗ | ✓ | ✗ | ✗ |
entered_by_user_in_role_id | ✓ | ✓ | ✗ | ✗ |
entered_by_user_in_role_uuid | ✓ | ✓ | ✗ | ✗ |
authorising_user_in_role_id | ✓ | ✓ | ✗ | ✗ |
authorising_user_in_role_uuid | ✓ | ✓ | ✗ | ✗ |
original_authorising_user_in_role_id | ✓ | ✗ | ✗ | ✗ |
original_authorising_user_in_role_uuid | ✓ | ✗ | ✗ | ✗ |
cancelled_by_user_in_role_id | ✓ | ✓ | ✗ | ✗ |
cancelled_by_user_in_role_uuid | ✓ | ✓ | ✗ | ✗ |
prescription_type_id | ✓ | ✓ | ✗ | ✗ |
most_recent_issue_record_id | ✓ | ✗ | ✗ | ✗ |
most_recent_issue_record_uuid | ✓ | ✗ | ✗ | ✗ |
most_recent_issue_method_id | ✓ | ✗ | ✗ | ✗ |
issue_method_id | ✗ | ✓ | ✗ | ✗ |
quantity_unit_of_measure_id | ✓ | ✓ | ✗ | ✗ |
problem_observation_id | ✗ | ✗ | ✓ | ✓ |
drug_record_code_id | ✗ | ✗ | ✓ | ✗ |
issue_record_code_id | ✗ | ✗ | ✗ | ✓ |
observation_code_id | ✗ | ✗ | ✓ | ✓ |
Why?
- To improve traceability across medication and problem-link models by adding stable IDs, UUIDs, and organisation-level relationship keys.
- To standardise linking between
drug_record,issue_record,problem_drug_record, andproblem_issue_record, so joins are explicit and consistent in v2. - To support richer analytics and lineage with additional clinical, consultation, and metadata fields where available.
Customer benefit
- More reliable joins across medication and problem-link datasets, reducing join ambiguity and duplicate/missed matches.
- Better auditability and lineage for downstream reporting, reconciliation, and incremental processing.
- Additional context (for example consultation linkage and local mixture fields) enables deeper analysis without relying on flavour-specific shortcuts.
Customer action
- Review existing queries and ETL mappings to ensure they use the new IDs/UUIDs and organisation keys introduced in v2.
- Update joins between medication and problem-link models to use the explicit record and organisation relationship fields.
- Validate downstream outputs after migration, including row counts, deduplication behaviour, and key business metrics.
3. Renamed Columns
Section titled “3. Renamed Columns”Several columns have been renamed between v1 and v2 to align naming conventions across the wider iPCV v2 models and clarify meaning (e.g., GUID vs UUID vs ID):
| V1 Column Name | V2 Column Name |
|---|---|
medication_id | drug_record_guid / issue_record_guid |
exa_medication_guid | drug_record_uuid / issue_record_uuid |
emis_medication_organisation_guid | drug_record_organisation_guid / issue_record_organisation_guid |
organisation_guid | drug_record_organisation_guid / issue_record_organisation_guid |
code_id | drug_record_code_id / issue_record_code_id |
organisation_id | patient_organisation_id |
Why?
Columns were renamed to align with the split into separate drug and issue record models and to make naming consistent across iPCV v2.
Customer benefit
- Data consistency
Customer action
- Validate downstream systems or reports to ensure they can utilise the new columns effectively
- No immediate action required if consuming the fields directly from the v2 model
4. Removal of Columns
Section titled “4. Removal of Columns”In iPCV v1, several attributes of other entities were directly included in the drug or issue record models. In iPCV v2, the below fields have been removed from the data models, and relevant IDs are provided to retrieve this information from dedicated extended data models.
| Decommissioned Column | Relevant ID/ Column | Reason / Extended Data Model to be Referred |
|---|---|---|
uom_dmd | drug_pack | mkb_mapping_dmdpreparation |
confidential_patient_flag | patient_id | patient_v2 |
dummy_patient_flag | patient_id | patient_v2 |
regular_patient_flag | patient_id | patient_v2 |
sensitive_patient_flag | patient_id | patient_v2 |
opt_out_93c1_flag | patient_id | patient_v2 |
opt_out_9nd19nu09nu4_flag | patient_id | patient_v2 |
opt_out_9nd19nu0_flag | patient_id | patient_v2 |
opt_out_9nu0_flag | patient_id | patient_v2 |
non_regular_and_current_active_flag | patient_id | patient_v2 |
regular_and_current_active_flag | patient_id | patient_v2 |
regular_current_active_and_inactive_flag | patient_id | patient_v2 |
clinician_user_in_role_guid | authorising_user_in_role_id | user_in_role_v2 |
entered_by_user_in_role_guid | entered_by_user_in_role_id | user_in_role_v2 |
intent | No longer available in v2 | |
hestia_event_type | No longer available in v2 | |
exa_prescription_guid | No longer available in v2 | |
_record_version | No longer available in v2 | |
_update_date | No longer available in v2 as changes are tracked differently | |
_update_hour | No longer available in v2 as changes are tracked differently | |
data_filter | No longer available in v2 |
Why?
This change simplifies the core drug and issue record models, 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 focused information within the extended models, that increases the performance of iPCV v2.
Customer benefit
- Improved Performance: Leaner models can lead to faster query performance.
- Enhanced Scalability: Decoupled models are easier to maintain and extend independently.
- Data Consistency: Centralising specific attributes in their own models ensures a single source of truth.
Customer action
- Review all reports and queries that rely on the decommissioned fields listed above
- Update them to join with the appropriate extended data models using the new IDs provided in the table
- Test thoroughly to ensure data accuracy and query performance with the new model structure
5. NULL value columns
Section titled “5. NULL value columns”Several columns in the medication models now consistently return NULL values and have been retained for backward compatibility.
These include:
| Decommissioned Column | Relevant ID/ Column | Reason / Extended Data Model to be Referred |
|---|---|---|
emis_authorising_userinrole_guid | authorising_user_in_role_id | user_in_role_v2 |
emis_enteredby_userinrole_guid | entered_by_user_in_role_id | user_in_role_v2 |
cancellation_userinrole_guid | cancelled_by_user_in_role_id | user_in_role_v2 |
authorisedissues_authorising_user_in_role | original_authorising_user_in_role_id/ authorising_user_in_role_id | user_in_role_v2 |
authorisedissues_enteredby_userinrole | entered_by_user_in_role_id | user_in_role_v2 |
reimburse_type | is_privately_prescribed | medication_drug_record_v2 |
problem_observation_guid | Removed from drug_record and issue_record models, but available in problem_drug_record and problem_issue_record models | |
fhir_medication_status | Always NULL as it is deprecated in v2 | |
fhir_medication_intent | Always NULL as it is deprecated in v2 | |
nhs_prescribing_agency | Always NULL as it is deprecated in v2 | |
nhs_prescription_type | Always NULL as it is deprecated in v2 | |
registration_ods_code | Always NULL as it is deprecated in v2 | |
processing_id | Always NULL as it is deprecated in v2 |
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 behaviour in downstream processes.
FHIR mappings have been removed from the core analytical view and dedicated reference tables or external FHIR services should be used when required.
Customer benefit
- Improved Performance: Leaner models can lead to faster query performance.
- Reduced risk of unexpected behavior in downstream processes
Customer action
- Review all reports and queries that rely on the decommissioned fields listed above
- Update them to join with the appropriate extended data models using the new IDs provided in the table
- Test thoroughly to ensure data accuracy and query performance with the new model structure