ClientGUID field
Data Element (edit) | |
Field Name: | ClientGUID |
CCMDB Label: | not stated |
CCMDB tab: | not stated |
Table: | Cognos_import3 table |
Data type: | string |
Length: | 16 |
Program: | Med and CC |
Created/Raw: | Raw |
Start Date: | 1988-07-11 |
End Date: | 2300-01-01 |
Sort Index: | |
Data Dependencies(Reports/Indicators/Data Elements): | No results |
The unique person identifier from Cognos.
Many patients don't have MB PHINs so we generate PseudoPHINs. I figured EPR must already solve this problem, and they use this field. We now get this as part of the Cognos data dump. If we set up the infrastructure to actually put this into patient records then we might be able to step away from the PseudoPhin process, and should have many fewer link errors.
![]() |
|
Implementation
This would likely replace Person ID field; Generate Person IDs would still need to be done to enter this into L_Person table.
![]() |
_ccmdb_data_dev, _ccmdb_dev
|
|
![]() |
|
Data Processing improvements
Having this field should further cut down on Pre-linking checks, or at least on how many problems those find.
![]() |
|
Backfilling
I started discussion with DSS that we would like to eventually back-fill this data. So, for any MRN where we don't have a ClientGUID we would ask for it to be provided. Chances are ancient records won't have a ClientGUID; we could fill in our PHIN/PseudoPHIN for those.
Log
- 2022-03-24 - added field to Cognos_import3 table in CCMDB.accdb so the import can still work.