Update of D ID exclude service/location
This page documents a proposed but abandoned move to a D_ID that no longer contains the Service/Location.
Legacy Content
This page contains Legacy Content.
- Explanation: The reasons to do this are no longer valid.
- Successor: No successor was entered
Click Expand to show legacy content.
Contents
Background
Rationale for doing this
At some point, including the Service/Location in D_ID was the biggest cause of Orphans in Centralized data.mdb, and required special processes such as Changing D IDs. With everyone now entering fewer profiles and fewer Service Locations due to PatientFollow Project, there should be much fewer problems caused by this, so this change is likely not worth the effort.
Rationale for not doing this
This would be a fairly troublesome change for sending.
Also, if there is an outstanding request, changing the Service/Location can break the connection to the returned data when it is imported.
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.
Some steps required:
- 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
- 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:
- 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.
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: |