Person ID field: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 15: Line 15:
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]].  


'''If an L_Person record 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 Patient_ID to change.  
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'''. 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.  
 
Once generated the [[Person_ID]] for new entries with same PHIN would be the same for new encounters.
 
If data becomes inconsistent (eg for some reason two [[Person_ID]]s for same PHIN, [[L_Person table]]  entry without corresponding [[L_Log table]] entry, [[L_Log table|L_Log]].[[Person_ID]] without corresponding [[L_Person table]] entry) the old data in [[L Person table]] will be '''deleted''' and the records will be treated as if newly encountered patients.
 
{{Discuss | who = Julie | question =
* When we initially discussed this it seemed that this possible change over time would be OK, but when we talked about this 2018 November 7 it seemed like this might not be OK after all, and that we have handed out this data as if this number never changes. How do we need to change this process so it works with how you give out data? }}


== Related articles ==
== Related articles ==

Revision as of 23:53, 2019 February 6

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 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 .

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. 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.

Once generated the Person_ID for new entries with same PHIN would be the same for new encounters.

If data becomes inconsistent (eg for some reason two Person_IDs for same PHIN, L_Person table entry without corresponding L_Log table entry, L_Log.Person_ID without corresponding L_Person table entry) the old data in L Person table will be deleted and the records will be treated as if newly encountered patients.

  • When we initially discussed this it seemed that this possible change over time would be OK, but when we talked about this 2018 November 7 it seemed like this might not be OK after all, and that we have handed out this data as if this number never changes. How do we need to change this process so it works with how you give out data?
  • SMW


  • Cargo


  • Categories

Related articles

Related articles: