Quality management solutions for MedTech that make quality data usable while the problem is still live, rather than defensible after it is over.
A medical device quality system is engineered for one purpose above all others, which is to demonstrate to an auditor that the required things were done, by the right people, in the right order, with evidence. It does that job well. The consequence is that every record it holds is a completed record, every trend is a trend of closed events, and every signal it produces describes a situation that has already finished. The organization running it has excellent visibility of last quarter and very little of this week.
Ask a quality director where the quality data lives and the honest answer is rarely the eQMS. Complaints arrive through the service organization or the CRM. Nonconformances are raised in the manufacturing system. Design history sits in PLM. Supplier performance is in the ERP. Field behaviour, for a connected product, is in the device cloud and frequently has never been treated as quality data at all. The eQMS holds the documents about these things, which is a different asset from the things themselves.
Everything that requires a view across those systems therefore requires a person to assemble it. That is why trending is quarterly rather than continuous, why the same question takes three days to answer every time it is asked, and why the connection between a field signal and a manufacturing cause is usually made by somebody who happened to remember both. It is not a failure of diligence. It is the predictable output of an architecture in which the quality record and the quality data are in different places.
Quality data is distributed and quality records are centralised
So every cross-system question is a manual assembly exercise with a person as the integration layer.
Signals arrive after the event has closed
Trending on closed records is history, and by the time a trend is visible the product has shipped.
The same investigation is performed repeatedly
Because nobody can find the three previous occurrences, and similarity search across free text was never built.
Process steps exist to produce evidence, not outcomes
Over time the organization optimises for the record rather than for the thing the record describes.
An approved change does not reach every system it affects
PLM, ERP, document control, training and production each need updating, and the follow-through is manual.
Audit preparation is a project rather than a state
Weeks of effort assembling what the system should be able to produce on demand.
Changing the process means revalidating the system
So improvements get deferred, and the inefficiency becomes permanent once it is validated.
The order matters more than any individual step. Process rationalisation before implementation, because afterwards it costs a revalidation. Integration before automation, because automating a process that cannot see its own inputs produces faster incompleteness. Analytics last, because a trend across data you do not trust is worse than no trend at all.
Step 1
Map the quality processes as they are actually performed
Step 2
Separate requirement from habit
Step 3
Rationalise before you implement
Step 4
Locate the quality data
Step 5
Define the records and the relationships
Step 6
Build the integration layer
Step 7
Automate the routing, not the judgement
Step 8
Instrument the leading indicators
Step 9
Validate proportionate to risk
Step 10
Make audit readiness a state rather than a project
We do not sell an eQMS and we are not reselling anybody else’s. Most manufacturers have already chosen a platform, or have one they inherited, and the problem is rarely the platform itself. It is that the platform is isolated, the processes inside it were never rationalised, and the data that would make it useful lives elsewhere. Three groups of capability, in the order they produce value.
Process and implementation
Quality process assessment and rationalisation, separating what the applicable standards require from what the organization has accumulated
eQMS implementation and configuration on the platform you have selected, including migration from paper or from a legacy system
Document control, including structure, lifecycle, periodic review and the training linkage that is usually bolted on afterwards
CAPA, nonconformance, deviation and complaint handling workflows configured to the rationalised process rather than the historical one
Change control, including the impact assessment path and the traceability to design and risk records
Supplier quality, audit management and training records where these sit inside the same system
Integration and data
Quality data integration across eQMS, PLM, ERP, MES, CRM, service systems and the device cloud
A quality data layer where complaints, nonconformances, CAPAs, changes and field behaviour can be queried together
Record and identity resolution, so the same device, lot, supplier and product means the same thing in every system
Data lineage retained from source to report, since integrity is a property of the whole path
Migration and reconciliation when records move between systems, with the evidence that nothing was lost
Interfaces to the connected product, so field behaviour becomes a quality input rather than a separate conversation
Automation and analytics
Workflow automation across routing, escalation, assignment, reminders and record assembly
Leading indicator instrumentation, with signals surfaced while the event is still open
Quality analytics and management review reporting produced from the data rather than assembled for the meeting
Similarity and duplicate detection across historical investigations, so the same problem is not investigated twice
Audit readiness tooling, including on-demand evidence assembly and traceability views
Computer system validation of what we build, scoped with your quality function and delivered with the engineering
The standards are common and the pressure point is not. The third column is where the existing quality system usually fails first, which is the sensible place to start rather than a general modernization.
| Organization type | Quality system character | Where it strains first |
|---|---|---|
| Established device manufacturer | Mature, documented, heavily accumulated | Process bloat and the manual assembly of any cross-system view |
| SaMD company | Built for software release cadence against a device-shaped standard | Change control designed for annual releases meeting weekly deployment |
| Digital health platform | Often immature, built after the product | Discovering mid-growth which parts of the product were always in scope |
| Connected device manufacturer | Conventional quality system plus a product that generates field data | Field behaviour not treated as quality data, so the earliest signal is unused |
| Contract manufacturer or supplier | Serving several customers with different quality expectations | Evidence produced repeatedly in each customer’s preferred format |
The eQMS is a system of record and it should stay one. What is usually missing is the layer beneath it, where quality data from every source is joined, reconciled and made queryable. Build that and the analytics, the leading indicators and the audit readiness follow from it. Skip it and each of those becomes a separate manual exercise for the rest of the system’s life.
| Source | What it holds | The integration problem |
|---|---|---|
| eQMS | Documents, CAPA, NC, change, training, audit | Usually closed, with an export rather than an interface |
| PLM | Design history, specifications, risk records, BOM | Part and revision identity rarely matches the other systems |
| ERP | Suppliers, lots, purchasing, distribution | Supplier identity is duplicated and inconsistently maintained |
| MES or production | Nonconformances, process data, batch records | High volume, and the quality-relevant subset is not marked as such |
| CRM or service | Complaints, field service, returns, installed base | Free text, duplicates, and the device identity often missing |
| Device cloud | Telemetry, errors, usage, firmware version | Never designed as quality data, and nobody owns that interpretation |
This is the section where a consultancy is tempted to imply more than it should. We do not determine your device classification, your regulatory strategy, your quality system scope, or whether a given framework applies to a given function. Those determinations belong to your quality, regulatory, clinical and legal functions, and a supplier who offers them is selling you a liability. What we do is engineer systems capable of supporting the determinations you make, and produce the evidence that they work.
Frameworks the controls may need to support
- FDA QMSR and ISO 13485 as the quality system frameworks the processes and records are configured against
- 21 CFR Part 11 expectations for electronic records and signatures, where the records fall within scope
- ISO 14971, with the risk records linked to change control and to the design history rather than held separately
- EU MDR obligations, including the post-market surveillance data flow where it applies
Electronic records
- Attributable, legible, contemporaneous, original and accurate as a property of the whole data path, not of the eQMS alone
- Audit trails that capture what changed, who changed it and why, and that cannot be altered or disabled
- Trails designed around the records that require control, since volumes of technical logging are not quality auditability
- Access control and segregation of duties enforced by the system rather than by procedure
- Retention, archival and retrieval that remain workable across a platform migration
Traceability
- A complaint traceable to the device, the lot, the design record, the risk control and any resulting change
- Change traceable to its impact assessment, verification evidence and training
- Lineage from a source value to the figure on a management review slide
- Evidence assembled on demand rather than compiled for an event
Validation
- Computer system validation scoped with your quality function, proportionate to what each function does and what fails if it is wrong
- Validation evidence produced by the delivery pipeline, versioned with the release it belongs to
- Supplier assessment of the eQMS vendor and any hosted components, under your existing supplier process
- Periodic review and revalidation triggers defined at implementation rather than discovered later
A quality management system is software, it is subject to every failure mode software has, and it carries a specific irony: when it fails quietly the organization loses the ability to detect that anything is wrong, including that the system is wrong. The failure modes below are the ones that recur, and the testing programme exists to find them before an auditor or an investigation does.
| Failure | How it presents |
|---|---|
| A workflow routes to a role nobody holds | Records sit unactioned in a queue nobody monitors, discovered during audit preparation |
| An approval is recorded under the wrong identity | Shared accounts or delegated access break the attribution the signature exists to establish |
| A rejected approval is treated as completed | Workflow state transitions do not reflect what the approval process intended |
| A user keeps access after changing role | Permissions follow the person rather than the responsibility, and segregation of duties quietly lapses |
| A CAPA closes without its effectiveness activities | Workflow logic permits closure while approved follow-up requirements remain outstanding |
| A restore leaves connected systems out of step | The eQMS and the systems it integrates with recover to incompatible points in time |
| An integration silently stops | The feed is empty rather than broken, so the trend simply flattens and looks like improvement |
| Identity resolution drifts | A supplier or part is renamed upstream and history splits into two entities nobody reconciles |
| A migration loses or duplicates records | Counts reconcile at the top level and individual records are wrong underneath |
| Audit trail gaps appear after an upgrade | A vendor change alters logging behaviour and nobody checked the trail still captures what it must |
| Reports and source diverge | A transformation changes, the figure in the management review no longer matches the record |
| Training linkage breaks | A document is revised and the training requirement does not follow it |
| Performance degrades as records accumulate | Searches and reports slow until people work around the system rather than in it |
Quality programmes are reported as processes digitized, documents migrated and modules implemented. The outcome that matters is whether the organization can now see its own quality position without assembling it by hand, and whether it finds out about problems while they are still cheap.
| Category | What we measure | Why it matters |
|---|---|---|
| Time to answer a cross-system question | Hours from question to defensible answer, with the sources involved | The clearest measure of whether the quality data is actually usable |
| Signal lead time | Interval between a condition arising and somebody competent seeing it | The whole point. Everything else is a means to shortening this |
| Process steps removed | Steps eliminated in rationalisation, separated from steps automated | Distinguishes real improvement from digitizing the existing overhead |
| Cycle time by stage | Where time is spent in CAPA, change and nonconformance, stage by stage | Identifies the single approval responsible for most of the delay |
| Investigation recurrence | Repeat root causes, and repeat investigations of the same issue | Measures whether CAPA is effective in the process rather than on paper |
| Audit evidence retrieval time | Time to produce a typical evidence request on demand | Converts audit readiness from a project into a measurable property |
| Workaround inventory | Where people keep the thing they actually work from | The most honest available indicator of whether the system fits the work |
We will map the quality processes as they are performed, separate what the standards require from what has accumulated, locate and join the quality data across your systems, instrument the signals you can act on, and validate what we build to the approach your quality function sets.
CaliberFocus is a MedTech engineering partner delivering quality management solutions that make quality data usable while the problem is still live. Platform-neutral and working with the eQMS you have chosen, we rationalise quality processes before implementation, join quality data across eQMS, PLM, ERP, MES, service and the device cloud, automate the clerical work and validate what we build to the approach your quality function sets.
- Platform-neutral engineering around the eQMS you already have
- Processes rationalised before they are implemented and validated
- Quality data joined across systems with lineage from source to report
- Engineering and validation delivered together, not sequentially
Security & Compliance
