Populate linking pairs: Difference between revisions

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

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

  • not implemented yet, the following is just the plan to go with
  • added: 2021-07-27
  • action: 2021-07-27
  • Cargo


  • Categories

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

  • added: 2021-08-03
  • action: 2021-08-03
  • Cargo


  • Categories


previous thoughts   

Clean our only those pairs that are questionable:

  • find all records whose pairs have non-consecutive (admit dttms)
    • need to admit this with the old style admit dttm included so the wholesale recreation will still work
  • remove all pairs related to those patients (ie have same PHIN)(easier than figuring out which to remove)
  • remove all pairs where a pair-less profile is present for the same phin
    • this would include old single encounters (57% of our records are single encounters)

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

Second draft.

Related articles

Related articles: