Lab Management for Medical Device Design Verification
6 min read
Case study by the National Institute of Chemistry, Slovenia, one of the country’s leading public research organisations, whose GMP Service Unit provides GMP certified analytical services to the pharmaceutical, cosmetics, food and environmental industries.
The lab that lab software forgot
Most lab management software, such as electronic lab notebooks, is marketed around one kind of lab: a scientist with a hypothesis, working at a wet bench. But every medical device company also runs a second kind of lab, one that software vendors have largely ignored.
In a design verification and reliability lab, the protocol is the product. Before anyone touches a fixture, it has been written, reviewed, approved and version-controlled. At the bench, the job is to run it exactly as written and record each result against a defined acceptance criterion. Engineers and technicians do the work, and the basic unit is the test datasheet, not an experiment. What comes out is submission evidence: records that must hold up in an FDA or notified-body review and in an external audit.
For CSOs and R&D directors, this lab sets the pace. Every design change, supplier change, 510(k) and PMA supplement goes through it. Every record it produces may be examined by a regulator years later.
Many of these labs still run on paper.
What the paper test protocol packet really costs
The workflow is familiar to anyone in device test engineering:
Each protocol takes hours, sometimes days, of handling before anyone analyses a result. Most of the cost sits further downstream:
Historical data is effectively unsearchable. If an audit, CAPA investigation or submission needs a result from 18 months ago, finding it becomes a project.
Fixtures and consumables are untraceable. Lots and expiry dates live in a spreadsheet with no link to the tests that used them. For a Class II or III manufacturer, “which lot went into which test?” should take seconds to answer. Stock-outs that nobody saw coming also hold up test execution.
Transcription adds risk to data integrity. A number written by hand and typed in later needs a second check, so paper carries a permanent verification overhead and an ALCOA+ exposure.
Submission assembly turns into a crunch. Evidence spread across scans, spreadsheets and shared drives has to be pulled together by hand, usually just when the timeline is tightest.
Why paper survives in regulated device test labs
Calling this inertia misses the point. Paper persists for four reasons, and each is rational on its own. They also double as a checklist for any replacement.
1. The paper process is already validated
An auditor has already accepted the paper process. Replacing it means validating a new system, writing a quality system transition plan, and defending both. A replacement needs a 21 CFR Part 11 ready audit trail, electronic signatures that lock the record, and a vendor validation package your software validation engineers can actually work from.
2. IT won’t accept a vendor-controlled cloud
Many medical device IT and security teams have a firm rule that essential product data cannot sit in a cloud environment the company doesn’t control. Many ELN and LIMS vendors offer only their own hosted cloud, which rules them out before features are compared. For many device companies, deployment choice decides the purchase.
3. In a test lab, the technician produces the data
Tools built for scientists assume the person recording results also designed the work. Test labs separate those roles on purpose. One person writes the protocol and another, usually a test technician, runs it. Many lab tools ship a technician role that can comment, tick off steps and sign, but cannot enter results. That works in a wet lab and is backwards in a test lab.
4. A datasheet is a form, not a notebook page
A test datasheet has fixed fields, required entries and pass/fail logic. Supervisors need every run of the same protocol to produce a record with the same structure, so results can be compared and the report defended. Free text with an attachment doesn’t provide that.
What a lab management system for design verification needs to do
The four reasons above translate into seven selection criteria. They are listed roughly in the order device companies weigh them:
- Deployment control. Vendor cloud, your own cloud account, or your own servers, with separate production and validation instances.
- Regulatory evidence. A full audit trail, locking e-signatures, role-based access, and validation documents delivered with every release.
- Controlled protocol templates. A central repository, so every run starts from the approved version.
- Structured digital datasheets. Required fields, defined results structures, and no way to close a record with blank entries that should be marked N/A.
- Traceability for fixtures and consumables. Lot numbers, expiry dates, storage locations and barcode scanning, all linked to the test that used each item.
- Configurable roles. Technicians enter data, engineers review, and authorised signers sign, each with exactly the rights they need.
- Integration. A documented API so records can move into PLM, ERP and QMS systems.
How SciNote supports medical device design verification
SciNote is a lab management system that combines ELN, LIMS and SDMS capabilities on one platform. In a design verification lab, each layer has a clear job:
In practice, a test runs in one place. The technician opens the approved template, records results into a structured datasheet, scans the fixtures and consumables used, and submits. The reviewer signs, and the record locks. When a submission or audit needs that run later, it can be found in seconds instead of searched for in a filing cabinet.
Deployment on your terms
SciNote can run as a hosted cloud service, in your organisation’s own cloud account, or on your own servers. The local install is container-based, and production and validation environments are kept separate. If your IT team won’t accept a vendor-controlled cloud, that option alone keeps SciNote on the shortlist.
Validation support every release
With each major release, twice a year, SciNote provides an IQ template, an OQ template, a user requirements specification, release notes and role-based access control specifications. Your team performs the validation, and SciNote supplies the package and supports the work.
Compliance evidence that supplier quality can collect themselves
Supplier quality and software validation teams can download evidence directly from the SciNote Trust Center. That includes 21 CFR Part 11 documentation, ISO 27001:2022 and its Statement of Applicability, SOC 2 Type 1 and Type 2, CSA STAR Level 1, Cyber Essentials, and policies covering the SDLC, AI governance, change management, incident response and more. An Approved Supplier List review no longer has to be a six-week email thread.
What this means for R&D leadership
For the CSO: design verification is often the slowest stretch of the path to submission and the most exposed one in an audit. Structured, signed, searchable records turn submission readiness into something you can check at any time, and they remove the transcription risk that paper builds into every test.
For the Director of Discovery or Development: you get one standard platform across test engineering, analytical chemistry and sensor R&D, instead of a separate tool or paper process in each team. Templates keep runs consistent, inventory linkage closes the traceability gap, and the validation package makes it clear who is accountable for what.
For the Scientific or Test Lead: technicians enter data directly, datasheets enforce required fields, and records lock on signature. You stop chasing missing entries and re-checking transcribed numbers.
Five lessons for medical device test labs going paperless
- Ask about hosting in the first conversation. If IT won’t accept a vendor-controlled cloud, most of the market drops out immediately.
- Trial with your own protocol, not demo data. The gaps that matter only show up when a real 40-page datasheet meets the tool.
- Have a technician, not an engineer, run a full protocol during the trial. A permissions matrix won’t show you what they can’t do.
- Start supplier qualification alongside the technical evaluation. Approved Supplier List review, quality agreements and IT contract review run on their own clock, and that clock is often longer than software selection.
- Check that your contract template fits the deployment. A master agreement written for hosted SaaS may not cover an on-premise licence.
