Generate Person IDs: Difference between revisions

Line 21:

== Consistency of Person_ID over time ==

Once generated the Person_ID for new entries with same PHIN would be the same for new encounters~~. If an L_Person entry were deleted, '''our current process would not catch this''' because it finds new entries by checking the L_Log.patient_ID field, which would still have content in this case~~.

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

~~Even~~ if ~~it did~~,

If data becomes inconsistent (eg for some reason two person_ids for same PHIN, L_Person entry without corresponding L_Log entry, L_Log.Person_ID without correspoinding L_Person entry) the old data will be cleaned out and the records will be treated as if newly encountered patients.

Tina discussed with Julie that this will affect previously given out data, and we will address by giving out fresh data as a set including the old where linking is necessary. 17:15, 2015 April 1 (CDT)

~~would be generate that would NOT have the same Person_ID. IE, '''this is not a hash, the Person_ID is not a function of PHIN.'''~~

It would be permanently stored and therefore remain the same for new encounters of that patient in L_Log/L_PHI, but if an L_Person record were ever deleted and recreated it would NOT receive the same ID next time around.

[[Category: Data Processing]]

[[Category:Multiple Encounter]]

@@ Line 21: / Line 21: @@
 == Consistency of Person_ID over time ==
-Once generated the Person_ID for new entries with same PHIN would be the same for new encounters. If an L_Person entry were deleted, '''our current process would not catch this''' because it finds new entries by checking the L_Log.patient_ID field, which would still have content in this case.
+Once generated the Person_ID for new entries with same PHIN would be the same for new encounters.
-Even if it did,
+If data becomes inconsistent (eg for some reason two person_ids for same PHIN, L_Person entry without corresponding L_Log entry, L_Log.Person_ID without correspoinding L_Person entry) the old data will be cleaned out and the records will be treated as if newly encountered patients.
+Tina discussed with Julie that this will affect previously given out data, and we will address by giving out fresh data as a set including the old where linking is necessary. 17:15, 2015 April 1 (CDT)
-would be generate that would NOT have the same Person_ID. IE, '''this is not a hash, the Person_ID is not a function of PHIN.'''
-It would be permanently stored and therefore remain the same for new encounters of that patient in L_Log/L_PHI, but if an L_Person record were ever deleted and recreated it would NOT receive the same ID next time around.
 [[Category: Data Processing]]
 [[Category:Multiple Encounter]]