Update of D ID exclude service/location: Difference between revisions
Ttenbergen (talk | contribs) mNo edit summary |
Ttenbergen (talk | contribs) m (→update sending) |
||
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.
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: |