Update of D ID to include a laptop identifier

From CCMDB Wiki
Revision as of 10:49, 2020 June 5 by Ttenbergen (talk | contribs) (Text replacement - "STB Medicine Workload splitting" to "STB Medicine workload splitting")
Jump to navigation Jump to search

This page documents our move to a D_ID that contains a Laptop identifier.

Why did we need to do this?

Our D_IDs consisted 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. Before this change we used two methods for this:

this still uses the old laptop locations now... will need to clean that up or keep info about it around.

  • added: no added date
  • action: no action date
  • Cargo


  • Categories

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 would 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 have updated the send functionality for this.

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

The following needs to be done after each sending window until the transition to the new sending is complete on all laptops.

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   
  • query 9_D_ID_change__int_finder gives the earliest-sent record of a set of records with same Pat_ID and same Service/Location but different D_ID
  • query 9_D_ID_change__int provides the D_IDs for the records found in query 1_D_ID_change__int_finder (necessary because it's an aggregate query that can't list non-aggregated fields)
  • query 9_D_ID_1_L_PHI_Deleter - deletes all records in L Log table that correspond to a line in query 1_D_ID_change__int - needs to be run before the next query since that query will eliminate the info what to delete
  • query 9_D_ID_2_L_Log_Deleter - deletes all records in L Log table that correspond to a line in query 1_D_ID_change__int

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.

TISS28

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 the Page 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

Transition from old to new

Re-linking previously scanned TISS forms to the new D_ID
  • TISS forms and Items that were scanned pre - ident_D_ID will need to have their ident added
  • We will need a 9_ query for Pagasa for this so it can be done before the other 9_ queries delete the old records
Scanning forms while mix of old and new
  • There will be a period where we have TISS forms coming in for both old records that were completed before laptop identifier was part of the D_ID, and some after.
  • Is there a way to process them that would not require manual sorting of the forms? EG an either-or match in the importer? Or will we need to pre-sort the forms and treat them separately?
  • All ICU laptops use Service/Location that translate directly into their Laptop identifier, e.g. HSC_ICUa -> H9; so, a translate list could generate potential new D_IDs
  • Process, then:
    1. update each D_ID that doesn't show up in L_Log to <ident>_D_ID

DSM Imports

Will this change cause issues with DSM imports? Only if there DSM data has been requested with records that are subject to this change. Do we have any outstanding DSM request right now? Emailed Pagasa/Trish/Julie.

  • added: no added date
  • action: no action date
  • Cargo


  • Categories

Related articles

Related articles: