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

From CCMDB Wiki
Jump to navigation Jump to search
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]]
}}

Revision as of 14:10, 2021 March 18

This page documents our 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
  • 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.

  • can someone else think of how this might not work out right?
  • SMW


  • Cargo


  • Categories

Related articles

Related articles:
Retrieved from "https://ccmdb.kuality.ca/index.php?title=Update_of_D_ID_exclude_service/location&oldid=149549"