EquatorOps
ONE QUALITY RECORD, TWO COMPANIES
A cross-company quality operating system for outsourced medical device manufacturing. One controlled record shared by the specification owner, the contract manufacturer and the quality team, carrying design changes and supplier actions through approvals, CAPA, management review and audit evidence.
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.
EquatorOps 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.
THREE ROLES, ONE VIEW
Each participant sees the shared program, scoped to what their role is responsible for.
Specification owner
Product and design authority, regulatory decisions, approval of changes that affect the device, and visibility into what the factory is actually doing.
Contract manufacturer
Manufacturing procedures, validations, executed production records, proposed process changes, and corrective actions, contributed directly rather than emailed.
Quality consultant
Diagnostic findings, on-site verification, evidence review, action coordination, and audit preparation across both organizations.
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.
EquatorOps evaluates a design file against the requirement rules that apply to it and reports what blocks release. An empty validation section is not a missing row in a spreadsheet. It is a blocker, named, with the rule it violates and the section it belongs to.
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 carry a predicted effect
Before a change goes for approval, the system works out what it touches across parts, bills of material, routings, tooling and linked documents, so the reviewer sees consequences rather than only a description. Findings that need a decision must be dispositioned before the change can be submitted.
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 being able to change anything.
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
EquatorOps can be deployed two ways. Both are full deployments; which one fits is a question about your program and your timing, not about the 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.
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.