The IT systems behind a medical device company, and which ones a small team actually needs.

Whether you're part of a team preparing to put your first medical device on the market, or you're already an established manufacturer, you know how much rides on managing your development and production records. The process always comes first. Before you buy any system, you need clarity on what your processes are and how they are governed, because no tool will fix a process you haven't defined. That said, you have probably already identified the need for one or more IT systems to help you handle those records: traceability, searchability, version control, controlled approval. There are many such systems used by medical device companies, each built for a different reason. We put together this guide to help you understand what each one does, where each one stops, and which of them you might actually need.

ERP: runs the business, not the device.

What it is: finance, procurement, inventory, orders, production planning, in one place.

Common tools: SAP and Oracle at the top end; NetSuite or Microsoft Dynamics for smaller companies.

Who needs it: anyone making and shipping a physical product at volume, but the pull toward an ERP comes more from the business and finance side than from the regulatory one. It earns its place in lot and material traceability (which batch of which part went into which unit, from which supplier, when), control of company assets, procurement and the books. That traceability is also what makes a recall surgical instead of total. If you grow, you'll need one at some point, but it is not your first step.

Where it stops: ERP runs the business around the device. It knows nothing about how the device was designed, what it has to do, or how you proved it's safe, and it is only marginally linked to the Technical File. Don't go looking for design control in your ERP. Wrong tool.

DM: controls documents, and nothing more.

What it is: document management. Plenty of things get called a DMS, including a shared drive or a folder full of PDFs, but for an ISO 13485 company two features are non-negotiable: proper version control (a clear answer to which version was effective on which date) and a 21 CFR Part 11 compliant electronic signature. With those, you can digitize every document and record and stop storing wet-signed paper. No more print, sign, scan. For a 3-person startup that alone is a step change.

Common tools: MasterControl, Veeva Vault QualityDocs, OpenText Documentum D2 and Egnyte, all built for regulated, Part 11 compliant document control.

Who needs it: every device company, from day one. This is the floor.

Where it stops: a DM digitizes paper and controls the process around documents, but the information inside stays as free text. It manages the container, not the contents. It'll confirm "Risk Management Report v4 was approved Tuesday," but it has no idea what a risk is, can't tell you whether every hazard has a control, and can't answer any question that lives across documents instead of inside one. Necessary, and dumb on purpose.

QMS: runs your processes, not your product.

What it is: the quality system: SOPs, CAPAs, complaints, training, audits, supplier qualification, change control. Run electronically, it's an eQMS. ISO 13485 (and the FDA equivalent) is the rulebook. This is the spine of any regulated company.

Common tools: Greenlight Guru, Qualio and MasterControl in med-dev; Veeva Vault QMS at the top end.

Who needs it, and when: eventually, everyone regulated, but it becomes a hard must only past a certain size and complexity. Plenty of small teams run quality out of a DM: a folder of SOPs, a spreadsheet of CAPAs, one heroic quality manager. It works until it doesn't, because quality is a set of processes (states, owners, due dates, escalations), not a set of files. The real blocker for small companies isn't need. It's price. The established eQMS tools are priced for organizations several sizes bigger, which is why small teams improvise for too long.

Where it stops: a QMS manages how you work. It does not manage the product: the requirements, the design, the specs, the engineering evidence that has to become a Technical File. A perfect eQMS leaves that gap wide open.

ALM: controls how the product is developed and validated.

What it is: Application Lifecycle Management. Requirements → design → verification → validation, all linked, all traceable. It came from software, where its shape is the V-model that IEC 62304 expects: every requirement on the way down has a test on the way up, and you can prove the line between them.

Common tools: Codebeamer, Polarion and Jama; plus the legacy workhorse a lot of teams still limp along on, HP Quality Center (HPQC).

Who needs it (broader than you think): anyone developing a product. Two things people miss. First, ALM scales down: its weight is in specifications and evidence, not physical parts, so a single-device startup benefits as much as a big team. Second, and this is the underrated one, ALM is not only for building software from scratch. It's just as much how you validate software or equipment you bought and configured for your own use. Pharma companies run their automated manufacturing equipment through an ALM-style lifecycle, qualifying the installation, the configuration and the operation (IQ/OQ/PQ, computer system validation). Whether you wrote the code or bought the machine, the validation problem is identical: define what the thing must do, then prove it does.

The nuance to get past: the name says "software," but the concept is broader: a structured way to validate a product or system as a whole. Don't let the "A" scare you off if your device isn't software-heavy.

PLM: ALM's heavy cousin, for physical complexity.

What it is: Product Lifecycle Management. BOMs, parts, CAD, configurations, and propagating a single engineering change across thousands of interdependent components and their suppliers.

Common tools: Siemens Teamcenter, PTC Windchill, Dassault 3DEXPERIENCE.

ALM vs PLM, the distinction people get wrong: both manage a product's definition over its life, so they get conflated. The split is clean: ALM's gravity is specifications and validation; PLM's gravity is parts, BOMs and configuration. ALM is about what the product must do and proving it does. PLM is about the physical thing and all its pieces staying coherent.

Who needs it: the biggest, most hardware-heavy companies. Think a company like Boeing coordinating millions of parts on an aircraft, where every revision, every supplier and every change ripples through the assemblies. No spreadsheet survives that; PLM exists for that magnitude. For a small device built from a modest BOM, PLM is overkill. Most small device companies need ALM-style thinking long before they ever need PLM.

RIM: manages the dossier and the registrations, not the content.

What it is: Regulatory Information Management. The system of record for the regulatory side: what's registered where, under which application or certificate number, in which markets, at what status. Plus planning, assembling, publishing and tracking the submission dossier, and managing health-authority correspondence and commitments. Heavy in pharma; less common but conceptually identical in med-dev.

Common tools: Veeva Vault RIM is the reference point. (Veeva Vault also does QMS and document control, which is why "Veeva" gets used as if it's one product. It's really a whole stack.)

Who needs it: large, multi-market, multi-product regulatory organizations juggling many registrations, variations and renewals at once. A first-device startup with one CE mark in flight does not have a RIM and shouldn't buy one.

Where it stops (and this is the key one): a RIM manages the metadata and the assembly of the dossier. It tracks what's registered and stitches the submission together. It does not author the content. Your requirements, your risk analysis, your test evidence and your design outputs all originate in ALM, QMS, DM, PLM and ERP. The RIM is the orchestration layer on top; the truth still lives in the operational systems below it.

Line them up and the gap is obvious.

Each system answers exactly one question:

Now look for the Technical File. The closest match is RIM, and that tells you exactly how the industry actually solves this. In a big company, the dossier content scatters across ALM, QMS, DM, PLM and ERP, and a RIM is bolted on top to assemble and track it. Six systems, one of which exists purely to glue the other five into a submission.

A small device company has none of that. No RIM, no PLM, often no real ALM: just a DM, maybe an eQMS, and a pile of engineering work. So the Technical File has no home at all. It gets assembled by hand, in Word, from evidence scattered across the DM, the eQMS, an engineer's laptop and someone's memory, in a panic the week before submission. Then it starts going stale the moment it's finished.

The Technical File isn't a document.

We call it a set of documents because that's how it's submitted. But most of what's inside isn't document-shaped. It's data: a requirement, a hazard, a risk and its control, a design input, a test result, a GSPR and the evidence mapped to it. Each is a small living object with its own lifecycle (created, revised, verified, linked), and each is maintained continuously during development.

The document is just a snapshot: that data, frozen and bound at release. The real object is the web of datapoints and the relationships between them. The Technical File is the assembly: a view you render at release, from data you were keeping all along. Which is exactly what a RIM understands about a dossier, except a RIM only manages the assembly and the metadata, and assumes five other systems are feeding it the content.

Structured data is:

• maintainable: change a requirement once, and everything that depends on it knows;
• searchable: ask questions across the whole device, not one document at a time;
• traceable: requirement → risk → test is native to the data, not a matrix you rebuild by hand;
• AI-legible: structured, attributable data is what AI-assisted work needs; a PDF is opaque, while a linked datapoint carries its own context and provenance.

You won't get everything into structure, and you shouldn't try. Some things really are documents: a clinical evaluation, a biocompatibility report, a sterilization validation. Attach those as controlled, linked evidence. The rule: structured where you can, document-attached where you must.

Bottom line.

You don't need to work out which category you "are," or buy six systems and a RIM to glue them together. You need one concrete outcome: your Technical File, true (current, linked, traceable, exportable on demand), as a by-product of the work you were already doing.

That's what Threeqa is built around, and it's worth being precise about what it is and isn't. It's not a RIM, not an ALM, not a QMS, not a DM, and it doesn't try to replace your ERP or PLM. It takes the parts of each that a small device company actually needs (structured, traceable content and validation from the ALM idea; records and controlled documents from the QMS/DM idea; dossier assembly plus device metadata from the RIM idea) and collapses them into one tool shaped like the thing you're actually trying to produce: the Technical File. Six categories of enterprise complexity, reduced to one a small team can run.

It won't make you compliant. No tool can, and be suspicious of anyone who says otherwise. The regulatory expertise stays with you. What changes is that the work stays organized and current, instead of being rebuilt from scratch every time someone asks to see it.