Update of D ID to include a laptop identifier: Difference between revisions
Ttenbergen (talk | contribs) m (→Implementation) |
TOstryzniuk (talk | contribs) m (→TISS Scanning) |
||
Line 52: | Line 52: | ||
=== TISS Scanning === | === TISS Scanning === | ||
'''Background:''' | '''Background:''' | ||
* Currently the Unit and Serial on the [[:Category:TISS28 | TISS]] forms uniquely map each form to a patient / [[D_ID]]. To move to the new definition of the identifier we need to find a way to connect TISS to D_ID. One way would be to re-do the form and the [[TISS28 Form Scanning]] process to accommodate the new data natively. We rarely change things in [[Teleform]], so it would be preferable to not mess with that working system. | * Currently the Unit and Serial on the [[:Category:TISS28 | TISS]] forms uniquely map each form to a patient / [[D_ID]]. To move to the '''new definition of the identifier''' we need to find a way to connect TISS to D_ID. One way would be to re-do the form and the [[TISS28 Form Scanning]] process to accommodate the new data natively. We rarely change things in [[Teleform]], so it would be preferable to not mess with that working system. | ||
''' | '''Solution: ''' | ||
* There is a legacy field | * There is a legacy field labeled '''Page''' on the top of the TISS form. It is still being scanned and verified, but we are no longer capturing the data because testing for continuous dates is sufficient. We will re-use this field to capture the laptop identifier instead. | ||
* Pagasa has tested a re-labelled form and the [[Teleform]] scanning, verifying, committing and importing worked. | * Pagasa has tested a re-labelled form and the [[Teleform]] scanning, verifying, committing and importing worked. | ||
* Julie has been consulted about this and thinks this should cause no problems at her end | * Julie has been consulted about this and thinks this should cause no problems at her end | ||
'''Required changes: ''' | '''Required changes: ''' |
Revision as of 19:36, 2020 March 4
This page documents our move to a D_ID that contains a Laptop identifier.
Why do we need to do this?
Our D_IDs consist of the site and location and the Pat ID/Serial number, e.g. HSC_A4-123. They must be unique. If two collectors wanted to enter for the same ward on two different laptops, we would need to make sure that there are no duplicate D_IDs used. Right now we use two methods for this.
- coordinate to not use same Pat ID/Serial numbers
- tedious for collectors; somewhat error prone, but since this will result in an error on sending rather than data corruption it is somewhat low risk
- add "fake" locations with a post-fix to make the D_ID unique that way (eg HSC_H4H_a, HSC_EMIP_a, HSC_IICa, HSC_MICa, HSC_SICa, see Property:Collection Location workload designation, STB Medicine Workload splitting)
- this means we need additional entries in s_dispo table for each laptop/location combination, and analysis of data is somewhat more messy than it needs to be
this still uses the old laptop locations now... will need to clean that up or keep info about it around. |
If/when we move to PatientFollow Project, the first solution would become completely impractical, and we would have to add dozens of fake entries to S dispo table to use the second solution, so we should fix it right instead. Also, with current understaffing, it would be nice to be able to collect another location when convenient to help others out. Finally, the situation of HSC Unknown Service patients leads us to a situation where we may not know for much of a pt's stay which laptop they should go on, so it would be best to collect as we go and be able to edit location to what it needs to be later.
STB Medicine Workload splitting will no longer need to communicate serial numbers.
Implementation
We need to add the Laptop identifier to the beginning of the D_ID.
update sending
We will need to update the send functionality for this. Sending_Patients#What_happens_when_patients_are_sent This requires a change to a lot of queries, so we would want to proof this before rolling it. Probably best to make a test patient on Tina's laptop send before and send after, and then test that Pagasa Query to see if pt us successfully excluded from orphans.
deal w orphans
"Orphans" (Orphans in Centralized data.mdb) are records in CFE that have RecordStatus=Incomplete and a SendDtTm that is earlier than the latest SendDtTm for the sending laptop.
When we go live, there will be orphans because the initially sent record with the no-laptop-D_ID will never be completed. We need to be able to identify and delete these easily so they don't pollute the regular process for Orphans in Centralized data.mdb.
Instructions for Data Processor
Before any other checking in Centralized, run the following. The PHI one needs to be run first since the Log one will eliminate the lookup for the PHI one:
- query 9_D_ID_1_L_PHI_Deleter
- query 9_D_ID_2_L_Log_Deleter
ugly details |
|
CCMDB data updates
There are some currently unused tables that had been added for the PatientFollow Project, they would need to be updated.
Data use - no changes required
Julie has confirmed that we do not parse or otherwise draw meaning from D_ID in ways that would be broken by this change.
TISS Scanning
Background:
- Currently the Unit and Serial on the TISS forms uniquely map each form to a patient / D_ID. To move to the new definition of the identifier we need to find a way to connect TISS to D_ID. One way would be to re-do the form and the TISS28 Form Scanning process to accommodate the new data natively. We rarely change things in Teleform, so it would be preferable to not mess with that working system.
Solution:
- There is a legacy field labeled Page on the top of the TISS form. It is still being scanned and verified, but we are no longer capturing the data because testing for continuous dates is sufficient. We will re-use this field to capture the laptop identifier instead.
- Pagasa has tested a re-labelled form and the Teleform scanning, verifying, committing and importing worked.
- Julie has been consulted about this and thinks this should cause no problems at her end
Required changes:
- TISS28 Collection Guide need to be updated with this.
- TISS28 Form Scanning process needs to be updated
- process itself needs to be updated
- instructions need to be updated
- File:TISS28 Form.pdf + local versions need to be officially updated (this would be a good time to update TISS_Form_(TISS28)#Ordering_copies_from_the_HSC_print_shop as well
- This can happen ASAP even before we change the D_ID
First week in March Julie is away and Vac planning is done, so that would be the time to go live.
DSM Imports
Related articles
Related articles: |