ClientGUID field: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
← Older edit
PTorres (talk | contribs)
CCMDB_legit, approved
1,548 edits
 
(35 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Data element
{{Data element
|field_name=ClientGUID
|field_name=ClientGUID
|Rank=N/A
|in_table=L_Log table
|in_table=Cognos_import3 table
|data_type=string
|data_type=string
|datafield_length=16
|datafield_length=16
|program_collecting=Med and CC
|program_collecting=Med and CC
|created_raw=Raw
|created_raw=Raw
|data_element_sort_index=
|data_element_start_date=2022-08-29
|element_description=The unique person identifier from [[Cognos]].  
|data_element_sort_index=1.5
|element_description=The unique person identifier from [[Cognos]].
|Rank=N/A
}}
}}
This page is about the {{PAGENAME}} which identifies people, not the [[ClientVisitGUID field]] which identifies admissions.
=== Background ===
Many patients don't have MB [[PHIN]]s so we generate [[PseudoPHIN]]s. EPR solves this by using a field ClientGUID, which we get as part of the [[Cognos EPR Report]]. 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.
* The Client GUID is not visible in EPR
=== Concerns ===
==== Inconsistent with Person_ID ====
Review of [[ClientGUID field]] and [[Person ID field]] showed that the data in {{PAGENAME}} is inconsistent. There are files with same Person_ID and different ClientGUID and vice versa. I have sent an excel to Julie, Pagasa and Lisa with details. For now, I would treat this data as absolutely suspect and we shouldn't use it.
{{Discuss|
* Lisa, any idea why this might be happening from a collection perspective? Is the problem in what we receive the right info from Cognos, or is there an issue in the collection process that makes this happen? [[User:Ttenbergen|Ttenbergen]] 09:52, 2024 December 5 (CST)
* Julie, do we need to flag anywhere further that this data is suspect? [[User:Ttenbergen|Ttenbergen]] 09:52, 2024 December 5 (CST)
}}


Many patients don't have MB [[PHIN]]s so we generate [[PseudoPHIN]]s. 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.
==== Data that is entered without a ClientGUID ====
* Could be a problem:
** Manual entry if we miss an admission and this is identified later past the 28 day of data in COGNOS


{{DiscussTask |
** [[Definition_of_a_Medicine_Laptop_Admission#Excluded_service_admissions_can_lead_to_missed_records]]
* 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. [[User:Ttenbergen|Ttenbergen]] 09:20, 2022 March 24 (CDT)
* Not a problem:
** 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.  --[[User:JMojica|JMojica]] 10:20, 2022 March 24 (CDT)  
** '''IICU:''' we use COGNOS now to enter all IICU admissions so it will be entered with ClientGUID automatically
*** I think you mean field Client'''Visit'''GUID. 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. [[User:Ttenbergen|Ttenbergen]] 12:10, 2022 March 24 (CDT) }}
 
==== Merged records ([[John or Jane Doe patient]] who get identified, and other corrections) ====
Chastity confirmed there is a merge process for J Does who get identified. Confirming how this works, emailed Chastity 2022-06-16.  
{{Todo
  | who = Tina
| todo_added = 2022-04-13
| todo_action = 2022-06-30
| question =  
* Chastity confirmed there is a merge process for J Does who get identified. Confirming how this works, emailed Chastity 2022-06-16.  
* Asked Chastity if 3 month updates will be possible.
}}


== Implementation ==
== Implementation ==
This would likely replace [[Person ID field]]; [[Generate Person IDs]] would still need to be done to enter this into [[L_Person table]].  
This would likely replace [[Person ID field]] eventually, but we'd keep it until tested; [[Generate Person IDs]] would still need to be done to enter this into [[L_Person table]].  


{{Todo  
{{Todo  
  | who = Tina   
  | who = Tina   
  | todo_added = 2022-03-24   
  | todo_added = 2022-03-24   
  | todo_action = 2022-03-24
  | todo_action = 2022-09-25
  | question = _ccmdb_data_dev, _ccmdb_dev
  | question = _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
* 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.
 
}}
{{Discuss |
* 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. [[User:Ttenbergen|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.--[[User:JMojica|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. [[User:Ttenbergen|Ttenbergen]] 12:10, 2022 March 24 (CDT)}}


=== Data Processing improvements ===
=== Data Processing improvements ===
Having this field should further cut down on [[Pre-linking checks]], or at least on how many problems those find.  
Having this field might further cut down on [[Pre-linking checks]], or at least on how many problems those find. Or it might add to them, since merges could be messy.
{{discuss | who = Pagasa | question =
* Do you still see many errors in the [[Pre-linking checks]] now that we get our data from Cognos? [[User:Ttenbergen|Ttenbergen]] 09:49, 2022 March 24 (CDT)
}}
* 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


[[User:PTorres|PTorres]] 14:08, 2022 March 24 (CDT)
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 ===
=== 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.  
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.  
 
Ancient records won't have a ClientGUID; Chastity doesn't know what method they used to generate the ID so we can't use it to recreate these. We can insert our PHIN/PseudoPHIN for those, but would need to have a cross check method to capture and update if a same PHIN ever comes in new with a ClientGUID.


=== Log ===
=== Log ===
* 2022-08-25 - added code to start sending this field to [[Centralized data.mdb]]
* 2022-08-04 - added field to [[Ccmdb data.mdb]]
* 2022-03-24 - added field to [[Cognos_import3 table]] in CCMDB.accdb so the import can still work.
* 2022-03-24 - added field to [[Cognos_import3 table]] in CCMDB.accdb so the import can still work.


Latest revision as of 09:52, 5 December 2024

Data Element (edit)
Field Name: ClientGUID
CCMDB Label: not stated
CCMDB tab: not stated
Table: L_Log table
Data type: string
Length: 16
Program: Med and CC
Created/Raw: Raw
Start Date: 2022-08-29
End Date: 2300-01-01
Sort Index: 1.5

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 field which identifies admissions.

Background

Many patients don't have MB PHINs so we generate PseudoPHINs. EPR solves this by using a field ClientGUID, which we get as part of the Cognos EPR Report. 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.

  • The Client GUID is not visible in EPR

Concerns

Inconsistent with Person_ID

Review of ClientGUID field and Person ID field showed that the data in ClientGUID field is inconsistent. There are files with same Person_ID and different ClientGUID and vice versa. I have sent an excel to Julie, Pagasa and Lisa with details. For now, I would treat this data as absolutely suspect and we shouldn't use it.

  • Lisa, any idea why this might be happening from a collection perspective? Is the problem in what we receive the right info from Cognos, or is there an issue in the collection process that makes this happen? Ttenbergen 09:52, 2024 December 5 (CST)
  • Julie, do we need to flag anywhere further that this data is suspect? Ttenbergen 09:52, 2024 December 5 (CST)
  • SMW


  • Cargo


  • Categories

Data that is entered without a ClientGUID

  • Could be a problem:
    • Manual entry if we miss an admission and this is identified later past the 28 day of data in COGNOS

Merged records (John or Jane Doe patient who get identified, and other corrections)

Chastity confirmed there is a merge process for J Does who get identified. Confirming how this works, emailed Chastity 2022-06-16.

  • Chastity confirmed there is a merge process for J Does who get identified. Confirming how this works, emailed Chastity 2022-06-16.
  • Asked Chastity if 3 month updates will be possible.
  • added: 2022-04-13
  • action: 2022-06-30
  • Cargo


  • Categories

Implementation

This would likely replace Person ID field eventually, but we'd keep it until tested; Generate Person IDs would still need to be done to enter this into L_Person table.

_dev_ccmdb

  • 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-09-25
  • 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. Or it might add to them, since merges could be messy.

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.

Ancient records won't have a ClientGUID; Chastity doesn't know what method they used to generate the ID so we can't use it to recreate these. We can insert our PHIN/PseudoPHIN for those, but would need to have a cross check method to capture and update if a same PHIN ever comes in new with a ClientGUID.

Log

Changing D_IDs

Changing D_IDs

Related Articles

Related articles:
Retrieved from "https://ccmdb.kuality.ca/index.php?title=ClientGUID_field&oldid=162169"