Refresh an Approved Care-Gap List Without Losing Work in Progress

Why list refreshes break work in progress

A new source delivery can differ from the list staff are working. Inspect additions, field changes and any stated removals without assuming that replacing a file safely transfers its attached work. The proposed method below keeps the source version, reconciliation decisions and work history separately identifiable. It does not interpret a measure, determine patient eligibility or direct clinical care.

AHRQ's Workflow Assessment for Health IT Toolkit frames health IT implementation as something that affects both clinical and administrative workflow and that should be assessed deliberately rather than assumed (AHRQ). A list refresh is exactly that kind of administrative workflow, and it deserves a written procedure.

This article covers version reconciliation and work continuity only. For how lists are received and organized, see payer care-gap lists workflow. For the broader closure program, see HEDIS gap closure.

Step 1: Identify the approved list version and its effective scope

Before any comparison, record a version header. Keep it short and stable so every later question can point back to it.

If the sender did not state the effective window or scope, record the field as not provided rather than guessing. Interpreting what a payer intended is outside the operations lane and belongs with the program owner.

Step 2: Compare additions, changes, and removals to existing work

Agree the matching key with the source and program owners. A patient identifier alone may cover several gaps, so include the source-defined gap, measure or episode identifier needed to distinguish the work. Route ambiguous or duplicate keys for reconciliation before merging.

Only infer absence from a full replacement covering the same approved scope. An incremental file or a file for another site does not establish that omitted rows were removed. With that boundary clear, classify changes in the proposed ledger below.

The ledger should hold, for each row: patient identifier, gap or measure label, prior version ID, new version ID, change type, fields changed, open task count, last contact date, and a routing decision. This is the reusable artifact. It supplies evidence for reviewing and correcting a mistaken reconciliation. Whether a change can be reversed depends on what actions occurred and the system's supported recovery process.

Step 3: Preserve contact history and assigned tasks across versions

Write preservation rules once and apply them every refresh. A workable starting set, offered as editorial guidance:

1. Preserve the permitted history. A routine refresh should not silently erase contact events, notes or their relationship to the source version. Follow the organization's approved record-handling process.
2. Separate preservation from continuing work. Retain an open task's history and owner when membership changes. Apply the approved hold, continue or cancel decision; keeping evidence does not mean continuing outreach automatically.
3. Update only a confirmed match. A changed due date may belong to the same work item, while a different gap or episode may require a separate item. Resolve the identity before updating.
4. Use earlier context within its authorized scope. Show relevant permitted history without assuming every program should share every note or task.
5. Document correction and recovery. Record before-and-after values and the responsible actor. Test the supported recovery process in staging before applying a new reconciliation rule to live work.

A log does not make an external call or message reversible. If the proposed refresh could trigger an action before its membership and disposition are checked, establish an approved staging or hold step. The Operational AI Evaluation Kit provides questions about logged actions and authorized correction; it does not establish a particular product's recovery capability.

Step 4: Route ambiguous changes to the designated program owner

Some changes cannot be resolved by rule. Examples: a removal with an open task that has a scheduled appointment attached; a changed measure label that staff do not recognize; a patient who appears on two lists with conflicting due dates. Define a single routing queue, a named owner, and a target turnaround that your team sets for itself.

The program owner coordinates the question and obtains a decision from the role authorized to interpret it. A program-owner title does not itself confer clinical or payer-policy authority. Record the source, decision, scope and version to which it applies. A later change may require a new decision rather than automatically reusing the old one.

Step 5: Reconcile the new worklist without assuming a removal means closure

An absent row tells you about membership in the compared source version. It does not, on its own, explain clinical status or authorize a task disposition. Keep these fields separate:

• Source membership: present, explicitly removed, absent from a confirmed replacement, or unresolved because scope is unclear.
• Removal explanation: the source-provided reason, or unknown if no supported explanation is available.
• Administrative work disposition: the approved continue, hold, cancel or archive decision for each affected task.
• Clinical or measure status: only the status supplied through the authorized source and review process, never derived from membership alone.

Confirming a removal reason can resolve a reconciliation question without closing a care gap. The worklist should make that distinction visible.

Labelled synthetic example

This example is illustrative and invented. It is not a Linear customer result or a measured outcome.

A fictional two-site practice receives a confirmed full replacement, version 2026-Q4-B, for the same scope as 2026-Q4-A. The comparison shows 412 unchanged rows, 38 added, 21 changed and 17 absent from the new version. The prior list therefore had 450 rows and the new list has 471. These counts are illustrative, not outcomes.

Of the 17 absent rows, five have open outreach tasks and a different two have scheduled-visit follow-up tasks. Those groups do not overlap. All 17 retain their permitted history; the seven with open work go to the program owner for authorized disposition. The ten without open work still need a supported membership explanation if the process requires one. If four of the seven reconciliation questions are later resolved, record those decisions and keep the other three pending. None of these arithmetic or membership events establishes clinical closure.

Practical evaluation method for refresh tooling

Use the same evidence standard whether you are reviewing a spreadsheet macro, an EHR worklist feature, or a vendor platform. The Operational AI Evaluation Kit describes a 0 to 3 scale: not addressed, claimed, demonstrated, verified (Linear Health). Apply it to these refresh-specific checks:

1. Show a synthetic refresh for a confirmed full replacement, then an incremental file, with additions, field changes and removed rows that have open tasks.
2. Show the change ledger the system produces and whether a person can export it.
3. Show preserved permitted history and task relationships, with disposition controlled separately from membership.
4. Show how a mistaken merge is corrected, who is authorized and which external actions cannot be undone.
5. Show the routing path for ambiguous rows and who owns the queue.
6. Show where a removed row's status lives in the system of record, and confirm a supported removal explanation cannot silently become clinical closure.

The kit's method notes that a scripted happy path is not enough and that unresolved privacy, security, safety, or authority issues should be treated as gates rather than offset by a high score (Linear Health). Any refresh that writes to your EHR or worklist system should clear those gates with your own reviewers. Integration specifics, including which fields are written, need demonstration in your configuration rather than inference from a vendor name.

For how this fits into a wider closure program, see the care-gap closure solution.

Frequently asked questions

Sources

• AHRQ, Workflow Assessment for Health IT Toolkit
• Linear Health, Operational AI Evaluation Kit