Update of D ID exclude service/location: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
Line 24: Line 24:
* to do:  
* to do:  
** integrate it into the send functions
** integrate it into the send functions
* 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.
}}
}}



Revision as of 16:22, 2020 August 13

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

Background

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.

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.

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
  • to do:
    • integrate it into the send functions


  • 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: