Person ID field: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 22: Line 22:
Once generated the [[Person_ID]] for new entries with same PHIN would be the same for new encounters.  
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.  
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


{{Discuss | who = Julie | question =  
=== Implication for data we have provided ===
* 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? }}
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 ==

Revision as of 16:01, 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 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 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:

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: