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.

• SMW

Legacy implementation right in the table

• Cargo

• Categories

• Forms

This page is about the ClientGUID field which identifies people, not the ClientVisitGUID which identifies admissions.

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) We still add records manually for our IICU admissions Lisa Kaita 07:58, 2022 April 28 (CDT)

• SMW

• Cargo

• Categories

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) With this extra info, do you think this could replace the Person ID field so Pagasa would no longer need to generate those? Ttenbergen 11:12, 2022 April 7 (CDT) Discussed with Julie, and she agreed that this looks like. We'd keep PersonID in the short term until we feel comfortable with this. We may also keep this for the early years pre GUID. Ttenbergen 15:47, 2022 April 13 (CDT)

added: 2022-04-13 action: 2022-04-13

• Cargo

• Categories

ask Chastity what happens to John Doe's for ClientGUID

added: 2022-04-13 action: 2022-04-13

• Cargo

• Categories

Implementation

This would likely replace Person ID field; Generate Person IDs would still need to be done to enter this into L_Person table.

_dev_ccmdb_data, _dev_ccmdb 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 remove the L_Person table - we don't use it and this further means we don't need/use it. as confirmed with Julie here.

added: 2022-03-24 action: 2022-03-24

• Cargo

• Categories

Data Processing improvements

Having this field might further cut down on Pre-linking checks, or at least on how many problems those find.

Pagasa confirmed that we already see very few pre-linking checks that are actual errors, and that those are usually from PL_SamePHIN_Site_Diff_chart now: "I have few errors common for HSC assigned a temporary chart which starts to 300 number but patient had already old chart number, another scenario old chart number but single admission nothing to compare with then have a current admission which is the correct one. "

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.

Changing D_IDs

Changing D_IDs