ClientGUID field: Difference between revisions
Jump to navigation
Jump to search
Ttenbergen (talk | contribs) mNo edit summary |
No edit summary |
||
| (23 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Data element | {{Data element | ||
|field_name=ClientGUID | |field_name=ClientGUID | ||
|in_table=L_Log table | |||
|in_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. | |||
Many patients don't have MB [[PHIN]]s so we generate [[PseudoPHIN]]s. | * The Client GUID is not visible in EPR | ||
=== Concerns === | |||
==== 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 | |||
** [[Definition_of_a_Medicine_Laptop_Admission#Excluded_service_admissions_can_lead_to_missed_records]] | |||
* | * Not a problem: | ||
* | ** '''IICU:''' we use COGNOS now to enter all IICU admissions so it will be entered with ClientGUID automatically | ||
** | |||
==== 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 | {{Todo | ||
| who = Tina | | who = Tina | ||
| todo_added = 2022-04-13 | | todo_added = 2022-04-13 | ||
| todo_action = 2022- | | todo_action = 2022-06-30 | ||
| question = | | 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- | | todo_action = 2022-09-25 | ||
| question = | | question = _dev_ccmdb | ||
* 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. | * 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. | ||
| Line 57: | Line 49: | ||
=== Data Processing improvements === | === Data Processing improvements === | ||
Having this field might 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. | ||
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. ''" | 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. | 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 11:21, 2024 March 12
| 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.
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
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
- Not a problem:
- IICU: we use COGNOS now to enter all IICU admissions so it will be entered with ClientGUID automatically
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.
|
|
|
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
|
|
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
- 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.