The 10.3 release from qmsWrapper packages QMS work into three layers — Foundation, Lifecycle, and Vigilance. On a slide it reads cleanly. In a two-person QA/RA function it reads as three new places where someone has to remember to do the thing. That is the honest tension I want to walk through.
What the three levels actually claim to do
Foundation is where the structural documents live — quality manual, procedures, the things auditors open the file with. Lifecycle is the operational engine: change control, CAPA, document control, training, supplier management. Vigilance is the post-market layer — complaints, vigilance reporting, PSUR, the things that keep you in the notified body's good books after the certificate is issued.
The split is sensible. To be fair, it roughly mirrors how MDR Annex II and Annex IX want you to think — pre-market evidence and post-market evidence are not the same workflow, and the granularity of vigilance activity is genuinely heavier than for a pure design-control change. A vendor naming those layers explicitly is helpful, because most eQMS tools smear them into a single module and leave you to draw the boundary yourself.
Where it earns its keep
The good idea here is that the three layers are supposed to be connected, not three separate databases. A change request in Lifecycle should be able to pull impacted documents from Foundation and trigger a vigilance review if the change touches post-market data. Forms are where quality data begins, and most QMS pain is friction at form boundaries — so a connected workflow is the whole-system pitch I want to hear.
In practice this means: when a CAPA references a non-conformance, the link should resolve to the actual record, not a copy-paste of a number. When a change is approved, the linked procedures should re-route for review automatically. When a complaint escalates to a vigilance event, the PSUR section that depends on it should know.
That is the right ambition. I have lost more hours than I care to count chasing traceability gaps where the link was technically present in the system but semantically wrong.
Where I start to worry — onboarding friction
The worry is what it costs a small team to stand this up. Three levels means three onboarding paths, three sets of templates, three sets of permissions to think about. A two-person QA/RA function does not have a dedicated system administrator. Whoever sets it up is the same person who has to answer the notified body's deficiency list next month.
Granting that vendors cannot build a one-size-fits-all template. But a lean start — a single recommended path that gets you to a defensible Technical File workflow in two weeks, with the other two layers activated when you are ready — would be kinder than presenting all three on day one. The current framing reads as "here are three layers, configure them" rather than "here is the smallest version that keeps your data linked from day one, expand later."
I have watched too many QMS rollouts stall at month four because the team tried to build the full lifecycle and the vigilance layer at the same time and ended up with a half-built Foundation instead.
The bigger worry — ownership at the handoffs
Three levels means three handoffs. Foundation to Lifecycle, Lifecycle to Vigilance. Someone has to own each one, and in most SMEs I have worked with or talked to, that someone is the same person wearing a different hat.
Per Article 10 of MDR, the manufacturer is responsible for keeping the technical documentation and the post-market system updated. Per ISO 13485 clause 8, controls apply across the whole QMS, not within isolated modules. Neither regulation cares whether your eQMS calls them Foundation, Lifecycle, or Vigilance — they care that you can demonstrate the link.
In practice, the handoff that breaks most often is from Lifecycle to Vigilance. A change is implemented, a CAPA is closed, and then nobody updates the post-market surveillance plan to reflect the new state. The link is meant to be automatic. In my experience it almost never is, because the trigger condition lives in a different module and the system does not push it forward — it relies on a human to act.
What a lean start could actually look like
If I were advising a 10-person medtech team standing this up tomorrow, I would tell them to start with Foundation plus Lifecycle, leave Vigilance as a configured-but-read-only shell, and turn it on once the first device is on the market. The first CE-marking submission does not need a full vigilance workflow — it needs a complaints process and a PMS plan. Everything else can wait.
That is not a criticism of the three-level model. It is a request to make the door in smaller. A 10.3 release that ships with an opinionated "first 30 days" template — Foundation documents for one device family, one change workflow, one CAPA workflow, complaints routed to a single inbox — would do more for adoption than another dashboard tile.
Open question
For those of you running QMS at a small medtech: when you onboard a layered eQMS, do you actually configure all the layers at once, or do you stand up the core and let the rest grow into the system? I am curious whether the three-level framing helps or hurts that decision in practice.
Disclosure: I work on qmsWrapper.
Top comments (0)