Issued April 18, 2024 — two days after match rules. These are the day-to-day procedures that guide data stewards through queue management, decision documentation, supervisor handoff, quality review, and escalation. This procedure is the bridge between the policy rules and the actual work.
Daily Workflow, Decision Documentation, Quality Acceptance, and Escalation
Contents
1. Role & Staffing Model
Data Stewards are specialists who review identity resolution pairs and make merger decisions on records that fall into the clerical review band (confidence 65–91%). These are not data entry roles; stewards are expert decision-makers who evaluate source data quality, business context, and matching confidence to produce a defensible merged record.
Staffing: The program planned for 4 stewards initially; a second cohort of 4 was approved via CR-002, bringing the team to 8. Both cohorts are scheduled to onboard in parallel across April and May 2024, with staggered start dates to allow mentoring. Cohort 1 carries the higher-risk records; Cohort 2 begins with lower-complexity cases and ramps up.
Reporting: All stewards report to T. Vandiver, Data Steward Supervisor. The Supervisor manages workload allocation, performs daily quality review (end-of-day), handles escalations, and coordinates with Dr. A. Ravindran (Data & EMPI) on patterns or exceptions.
2. Daily Queue Management
The EMPI steward dashboard displays the worklist in priority order each morning at 7:00 AM ET.
At the start of each business day, the steward logs into the EMPI steward dashboard and reviews the day's worklist. Records are ranked by:
- Confidence score band: Records scoring 85–91% (the "near-miss" band) arrive first, as these require the most careful review.
- Age in queue: Records waiting >10 business days appear next (to prevent indefinite queue backlog).
- Data quality flags: Records flagged as potential duplicates or with SSN conflicts appear third (to surface urgent data issues).
- Steward affinity: Records similar to pairs the steward has previously reviewed appear fourth (for consistency).
The daily target is 100 records completed per steward per day. This pace allows approximately 15–20 minutes per record for detailed review, documentation, and decision reasoning. Stewards working faster than this pace are assumed to be cutting corners on the uncertain cases, which is when false positives emerge.
Throughput is not a speed metric. A steward who completes 120 records in a day by abbreviated review is producing lower-quality decisions, even though the count looks better. Quality audits (weekly false-positive sampling) are designed to surface this drift. Stewards are coached on pacing if their queue velocity exceeds 110 records per day.
Before beginning review, the steward opens a record pair in the dashboard and makes note of any prior decisions the steward has made on similar pairs. The system displays:
- The matching confidence score and the engine rules that produced it.
- Side-by-side display of all source (Cumberland Valley) and target (ACME) fields.
- Data quality flags (e.g., "SSN appears in 3 target records," "address contains corrected zip code," "name is a known variation").
- The steward's prior decisions on phonetically similar names or nearby dates, to promote consistency.
The steward has access to external reference materials (census data for name variants, postal databases for address quality) during review, but such research is logged as "extended review" and is counted toward the 20-minute per-record target.
3. Decision-Making Workflow
For each record pair, the steward makes a binary decision: MATCH or NO MATCH.
MATCH decision: The steward confirms that both records represent the same person and should be merged. The steward selects a reason from the following categories:
| Reason Category | When to Use |
|---|---|
| High-confidence name + address + phone combination | Multiple fields align despite lower overall score (e.g., name matches phonetically, address is identical, phone differs only in area code) |
| DOB confirmed by secondary source (benefits, enrollment, claims) | The matching engine scored the DOB as uncertain, but external data (e.g., an active claim dated after enrollment) confirms the DOB belongs to the person |
| Known variation (nickname, name order, married name) | The records use different name formats known to be variants of the same person (e.g., "William" vs. "Bill," "Maria Garcia Lopez" vs. "Maria Lopez") |
| Internal verification (system ID match in other records) | A family member or linked record in one system matches a record in the other system with the same ID pattern, strongly suggesting the index person is a match |
| Other (free-text explanation) | A match that does not fit the above categories; steward provides custom reasoning (e.g., "Medical record number appears in both systems for same procedure") |
NO MATCH decision: The steward concludes the records represent different people. If the score is >80% (the near-miss band), the steward must provide a reason: (a) conflicting DOB or sex, (b) address in different states with no moves in account history, (c) score is driven by common name + no other matching fields, or (d) other. For scores <80%, no explanation is required.
A NO MATCH in the near-miss band requires explanation because these are the cases where the automated suggestion might mislead a less-careful reviewer. Documenting the reason forces the steward to articulate why the system was wrong, and creates evidence for post-close analysis if that pair surfaces as an issue later.
If the steward decides MATCH, the next step is to select the surviving value for each attribute. The steward does not choose a "winning record"; instead, each field is evaluated independently:
- Name: Which source is more recent? Is one a known variation of the other? Select the value the steward judges most likely to be correct, or flag for supervisory review if unresolvable.
- DOB: Are the two dates identical, nearly identical (off-by-one day could be timezone or entry error), or genuinely conflicting? If identical or near, use that value. If conflicting, flag for Supervisor review.
- Address: Is one a forwarding address or correction of the other? Are both addresses valid? Select the most recent mailing address, or flag if postal history is unclear.
- Phone/Email: Use both if different (one may be work, one home). Flag if both appear to be primary contacts and the relationship is ambiguous.
- Sex: Rare to have conflicts, but flag if present (data entry error or genuine ambiguity in the source records).
The merged record is written to the integration layer with full lineage: an audit trail records which source contributed which attribute and the steward's reasoning for selection.
4. Documentation & Audit Trail
Every decision is logged with the following metadata:
| Field | Requirement |
|---|---|
| Steward name & ID | Automatically captured from login |
| Timestamp | System-generated at decision submission |
| Source & target member IDs | Automatically captured |
| Decision (MATCH / NO MATCH) | Steward-selected |
| Reason category | Steward-selected from dropdown |
| Free-text explanation | Required if reason = "Other" or if score >80% and decision = NO MATCH |
| Confidence assessment | Steward rates own confidence (High / Medium / Low) on the decision |
Decisions are held in a staging area until end-of-day supervisor review. No merged records are written to production until the Supervisor approves them.
At 5:00 PM ET each business day, T. Vandiver (Steward Supervisor) reviews all decisions submitted by stewards that day. The Supervisor checks:
- Decisions are properly documented (no blank explanations, confidence assessments present).
- No obvious errors (steward confidence = "Low" on every decision, or steward has made >120 decisions, signaling rushed work).
- Any records flagged by stewards for supervisory review are escalated (Supervisor makes final call on attribute conflicts, or escalates to Dr. Ravindran if unresolvable).
If a decision passes review, it is approved and the merged record is written to the integration layer. If the Supervisor questions a decision, the record is returned to the steward for re-review with notes explaining the Supervisor's concern.
5. Quality Assurance & Escalation
Once per week (Thursdays, 2:00 PM), Dr. A. Ravindran samples 5% of the previous week's MATCH decisions and independently reviews the pairs. For each sampled pair, Dr. Ravindran assesses:
- Is the steward's MATCH decision defensible, given the confidence score and documented reasoning?
- Does the merged record make clinical and operational sense (e.g., no duplicate member IDs, no conflicting family relationships)?
- Is there any signal that this merger could cause problems post-close (e.g., merged record has conflicting insurance coverage dates)?
If a merger is questionable, Dr. Ravindran flags it for re-review. The steward is notified and given one business day to re-examine the pair. If the steward's decision holds up to renewed scrutiny, the record remains merged. If the steward concedes the decision was in error, the merge is reversed and the records are returned to non-match status for potential re-review or escalation.
Repeated failures in an individual steward's queue (>3% error rate in the weekly sample) trigger a 1:1 coaching session with the Supervisor, focusing on the specific types of pairs causing issues (e.g., near-matches on name but with conflicting address).
Records that require decision-making authority beyond the steward's role are escalated as follows:
- Steward → Supervisor (T. Vandiver): Attribute conflicts, scores in the near-miss band with ambiguous reasoning, or records flagged by the steward as uncertain.
- Supervisor → Data Lead (Dr. A. Ravindran): Persistent steward uncertainties, policy questions, or records with potential clinical implications (e.g., conflicting medication allergies).
- Data Lead → Program Manager (C. Tyrrell) → Steering Committee: If the issue suggests a pattern of data quality problems or a need for policy change (e.g., to raise/lower thresholds).
Escalation is logged with timestamp and reason. The target receives escalated records within 1 business day and provides a decision or guidance within 2 business days.
6. Training & Ramp
Each steward (both cohorts) receives 3 days of classroom training covering:
- Match rules (Artifact 32): Deterministic, probabilistic, and clerical decision logic.
- EMPI system & dashboard: Hands-on walkthrough of worklist, record pair display, decision entry, and audit logging.
- Data quality context: Why the deterministic shortfall happened (SSN completeness issues), what flags in the data mean (duplicate SSNs, transposed DOBs), and how to spot red flags.
- Survivor-per-attribute methodology: How to decide which record's value to retain and how to document the decision.
Each steward works on a curated set of 50 "training pairs" alongside a Cohort 1 mentor (or the Supervisor if Cohort 1 is not yet fully ramped). Mentors review decisions in real-time and provide coaching on reasoning and pacing. Training pairs are weighted toward lower-complexity cases (high-confidence name + address matches, clear non-matches) to build confidence before moving to near-miss records.
After completing supervised practice with a pass rate >90% (mentor agreement on decision for >90% of pairs), the steward is cleared to work independently on live queue records. The Supervisor continues daily end-of-day review and weekly false-positive audits remain in effect for all stewards indefinitely (quality assurance does not end when ramp completes).
Related artifacts: 32 — EMPI Match Rules & Decision Logic · 31 — Data Profiling Results · 19 — Retention Plan (T. Vandiver, Data Steward Supervisor)