I spent years as a field service engineer on regulated medical imaging equipment. I have been on both sides of the audit table: the technician who had to reconstruct what happened six months ago from a PDF attachment and a handwritten note, and the engineer trying to convince a Quality auditor that yes, this procedure was actually followed, step by step, in the correct order.
The documentation existed. The intent was there. But the system could not prove it โ because the system was not designed to enforce it. It was designed to store it.
That distinction is exactly where audit findings occur.
The Core Problem
Most service platforms claim to be "compliant" with 21 CFR Part 820.
What they actually mean is:
- They can store documentation
- They can attach PDFs to work orders
- They can log that something happened
What they cannot do is enforce how work is executed, in what order, by whom, and under what constraints.
That gap is where exposure lives.
What 21 CFR 820 Actually Requires (In Practice)
At a system level, compliance is not about records โ it is about controlled execution.
In practice, that means:
- Procedures must be followed exactly as defined
- Steps must be completed in sequence
- Critical actions must require verified approvals
- Records must be attributable, contemporaneous, and immutable
- Deviations must be detectable and reviewable
Most systems fail here because they treat procedures as documents, not executable systems.
Teardown #1: The "PDF-as-Procedure" Model
How Legacy Systems Work
Platforms like ServiceMax or Fiix typically structure work like this:
- Work Order created
- PDF manual attached
- Technician opens PDF
- Technician performs steps manually
- Technician marks work order "complete"
Where This Fails
Consider a concrete scenario: a technician is performing a high-voltage subsystem service on an MRI linac. Step 14 requires measuring and logging the output voltage at three specific test points before proceeding. The PDF is open on a tablet in airplane mode. The measurement takes four minutes and requires moving a probe between cabinet sections. Under time pressure โ a delayed flight, a hospital schedule, a system that needs to be back online for afternoon treatments โ the technician skips step 14 and marks the procedure complete.
The system records: procedure completed, technician ID, timestamp. What it does not record: that step 14 was skipped, that no measurement was taken, that the safety constraint was bypassed.
From an audit perspective, the system can prove that a document existed โ but not that it was followed.
The Audit Reality
The system has no visibility into execution:
- Did the technician skip steps?
- Were steps performed out of order?
- Were required measurements actually taken?
- Was the correct revision of the procedure used?
Every one of these is an audit question. None of them has a defensible answer in a PDF-as-procedure model.
Teardown #2: The Self-Approval Loophole
What Happens in Practice
In many CMMS platforms:
- Technician completes work
- Technician checks a box: "Verified"
- Technician closes the work order
Why This Is a Problem
This creates a hidden violation:
- No enforced separation of duties
- No independent verification
- No structural prevention of self-approval
Even if SOPs say otherwise, the system does not prevent the behavior โ it merely hopes users comply.
That is not compliance. That is policy without enforcement.
Teardown #3: "After-the-Fact" Audit Trails
The Illusion
Most systems provide:
- Timestamps
- Activity logs
- Edit histories
This creates the impression of traceability.
The Reality
These logs are:
- Not tied to step-level execution
- Not constrained by workflow logic
- Often editable or reconstructable
So while you can see that something happened, you cannot prove it happened correctly.
The Root Cause: Compliance Is Not a Feature
All of these failures stem from a single architectural issue: compliance is treated as a layer on top of the system, not a property of the system itself.
Legacy platforms were designed to track work, manage tickets, and store data. They were not designed to enforce regulated execution.
So compliance gets "added" via SOPs, training, QA review, and manual audits. But the system itself remains permissive.
What Structural Compliance Actually Looks Like
A compliant system does not just record work โ it constrains it.
In a structurally compliant model:
- Procedures Are Executable โ Each step is discrete and required. Execution order is enforced. Skipping steps is impossible without deviation logging.
- Actions Are Attributable at the Step Level โ Every action is tied to a user, a timestamp, and a specific step.
- Approvals Are Enforced by Design โ Critical steps require separate roles. Self-approval is structurally blocked. Signature events are cryptographically bound.
- Records Are Generated, Not Assembled โ The audit trail is created as work happens, not reconstructed after completion.
Why This Matters in an Audit
During an audit, the question is never: "Do you have procedures?"
The real question is: "How do you ensure those procedures were actually followed?"
If your answer depends on trusting technicians, reviewing PDFs, or sampling records, you have exposure.
If your system enforces execution order, required inputs, and role separation, then compliance becomes a property of the system โ not a result of inspection.
The Design Decision
When we started building WELR, we had a choice: build a flexible service management tool and add compliance features later, or design the execution model around compliance constraints from the beginning.
We chose the second path โ not because it is easier, but because the first path is what created the problem we are trying to solve. Separation of duties is enforced at the API layer, not just documented in a policy. Procedures are executable workflows, not attached PDFs. The audit trail is generated as work happens, because a trail assembled afterward is an argument, not evidence.
That is the architecture we chose. And it is the reason compliance in WELR is a structural property, not a setting.