PHIN field

Data Element (edit)
Field Name:	PHIN
CCMDB Label:	PHIN
CCMDB tab:	Top Row
Table:	L_Log table, L_PHI table
Data type:	number
Length:	Long Integer
Program:	Med and CC
Created/Raw:	Raw
Start Date:	1988-07-11
End Date:	2300-01-01
Sort Index:	4

The patient's PHIN .

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

The PHIN (Personal Health Information number) is a unique nine-digit numeric identifier assigned by Manitoba Health to every person registered for health insurance in Manitoba. For patients who are not registered with Manitoba Health we assign a Pseudo PHIN.

MB Health PHINs only

Manitoba Health PHIN numbers only.

If patient permanently resides outside of the province of Manitoba the Province field should not be MB and the PHIN field should be left blank.

Please make every effort to obtain this information and call medical records to help.

Special Cases

Location Manitoba and no PHIN

There are scenarios where a PHIN will not be available for a Manitoba patient, including but not limited to

• immigrants on visas
• some prison inmates

In these and similar cases, use 999999999 as the PHIN. The data processor will assign a Pseudo PHIN.

Location Outside Manitoba and no PHIN

PHIN must be entered by data collector as blank. A Pseudo PHIN will be entered by the data processor after file is appended to master database.

Canadian Forces patients

see Canadian Forces patients.

PseudoPHIN

Since the PHIN is used as a unique identifier for patients to detect repeat and continuous visits, a "pseudoPHIN" is assigned for patients who don't have a PHIN. At this point, pseudoPHINS are assigned by Pagasa, see see Generating PseudoPHINs.

Use started in 1999 and starts in '1' and as of Mar 18, 2013 our last Pseudo number was 7043.

Patient changes PHIN over time

A Patient's PHIN

Regarding PHIN/pseudPHINs for people with multiple such identifiers. This can occur in 3 main ways:

• moving from OOP to MB,
• moving from MB to OOP, and
• a single individual having multiple PHINs

For the purpose of identifying “same person”, and uniformity, we agreed that we will capture the current/most recent identifier (PHIN or pseudoPHIN) and record prior identifiers in the ALIAS location.

What do we do if a person's insurance status changes or they move in or out of Province? Do we change those PHINs? If we wanted to keep the same person_ID for different PHINs we would need to remove the first step in Generate Person IDs that blows away Person_IDs for duplicate PHINs. but: if we remove that step we will no longer make sure that the scenario of multiple PHINs per Person_ID doesn't happen accidentally. Pagasa says: if there is a PHIN in EPR, we always use the PHIN in the current entry and change all previous PHIN entries to that PHIN; we leave alone the Province entries of previous records in that case. However, if the patient used to have a PHIN but doesn't any more (e.g. moved out of province and is then admitted), then it is not clear what we should do. The answer of this needs to take into account how the Person ID generator will deal with this. Likley we would need to assign a pseudoPHIN to this scenario and replace earlier real PHINS with that PseudoPHIN. But that would lose our ability to link with e.g. MCHP. Allan also pointed out that people can have 2 PHINS if something goes wrong with their registration with MB Health.

• SMW

• Cargo

• Categories

In all three cases, newest and most current is stored in PHIN and old would go into ALIAS field.

• SMW

• Cargo

• Categories

Changing PHINs

See Changing PHINs

Minimal Data Set

This entry is part of the Minimal Data Set. Special collection instructions apply, see that page for more info.

L_PHI vs L_Log

This field is stored in the L_PHI table in CFE but in the L_Log table in CCMDB.accdb. See L_PHI table for details why.

Data Integrity Checks (automatic list)

	App	Status
Check duplicate patient	CCMDB.accdb	implemented
Query check minimal data set incomplete	CCMDB.accdb	implemented
Function Validate PHIN	CCMDB.accdb	implemented
Function PHIN same as Chart	CCMDB.accdb	implemented
Function Validate Chart	CCMDB.accdb	implemented
Function Validate Province	CCMDB.accdb	implemented
Link suspect dead then alive query	Centralized data front end.accdb	implemented
Link suspect mismatch from ours incomplete query	Centralized data front end.accdb	implemented
Link suspect mismatch to ours incomplete query	Centralized data front end.accdb	implemented
Link suspect negative transit time query	Centralized data front end.accdb	implemented
PL SamePHIN Site Diff chart	Centralized data front end.accdb	implemented
PL SameCHART Site Diff PHIN	Centralized data front end.accdb	implemented
PL Diff Phin SameLN FN DOB	Centralized data front end.accdb	implemented
PL 2Phin Fake or Blank	Centralized data front end.accdb	implemented
PL SamePhin Diff DOB Sex	Centralized data front end.accdb	implemented