Last updated
Tracking QC Failures and Corrective Actions From Unity Flags
A red flag in Bio-Rad Unity tells you a control result broke a reject-level rule. CLIA then expects a documented corrective action that covers the cause, the fix and an evaluation of patient results back to the last acceptable run (42 CFR 493.1282). myLabCompliance gives labs a place to track that investigation, with QC failure status, retry attempts, level-specific corrective actions, root cause and resolution notes, next to the related instrument, procedure and staff records. Its public pages do not describe pulling flags from Unity automatically, so the failure is logged in myLabCompliance by staff.
Independent guide from myLabCompliance. Not a Bio-Rad publication; no affiliation with Bio-Rad.
From flag to finished record
Bio-Rad's help pages explain how Unity surfaces a problem. During bench review and supervisor review, data points that violate a reject rule are highlighted in red and warnings in yellow. Unity can also require an automatic action log entry when someone manually enters a point that breaks a reject rule; the help page notes that this applies only to manually entered point data.
That covers detection and a first note. A surveyor, though, usually reads the event as a story with five parts: what failed, what the lab did with patient testing, why it happened, how it was fixed, and who checked the work. If the story stops at "repeated, in range," the lab has a gap.
Why the record matters beyond the survey
A complete QC failure record is not only for inspectors. It is how a lab learns. Six months from now, when the same analyte fails again, a record that names the reagent pack, the onboard time and the fix lets the next tech start in the right place. A record that says "repeated" teaches nothing.
What CLIA asks for
42 CFR 493.1256(f) requires control results to meet acceptability criteria before patient results are released, and (g) requires all control procedures to be documented.
42 CFR 493.1282(b)(2) addresses failed control or calibration results directly: every patient result in the unacceptable run and since the last acceptable run must be evaluated to see whether it was adversely affected, and the lab must take whatever corrective action is needed. Paragraph (b) requires all corrective actions to be documented.
Test records under 42 CFR 493.1283 must identify who performed each test, and 42 CFR 493.1105 sets how long records are kept. Together, these mean the record should name people, times, instruments and patient result ranges, not only the analyte.
A field list for each QC failure
Whether you record failures in Unity, myLabCompliance or both, capture the same data each time:
- Date and time of the failed run, instrument, test and control level(s).
- Rule(s) violated, such as 1-3s, 2-2s or R-4s, and the observed values.
- Control lot and reagent lot in use.
- Whether patient results were held, and how (manual hold, autoverification stop).
- Each troubleshooting attempt in order, with the result of each re-run.
- Root cause, or "no cause found" with what was checked.
- Fix applied: new reagent pack, recalibration, maintenance, fresh control vial.
- Range of patient results reviewed, the criteria used, re-test outcomes and any corrected reports.
- Provider notification, if corrected results changed clinical meaning.
- Reviewer name, role and date.
- Follow-up check that the problem did not recur.
How myLabCompliance tracks it
Per the myLabCompliance QC page, its QC components include fields and workflows for failure status, retry sessions, attempt sequence, level-specific corrective actions, root cause of QC failure, and escalation or resolution notes. That maps closely onto the field list above:
- Failure status shows whether the event is open, escalated or resolved, so supervisors can see what still needs attention.
- Retry sessions and attempt sequence record each re-run in order, which is how a surveyor tells a reasoned troubleshooting path from repeat-until-pass.
- Level-specific corrective actions handle failures that affect one level but not another.
- Root cause and resolution notes hold the explanation and the fix.
- Escalation lets the event move to a technical consultant or director when the bench cannot close it.
Because myLabCompliance also holds equipment maintenance and calibration records, document control and personnel competency, the investigation can reference the maintenance entry, the procedure version and the staff member involved, without hunting across systems. The platform's audit trails record who changed what.
Getting the Unity event into myLabCompliance
myLabCompliance's public pages do not describe an import from Unity, so plan a manual step. Two approaches work:
- Full record in myLabCompliance. When a reject flag appears in Unity, the bench tech enters a short action log note in Unity ("see myLabCompliance QC investigation, [date/test]") and opens the full investigation in myLabCompliance. The Unity note satisfies any required action log; the full record lives with the rest of the compliance file.
- QC charted in myLabCompliance. If the lab enters QC results directly in myLabCompliance, its Westgard rule detection flags the failure there and the investigation starts in the same place. Unity, if used, is kept for peer comparison.
Either way, write the approach into the QC procedure so every shift does it the same way. Attaching a screenshot or exported chart from Unity to the investigation helps reviewers see what the bench saw.
Using Bio-Rad peer data while you investigate
When the cause is not obvious, peer data can narrow it down. Bio-Rad describes InstantQC reports as on-demand peer comparison intended for troubleshooting, with SDI, bias and TEB% against a selected consensus group; the report selection page shows periods from one day to six months.
The logic is simple. If labs running the same control lot on similar instruments show the same shift, suspect the control material or a shared reagent lot and contact Bio-Rad. If peers look normal and only your lab moved, look at your own calibration, maintenance, reagents and handling. Note which conclusion you reached and save the peer report you used with the investigation. In myLabCompliance, that file can be uploaded and linked so the evidence travels with the record.
The patient look-back, step by step
This is the part most often missing in survey findings. A workable procedure:
- Identify the last acceptable QC run for the analyte on that instrument.
- List all patient results reported since then, from the LIS or instrument log.
- Apply the lab's written criteria for which to re-test. Labs often re-test a selection across the measuring range and any results near decision points; the criteria are the director's call.
- Compare original and repeat results against the lab's allowable difference.
- Correct and re-issue reports where needed, following the lab's corrected report procedure.
- Record the patient range reviewed, the number re-tested, the outcome and any corrected reports in the investigation.
If no patient results were released because the failure was caught before reporting, say that explicitly. "No patient impact" without the reason invites a follow-up question.
Warnings and slow shifts
Yellow flags usually do not stop reporting, but they are early signals. Decide in the QC procedure what happens when a warning rule fires, who looks at multi-day trend rules, and when a run of warnings becomes an investigation. Because trend rules span several runs, they are easy for a single bench shift to miss; a scheduled supervisor look at the Levey-Jennings charts, in Unity or in myLabCompliance, catches them. Record the trend review and any action, even when the answer is "within limits, continue to monitor," and give a date for the next look.
Review and trend
Supervisor review should check that each investigation is complete, not just present. A monthly look across all QC failures also catches patterns that single events hide:
- The same analyte failing repeatedly on one instrument.
- Several failures traced to the same cause, such as reconstitution or reagent onboard time.
- Failures clustering on one shift.
- Failures that follow a control or reagent lot change.
Patterns like these call for a CAPA: a wider look at training, procedure wording, workload or equipment, with a check that the fix holds. myLabCompliance describes corrective action workflows for both QC failures and proficiency testing, which keeps related events in one place for that kind of review. When the same instrument shows up repeatedly, its maintenance and calibration history in the equipment module is the next place to look.
Common gaps, and the fix for each
| Gap | Fix |
|---|---|
| "Repeated QC, OK" with no cause | Require a cause or a list of what was checked before closing |
| No patient evaluation recorded | Make the look-back a required step with its own fields |
| Review signed weeks later in bulk | Set a review time frame and track open items |
| Interfaced QC with no action log | Remember automatic action logs cover manual entries only; set a separate check for interfaced data |
| Unity and the written procedure disagree | Name the system of record and align rules and limits |
Walk through a QC failure workflow in myLabCompliance using one of your own recent Unity flags.
FAQs
Does myLabCompliance pull rejection flags from Unity automatically?
Its public pages do not describe a Unity import or integration. Staff open the investigation in myLabCompliance, or chart QC directly in myLabCompliance so its Westgard detection raises the flag.
What does CLIA require after a QC rejection?
42 CFR 493.1282 requires documented corrective action, including evaluation of all patient results from the unacceptable run and since the last acceptable run.
Are Unity automatic action logs enough?
They help, but Bio-Rad's help says they apply only to manually entered point data, and a short entry may not show the cause, patient review and reviewer. Many labs keep a fuller investigation record.
What fields does myLabCompliance have for QC failures?
Its QC page lists failure status, retry sessions, attempt sequence, level-specific corrective actions, root cause of QC failure, and escalation or resolution notes.
Who should sign off on a QC investigation?
The role named in your QC procedure, often a supervisor, technical consultant or lab director, within a stated time frame.
How do we show we are not repeating QC until it passes?
Record each attempt in order with what changed before it. Retry and attempt sequence fields make that visible.
Should we save InstantQC reports with an investigation?
If you used one to reach a conclusion, yes. Save or export it and attach it to the investigation so a reviewer can see the peer data you relied on.
Sources
- eCFR 42 CFR 493.1282
- eCFR 42 CFR 493.1256
- eCFR 42 CFR 493.1283
- eCFR 42 CFR 493.1105
- QCNet help, Automatic Action Logs
- QCNet help, Bench Review and Supervisor Review
- myLabCompliance, QC software
- myLabCompliance, CLIA compliance software
Related myLabCompliance pages
- Lab QC software
- QC failure investigation
- CLIA corrective action documentation
- QC failure troubleshooting
- Using myLabCompliance alongside Bio-Rad Unity
Bio-Rad, Unity, Unity Real Time, UnityWeb, Unity Next, QCNet, InstantQC, Westgard Advisor, EQAS, Lyphochek, Liquichek and InteliQ are trademarks of Bio-Rad Laboratories, Inc. myLabCompliance is independent software and is not affiliated with or endorsed by Bio-Rad. Bio-Rad product details here are taken from Bio-Rad's public pages and help documentation, linked in the sources; check them with Bio-Rad. This page is educational and is not legal or regulatory advice.