Definition

The Patient Registration History data model provides the historical view of a patient’s registration type and registration status within an organisation. It should be used where analysis needs to understand how a patient’s registration has changed over time, rather than only their latest state in the Patient model.

Patient history covers previous registration types and statuses recorded in EMIS Web. This includes movement through the registration lifecycle, patients leaving an organisation, deceased patients, and non-regular registration types such as temporary, emergency, private, immediately necessary, homeless, and dummy patients.

Information

This model contains the following key information for historical registration records:

• Patient history, patient, and organisation identifiers
• Patient GUID and person GUID linking fields
• Healthcare service numbers and validity flags
• Registration status and patient type identifiers and descriptions
• Derived lifecycle flags such as registered, left, and deceased
• The date and year the registration history event was recorded
• Warehouse lineage fields for incremental processing

Grain and Scope

Each row represents one historical registration type or status entry for a patient within an organisation. Each record is uniquely identified by combining patient_history_id and organisation, or by using patient_history_uuid.

The model includes historical rows only. For the current patient state, use the Patient model.

The following fields are important for interpreting the registration lifecycle:

• patient_status_id and patient_status_description: The registration status recorded in EMIS Web for this history entry.
• patient_type_id and patient_type_description: The type of patient the history entry relates to.
• is_registered: Indicates whether the history row is considered fully registered according to the patient type and status combination.
• has_left: Indicates that the patient had left the organisation at the point represented by the history row, excluding deceased patients.
• has_died: Indicates that the patient was deceased, had a recorded date of death, or was linked to a deceased caseload status.

Registered Status

The is_registered flag is derived from both patient type and registration status:

• For regular patients (patient_type_id = 4), the patient is considered registered when patient_status_id is between 4 and 7. This covers the main GP registration process from notification of registration through receipt of the medical record.
• For non-regular patients, the patient is considered registered only when patient_status_id = 8, which represents correctly registered patients for community organisations.

The descriptions most commonly used to identify registered history are:

Patient Type	Status ID	Status Description
Regular	4	Notification of registration
Regular	5	Medical record sent
Regular	6	Record Received
Non-regular	8	Correctly registered

The source calculation also treats regular status ID 7 as registered where it is present in the local EMIS lookup.

Patient Type Mapping

Common EMIS patient type values include:

Patient Type ID	Description	FHIR Mapping
1	Emergency	E
2	Immediately Necessary	IN
3	Private	P
4	Regular	R
5	Temporary	T
7	Dummy	S

Other patient type values are mapped as O for other in FHIR-facing outputs. Dummy patients are usually created for demonstration, onboarding, or training within a practice’s own data.

Constraints and Notes

• Soft deletion: When is_deleted is true, patient-identifiable and descriptive fields are nullified in the serving layer while primary keys and lineage fields are retained so deleted history rows can still be identified.
• Patient merges are not resolved in this model. If a duplicate patient record has been merged in EMIS Web, the sacrificed patient ID can still appear in historical data.
• Archived patients are retained in the source data. Archiving hides the patient for most purposes in EMIS Web but does not delete the underlying history.
• Observation data and external data sources are not used to derive this model.

Overview

flowchart TD
    patient_history[(Patient History)] --> patient_registration_history[(Patient Registration History)]
    patient[(Patient)] --> patient_registration_history
    patient_status[(Patient Status)] --> patient_registration_history
    patient_type[(Patient Type)] --> patient_registration_history
    patient_identifier[(Patient Identifiers)] --> patient_registration_history

    classDef nodeStyle stroke:#9961a4;
    class patient_history,patient,patient_status,patient_type,patient_identifier nodeStyle;

Examples

Find registration history for a patient

SELECT
  patient_history_id,
  emis_patient_id,
  registration_status_description,
  registration_type_description,
  is_registered,
  has_left,
  has_died,
  recorded_date,
  organisation
FROM hive.explorer_ipcv_vanilla.patient_registration_history
WHERE emis_patient_id = 123456789
ORDER BY recorded_date DESC;

Count registered history entries by year and type

SELECT
  recorded_year,
  registration_type_description,
  COUNT(*) AS history_rows
FROM hive.explorer_ipcv_vanilla.patient_registration_history
WHERE is_registered = TRUE
GROUP BY
  recorded_year,
  registration_type_description
ORDER BY recorded_year DESC;

Review patients who have left or died

SELECT
  emis_patient_id,
  registration_status_description,
  registration_type_description,
  has_left,
  has_died,
  recorded_datetime,
  organisation
FROM hive.explorer_ipcv_vanilla.patient_registration_history
WHERE has_left = TRUE
   OR has_died = TRUE
ORDER BY recorded_datetime DESC;