| 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:
|
|
The unique person identifier from Cognos.
Legacy implementation right in the table
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.
|
- Do all collectors now add records from Cognos only or do some still do manual entry? Manual entry would break any processes we change to use this. Ttenbergen 09:20, 2022 March 24 (CDT)
- ClientGUID is defined as unique identifier of the visit, seems to be used as prefix by later fields ending in *Chg - is that the same as unique person (PHIN and Pseudo PHIN) or it is only unique by visit per site? For NON-MB, you still need to run Person_ID, correct? what will be the gain having the clientGUID, is there a running time advantage? I am using Person_ID instead of PHIN/PseudoPHIN as unique patient identifier when providing individual patient data and when linking admissions - I need to be assured that the ClientGUID is really unique by patient. --JMojica 10:20, 2022 March 24 (CDT)
- I think you mean field ClientVisitGUID. This is a new field and it actually identifies the patient, regardless of which province etc. The Non-MB issue is exactly what this field would solve. So, yes, unique by pt. Ttenbergen 12:10, 2022 March 24 (CDT)
|
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
- add this field to L_Log table in CCMDB_data and Centralized_Data
- add code so it's entered on patient generation
- add the field to sending
- review linking and related processes to see what could change to make best use of this
|
- added: 2022-03-24
- action: 2022-03-24
|
|
- Do we even still need the L_Person table if we have this field? It contains last updated and death. Since we never got hospital deaths, we probably don't use that field. And I doubt we use the last-updated field - and in any case, it could easily be recreated from data, no need to store it. Unless of course we want to use it so we can streamline the re-checking and re-indexing of data somehow. Ttenbergen 09:28, 2022 March 24 (CDT)
- I haven't used this table L_Person table and not aware of its purpose. Is it intended to know quickly how many unique patients there are in the database? but without any other relevant data, not useful at all.--JMojica 10:20, 2022 March 24 (CDT)
- Agreed, not much use, it was added when we thought we would get Hospital Death in the near future. It is also used to contain the PersonID to make sure it's unique, but it really doesn't do a great job with it for now. I just wanted to be sure you are not using it for anything before possibly making big changes to it. Ttenbergen 12:10, 2022 March 24 (CDT)
|
Data Processing improvements
Having this field should further cut down on Pre-linking checks, or at least on how many problems those find.
- No even the assigning of Pseudo Phin.
- Only this query PL_SamePHIN_Site_Diff_chart common for HSC assigned a temporary chart which starts to 300 number but patient had already old chart number, but not many as well
- Most of Pre-linking checks are only few errors
PTorres 14:08, 2022 March 24 (CDT)
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
Changing D_IDs
Changing D_IDs
Related Articles
