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

(8 intermediate revisions by the same user not shown)

Line 1:

This page documents ~~our~~ move to a [[D_ID]] that no longer contains the [[Service/Location]].

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 ==

=== Rationale for doing this ===

At some point, including the [[Service/Location]] in [[D_ID]] was the biggest cause of [[Orphans in Centralized_data.accdb]], 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]].

[[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]].

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 ==

Line 18:

Line 27:

We have updated the [[Sending_Patients#What_happens_when_patients_are_sent|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.

We will either need to make the change contingent on start_date field or there will be [[Orphans in Centralized_data.accdb]]to clean up.

~~{{DT |~~

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:

Line 30:

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.

}}

=== Data use - no changes required ===

Line 40:

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.

~~{{Discuss|~~

* can someone else think of how this might not work out right? }}

== Related articles ==

~~[[Category:IT Instructions]]~~

}}

@@ Line 1: / Line 1: @@
-This page documents our move to a [[D_ID]] that no longer contains the [[Service/Location]].
+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 ==
+=== Rationale for doing this ===
+At some point, including the [[Service/Location]] in [[D_ID]] was the biggest cause of [[Orphans in Centralized_data.accdb]], 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]].
 [[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]].
-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 ==
@@ Line 18: / Line 27: @@
 We have updated the [[Sending_Patients#What_happens_when_patients_are_sent|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.
+We will either need to make the change contingent on start_date field or there will be [[Orphans in Centralized_data.accdb]]to clean up.
-{{DT |
+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:
@@ Line 30: / 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.
-}}
 === Data use - no changes required ===
@@ Line 40: / 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.
-{{Discuss|
-* can someone else think of how this might not work out right? }}
 == Related articles ==
 {{Related Articles}}
-[[Category:IT Instructions]]
+}}