Populate linking pairs: Difference between revisions
Ttenbergen (talk | contribs) m (→Algorithm) |
Ttenbergen (talk | contribs) m (→Algorithm) |
||
Line 35: | Line 35: | ||
* delete any non-consecutive records | * delete any non-consecutive records | ||
* add any new records | * add any new records | ||
{{Todo | |||
| who = Tina | |||
| todo_added = 2021-08-03 | |||
| todo_action = 2021-08-03 | |||
| question = I still need to document the new process properly, e.g. [[Query linking_pairs_preList]], [[Query linking_pairs_LatestLinkedPHINAdmit]] | |||
[[Query linking_pairs_multis]] | |||
[[Query linking_pairs_out_of_sequence/linking_pairs_out_of_sequence_deleter]] | |||
[[Query linking_pairs_unlinkeds]] | |||
}} | |||
{{Collapsable | {{Collapsable | ||
Line 47: | Line 58: | ||
Run the populate linking code, but run it only for profiles that aren't in pairs | Run the populate linking code, but run it only for profiles that aren't in pairs | ||
* run the linking pairs updater only for profiles that don't have | * run the linking pairs updater only for profiles that don't have | ||
Second draft. | Second draft. | ||
* Find every D_ID not in [[Linking pairs table]], and delete all other/existing records from [[Linking pairs table]] for that PHIN | * Find every D_ID not in [[Linking pairs table]], and delete all other/existing records from [[Linking pairs table]] for that PHIN |
Revision as of 22:29, 2021 August 3
As part of vetting CFE needs to pair up any records for the consecutive/continuous admission of a patient.
Instructions
- be sure you have completed Pre-linking checks
- click the "populate linking_pairs" button on the main screen
- 2019-Feb-07: NOTE: takes ~08 minutes to run
- After this is done, move on to Correcting suspect links
Implementation
Because MS Access doesn't have functionality to compare data in a "current" to a "next" record this is implemented as an iterative process in Module linking Sub populate_linking_pairs which populates the linking_pairs table.
The process considers the output of Query linking_pairs_preList.
For any line that has the same PHIN as the previous line it generates a record in linking_pairs table of the two D_IDs.
2021-07 review
The iterating is the slow part, so how can we reduce it; eg by shifting some of the work into queries
Scenarios
Two things will make a record require a pairs update:
- a new record is added (the >95% case)
- an older record(s) is changed, requiring a re-alignment (the <2% case)
- a collector catches up with backlog, and 2 records that had already been linked 1-3 need to be re-linked to 1-2-3 (the 3% case)
Algorithm
- add any new records as if all was good
- delete any non-consecutive records
- add any new records
I still need to document the new process properly, e.g. Query linking_pairs_preList, Query linking_pairs_LatestLinkedPHINAdmit Query linking_pairs_multis Query linking_pairs_out_of_sequence/linking_pairs_out_of_sequence_deleter Query linking_pairs_unlinkeds |
|
previous thoughts |
Clean our only those pairs that are questionable:
Run the populate linking code, but run it only for profiles that aren't in pairs
Second draft.
|