Person ID field: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
Line 11: Line 11:
}}
}}


See [[Generate Person IDs]] and [[Correcting Person IDs]] for how Person_IDs are generated and maintained. A new line is generated in [[L_Person table]], and the Person_ID is assigned to [[Centralized data.mdb]].[[L_Log table]].Person_ID .
See [[Generate Person IDs]] for how Person_IDs are generated and maintained. A new line is generated in [[L_Person table]], and the Person_ID is assigned to [[Centralized data.mdb]].[[L_Log table]].Person_ID .


For the most part, Person_ID is permanently stored and therefore remains the same for new encounters of that patient in [[L_Log table]]/[[L_Person table]].  
For the most part, Person_ID is permanently stored and therefore remains the same for new encounters of that patient in [[L_Log table]]/[[L_Person table]].  
Line 18: Line 18:


== Consistency of Person_ID over time ==
== Consistency of Person_ID over time ==
'''If a record in [[L Person table]] were ever deleted and recreated it would NEVER receive the same Person_ID next time around'''. See [[Generate Person IDs]] and [[Correcting Person IDs]] for how Person_IDs are generated and updated for more info on scenarios that might cause a Person_ID to change.
'''If a record in [[L Person table]] were ever deleted and recreated it would ''never'' receive the same Person_ID next time around'''. However, a new, re-generated Person ID would still link all records for that patient. See [[Generate Person IDs#Algorithm summary]] for details.  
 
Once generated the [[Person_ID]] for new entries with same PHIN would be the same for new encounters.  
 
If data becomes inconsistent the old data in [[L Person table]] will be '''deleted''' and the records will be treated as if newly encountered patients. Some scenarios that might cause this are:
* for some reason two [[Person_ID]]s for same PHIN
* [[L_Person table]]  entry without corresponding [[L_Log table]] entry


=== Implication for data we have provided ===
=== Implication for data we have provided ===

Latest revision as of 16:11, 2019 March 20

Data Element (edit)
Field Name: Person_ID
CCMDB Label: N/A
CCMDB tab: not stated
Table: L Log table, L Person table
Data type: number
Length: long integer
Program: Med and CC
Created/Raw: Created
Start Date: 1988-07-11
End Date: 2300-01-01
Sort Index: 1

Unique random number id per patient that combines the D_IDs across admissions/encounters.

  • SMW

Legacy implementation right in the table

  • Cargo


  • Categories
  • Forms


See Generate Person IDs for how Person_IDs are generated and maintained. A new line is generated in L_Person table, and the Person_ID is assigned to Centralized data.mdb.L_Log table.Person_ID .

For the most part, Person_ID is permanently stored and therefore remains the same for new encounters of that patient in L_Log table/L_Person table.

As of 2019-02-06, Person_ID doesn't show in any form in CFE.

Consistency of Person_ID over time

If a record in L Person table were ever deleted and recreated it would never receive the same Person_ID next time around. However, a new, re-generated Person ID would still link all records for that patient. See Generate Person IDs#Algorithm summary for details.

Implication for data we have provided

Main office discussed that the Person ID might change over time if a PHIN changes as per PHIN_field#Multiple_PHINs_or_PHIN_changes_over_time. Julie is aware of this and will include this in any considerations about ongoing data she provides.

Related articles

Related articles: