PHIN field: Difference between revisions
Ttenbergen (talk | contribs) mNo edit summary |
Ttenbergen (talk | contribs) |
||
| Line 40: | Line 40: | ||
=== Patient changes PHIN over time === | === 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.''' | |||
{{DiscussTask | | {{DiscussTask | | ||
* 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. | * 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. | ||
| Line 48: | Line 57: | ||
{{DT | In all three cases, newest and most current is stored in PHIN and old would go into ALIAS field. }} | {{DT | In all three cases, newest and most current is stored in PHIN and old would go into ALIAS field. }} | ||
<!-- as per Task Team Meeting - Rolling Agenda and Minutes 2019#ICU Database Task Group Meeting – February 25, 2019 --> | |||
=== Changing PHINs === | === Changing PHINs === | ||
Revision as of 15:28, 2019 March 9
| 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 .
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
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.
|
|
|
In all three cases, newest and most current is stored in PHIN and old would go into ALIAS field. |
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 |