Engineering Care Gaps as Computable Logic
Care gaps are not report filters — they are executable clinical protocols with target populations, evidence requirements, time windows, and resolution criteria. Encoding them as computable logic enables real-time, scalable gap detection and closure.
A care gap is the difference between what a patient should receive -- according to evidence-based guidelines -- and what they actually received. Every healthcare organization tracks care gaps. Most do it badly.
The typical approach: an analyst writes a SQL query joining demographics, encounters, and lab results to find patients "overdue" for something. The query runs monthly, produces a spreadsheet, and by the time anyone acts on it, the data is stale.
There is a better way. Encode care gaps as computable logic that runs continuously, produces deterministic results, and feeds directly into engagement workflows.
What a Care Gap Actually Is
A care gap is not a query result. It is a clinical protocol with four components:
Target population. Who does this gap apply to? Diabetic patients over 40. Women aged 50-74. Patients with a history of cardiovascular events. The population definition includes inclusion criteria, exclusion criteria, and sometimes risk stratification.
Evidence requirement. What action should have been taken? An HbA1c test, a mammogram, a colonoscopy, a medication refill. The requirement specifies the action type, the acceptable timeframe, and any qualifying conditions.
Evaluation logic. Given a patient's record, is the gap open or closed? This is the core computation. It searches the patient's history for evidence that satisfies the requirement within the specified time window.
Resolution criteria. What closes the gap? A new lab result, a completed procedure, a documented refusal. Resolution must be tracked prospectively — not just re-queried.
Anatomy of a Care Gap Protocol
Target Population
Inclusion and exclusion criteria that define which patients the protocol applies to. Age, diagnosis, medication history, risk factors.
Evidence Requirement
The specific clinical action required — test type, procedure code, medication class — and the acceptable time window.
Evaluation Logic
Computable rules that search a patient's longitudinal record for qualifying evidence within the defined window.
Resolution Criteria
What constitutes gap closure — new evidence arrival, documented exception, or patient-initiated refusal.
Why SQL Queries Are Not Enough
A SQL query can approximate a care gap. It can join the diagnosis table to the lab results table and filter for patients whose last HbA1c was more than six months ago. This approach has three problems:
Problem 1: Brittle Logic
Clinical protocols are complex. A breast cancer screening protocol does not just check "has the patient had a mammogram in the last two years." It also checks:
- Is the patient between 50 and 74?
- Has the patient had a bilateral mastectomy? (exclusion)
- Is the patient currently undergoing breast cancer treatment? (exclusion)
- Has the patient documented a refusal? (documented exception)
- Was the most recent mammogram a qualifying study? (not all imaging counts)
Encoding this in SQL produces a query that is hundreds of lines long, impossible to unit test, and breaks whenever the source schema changes.
Problem 2: Point-in-Time Evaluation
A SQL query evaluates the gap at the moment you run it. But care gaps are temporal: they open when a time window expires and close when new evidence arrives. A query-based approach requires re-running the entire query set on a schedule, which means gaps are only as current as your last batch run.
A computable protocol, by contrast, can be evaluated incrementally. When a new lab result arrives, only the affected patient's gaps are re-evaluated — in seconds, not hours.
Problem 3: No Versioning
Clinical guidelines change. Screening ages are lowered. Evidence windows are adjusted. Medication classes are updated. When a guideline changes:
- SQL queries are edited in place, losing the previous version
- Historical gap status becomes unreproducible
- It is impossible to compare "gaps under the old guideline" vs "gaps under the new guideline"
A versioned protocol maintains its full history. You can re-evaluate any patient against any protocol version at any point in time.
Encoding Gaps as Computable Logic
A computable care gap protocol is a structured definition — not code, not SQL, but a declarative specification that a processing engine can execute. Here is what it contains:
Protocol: Diabetic HbA1c Monitoring
Version: 3.2
Effective: 2025-01-01
Population:
Include: diagnosis IN (E11.*, E13.*) AND age >= 18
Exclude: pregnancy_status = active OR hospice = true
Requirement:
Action: lab_test
Code: LOINC 4548-4 (HbA1c)
Window: 6 months rolling
Qualifying: result IS NOT NULL
Resolution:
- New qualifying lab result within window
- Documented clinical exception with reason code
- Patient refusal with counseling documentation
This definition is:
- Readable by clinical teams who own the protocol
- Executable by a processing engine that evaluates it against patient records
- Testable with unit tests that verify behavior against sample records
- Versionable with full history and diff capability
Running Protocols at Scale
A hospital network with a large active patient population and 200+ care gap protocols generates millions of gap evaluations. This is not a batch job that runs overnight — it is a continuous computation that updates as new data arrives.
The processing architecture has three stages:
Care Gap Processing Pipeline
Stage 1: Event-driven re-evaluation. When a new lab result, encounter, or claim arrives, the engine identifies which patients and protocols are affected and re-evaluates only those gaps. A single HbA1c result might close one gap and have no effect on 199 others.
Stage 2: Registry maintenance. The gap registry maintains the current status of every patient-protocol combination. Each gap has a status (open, closed, exception), a timestamp, and a reference to the evidence or exception that determined the status.
Stage 3: Downstream activation. Open gaps feed directly into engagement workflows. A newly opened gap can trigger an automated patient message, a provider notification, or a campaign enrollment — without manual intervention.
The Compound Effect
Individual care gap detection is useful. The compound effect across 200+ protocols is transformational:
Morning brief. A physician starting their day sees a prioritized list of care gaps across their patient panel — not a spreadsheet export from last month, but a live view computed from the most recent data.
Campaign targeting. A population health team builds a campaign targeting "patients with 3+ open care gaps who have a visit scheduled in the next 14 days" — a cohort that is impossible to compute with manual queries and stale data.
Quality reporting. Regulatory quality measures (HEDIS, MIPS) are fundamentally care gap computations. When gaps are computable, quality reporting becomes a byproduct of the system — not a separate annual exercise.
ROI measurement. When a care gap closes, the system tracks whether it was closed by automated outreach, provider action, or patient self-service. This creates a direct attribution chain from engagement intervention to clinical outcome.
The Bottom Line
Care gaps are not report filters. They are clinical protocols with precise definitions, temporal logic, and resolution criteria. Encode them as computable logic -- versioned, testable, executable at scale -- and care gap management goes from a quarterly spreadsheet exercise to a real-time operating system for clinical quality.
A SQL query checks a spreadsheet. A computable protocol runs an engine. Healthcare quality at scale requires the engine.
THB's DataCloud runs 200+ care gap protocols across millions of patient records, with event-driven re-evaluation and direct integration into PEP engagement workflows. Learn more about clinical intelligence.