ONE QUALITY RECORD, TWO COMPANIES
A cross-company quality operating system for outsourced medical device manufacturing. One approved record carries the work that crosses the company boundary through change approvals, CAPA, management review and audit evidence, while each party's commercial and proprietary records remain private.
The quality module of the EquatorOps Platform
AN eQMS BUILT FOR TWO COMPANIES, NOT ONE
Every established eQMS is built for one company. Your procedures, your approvals, your records. That works until the product is designed, built, and tested by a different company on the other side of the world. Then the most important information lives in the gap between two systems that cannot see each other, and the gap is where findings come from.
The EquatorOps Platform is built for that gap. The manufacturer proposes a change, the specification owner reviews the exact version that was proposed, both parties sign what they actually reviewed, and the record of who agreed to what is one record rather than two email threads and a spreadsheet.
ONE SHARED RECORD DOES NOT MEAN SHARED EVERYTHING
The engagement has a controlled shared boundary. Each company keeps its own commercial, strategic and proprietary records outside it.
Shared
- Approved configuration
- Joint changes
- Quality agreement
- CAPA commitments
- Validation evidence
Specification-owner private
- Target cost
- Forecast strategy
- Alternate sources
- Legal and regulatory drafts
- Sensitive complaint information
Manufacturer private
- Purchase cost
- Margin and yield reserve
- Internal suppliers
- Proprietary processes
- Other-customer capacity
Shared where the work crosses the boundary. Private where it does not. Consultant access is separately assigned; being engaged to administer a quality program does not create default access to either party's private commercial workspace.
THREE OPERATING MODELS
Whose system is this? The host, controller, access administrator, retention rules and exit rights are defined during onboarding.
Specification-owner hosted
The factory participates in the customer's shared program while retaining its private manufacturing, supplier and commercial records.
Manufacturer hosted
The factory provides a controlled customer-quality portal for the agreed device family, evidence, changes, actions and approvals.
AsianOPS managed
AsianOPS administers the shared workspace and leads the quality program, with consultant and support access explicitly scoped and audited.
WHO OWNS WHICH FILE?
File architecture follows the actual design authority. The EquatorOps Platform does not force every outsourced program into one DHF or DMR pattern.
Customer-owned design
The specification owner controls the device design and approves the factory's manufacturing implementation.
- Customer owns the design and development file
- Factory owns private process know-how and executed records
- Transfer, validation and change evidence cross the shared boundary
Factory-owned private-label design
The manufacturer retains its platform design while the brand owner controls the U.S. market-facing obligations it actually holds.
- Factory retains its private design and process files
- Customer retains labeling, market and role-specific records
- Interface, change-notice and accessible evidence rules are shared
Hybrid platform and customer variant
The factory owns a base platform and the customer owns or approves a product-specific configuration, claim set or risk profile.
- Base-platform evidence remains factory controlled
- Variant design authority is mapped record by record
- The shared interface file links dependencies without merging ownership
EVIDENCE, NOT A FILE COUNT
A checklist can tell you a document exists. The question an auditor asks is whether the record is current, approved, traceable, and supported by objective evidence.
The EquatorOps Platform evaluates a design file against the requirement rules configured for the engagement and reports what may block release. An empty validation section is not merely a missing row in a spreadsheet: it is surfaced with the source rule, the affected section and any data gap. A named, qualified person determines applicability, records the rationale and approves the release decision.
Heating Pad · Design History File
Regulatory profile: QMSR / ISO 13485 clause 7.3 · readiness, traceability, baselines
Not release ready: 1 blocker, 0 warnings
MISSING_REQUIRED_MEMBER
INPUTS
OUTPUTS
VALIDATION
| Requirement rule | Severity | Observed / Min | Status |
|---|---|---|---|
| QMSR_ISO_13485_7_3::DHF::INPUTS::RECORD At least one design input must be recorded. | Blocker | 4 / 1 | Satisfied |
| QMSR_ISO_13485_7_3::DHF::VALIDATION::RECORD Validation evidence is required before release. | Blocker | 0 / 1 | Unsatisfied |
| QMSR_ISO_13485_7_3::DHF::VERIFICATION::TRACE Design inputs should be satisfied by outputs. | Warning | 4 / 1 | Satisfied |
Illustrative view of design file readiness. Configuration reflects the device family and regulatory framework agreed for the engagement.
EACH PARTY SIGNS WHAT IT REVIEWED
When a change is submitted for review, its content is sealed. Approvers are assigned by party, each one re-authenticates at the moment of signing, and the approval binds to that exact sealed revision.
If the content changes, the prior approvals do not carry forward. That is the difference between a signature that records agreement and a signature that merely records a click.
CC-0042 · Thermal cutoff supplier change
Review revision 3 · sealed at submission · both parties required
Specification owner · approved
Signed by the specification owner's quality approver
Manufacturer · approved
Signed by the manufacturer's quality approver
SEALED REVISION
AUDIT CHAIN
Illustrative multi-party change approval. Required approvers and parties are configured per engagement.
WHAT THE WORKSPACE DOES
Controlled documents separated from executed evidence
Revision status, approval state, and controlled-copy handling, with procedures and templates distinguished from the records they produce. Source, revision, date, and ownership are preserved on every record.
Design files organized by lifecycle phase
Planning, inputs, outputs, review, verification, validation, transfer, changes, risk, and post-market, each with its own members, readiness state, and requirement rules. Design and Development Files (formerly the DHF), Medical Device Files (formerly the DMR), production and batch records with their executed manufacturing evidence (formerly DHRs), and technical files are separate archive types, so records created under either vocabulary stay findable.
Requirements traced to the evidence that satisfies them
A trace matrix connecting design inputs to outputs, risk controls to verification, and requirements to the records that close them, with the gaps visible rather than inferred.
Multi-party change review with assigned approvals
Proposed changes carry an impact assessment across affected parts, documents, and processes. Review content is sealed at submission and each required party signs that exact revision.
Nonconformances, CAPA, and complaints that stay connected
Findings carry severity, disposition, ownership, and CAPA linkage. Complaints connect to the investigation, the resulting NCR or CAPA, and the closure decision, so the chain survives the personnel who created it.
Electronic signature and tamper-evident history
Signing requires re-authentication, supports a second factor, and records a server-authored signature manifestation that persists with the record. Field-level history is captured in a verifiable chain.
An assembled evidence package for the auditor
Record identity, chronological history, signature manifestations, and chain verification exported as a coherent offline package, rather than a folder of screenshots assembled the week before an inspection.
A shared inbox and assigned work across both companies
Open items, readiness gaps, training, calibration, inspections, and remediation status in one view, with work assigned to the person responsible at whichever company owns it. Each participant sees the approvals and actions waiting on them personally.
Proposed changes surface potential effects for human review
Before a change goes for approval, the platform identifies affected parts, bills of material, routings, tooling and linked documents. It shows sources, data gaps and potential consequences; named people disposition the findings and record their rationale. The platform does not make the regulatory or release decision automatically.
Management review that consumes the real records
Inputs are assembled from the complaints, nonconformances, CAPA, audits, supplier performance and design activity already in the system, captured as a frozen snapshot so later changes never rewrite what management actually reviewed. Decisions and action items attach to that snapshot.
Party-aware permissions
Each participant is scoped to the shared engagement and to their own organization's role in it. A manufacturer contributes and proposes; a specification owner approves what affects the device; an auditor reads and exports without changing records. Consultant access is assigned explicitly, and support access is separate, temporary, audited and used through a break-glass process rather than default administrator visibility.
Open quality items across the engagement
One view for the specification owner, the factory, and AsianOPS
| Source | Open | Owner |
|---|---|---|
| Design archives not ready | 1 | Spec owner |
| Open design reviews | 4 | Spec owner |
| Open nonconformances | 2 | Factory |
| Open CAPA | 2 | Factory |
| Calibration due | 3 | Factory |
| Pending signatures | 2 | Both parties |
Illustrative shared quality inbox. Sources shown depend on the modules configured for the engagement.
HOW IT FITS YOUR EXISTING SYSTEMS
Under any of the three hosting models, the EquatorOps Platform can be authoritative for cross-company approvals and evidence while each company retains its own ERP, PLM, eQMS and financial systems. Two adoption patterns are available; the right one depends on the program and timing, not on a requirement to replace every internal system.
Engagements are set up and provisioned by our team around your device family, your factory, and the regulatory roles you and the manufacturer actually occupy, so the permissions and approval model match the responsibility split rather than a generic template. The workspace is included in the diagnostic engagement.
BUYER FAQ: CONTROL, VALIDATION AND EXIT
The data boundary and operating rules are part of the implementation, not assumptions left for the two companies to discover later.
Can the customer see the factory's cost and margin?
No. Purchase cost, yield reserve, margin and private supplier terms remain in the manufacturer's controlled workspace unless the parties deliberately choose an open-book model. The shared record carries the quote, assumptions, accepted price and effective terms.
Can the factory see the customer's forecast and alternate sources?
Not by default. Forecast strategy, target cost and alternate-source plans remain specification-owner private. Only approved projections, attestations and sourcing decisions needed to execute the shared program cross the boundary.
Who owns the design file?
The answer follows actual design authority. A customer-owned design, a factory-owned private-label platform and a hybrid customer variant use different file boundaries. Onboarding maps the factory, customer and shared-interface files record by record rather than forcing a merged DHF or DMR.
Can the EquatorOps Platform coexist with our current eQMS, PLM or ERP?
Yes. The EquatorOps Platform can be authoritative for cross-company approvals and evidence while integrating with or publishing approved records to internal systems. Neither company must replace every system it uses to gain a controlled record at the company boundary.
Who controls user access, and can AsianOPS see everything?
Onboarding identifies the host, data controller, access administrator, shared-record owner and each private-record owner. Access is least privilege and party scoped. AsianOPS consultant access must be assigned; support access is separate, temporary, audited and reserved for an authorized break-glass process.
What happens when the supplier relationship ends?
The complete shared record and immutable history are exported, factory access is revoked, and agreed retention is preserved. A new factory relationship can then be established without transferring the former manufacturer's private cost, supplier or process data.
How are records exported for an auditor?
Exports provide readable electronic copies with record identity, chronology, signature manifestations, history and chain verification, assembled into an offline audit binder. The Part 11 control model is documented, while the customer retains responsibility for its intended use, procedures, training and other applicable predicate-rule controls.
Can an auditor receive temporary access?
Yes. An auditor can receive time-limited read and export access to the agreed engagement scope without edit rights or visibility into either party's unrelated private workspace. Grant, activity and revocation remain in the access history.
How does customer validation work?
The implementation package includes an intended-use template, risk-based computer software assurance plan, test evidence, release notes, change-impact assessments and customer-executable acceptance protocols. The customer approves its intended use, risk rationale, acceptance evidence and validation conclusion.
Does the EquatorOps Platform make regulatory decisions automatically?
No. The platform identifies potentially affected records and consequences, shows its sources and data gaps, and requires named people to disposition the result and record their rationale. Humans make and sign applicability, release and regulatory decisions.
Does the factory have to migrate its ERP or work in another full portal?
No ERP migration is required. External participants receive included, task-focused partner seats, email notifications and bilingual terminology for the records and approvals assigned to them. Integration and publishing can keep internal systems current without exposing unrelated factory data.
Why not use Veeva, Arena or another enterprise system?
Those systems may remain appropriate inside one company. The EquatorOps Platform is designed around the bilateral boundary: multi-party approvals, product and BOM context, manufacturing impact analysis, controlled private workspaces, and AsianOPS execution at the factory for smaller outsourced hardware and medical-device teams.
SEE IT WITH YOUR OWN PROGRAM IN MIND
The most useful demonstration is one framed around your device and your factory. A short call is enough to set that up.