Update of D ID exclude service/location

From CCMDB Wiki
Jump to navigation Jump to search

This page documents our move to a D_ID that no longer contains the Service/Location.

Background

Rationale for doing this

Including the Service/Location in D_ID is the biggest cause of Orphans in Centralized data.mdb, and requires special processes such as Changing D IDs. So, we will remove this field from generating the D_ID.

Also, if there is an outstanding request, changing the Service/Location can break the connection to the returned data when it is imported.

Rationale for not doing this

This would be a fairly troublesome change for sending. With everyone now entering fewer profiles and fewer Service Locations due to PatientFollow Project, there should be much fewer problems caused by this. So we should review if this is still a thing we want to do right now. I will consider this on hold unless someone tells me we should still do it. Ttenbergen 11:22, 2020 December 3 (CST)

  • SMW


  • Cargo


  • Categories

Considerations that it is possible to do this

When we first set up D_ID it consisted of the Pat_ID and the Service/Location. For reasons explained in Update of D ID to include a laptop identifier#Background we added the Laptop identifier to the D_ID. The D_ID now consists of three components: Laptop identifier, Service/Location and Pat_ID.

Pat_IDs used to be inconsistently unique per Service/Location or per Laptop identifier, but as part of Facilitated Management of Serial numbers we unified this to use a single pool of Pat_IDs per Laptop identifier.

As a result, it turns out that Laptop identifier and Pat_ID are now sufficient to guarantee a unique D_ID.

Implementation

We need to remove the Service/Location from the D_ID in Sending.

update sending

We have updated the send functionality for this.

We will either need to make the change contingent on start_date field or there will be Orphans in Centralized data.mdb to clean up.


  • created Function make_D_ID
    • Problem: If I use a function for this, then the way the delete queries work breaks with a non-specific #Error if a record has been deleted; Possible solutions:
      • Save D_ID locally already rather than only generating it on sending
      • there might' be another way to re-write the query so it doesn't break
  • To do:
    • Make sure that PHI sending and importing will work
    • make sure that TISS scanning and importing will work
  • I plan to have this function just generate the old style D_ID for now, and integrate it into all the sending spots. Then we can decide the start dttm after which we want to use the new format, and I just set that as a parameter in the function.
  • SMW


  • Cargo


  • Categories

Data use - no changes required

Julie had confirmed for Update of D ID to include a laptop identifier that we do not parse or otherwise draw meaning from D_ID in ways that would be broken by this change.

TISS28

Since we are only removing a field, no changes to collection process will be required.

The Tiss import process will need to be updated to use the new D_ID format based on start_date field. If this is done successfully, I think no further process change would be necessary.

  • can someone else think of how this might not work out right?
  • SMW


  • Cargo


  • Categories

Related articles

Related articles:
Retrieved from "https://ccmdb.kuality.ca/index.php?title=Update_of_D_ID_exclude_service/location&oldid=147867"