QMS controls quality processes, RIM organizes regulatory information and activities, and EDMS controls documents through their lifecycle. They can share a platform or be separate applications. The useful distinction is which record and decision each function owns—not how many software logos appear in the architecture.
A quality team can approve a change without having completed every required regulatory assessment. A regulatory team can record a planned filing without having an approved source document ready. An EDMS can hold that document without deciding whether a filing is needed. Treating those three statuses as one creates an avoidable handoff problem.
This guide provides an operating-responsibility matrix, a worked change example and an interface record you can adapt. It does not prescribe a particular vendor or make a filing-pathway decision for your product. The example controls are suggested working practices; apply them through your own responsibilities, procedures and applicable requirements.
The three functions and the questions they answer
| Function | Main question | Typical records or information | What the label alone does not establish |
|---|---|---|---|
| Quality management system, QMS | Was the quality process performed, assessed and approved appropriately? | Procedures, training, investigations, CAPA, quality changes and supplier oversight | Which market-specific regulatory action is required or whether it has occurred |
| Regulatory information management, RIM | What is the product's regulatory position, and what regulatory work remains? | Product/application context, registrations, submission plans, correspondence and commitments | Whether the underlying quality activity is complete or the source evidence is acceptable |
| Electronic document management system, EDMS | Which document and version is this, and what is its controlled state? | Document identity, metadata, revisions, approval history and controlled renditions | Whether a quality event is resolved or a regulatory decision is correct |
These are functional distinctions. A QMS is an organizational management system; eQMS software supports parts of it. RIM is an information-management discipline that software can support. An EDMS is a document-control application that may sit inside either software offering. A business process does not disappear because two functions share one database.
For pharmaceutical quality, FDA's April 2009 ICH Q10 Pharmaceutical Quality System guidance describes a management-system model, including monitoring, CAPA, change management and management review. It is guidance about the pharmaceutical quality system, not a specification for purchasing one commercial application. FDA Q10 guidance.
RIM product boundaries vary. As a concrete vendor example, Veeva identifies Registrations, Submissions, Submissions Publishing and Submissions Archive as distinct applications within its RIM offering. That illustrates why a “RIM” label does not prove that every document or publishing function is included in a particular purchase. Veeva RIM application descriptions.
For a product-specific application of this distinction, see Veeva Vault QMS versus RIM. Once the required regulatory records and activities are defined, the RIM software comparison helps turn that scope into a vendor evaluation.
Assign authority to a record or decision, not an entire department's data
“Quality owns QMS and Regulatory owns RIM” is a start, but it leaves shared work ambiguous. Decide who can approve each business decision, where its authoritative record lives and which other systems can display or consume it.
Use this matrix as a starting point. The suggested owners are roles to assign explicitly in your organization, not a claim that every company uses the same job titles. The authoritative location may be a module in a shared platform or a separate system.
| Item | Suggested accountable role | Authoritative record | What the other function should receive |
|---|---|---|---|
| Quality investigation and conclusion | Quality process owner | Controlled investigation record in the quality process | Relevant approved evidence and the investigation's actual status |
| Document approval and revision state | Document/process owner under the approval procedure | Controlled document record in the designated EDMS | Stable document ID, exact version and state required for the intended use |
| Regulatory impact decision | Assigned regulatory decision-maker | Approved assessment with product/application/market scope | Decision, conditions, rationale reference and reassessment trigger |
| Submission plan | Regulatory operations owner | Controlled plan for the identified application/activity | Required source evidence, milestones and unresolved dependencies |
| Quality implementation evidence | Quality/operations owner for the change | Implementation and verification records | Completion evidence relevant to the regulatory decision or commitment |
| Health authority correspondence | Regulatory owner | Correspondence record with application and date context | Assigned actions and linked source request, with appropriate permissions |
| Commitment completion decision | Assigned regulatory owner, with execution owners identified | Commitment record and accepted evidence reference | Closure or remaining action, without overwriting underlying quality records |
| Product/site identity mapping | Named data steward | Agreed master or cross-reference registry | Durable IDs and reviewed mapping changes |
The regulatory impact assessment can physically live within a QMS workflow, in RIM or in another controlled location. Choose one authoritative decision record. A second system may show a reference or synchronized status, but should not create an independently editable competing conclusion.
The same principle applies to documents. A quality record can reference a document whose bytes and version history live in a separate EDMS. The QMS's event status and the EDMS's document state describe different things. Closing an investigation should not silently change a document's approval state, and approving a document should not silently close a regulatory commitment.
Where the handoff begins: a change with regulatory relevance
Change control is a useful first workflow to map because a proposed quality change may need a regulatory assessment. ICH Q10 section 3.2.3 recommends evaluating proposed changes relative to the marketing authorization and assessing whether regional requirements call for a regulatory filing change, with appropriate cross-functional expertise. It also distinguishes lifecycle stages. That supports a deliberate assessment step; it does not assign one filing category to every change. ICH Q10, change management, section 3.2.3.
The same operating pattern can apply when a CAPA leads to a process revision, a supplier notifies a sponsor of a change or an authority question requires quality evidence. First identify the event and its evidence, then assign the regulatory question. Do not assume every quality event creates a filing, or that a closed quality record means no regulatory work remains.
Keep separate status fields where the meanings differ. For example:
- Quality change: proposed, under assessment, approved for the defined next step, implemented or closed under your procedure.
- Regulatory assessment: pending, additional information required or decision approved for the stated scope.
- Source document: draft, approved/effective or superseded under its document lifecycle.
- Regulatory activity: planned, prepared, submitted or at another accurately defined stage.
These labels are illustrative. Define your own controlled values and their meaning once, then map system-specific labels to them. The important condition is that “approved” never travels across an interface without identifying what was approved and by whom.
Worked example: one specification, two versions and two decisions
Assume a fictional sponsor is reviewing change CHG-014 concerning a specification for product P-100. The controlled source SPEC-020 has effective revision 3; revision 4 is a draft under review. The product has application records in two markets. These are invented identifiers, not a real case or a tested software integration.
Step 1: Quality describes the change. The quality process owner records what is proposed, why, which records support it and which evidence is still missing. CHG-014 references SPEC-020 revision 3 as the current baseline and revision 4 as the proposed content. It does not merely link to “the latest specification.”
Step 2: Regulatory accepts a defined assessment request. The receiving owner checks that P-100 and both application/market references resolve to known records. Regulatory assesses the proposal for each relevant scope and records the decision and any implementation conditions. This example deliberately assigns no filing category; that conclusion requires product-, market- and change-specific evaluation.
Step 3: Document approval proceeds under its own control. The EDMS maintains revision 4's actual status. A regulatory reviewer seeing the draft does not convert it into an approved document. If a prepared narrative used revision 3, that relationship remains identifiable when revision 4 later changes state.
Step 4: Implementation follows the agreed conditions. The quality/operations owner obtains the applicable authorizations and completes the defined work. Evidence of implementation is returned to the appropriate regulatory activity or commitment when needed. An interface receipt saying “message delivered” is not evidence that a human assessment or implementation occurred.
Step 5: Each owner closes only their own obligation. Quality may close its record after its criteria are met; Regulatory updates the relevant assessment, activity or commitment according to its own evidence. The two records remain linked, with differing statuses allowed when they represent different stages.
This design supports useful cross-functional visibility without granting either team silent authority over the other's controlled decision. For the wider source-evidence chain, see quality-to-regulatory traceability.
Define the interface before automating it
Copy this interface record for one workflow. Fill the examples with your actual identifiers, systems, roles and acceptance rules. A manually controlled handoff can use the same contract as an API integration; the transport does not define the business meaning.
| Field or rule | Example for CHG-014 | Acceptance question |
|---|---|---|
| Event identity | Source system plus CHG-014 and event revision | Can the receiver distinguish an update from a duplicate? |
| Business object | Product P-100 with agreed master identifier | Does it resolve to one intended product rather than a name match? |
| Regulatory scope | Explicit application and market identifiers | Is each affected scope identified, or is discovery still required? |
| Source evidence | SPEC-020 revision 3 baseline; revision 4 proposed | Are version and state explicit for each intended use? |
| Requested decision | Assess regulatory impact of the described proposal | Is the receiver being asked to assess, approve, acknowledge or implement? |
| Decision owner | Named accountable role and assigned person/team | Is someone authorized and responsible to act? |
| Readiness rule | Required evidence present; missing items identified | Can the assessment proceed under the agreed procedure? |
| Response | Decision record ID, version, scope and conditions | Can the sender retrieve the approved response and its limits? |
| Change notification | Reassess if the described proposal or relevant source changes | What invalidates reliance on the earlier response? |
| Delivery/reconciliation | Receipt, business acceptance and exception owner | Can the team detect messages delivered but not accepted? |
| Access | Role-appropriate link or permitted evidence package | Can the intended reviewer read it without excessive access? |
| Retention/exit | Location and retrieval owner for the preserved record | Will the decision and source context remain retrievable? |
Make the contract machine-readable if automation needs it, but keep a human-readable version with the procedure. An AI assistant comparing records needs the same explicit identity, state, scope and ownership that a person does. An acronym or document title cannot safely substitute for those fields.
Fail closed when the record is ambiguous
Failing closed here means do not mark the specific handoff or decision ready until the ambiguity is resolved. It does not mean automatically stopping unrelated manufacturing or changing a legal deadline. Route the exception to its accountable owner under the approved procedure.
If two product records share a similar display name, do not choose the first search result. Request the authoritative identifier or have the data steward resolve the mapping. Preserve the original input and resolution so a retry does not quietly select something different.
If an assessment request says “use the approved specification” but points to a draft, keep the request unresolved. Ask whether the reviewer needs the current approved baseline or the proposed revision for assessment. Those are both legitimate uses, but they are different inputs. Do not silently replace the draft with the effective version and assume the question is unchanged.
If both QMS and RIM contain different filing conclusions, do not let the latest timestamp decide authority. Identify the approved decision record, its scope and any superseding assessment. Resolve the conflict with the assigned regulatory decision-maker before using either conclusion to satisfy the handoff.
Finally, test duplicate and delayed messages. Re-sending CHG-014 should not create a second independent regulatory decision unless the process deliberately requests a new assessment. An older response arriving after a revised decision should not overwrite the approved current state. These are interface acceptance criteria to specify and test, not claims that all products implement them automatically.
Use this small extension of the fictional example to make those checks observable. Assessment RA-014 revision 2 has been approved for Market A only; Market B is still awaiting information. The exact filing decisions are deliberately unspecified.
| Incoming event | Expected treatment | Evidence that would fail the check |
|---|---|---|
| A retry of the same CHG-014 request, with the same event identity and unchanged content | Recognize the retry and return or reference the existing receipt under the agreed contract | A second independently editable assessment appears without an intentional new-assessment decision |
| A delayed RA-014 revision 1 response arrives after revision 2 | Preserve it as historical evidence; keep the accepted revision 2 current | The displayed current decision silently reverts to revision 1 |
| RA-014 revision 2 is delivered with different content under the same identity | Flag the conflict for the decision owner; do not select either by arrival time | A later timestamp silently replaces an approved decision with conflicting content |
| Market A's approved response reaches the quality workflow | Apply its status only to its named market and scope; keep Market B pending | One market's completion marks the entire change as regulatory-complete |
Retain both the transport receipt and the business disposition. If a message cannot be delivered, investigate delivery. If it arrives but names the wrong market, investigate the business mapping. The same “integration failed” label would hide two different corrections and make a successful retest difficult to define.
Different operating problems justify different first priorities
Scenario A: quality execution is uncontrolled. A small biotech cannot reliably identify effective SOPs, assigned training or the owner of open quality investigations. Prioritize the quality operating model and the software functions needed to support it. Adding a sophisticated regulatory dashboard will not establish missing approvals or create evidence that work occurred. Keep required regulatory tracking running, but do not mistake it for quality remediation.
Scenario B: quality records are controlled, but regulatory obligations are fragmented. A sponsor can retrieve approved records yet cannot consistently identify application scope, open commitments or the source behind a regulatory response. Prioritize the regulatory information model and its links to existing evidence. Replacing the QMS may add disruption without addressing the missing regulatory ownership.
Scenario C: both teams work well internally, but document handoffs fail. They exchange attachments with unclear revisions and have no agreed authoritative copy. Focus on document identity, controlled transfer and the interface contract. An EDMS improvement or a better boundary procedure may be more relevant than buying a complete replacement QMS or RIM.
These are illustrative conditions, not claims about what companies of a certain size always need. For selecting software categories rather than assigning this operating model, see the separate RIM software versus QMS software comparison. For a shared-platform architecture, see QMS and RIM in one platform. Sharing infrastructure does not remove the ownership decisions above.
Keep EDMS, submission publishing and regulatory status distinct
An EDMS can supply a controlled source document or rendition. An eCTD publishing workflow prepares the applicable electronic submission structure and related outputs. RIM may plan and track that activity, and some suites provide publishing as another application. Neither document approval nor a planned activity proves that a submission package was published, transmitted, received or accepted.
FDA describes eCTD as the standard format for specified submissions to CDER and CBER and publishes supported versions and technical resources. That submission-format role is distinct from managing an organization's quality records or regulatory commitments. Verify the applicable submission type and current technical requirements when selecting the publishing path. FDA eCTD overview.
For device teams, keep product-specific obligations distinct from drug workflows. FDA's QMSR became effective February 2, 2026 and incorporates ISO 13485:2016 by reference within the device quality framework. That does not make drug eCTD and device submission preparation interchangeable, or establish that a particular software product supports both. FDA QMSR overview.
For electronic records, determine the applicable underlying requirements and Part 11 scope from the records and their use. FDA's scope-and-application guidance addresses that relationship; a shared software platform or a successful data transfer is not a substitute for the intended-use assessment and operating controls. FDA Part 11 guidance.
Validate the ownership model in a demonstration
Give a supplier the CHG-014 scenario or a permitted representative case. Ask three different users to act as quality owner, regulatory decision-maker and document controller. Trace the exact record and version each uses. Then introduce one ambiguous product mapping and one wrong-state document reference.
A useful demonstration shows where the exception appears, who owns its resolution and which dependent step remains pending. It also shows that a rejected or revised regulatory decision does not erase the underlying quality record. If a feature requires another application, configuration project or manual procedure, record that dependency in the proposal.
Retain the completed ownership matrix, interface record and observed outputs. Mark unknowns as unknown; a presentation describing an ideal integration is not proof that the proposed configuration executes it. The first workflow can be modest. Its value comes from a reliable boundary that can be expanded deliberately.
If your bounded next step is regulatory document preparation or review, Assyro's document-management offering can be evaluated in that context. Do not infer a complete QMS, full RIM replacement, automated quality-to-regulatory mapping or device-submission capability from that positioning. Discuss the specific workflow with Assyro, including which system must remain authoritative and which output would demonstrate success.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.