Validated systems that stand up to an audit trail request
Willowark builds production software and inspection systems for medical device manufacturers, designed from the start to be validated: electronic device history records, Part 11 compliant applications with real audit trails, automated dimensional and cosmetic inspection, and UDI marking verification. The problem it removes is the gap between what your process actually does and what your records can prove it did.
We work risk-based, in line with GAMP 5 thinking. Requirements are written first and carried through a traceability matrix to the tests that verify them. Configuration is separated from code so recipe and parameter changes do not force a full software revalidation. IQ, OQ, and PQ protocols are drafted alongside the build rather than reconstructed afterward, and automated regression tests mean a future change is revalidated in scope instead of from scratch.
Regulation shapes the engineering here more than technology does. A first project is usually one process step with a documentation gap the quality team already feels — a manual inspection with no objective record, a traveler that gets transcribed, a piece of equipment logging to a printer — and it is scoped so the validation effort matches the risk. We write the user requirements with your quality and regulatory staff before any code, because the requirements document is what the auditor will read first and what every test afterward has to trace back to.
Reviewed
Sound familiar?
If you've said any of these, we should talk.
“Every software change means months of revalidation, so we changed nothing for two years.”
We structure systems so the validated surface is small and the changeable surface is configuration. Automated test suites re-execute the verification evidence on demand, turning revalidation into a scoped, risk-assessed activity rather than a repeat of the original effort.
“Our DHR is a paper traveler that someone scans into a folder at the end.”
We capture the record at each operation as it happens, with enforced required fields, equipment identifiers, and electronic signatures where your procedures call for them. A unit cannot advance with an incomplete record, so review by exception replaces reviewing every page afterward.
“We inspect by eye against a workmanship standard and two inspectors disagree.”
We convert the workmanship standard into measurable criteria, then build vision inspection that applies them identically every time and archives the image with the result. The repeatability study against known conforming and nonconforming units becomes part of the qualification package.
“The auditor asked for the audit trail and we handed over a spreadsheet.”
We implement append-only audit trails recording old value, new value, user, timestamp, and reason where required, with no ability for any user to edit history. They are queryable and exportable during an inspection, which is the difference between a discussion and an observation.
“Our contract manufacturer sends us a DHR we cannot verify, and our name is on the device.”
We build supplier-facing record capture that your contract manufacturer uses at each operation, writing to a system you own, so the DHR arrives as structured data with equipment IDs and signatures rather than a PDF. Incoming review becomes an exception report, and a question about a specific lot is answered from the record instead of a phone call.
How this industry actually runs
The operation as we usually find it.
Device manufacturing runs under 21 CFR Part 820, now harmonized with ISO 13485 through the Quality Management System Regulation, which makes the device history record the central artifact: every unit or lot must carry evidence of the process that produced it, who performed each step, and that the equipment was qualified. Any system that creates, modifies, or stores a quality record falls under 21 CFR Part 11 — unique user identity with no shared logins, secure computer-generated timestamped audit trails, and electronic signatures that carry meaning. Automated equipment is validated per 820.70(i), and a change to a validated system triggers change control rather than a quick edit. Layered on top are UDI marking and GUDID submission, sterilization and lot records, and cleanroom environmental monitoring.
Machine signals to the people who decide
Components:
- PLCs & sensors (counts, states, current)
- Legacy machine (dry contact / clamp)
- Edge gateway (normalize, buffer)
- Production dashboard (downtime, OEE)
- Alerts & reports (who acts, when)
Connections:
- PLCs & sensors to Edge gateway (EtherNet/IP, Modbus)
- Legacy machine to Edge gateway
- Edge gateway to Production dashboard (MQTT)
- Edge gateway to Alerts & reports
What we build
Starting projects that fit Medical Devices.
- Part 11 applications with unique accounts, electronic signatures, and append-only audit trails
- Electronic device history records captured per operation with enforced fields and review by exception
- Validated vision inspection for dimensional, cosmetic, assembly, and seal integrity checks
- UDI label and direct part mark verification with barcode grading and human-readable OCR
- Validation deliverables: traceability matrix, IQ, OQ, and PQ protocols with executed evidence
- Cleanroom, autoclave, and sealer monitoring with alarm records and calibration tracking
- Nonconformance and CAPA workflows connected to the production data that triggered them
- Label control and reconciliation with automated checks that issued, applied, and destroyed labels balance per lot
Capabilities we bring
What we'd build first
Three places a first project usually starts.
01
Part 11 applications with unique accounts, electronic signatures, and append-only audit trails
02
Electronic device history records captured per operation with enforced fields and review by exception
03
Validated vision inspection for dimensional, cosmetic, assembly, and seal integrity checks
Scoped in writing before any work starts — how engagements work.
Working in Medical Devices?
Tell us the line.
What runs by hand, what is not connected, what you are trying to build. An engineer replies within one business day with whether and how we would approach it.
Common questions
What Medical Devices teams ask first.
Do you produce validation documentation, or is that on our quality team?
We produce the engineering side — requirements and design specifications, traceability matrices, IQ and OQ protocols, and executed test evidence — written to fit your existing quality system rather than imposing a template. PQ generally belongs with your team because it exercises your process.
Can a deep learning inspection model be validated?
Yes, with discipline. The model version is frozen and controlled like any other configuration item, training and test datasets are documented and retained, performance is characterized against a defined challenge set, and the system cannot retrain itself in production. Where a deterministic algorithm works, we prefer it.
Can a Part 11 system run in the cloud?
It can. Part 11 concerns controls, not hosting location: access control, audit trails, record retention and retrieval, backup, and qualified infrastructure with documented change control. Supplier qualification and the validation package have to cover the hosting environment, and records must stay retrievable in readable form.
Do we have to validate off-the-shelf software the same way as custom software?
Not in the same depth, and GAMP 5 categories exist for exactly this reason. Configured commercial software typically needs its configuration and intended use verified, with supplier assessment covering the underlying product, while custom code needs the full design and test lifecycle. Most systems we build are a mix, so the validation plan assigns each component a category and a proportionate level of testing rather than treating the whole thing as bespoke.
How do you handle changes after the system is validated?
Through your change control process, with the engineering built to make that manageable. Each change gets an impact assessment that identifies which requirements and tests it touches, the automated regression suite re-executes the affected verification, and the documentation package is updated in scope. Configuration changes such as a new recipe or tolerance usually fall under a lighter procedure defined during validation, so routine adjustments do not reopen the whole package.
Strategy. Software. Systems.
Engineering for Medical Devices.
Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.