Update of D ID exclude service/location: Difference between revisions
Ttenbergen (talk | contribs) m (→Implementation) |
Ttenbergen (talk | contribs) m (→Background) |
||
Line 8: | Line 8: | ||
As a result, it turns out that [[Laptop identifier]] and [[Pat_ID]] are now sufficient to guarantee a unique [[D_ID]]. | 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. | 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 [[Instructions for requesting a batch of data from DSM | request]], changing the [[Service/Location]] can break the connection to the returned data when it is [[Instructions for importing a batch of DSM Data |imported]]. | |||
== Implementation == | == Implementation == |
Revision as of 14:27, 2020 July 24
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.
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.
Related articles
Related articles: |