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

mNo edit summary
Really not something we need to do now that we use PatientFollow and there are much fewer changes to Service_Location
Line 1: Line 1:
This page documents our move to a [[D_ID]] that no longer contains the [[Service/Location]].  
This page documents our 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 ===
=== Rationale for doing this ===
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.
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]].
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]].
==== Rationale for ''not'' doing this ====
{{Discuss |
This would be a fairly troublesome change for sending. 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 we should review if this is still a thing we want to do right now. I  will consider this on hold unless someone tells me we should still do it. [[User:Ttenbergen|Ttenbergen]] 11:22, 2020 December 3 (CST)
}}


=== Considerations that it is possible to do this ===
=== Considerations that it is possible to do this ===
Line 27: 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.  


{{DT |
Some steps required:
* created Function make_D_ID
* 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:  
** '''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:  
Line 37: Line 39:


* 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 53: Line 53:
{{Related Articles}}
{{Related Articles}}


[[Category:IT Instructions]]
}}