Update of D ID exclude service/location: Difference between revisions
Ttenbergen (talk | contribs) |
Ttenbergen (talk | contribs) mNo edit summary |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
This page documents | This page documents a proposed but abandoned move to a [[D_ID]] that no longer contains the [[Service/Location]]. | ||
{{LegacyContent | |||
|explanation= The reasons to do this are no longer valid. | |||
|content= | |||
== Background == | == 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 Location]]s 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 [[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]]. | |||
=== 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]]. | 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_ID]]s 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_ID]]s per [[Laptop identifier]]. | [[Pat_ID]]s 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_ID]]s per [[Laptop identifier]]. | ||
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]]. | ||
== Implementation == | == Implementation == | ||
| Line 20: | Line 29: | ||
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. | 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 | * created Function make_D_ID | ||
* to do: | ** '''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. | * 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 === | === Data use - no changes required === | ||
| Line 37: | Line 47: | ||
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. | 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 == | ||
{{Related Articles}} | {{Related Articles}} | ||
}} | |||
Latest revision as of 20:39, 2022 February 17
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.
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: |