Populate linking pairs: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
Line 37: Line 37:
Clean our only those pairs that are questionable:
Clean our only those pairs that are questionable:
* find all records whose pairs have non-consecutive (admit dttms)  
* find all records whose pairs have non-consecutive (admit dttms)  
** need to admit this with the old style admit dttm included so the wholsale recreation will still work
** 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 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
* 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 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


== Related articles ==
== Related articles ==

Revision as of 09:40, 2021 July 28

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

SELECT L_PHI.PHIN, L_Log.Arrive_DtTm, L_Log.D_ID, IIf(Not IsNull([accept_dttm]),[accept_dttm],[arrive_dttm]) AS adm
FROM L_Log INNER JOIN L_PHI ON L_Log.D_ID = L_PHI.D_ID
ORDER BY L_PHI.PHIN, IIf(Not IsNull([accept_dttm]),[accept_dttm],[arrive_dttm]);

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

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

Related articles

Related articles: