How Does an Electronic QMS Meet MDSAP's Requirements?
Summary
MDSAP relies on ISO 13485 for the control of documents, records, and training. This article follows one document through our own electronic QMS, from creation to an effective, trained-on version, and shows where each control meets the requirement.
One version is in force at any time, the previous version is retired automatically, electronic signatures are attributable to a named person, and the audit trail is produced by the normal work rather than assembled before an audit.
Part 1 set out what MDSAP asks of an electronic QMS. The requirements come from ISO 13485: control of documents, control of records, and training and competence, together with the record and signature integrity that regulators such as the FDA expect.
This article shows the other half.
Meeting a requirement on paper is one thing. Running a system that meets it every day, one the team can actually use without it slowing them down, is the part that decides whether a quality system works or becomes a burden.
We built our eQMS on ISO 13485. Here we follow a single document through it, to show how the controls hold and how the system is built to be used.
How the System Is Structured
The system is organised as a hierarchy, and each level inherits from the one above it. Understanding that structure is the key to what follows.
There are three levels:
Category
The top grouping under which documents are filed; it gives each document its number.
QMS Document
The parent record that holds everything shared across a document's life: its name, its type, and the access settings that decide who authors, reviews, approves, and is trained on it.
Document Version
An individual file created under that parent; only one version is effective at any moment.
Inheritance is what makes this practical.
The access settings and rules are defined once, on the parent record, and every version created beneath it takes them on. A new version does not require re-entering who may approve it or who has to be trained on it.
That is decided once and applied consistently, which removes a common source of error: a new revision that quietly goes out under the wrong approvers or to the wrong audience.
[EMBED: All_QMS_Master_Documents_list.png]
Control of Documents: One Version in Force
Control of documents means the current version is available where it is needed, changes are approved before the document is used, and superseded versions are retired. ISO 13485 sets this requirement. The system enforces it through a controlled release.
A document begins as a version created from a template, with the status Draft. When it is ready, the author starts the release.
The release process asks for the review and approval settings and the people who will approve. Starting it is itself a signed action.
[EMBED: start-document-relase.png]
[EMBED: document-release-process-interface.png]
Where reviewers are assigned, they review and sign first. The approver then approves, confirms the attestation, and signs.
At the release stage, the effective date and the next review date are set. The document can be released immediately or scheduled to become effective on its planned date.
[EMBED: select-approvers.png]
The control that matters most for an audit happens at the moment the new version becomes effective. The version it replaces becomes Obsolete automatically.
There is no separate step to retire the old document, and no window in which two versions are both in force. The current document is never in question, which is what control of documents asks for: obsolete documents controlled, and the current version the one in use.
[EMBED: document-release-initiated.png]
The document status that drives this (Draft, Approved, Effective, Obsolete) is set by the system through the release process and cannot be changed by hand. A separate working status lets teams label their own progress, with no effect on the controlled lifecycle. The status an auditor relies on is the one the system sets, not one a user can move.
Records and Signatures: Evidence as a By-Product
Control of records means the evidence is attributable, protected from undocumented change, and retrievable when needed. This is control of records, and for FDA-regulated work it is where the electronic-signature expectations of 21 CFR Part 11 apply.
The system produces this evidence as a by-product of the normal work, rather than as a separate exercise before an audit.
Every signing action is confirmed with a personal Signature PIN. The PIN is set by the individual and held only by them, so each signature is attributable to a single named person. Until a user sets their PIN, they cannot perform any action that requires a signature.
[EMBED: Signature_pin_set.png]
[EMBED: start-release-attestation-pin.png]
Each release produces an approval record. It shows what was submitted and by whom, the review status and who reviewed it, and the approval status with the date and any comments.
These fields are read-only. The decisions were made through the release process, so the record exists to be the audit trail, not to be edited after the fact.
[EMBED: Document_approval_record.png]
The result is that the evidence an auditor asks for already exists. Who approved a document, when, against which version, and with what signature is recorded at the moment the work happened. Nothing has to be reconstructed, and because the controlled records cannot be altered by hand, what the system shows is what occurred.
Training That Follows the Document
Training and competence means the people who rely on a document are trained on it, and that the training is recorded. The system ties training to the document itself.
Training is generated from the document's Target Audience, which is defined on the parent record and inherited by each version. When a version is released, the training is created for the people in that audience.
They complete it from their Dashboard, either by confirming they have read and understood the document or by answering a questionnaire with a pass mark, depending on how the training is configured. Where a document requires training before it takes effect, the audience completes it in the window before the effective date.
[EMBED: Version_training_tab.png]
[EMBED: My_trainings_list.png]
Each person's Dashboard shows only the effective version of the documents assigned to them, grouped by category, alongside the trainings they owe — overdue, due soon, pending, or completed.
Because the view is built from their assignments, a person is always pointed at the current version and can see what they still have to complete. This closes the loop that control of documents opens: a document changes, the previous version is retired, the new one takes effect, and the people who use it are trained on it, with each step recorded.
[EMBED: Dashboard_my_documents.png]
The Logic Behind the Design
The controls above satisfy the requirement. How they were designed is a separate question, and it is the one that decides whether people actually use the system.
Our approach to that is simplicity.
A quality system only works if the people who depend on it can stand using it day to day. So the design goal is the simplest solution that meets the requirement, not the most elaborate one. A system people avoid does not help a company, however complete it looks on paper.
ISO 13485 leaves room for this. The standard states what must be done, and not how to do it.
Control of documents and control of records require that a document is approved, kept current, and retired when superseded, and that records stay legible, retrievable, and retained.
They do not say how to build the system that does it. The implementation is left to the organisation, and the simplest one that satisfies the requirement is usually the best, because more can be added later when a real need appears.
The distance between what the standard specifies and what a working system needs is wider than it looks.
Computer system validation is one example. In ISO 13485 it is close to a single paragraph: the organisation validates the software it uses and keeps records of that validation.
Building the actual process meant working from how a company had really done it and adding controls where they were needed, not from the text of the standard. The standard tells you the control has to exist. It does not design it for you.
This is also why we lean on what the platform already provides rather than rebuilding it.
A working environment gives a great deal for free: a record of who created and changed each item, version history, and a framework for views, forms, and collaboration. Much of what a quality system needs on paper is already there, so the work is to configure it sensibly. Keeping that layer thin keeps the system simple to run, and quick to change as needs shift.
The same instinct shows in the smaller decisions.
We derive whether a document needs review from whether a reviewer is assigned to it. Earlier this was a separate setting to switch on or off. We changed it because the separate setting was one more thing to get wrong: a document could be marked as requiring review with no reviewer named, or the reverse.
Deriving the step from the assignment removes that contradiction. If there is a reviewer, there is a review; if there is not, there is not.
We renamed the parent record. It was originally the Master Document, and we found the term confused people, so it is now the QMS Document. The record did not change, only the name, but a name people read correctly is part of a system being usable.
We allow one training to cover several document versions. When related documents change together, the people affected complete a single training rather than a series of near-identical ones. The competence evidence is still recorded per person, but the work of staying trained does not multiply with every small related change.
None of these decisions changes what the system controls. Each changes how much effort it takes to run it correctly, which is the difference between a quality system people follow and one they work around.
What This Shows
Followed end to end, an electronic QMS built on ISO 13485 meets MDSAP's requirements for documents, records, and training in the course of normal work.
One version is in force and available. The previous version is retired the moment the new one takes effect. Signatures are attributable, and the audit trail is a by-product rather than a preparation. Training follows the document that changed, and it is recorded.
This is the part of MDSAP an electronic QMS carries directly.
The boundary is worth being clear about: the eQMS is the backbone for controlling documents, records, and training. The process-level parts of MDSAP, corrective and preventive action, complaint handling, management review, sit beyond that backbone. How a system extends to reach them is a separate subject, and one we will return to.
Frequently Asked Questions
How does an electronic QMS control which document version is in force?
Through a controlled release. When a new version becomes effective, the version it replaces is marked obsolete automatically. Only one version is effective at any time, so the current document is never in doubt, which meets the ISO 13485 requirement for control of documents.
What happens to the old version when a document is updated?
It becomes obsolete automatically at the moment the new version takes effect. There is no separate step to retire it, and no period in which two versions are both in force.
How are electronic signatures handled in an eQMS?
Each signing action is confirmed with a personal Signature PIN, set and held only by the individual. This makes every signature attributable to a named person, which supports the electronic-signature expectations under 21 CFR Part 11.
Where does the audit trail come from in an electronic QMS?
It is produced by the normal work. Each release creates a read-only approval record showing who submitted, reviewed, and approved the document, and when. The evidence exists at the moment the work happens rather than being assembled before an audit.
How does an eQMS make sure people are trained on the current document?
Training is generated from the document's target audience when a version is released, and the audience completes it from their dashboard. Each person sees only the effective version of their documents, so training follows the current document and is recorded per person, meeting the ISO 13485 requirement for training and competence.
