Generate Person IDs: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
when and how
Line 21: Line 21:


== Consistency of Person_ID over time ==
== 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: Data Processing]]
[[Category:Multiple Encounter]]
[[Category:Multiple Encounter]]

Revision as of 17:15, 1 April 2015

"Generate Person IDs" is the process by which unique Person IDs are generated in L Person and associated with the ward-admission records in centralized_data.mdb. It also refers to the button "Generate Person IDs" in CFE.

Related to Encounter processing and L Person.

Instructions

At the right point in Centralized data Vetting Process (and only then) press the "Generate Person IDs" button.

algorithm summary

see encounter_processing module Sub Encounter_processor() for most current implementation

for each L_Log entry for which Person_ID is blank and recordstatus is not "incomplete"

  • if a record matching PHIN doesn't exist in L_Person
    • generate record in L_Person (set death to discharge date if deceased)
    • update L_Log.Person_ID to that new record's Person_ID
  • if a record matching PHIN does exist in L_Person
    • if patient is deceased in this L_Log, then confirm death date is not before one we already have in L_Person, don't process record and launch error if so
    • if no inconsistent death data, update last_updated and death in L_Person
    • add Person_ID to L_Log

We don't have process to populate L_Hospitalization worked out yet.

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