Overlapping Care-Gap Lists: Coordinate One Patient's Outreach Across Teams

This is an original administrative worksheet method. It assumes each program has already approved its outreach scope and does not define clinical eligibility or gap-closure criteria. Related workflows are covered in payer care-gap lists workflow and patient outreach campaign capacity planning.

Where overlapping outreach tasks can arise

Inventory the sources your organization uses, such as payer files, quality programs or internal registries. Confirm approval with each owner rather than treating inclusion in a received file as permission to contact. A patient on several approved lists may have multiple pending contact tasks; compare those tasks before concluding that they are duplicates.

The Agency for Healthcare Research and Quality's Workflow Assessment for Health IT Toolkit notes that successful health IT implementation depends on recognizing its impact on both clinical and administrative workflow, and that implemented systems can provide information to help reorganize workflow (AHRQ). This article applies that general workflow perspective to coordination between separately owned programs. The worksheets below are editorial proposals, not AHRQ protocols.

This article covers operations only. Whether a patient is eligible for a measure, what a payer requires, or how a gap is clinically resolved is outside its scope.

Keep each approved list's purpose and owner visible

Before comparing lists, write a one-line register entry for each. The entry should fit on a single row:

If verification or contact authority is unclear, pause combining that list with other programs and escalate to its owner. Preserve existing authorized work and time-sensitive escalation paths while the question is resolved. Nothing in a shared plan may silently change a program's verification rule or leave pending work without an owner.

Identify overlapping contact work for the same patient

Use the organization's authorized identity-resolution process and record the match reference. Do not match on phone number alone, or assume an identifier is unique across different source systems. Keep uncertain matches separate and route them to the responsible team before sharing item details or combining outreach.

For a verified match, compare the authorized contact tasks: purpose, channel, timing, script, contact history and staff permissions. Record a potential shared-contact opportunity only when those requirements can be met together. Different channel permissions, timing or patient preferences may require separate contacts despite the identity match.

Labelled synthetic example

This example is illustrative. It is not a Linear customer experience or a measured result.

Patient A has been verified across three fictional approved lists. The example uses administrative tasks; the programs' clinical verification rules are supplied separately by their authorized owners.

In this fictional case, the authorized caller may cover all three tasks by phone and the patient agrees to discuss them. One conversation produces three different administrative outcomes. This is not a claim that one call is always permitted, that it replaces every future contact or that any care gap is closed.

Agree a shared contact plan without merging program outcomes

Use a plan that retains each program item and records which contact actions are combined or kept separate. Keep it in an approved system with access limited to the relevant staff; a new shared spreadsheet is not automatically an authorized place for patient information.

Do not resolve incompatible rules by automatically choosing the lowest attempt count. A limit may apply per program, channel, time period or patient, and a requirement in one program may conflict with another. Record the conflict and obtain the authorized plan before combining contacts. Keep existing approved obligations and escalation paths visible while that decision is pending.

One conversation is one contact event. Link its identifier to the relevant program items rather than counting each write-back as another patient contact. Do not assume an unsuccessful attempt on one program satisfies another program's contact requirement.

Preserve responses and unfinished tasks for each team

Record what happened for each relevant program item, including the contact event, timestamp, patient response, administrative action and remaining owner. Share only the outcome details that the receiving program is authorized to access. A general note copied to every record can obscure which item was discussed or expose unrelated information.

Keep these distinctions explicit: an appointment booked is not a visit completed; a callback preference is not verification that a gap is closed; and declining a particular contact or offer does not automatically resolve the program item. Apply the organization's approved process for preferences and restrictions without inventing a clinical interpretation.

If another team must act, record the receiving owner, next action and acknowledgement. Until acceptance is confirmed, keep the failed or pending handoff visible to the coordinating owner. No team should assume that placing an item in the shared plan transferred responsibility.

Check that each expected write-back reached the correct program item. If one write fails, preserve successful writes and reconcile the failed target before retrying; do not repeat outreach just because one tracking system missed the update. Review a risk-based sample and all known write-back failures, reporting the coverage rather than treating a fixed sample size as proof of completeness.

Reconcile campaign changes and review duplicated effort

Lists change. A payer file is refreshed, a registry adds a measure, a campaign is paused. Each change can create or remove overlap. Keep a campaign conflict worksheet alongside the contact plan. The row below is fictional:

The worksheet records potential duplication and the owner-authorized resolution of rule conflicts. At a refresh, reconcile source versions and item identifiers, preserve contact history and check queued actions against new responses or restrictions before they run. A refreshed row must not silently restart the attempt history. Use the reporting date as an additional reconciliation checkpoint, not a reason to delay a needed change.

If you are evaluating software to support this, the useful question is whether a vendor can show how a response from one contact is written to several program records and how each program's owner corrects an error. Book a demo and we will walk through your list register with you.

A practical evaluation method

The Linear Health Operational AI Evaluation Kit recommends inspecting a representative workflow with missing data and exceptions. Its evidence ladder distinguishes a claim, a controlled demonstration and behavior verified in production. It also treats unresolved privacy, security, safety, authorization and accountability issues as gates.

Ask any vendor to run the synthetic case and show:

1. A verified identity match and an uncertain match that remains separate.
2. Compatible contact tasks combined, and a conflicting contact rule held for owner resolution.
3. A patient accepting one task and deferring another, with separate program outcomes.
4. One failed write-back recovered without erasing successful updates or duplicating the call.
5. A new list version arriving after contact, with history preserved and queued actions reconciled.
6. A handoff rejected by the receiving team, with ownership still visible.

Record the expected outcome, observed result and evidence strength separately. A clear demonstration of an incorrect closure is still a failed scenario. Require configuration-specific evidence for multi-record writes, permissions and corrections; a vendor category or integration list does not establish that these actions work in your environment. The Operational AI Evaluation Kit can organize the evidence, while the program owners retain their approval responsibilities.

Next steps

Start by testing the register and conflict worksheet with approved synthetic cases from two programs. Resolve authority and write-back questions before any controlled live pilot, whose scope and monitoring should be set by the responsible owners. To compare how software handles separate program records, book a demo and bring synthetic examples of the register and worksheet. The care-gap closure solution page describes Linear Health's scope for this work.

Frequently asked questions

Sources

Sources accessed October 26, 2026.

• AHRQ, Workflow Assessment for Health IT Toolkit.
• Linear Health, Operational AI Evaluation Kit.
• Linear Health, Care-gap closure workflow.