How Does an Electronic QMS Meet MDSAP's Requirements?
By Vaclav Vlcek, MD
Summary:
Part 1 set out the three controls in the MDSAP Audit Approach that are particularly relevant to an electronic QMS: control of documents and records, personnel competence, and validation of the software for its intended use. This article follows one document through our own eQMS against them. One version is in force at any time, the superseded version is kept rather than overwritten, signatures are tied to a named person, and a change is handled according to whether it affects the work people do. The system supports an organisation in meeting these requirements. It cannot meet them on the organisation's behalf.
Part 1 set out what the current MDSAP Audit Approach asks an auditor to confirm. The version in force is AU P0002.011, revised 3 August 2026.
This article shows the other half.
Meeting the audit criteria is the baseline. Running a system the team can use every day, without it slowing them down, is the part that decides whether a quality system holds up or turns into a burden.
We designed our eQMS to support an organisation's ISO 13485 quality system, and it is the system we run our own quality work on. What follows is that system as we use it. A customer's version is configured to their processes and to the markets they are entering, so the detail differs; the controls described here are the ones that hold in either case.
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.
The top grouping under which documents are filed; it gives each document its number.
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.
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.
Access and responsibility are usually assigned by role.
A document's author, reviewers and approvers are usually Roles rather than named people. The author might be the Risk Manager, the reviewer the Quality Manager. Named individuals can be assigned where that is what a company wants, though in practice roles are the norm. Because a role is held by a group, access and the training that comes with a document are managed in one place, and when someone joins or changes role their access and obligations follow the role.
Control of Documents and Records
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 and kept. The system enforces this 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 runs as a single guided dialog. It brings the document version and the release plan into one place, with a stage bar showing where the release stands and a banner naming the next action needed, for example defining an approver before the release can start. Each part carries its own status. A release plan can be saved while it is still incomplete, and the release itself cannot be started until what it needs is in place.
The reviewers, approvers and target audience are drawn from the document's own settings, so nobody re-keys who does what. Starting the release is itself a signed action.
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 next-review date is calculated from the document's Criticality Index, and can also be entered by hand. The document can be released immediately or scheduled to become effective on its planned date.
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.
The Superseded Version Is Kept, Not Overwritten
Part 1 set out the retention rule: at least one obsolete copy of every controlled document, held for at least the lifetime of the device and never less than two years from the date of product release.
This is where the version model earns its place. A superseded version is marked obsolete and kept as a record in its own right, alongside the approval record that released it. The system stores history rather than only the current state.
A document builds up versions over its life, and each one can be retrieved with the evidence of who approved it and when. What the system does is store and retrieve superseded versions and let them be managed according to the retention rules a company has set. The retention periods themselves, and the controls over who may delete anything, remain the organisation's to define, since they depend on the device and the markets in scope.
The document statuses that drive this, from Draft and Approved to Effective and Obsolete, are 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.
The list of QMS Documents also serves as a current list of what is approved and effective, which is the kind of thing several markets ask for specifically. Brazil, as Part 1 noted, requires a list of approved and effective documents, together with change records and backups of electronic records. Which of those the system answers directly, and which depend on how it is set up, is a question for a specific implementation rather than a claim to make in general.
One limit on this walkthrough is worth naming. The audit covers documents and records of both internal and external origin. What follows is mainly about documents a company writes and controls itself, and the records its releases produce.
Records and Signatures
Controlled records have to stay identifiable, legible, protected, retrievable and kept for as long as the rules require. For a release record, the decisions also have to be traceable to a person. What this section shows is the evidence a release produces, which is one part of controlling records rather than the whole of it.
Every signing action is confirmed with a personal Signature PIN, a simplified electronic signature. The PIN stands in for the person's signature. It is set by that person and intended to be known and used only by them, and each time it is used it carries a statement that they are accountable for the signature and have not shared their credentials. That ties the signature to one named individual. Until a user sets their PIN, they cannot do anything that requires a signature.
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 forms the release audit trail. Dataverse, the data layer beneath the app, holds the records themselves: the tables, the audit logs, the approvals and the signatures. How much is logged, and for how long, depends on how the environment is set up, which is part of what an organisation configures and validates.
Questions raised during a release are recorded as consultations and stay with the release, so a query is answered against the release itself rather than in email. The person who raised one can delete it while it has no replies; once there are replies it can only be closed. Those threads form part of the same trail.
The result is that much of the evidence an auditor asks for already exists. Who approved a document, when, against which version, and with what signature is recorded as the work happens rather than assembled afterwards.
Competence, and the Two Kinds of Change
Part 1 set out what changed in the current Audit Approach: the personnel task was refocused from training to competence, and the audit does not stop at attendance. It examines whether the action taken achieved the required competence, with a check proportionate to the risk of the work.
Deciding what a change requires is the organisation's job, and it records that decision under its own quality system. What the software does is support the work that follows from it.
The system separates two kinds of change.
A revision that alters the document itself becomes a new Document Version. It goes through review, approval and release, and where training is required and set up, the release creates or assigns training for the document's Target Audience, inherited from the parent record.
A change to a value or a cross-reference used across several documents is handled centrally in the Content Manager. Editing the value there lists every document that uses it, with an indicator showing which ones no longer match, and the new value can then be pushed into those that are out of date.
The limit on that is the part worth knowing. A push cannot touch a version that is effective, obsolete, or already in the middle of a release. It reaches drafts only. A released document is changed the way any released document is changed, by creating a new version and taking it through review, approval and release.
Evidence Beyond Attendance
Training is completed in one of two ways, and the difference matters for what the record shows.
A read-and-understood training records that a person confirmed they have read the document. A questionnaire training asks them to answer questions, with a Pass threshold set as the number of correct answers needed out of the total, shown as a percentage. Someone who does not reach the threshold takes the training again.
The record that comes out of that is a pass or a fail against the threshold, rather than the individual answers. It goes further than a read-and-understood acknowledgement, and it is one input among several. Competence itself rests on education, training, skills and experience together, so a questionnaire result contributes evidence rather than settling the question on its own.
The training content is itself controlled. Where approval is required, a training version goes through review and approval before it becomes effective. The questions people answer are approved material rather than something put together on the spot.
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 pointed at the current version and can see what they still have to complete.
A Coverage Gaps view lists document versions that have no training, or whose training is rejected or obsolete. It is there to make a gap visible so someone can act on it. It does not block a release: if a version is released with no training created, the system warns and asks whether to go ahead anyway, and the decision sits with the person releasing it.
Validating the System Itself
Part 1 set out a requirement that is easy to read past. The Audit Approach expects software used in the quality management system to be validated for its intended use, against a written protocol, and that applies to software bought in rather than built.
This is the point at which the division of responsibility has to be stated plainly.
We build and supply the system, and we can supply what a validation draws on: what the software does, how the controls described in this article behave, what changed in a release, and our own test evidence. The validation itself belongs to the organisation. It sets out its own intended use and what it needs the system to do, decides in advance what a successful result looks like, runs the protocol against its own setup, and keeps the records.
The thing being validated is the configured system, not the product in the abstract. That means the workflows in use, who has which permissions, any connections to other systems, the signature settings, what the environment logs and for how long, and the retention and backup arrangements. When any of that changes, the change goes through change control and is revalidated where the change warrants it.
No vendor can hand over MDSAP or ISO 13485 conformity with a product. An auditor examines the manufacturer's use of the system, including whether it was validated for the use the manufacturer puts it to.
This is ordinary computer system validation work, and it is the reason the last section of this article matters as much as the controls above it. A system that is simple to describe is simpler to validate.
The Logic Behind the Design
The controls above support the requirement. The design decides whether people use the system at all.
The foundational choice is that the eQMS completes the customer's environment rather than replacing it.
It is built on the Microsoft Power Platform and the wider Microsoft stack, so it extends the tools an organisation already runs: SharePoint, Dataverse, Power Automate, Teams. This is the same principle QMLogic applies everywhere: use what works, extend what does not, and fit the tool to the organisation. It is also what makes adoption easier, because there is less to learn and less to rip out.
From there, the guiding instinct 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. A system people avoid does not help a company, however complete it looks on paper.
ISO 13485 leaves room for this. It sets out the controls that have to exist and leaves most of the choices about building them to the organisation.
Control of documents and control of records, the two requirements a document-control system touches most, say 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.
Validating the software a quality system runs on is one example. The standard covers it briefly: a documented approach, scaled to the risk involved, with the software validated before it is first used and again where a change calls for it, and records kept. It says what has to be true and leaves the building of it to the organisation. Working out the actual process meant starting from how a company had really done it and adding controls where they were needed.
Working on the Microsoft stack also means much of what a quality system needs is already there.
The platform provides a record of who created and changed each item, version history, and a framework for views, forms and collaboration. A good deal of the machinery a QMS needs on paper comes with the environment, so the work is to configure it sensibly. Keeping that layer thin keeps the system simple to run, simpler to validate, 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 training evidence is still recorded per person, and 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 supports the three controls Part 1 set out, in the course of normal work.
One version is in force and available. The superseded version is kept rather than overwritten, and can be retrieved. Signatures are tied to a named person, and the trail is created as the work happens. Where a change calls for training, the record shows a pass or a fail against a set threshold rather than only a read-and-understood acknowledgement.
The software validation belongs to the organisation, and a system that is simple to describe is simpler to validate.
This walkthrough covers controlling documents, records and training. Other parts of the audit, such as corrective and preventive action, complaint handling and management review, sit outside what is described here. How a system extends to cover them is a separate subject, and one we will return to.
Frequently Asked Questions
How does QMLogic eQMS 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.
What happens in QMLogic eQMS when a document is updated?
It is marked obsolete automatically at the moment the new version takes effect, and kept as a record alongside the approval record that released it. Nothing is overwritten. The system stores and retrieves superseded versions; how long they are kept, and who may remove anything, is set by the organisation to match the retention rules that apply to it.
How does QMLogic eQMS handle electronic signatures?
Each signing action is confirmed with a personal Signature PIN, a simplified electronic signature set by the individual and intended to be known only by them, carrying a statement of accountability each time it is used. This ties every signature to a named person.
Where does the release audit trail in QMLogic eQMS come from?
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. Questions raised during the release are recorded as consultations kept with the release; the person who raised one can delete it while it has no replies, and once there are replies it can only be closed. How much the wider environment logs, and for how long, depends on how it is configured.
Does every document change require retraining?
No. Deciding what a change requires is the organisation's judgment, recorded under its own quality system. In the software, a revision to the document becomes a new controlled version, and where training is required and set up the release creates or assigns it. A change to a shared value or cross-reference can be handled centrally in the Content Manager, which shows which documents no longer match and can push the new value into drafts. It cannot alter a version that is effective, obsolete or mid-release.
What training evidence does QMLogic eQMS produce?
A questionnaire training asks a person to answer questions against a pass threshold, the number of correct answers needed out of the total. Someone below the threshold takes the training again. The record is a pass or a fail against that threshold rather than the individual answers. It goes further than a read-and-understood acknowledgement, and it is one input into competence rather than proof of it on its own.
Does an eQMS need to be validated for MDSAP?
Yes. The MDSAP Audit Approach expects software used in the quality management system to be validated for its intended use, and that includes software bought in rather than built. The supplier can provide what a validation draws on; the organisation sets out its own intended use, decides in advance what a successful result looks like, runs the protocol against its own setup, and keeps the records. What is validated is the configured system, including workflows, permissions, connections, signature settings, logging and retention, revalidated where a change warrants it.
Does using a compliant eQMS make our quality system compliant?
No. Conformity belongs to the organisation. An auditor looks at how the manufacturer uses the system, including whether it was validated for the use the manufacturer puts it to. No product can hand over conformity.
