Change-control starts with the change, not the document
Quality Management owns the SOPs, the change-control trail and the audit posture. Most QMS systems version the document and treat content as an attachment. DitaExchange makes content the unit of management, so every approved paragraph carries its own history and approval record.
Document-level QMS hides the change at the paragraph level
The QMS records that SOP-1052-v7 was approved on a date by named people. It does not record which paragraphs changed since v6, who wrote them, or which other SOPs reference them. The entry says document approved; the change itself is buried inside the document.
Component-level QMS records the change where it happens, at the fragment. Version history is queryable, propagation is logged, and the audit response shrinks from a reconstruction to a query.
"When did this control change, and where else does it live?"
The same auditor question, asked of a document-level QMS and a component-level one. The work the quality team has to do to answer differs by a factor that matters at inspection time.
A guidance library drifts the moment it leaves the library
The same mechanics apply to the guidance a quality function owns: the methodology, the work instructions, the templates every team is supposed to work from. Somebody takes a copy and adapts it, the next team copies the copy, and by the third one the guidance in use bears a familial resemblance to the canonical version and not much more.
Referencing removes the copying. Each team's deliverable points at the canonical component and resolves to the current approved version when it is assembled, so an update propagates instead of being announced. Where-used reporting then answers the question that makes withdrawal possible at all: who is still reading the version you are about to retire.
What changes for Quality
| What changes | How |
|---|---|
| Change-control at the granularity the change actually has | Version history at the component, not the document. The change is captured where it happened, not at the assembly that contains it. |
| 21 CFR Part 11 and Annex 11 alignment without bolt-on tooling | Attributable, contemporaneous, original, accurate, retained. Captured at the fragment, through the SharePoint identity model your IT already operates. |
| Controlled-language enforcement that is not somebody else’s problem | DxChecker. Configurable rules run at authoring time inside DxAuthor+, across libraries on a schedule, or via workflow. Defects caught structurally, not in review. |
| SOP propagation that does not depend on remembering | An approved SOP component refreshes every document that references it. The dependency tree is queryable; the propagation is logged. |
| Release freezes for audit and inspection | Snapshot capability, freeze a version of the content at any point in time. Inspections and audits read against the snapshot rather than a moving target. |
The compliance overlay across sectors
Pharma and medical device
FDA QMSR (effective February 2026), ISO 13485, 21 CFR Part 11, EU GMP Annex 11, EMA pharmacovigilance system master files.
Aerospace and defense
AS9100 derivatives, NATO STANAG quality clauses, MIL-STD documentation requirements.
Nuclear and energy
IAEA quality standards, multi-decade asset documentation, decommissioning records.
Financial services
DORA operational resilience, ISO 27001, EU regulatory disclosure under MiFID II.
None of these frameworks specifies a CCMS. All of them assume the change-control trail can be retrieved at the granularity the change happened.
Frequently asked questions
Does this replace our QMS?
No. The controlled-document register and the sign-off process your quality system runs stay where they are. What moves is the content underneath those documents, from files to components carrying their own version and approval history. The two are connected through the SharePoint API, the Dx5 API, or a Power Automate flow in the tenant you already run.
What does validation look like, and what reduces it?
The scope is yours to set against your own procedures, and we hand you no compliance claim to shortcut it. What reduces the work is that identity, access control, audit logging, backup and data residency are the tenant's, already cleared for SharePoint, and Dx5 adds no separate plan for any of them. Bring your validation approach to the first conversation rather than the last.
Our rules live in an SOP. What does it take to make them checkable?
Each rule becomes a human-readable XML file with an assert statement, optional auto-fix instructions, and a record of who created and approved it, so the rule itself is a controlled artifact rather than a script somebody wrote. Rules assemble into rulesets, from one rule to several hundred. Literal text, patterns, document structure, references and XML schema validation are all rule types.
Can Quality check the whole library rather than one document at a time?
DxChecker Server runs a ruleset across a folder, a SharePoint library or a whole repository, on a schedule or on demand, with reports surfaced where compliance and quality teams already work. The same rules can gate a workflow through the DxChecker API, so a document fails before it moves downstream rather than after somebody notices in review.
Is there a record of what the platform did, not just what people did?
Yes, and it matters more than it sounds. The job history and monitoring dashboard logs every background operation, so propagation and publishing runs are evidenced rather than assumed. Underneath that, SharePoint's own audit log covers item-level activity and feeds Microsoft Sentinel or another SIEM through standard connectors, because a component is a SharePoint item.
Start with the SOP family where the next inspection is loudest
Most Quality rollouts begin with the SOP set where the inspection cost of inconsistency is most visible. The change-control trail tightens immediately; the rest of the controlled-documents library follows.
