NetSuite Setup Guide for Medical Devices

A medical device business runs the same processes as any other manufacturer. It buys, builds, ships and invoices. The difference is what happens to the record afterwards.

In most businesses a transaction record is useful for a few years and then it is history. In medical devices it may be the thing an auditor or an investigator asks about long after everyone who touched it has moved on. That single fact changes how you design the system.

NetSuite for medical device companies is designed for the audit

The usual ERP design question is how to make a process fast. Here there is a second question underneath it. If somebody asks about this in five years, what will we be able to show.

That reframes a lot of decisions. A field that gets overwritten is fine for efficiency and useless for evidence. A change made directly in a record is convenient and leaves nothing behind. A workaround that saves a team ten minutes a day may quietly remove the trail that proves the process was followed.

You do not need to make everything slow. You need to know which records are evidence and treat those differently from the rest.

Serial or lot, decided per product

The first structural decision is which products carry a serial number and which carry a lot number.

Serialisation gives you a unique identity per unit. It is what you need where a specific device has to be traced to a specific recipient, which is typical for implantables and higher risk devices. Lot control groups units made together. It is lighter to operate and it widens the scope of any investigation, because you cannot narrow below the lot.

Get this wrong in the cautious direction and you carry extra operational load. Get it wrong in the other direction and you will one day be recalling a lot when you could have recalled a handful of units. Decide it per product family with the quality function in the room, before go live.

Whatever you choose has to survive the whole life of the unit. Through production. Through despatch. Through distribution. Through field service. Through a return. A serial that gets lost at any of those points breaks the chain, and it breaks it silently.

Unique device identification has to come from somewhere

Device identification requirements in the United States and in the European Union both expect a device to carry an identifier and for defined attributes to be submitted to a database.

The practical question for a systems build is which system holds those attributes and which one submits them. You want one source of truth. When the identifier attributes live in a spreadsheet that feeds a submission, and the item master separately holds its own version, the two drift. Nobody notices until a submission gets rejected or an attribute turns out to be wrong on a product already in the field.

Bringing those attributes onto the item record, with controlled change, removes a whole category of problem.

Controlled change is the part people underestimate

In an ordinary business a product specification changes when somebody updates it. In a device business a change to a controlled item is an event that needs a reason, an approval and a record.

Your system has to support that without making routine work unbearable. That means knowing which fields on which records are controlled, requiring approval before those change, keeping the previous value, and being able to show the history on demand.

It also means effective dating. A change that takes effect on a date needs the system to know which version applied when a given unit was built. Otherwise the device history you produce later reflects today specification rather than the one in force at the time.

Supplier qualification has to bite

Every device business has a list of qualified suppliers. The question is whether the list does anything.

If qualification status lives in a quality document and purchasing works from a separate vendor list, the two will diverge. A supplier whose qualification lapses stays usable. Somebody raises a purchase order in good faith. The finding turns up later.

The fix is to hold qualification status on the vendor record and enforce it at the point of purchase for controlled items. An unqualified source should block, not warn. Warnings get clicked through by people who are busy and assume somebody else checked.

The same logic applies to receiving inspection. If an item requires inspection before use, the system should hold it rather than making it available and trusting a process.

Where the quality system ends

Almost every device business runs a separate quality management system. Complaints, corrective actions, design control and document control usually live there. That is sensible and it creates a boundary problem.

The boundary needs to be explicit. Which system owns the item specification. Which one owns supplier qualification. Which one owns the training record that gates who can approve a change. When both systems hold a version of the same fact, you now have two sources of truth and a reconciliation nobody scheduled.

We look at this in more detail in our guide to where the quality system ends and the ERP begins. The short version is to decide ownership per record type and let one system be authoritative, with the other reading rather than holding its own copy.

Validation is part of the plan, not a surprise at the end

Computer system validation is not optional in this sector, and it is routinely discovered late. Teams scope an implementation like any other, then find that the testing and documentation expectations are considerably heavier than planned.

Build it into the plan from the start. Decide what is in scope for validation, agree the approach with quality early, and accept that it affects how you handle releases and updates afterwards as well. A change management process that works for a normal business will not survive contact with a validated system.

What to phase

Traceability, controlled change, supplier qualification and the financial core belong in the first release. They are expensive to retrofit and they carry the compliance weight.

Demand planning, advanced analytics and customer integrations can follow. The implementation timeline guide covers how phases usually break down, and the data migration checklist matters more here than elsewhere, because migrated traceability data is evidence too.

Getting it designed

TechCloudPro sets up NetSuite for medical device companies through NetSuite implementation, where audit evidence is a design input rather than a later worry, for the sector as a whole. Much of the same thinking applies in healthcare and in food and beverage, where the traceability duty is similar in shape if not in depth.