QMS and ERP Integration for Medical Device Companies

Almost every medical device business runs two systems that both claim to describe the product. A quality management system holds design control, document control, complaints and corrective actions. An ERP holds items, inventory, purchasing, production and orders.

Both are correct within their own scope. The difficulty lives in the strip of ground between them, where the same fact exists twice.

QMS and ERP integration fails in the overlap

Think about a specification. Quality holds the approved version with its approval history. The ERP holds a bill of materials and item attributes used to actually buy and build.

Those are two representations of one thing. When they agree, nobody notices. When they drift, you have built product to a version that was not the approved one, and you will find out during an audit or a complaint investigation.

The same pattern repeats across supplier qualification, training records, equipment calibration and device identification attributes. In each case both systems have a legitimate interest and only one should be authoritative.

Decide ownership per record type

The useful exercise is short and it is rarely done. List every record type that exists in both systems. For each one, name the owner. Write down which system is authoritative, which direction data flows, how often, and what happens when they disagree.

A reasonable starting position looks like this.

• Approved specification and design records. Quality owns them. The ERP consumes the current approved version.
• Item master and bill of materials for execution. The ERP owns them, built from the approved specification rather than invented separately.
• Supplier qualification status. Quality owns it. The ERP enforces it at purchase.
• Inventory, lots, serials and transactions. The ERP owns them. Quality reads them when investigating.
• Complaints, corrective actions and nonconformance investigations. Quality owns them, with an explicit link to affected stock in the ERP.
• Training and authorisation. Quality usually owns it. The ERP may need to know who can approve what.

The value of writing this down is not the document. It is that the argument happens once, in a room, rather than repeatedly at the point of failure.

One way flows beat two way sync

The instinct when two systems hold the same data is to synchronise them both ways. Resist it.

Two way synchronisation means both sides can change a value, which means you need conflict resolution, which means somebody has to define what happens when both changed since the last run. That logic is where integrations go wrong, and it goes wrong quietly.

A one way flow from the authoritative system is simpler to build, simpler to test and far simpler to explain to an auditor. If a value needs changing, it gets changed at the source and flows down.

Match the frequency to the data

Not everything needs to move in real time, and most of these records do not.

Supplier qualification changes rarely. A daily flow is fine, and the enforcement point matters more than the latency. An approved specification change is an event, so triggering on approval makes sense. Inventory transactions are high volume and belong where they happen rather than being copied anywhere.

Choosing the slowest acceptable frequency for each flow keeps the integration simple and reduces the number of ways it can fail. Real time everywhere is a choice that costs money and buys very little here.

Make the links visible to people, not just to systems

An integration that moves data correctly and leaves no visible connection is only half useful.

If stock is on hold because of an investigation, somebody looking at the hold should be able to find the investigation. Somebody looking at the investigation should be able to see exactly what was held and where it is. A reference number on both sides does this. Matching by date and product does not, although a surprising number of businesses rely on it.

The test is simple. Can a person who was not involved follow the trail in either direction without asking somebody.

Validation applies to the join as well

Where an integration moves records that carry compliance weight, the integration itself is in scope for validation. That has a consequence people miss. Every change to it afterwards carries that weight too.

So keep the integration narrow. The more record types it carries, the more often it changes, and the more often you pay the validation cost. A small number of well defined flows is cheaper over the life of the system than a broad connector that does everything.

Where this fits in a programme

The boundary conversation belongs early, before either system gets configured around assumptions about the other. It involves quality, operations, IT and finance, and it usually takes a couple of sessions rather than a project.

Our guide to setting up NetSuite for medical device companies covers the ERP side in more depth, and the traceability guide covers the record that most often spans both systems.

Getting it settled

TechCloudPro handles QMS and ERP integration for medical device businesses on NetSuite programmes, where a quality system is already in place and has to stay. If you are currently maintaining the same fact in two systems and reconciling by hand, that is the point where this conversation pays for itself.