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.

Possibility of adding other Province's PHINs

old discussion, result: not at this time

With Cognos EPR Report we now get PHINs from out of province with province prefix; do we want to start collecting these for out-of-province patients for cleaner matching, and to enable better matching for external users of our data such as MCHP? sure. will this affect any of the query? the data type will become text if you will add the province prefix. --JMojica 19:03, 2020 April 5 (CDT) We could just import the PHIN without the prefix, the fact it's a different province already shows. However, it would have a trickle-down effect of having to fix old pseudo-PHINs, and of having to update code that links patients across admissions, and likely more. So, let's leave it for now. Ttenbergen 09:21, 2020 June 3 (CDT) Cognos EPR Report does not provide data on a given line about where a pt was in a previous hospital. If the pt was a med or CC pt at that previous hospital in the previous 2 weeks, we would have rows for him from the other location. However, because we use PseudoPhins for many pts, I currently use the chart number for matching lines to a same patient, so records from other sites don't show up. Pro: there is no clutter of irrelevant info from other sites; Con: Even if data would be available for pts status at other site, I am hiding it. Starting to collect PHIN for all would help this for OOP pts, but would still not address it for legit-no-PHIN pts.

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 and international students on visas
• some prison inmates

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

International Students

Profiles of international students may or may not have a PHIN. At some point, students have at times been covered[1], then been required to get a specific U of M insurance[2], and as of 2021-07 appear to have some choice of how they insure, although insurance is mandatory [3]archive.

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.

Pagasa just mentioned to me that she used to get many records needing a PseudoPHIN assigned (as many as ~50/day, ~20 average), but lately there are many fewer, e.g. ~5. Can we think of any reason why that would be right? Have some processes external to us changed that would cause this? Or might this be an indicator that we are missing these patients? Ttenbergen 14:41, 2022 March 24 (CDT)

• SMW

• Cargo

• Categories

Multiple PHINs or PHIN changes over time

People may change PHINs over time or have multiple PHINs. This can occur in 3 main ways:

• moving from OOP to MB,
• moving from MB to OOP, and
• a single individual having multiple PHINs (usually somethign went wrong in registration with MB Health)

For the purpose of identifying "same person", and uniformity, we will enter the current/most PHIN or PseudoPHIN into the PHIN field of all encounters of that patient in our database. Earlier PHINs or PseudoPHINs will be retained in Alias ID collection. This may mean that we change an existing PHIN to a PseudoPHIN. This may trigger some errors in our cross checks; if so, appropriate records will be added to the L_Problem table so the error goes away.

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