Specialist ERPsIndustry

QAD + medical devices

AI for QAD in Medical Devices: Traceability, DHR Review and CAPA Trends Without Exposing Regulated Data

Short answer

AI for QAD in a medical device company puts a private, read-only language model on QAD Adaptive ERP so quality, regulatory and operations teams can ask plain-English questions about lot and serial traceability, device history record completeness, supplier controls and CAPA and complaint trends, with the query shown. It runs on-prem or in a private tenancy and is designed to support, not replace, a validated quality system under FDA QMSR and ISO 13485.

ERP: QAD Adaptive ERP, QAD Enterprise Edition, QAD Cloud ERP
Industries: Medical devices, Life sciences, Contract manufacturing, Diagnostics
Written for: Quality or Regulatory Manager at a medical device manufacturer

Discuss your QAD Adaptive ERP environment See use cases

Medical device manufacturers choose an ERP like QAD for lot and serial control, multi-site operations and supplier management, then layer a quality management system and often a PLM around it. The regulatory frame is demanding: FDA 21 CFR Part 820, which since February 2026 is the Quality Management System Regulation aligned with ISO 13485:2016, plus UDI requirements, MDR vigilance reporting in the US and EU, and in many cases EU MDR 2017/745 and MDSAP audits.

Day to day, the records that matter live across systems: device history records built from work orders, inspection and lot data; complaint and CAPA records in the QMS; supplier approvals and certificates; UDI and labeling data. When a complaint arrives or an auditor asks for evidence, quality staff trace a device back through components, suppliers, processes and distribution, often with several systems open and a spreadsheet to join them.

That work is skilled, slow and high stakes, and it competes with the routine release and review tasks that keep product moving. At the same time, medical device manufacturers are rightly cautious about AI. Patient-related complaint data, design information and supplier terms are sensitive, and the QMS requires validated, controlled software for anything that affects product quality records.

This page describes what AI on QAD looks like for a device manufacturer: which data it reads, how it stays outside the validated record flow, where it saves real time, and where it is not appropriate. It is written for the quality, regulatory or IT leader deciding whether and how to run a controlled pilot.

What usually gets in the way

The problems we hear most from quality or regulatory manager at a medical device manufacturer teams running QAD Adaptive ERP.

Traceability assembly is slow and error-prone

Tracing a finished device back to component lots, suppliers and process records, and forward to distribution, means joining inventory transactions, work orders, inspection records and shipments. Under pressure from a complaint, the speed and completeness of that trace matter.

DHR review consumes quality time

Reviewing device history records for completeness before release involves checking that every required step, inspection and signature is present. Much of it is mechanical, yet it requires skilled people, which delays release.

Complaint and CAPA trends hide in free text

Complaint narratives, investigation notes and CAPA descriptions are unstructured. Spotting a pattern across them, such as a recurring failure mode on one component, is difficult without reading hundreds of records.

Supplier control evidence is scattered

Approved supplier status, audit reports, certificates and incoming inspection results live in different places. Auditors ask for them together.

AI use must be defensible in a regulated QMS

Software used in the QMS must be controlled and, where it affects quality records, validated. Casual use of public AI tools on complaint or device data is a compliance and confidentiality problem.

Where AI earns its place in QAD Adaptive ERP

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Forward and backward lot traceability

Quality asks "which finished lots used this component lot, and which customers received them" and gets the genealogy with quantities and ship dates, ready for a person to verify.

Touches: Lot and serial inventory detail (ld_det), transaction history (tr_hist), work orders (wo_mstr), receiving and shipment records

Outcome: A trace for a field action can be drafted in minutes for review, instead of consuming hours of joined queries during an urgent investigation.

DHR completeness pre-check

Before QA release, the assistant lists missing or out-of-sequence steps in a work order's records, such as absent inspections or unsigned operations, for the reviewer to confirm.

Touches: Work orders and operations, inspection and test records, lot consumption, operator and signature records

Outcome: Reviewers spend less time on mechanical checks and more on judgment, while the formal DHR review remains with QA.

Complaint and CAPA trend summary

Quality asks for recurring themes in complaints and CAPAs for a product family over the last quarter and gets grouped themes linked to the source records.

Touches: Complaint records, nonconformance and CAPA records (QMS data alongside QAD), product and lot references

Outcome: Trend reviews start from an organised view, which helps management review and risk file updates, with people judging significance.

UDI and labeling consistency check

Regulatory asks which items lack a UDI-DI mapping, and which shipped lots carry labeling data that differs from the master record.

Touches: Item master and UDI attributes, lot and expiry data, labeling and shipment records

Outcome: UDI data gaps are found before an audit or submission, not during one.

Supplier status and incoming quality review

Supplier quality asks which approved suppliers have expiring certificates, repeat rejects or overdue audits, and which components depend on them.

Touches: Supplier and approved vendor records, receiving inspection and rejection data, purchase orders, document store

Outcome: Supplier reevaluations are prioritised on evidence, which supports the supplier control requirements of ISO 13485.

Expiry, quarantine and hold review

Operations asks which lots are near expiry, in quarantine or on hold, and which open work orders depend on them.

Touches: Lot status, expiry dates, location inventory, work orders, quarantine records

Outcome: Scrap from expiry and release delays from unresolved holds are reduced through earlier visibility.

Audit evidence assembly

For an FDA or notified body audit request, the assistant gathers the relevant records and documents for a part or process into a package for a quality lead to review.

Touches: Item and revision data, inspection and nonconformance records, controlled documents, training and supplier records

Outcome: Evidence packages are prepared faster and more consistently, with a named person verifying before anything is shared.

Reference architecture

The AI layer reads QAD through a read-only SQL path to the OpenEdge database for self-hosted systems, or through QAD's integration services for vendor-hosted ones, and reads QMS and document data from their own APIs or exports. A private open-weight model runs on your infrastructure. It sits outside the validated record flow: it reads and summarises, and does not create or approve quality records.

1
Read-only data access
A restricted database user or integration role limited to the tables in scope, using a replica so analytic queries do not affect production. QMS and document sources are connected through their own read-only interfaces.
2
Semantic model with domain control
QAD domains and sites are enforced on every query. Business terms such as lot, device history, UDI-DI and supplier status map to the underlying data with documented definitions.
3
Document and record retrieval
Controlled documents, SOPs, supplier files and audit reports are indexed with revision and approval status so the assistant cites effective versions only.
4
Private model serving
An open-weight model (Llama, Qwen, Mistral, Gemma or gpt-oss class) runs under vLLM or Ollama on your GPUs or in a private cloud, so complaint and design data are not sent to a public endpoint.
5
Governance and audit trail
Role-based access, full query and response logging, versioned prompts and model, a regression test set and a defined intended-use statement, so the AI layer can be assessed under your software validation procedure.

Integration notes for your ERP team

Define the intended use in writing before the pilot: read-only retrieval and summarisation, not release decisions, not record creation.
Connect QAD through a replica with a read-only role, and connect the QMS and document systems through their own read-only interfaces. Do not let the AI write to any of them.
Enforce QAD domains and sites in the semantic layer, tested with users from different sites.
Index only effective, approved document versions and carry revision metadata so retired procedures are not quoted.
Minimise personal data: redact or exclude fields that identify patients or reporters unless the use case genuinely requires them.
Maintain a regression set of known traceability and DHR questions with verified answers, and rerun it after any model, prompt or data model change.

Deployment options

On-prem next to QAD

Manufacturers hosting QAD themselves with strict data handling requirements for complaint and design data.

A GPU server and read replica sit in your data center, with access limited to the quality and operations network segments.

Validated private cloud tenancy

Companies with cloud governance already in place for regulated workloads.

Data and model serving run in your own subscription, in a region meeting your residency needs, with change control documented under your QMS.

Pilot outside the regulated record flow

Teams that want to prove value before formal validation.

A limited pilot on non-patient data, read-only, with an intended-use statement that excludes it from quality decisions, followed by a formal assessment before wider use.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

FDA 21 CFR Part 820 (QMSR) and ISO 13485:2016

The assistant retrieves and summarises records for human review. Under your software validation procedure, define its intended use, assess risk, and keep it out of the creation or approval of quality records unless validated for that purpose.

FDA 21 CFR Part 11 for electronic records and signatures

Read-only access avoids creating electronic records. Where any record creation is later considered, access control, audit trails and signature controls must meet Part 11 expectations in the system of record.

UDI (21 CFR 830) and EU MDR 2017/745 traceability

UDI and lot data can be checked for consistency, with regulatory staff owning submissions and corrections.

ISO 14971 risk management and post-market surveillance

Complaint and CAPA trend summaries can inform risk file reviews. Judgments on risk acceptability remain with qualified people.

Data protection (HIPAA where applicable, GDPR)

Complaint data may contain personal data. A private deployment with minimisation and access control keeps it in an environment you govern, and redaction can be applied before retrieval.

Where Netray fits

ERPray

Grounded answers over live QAD lot, work order, supplier and shipment data with the query shown, domain-aware and read-only, covering traceability and DHR pre-check questions.

DataRay

Lets quality ask questions across QAD, the QMS, controlled documents and audit files on-prem, which suits evidence assembly and CAPA trend review.

How an engagement runs

Phase 1 . 1 to 2 weeks

Discovery and intended use

-Written intended-use statement and risk assessment inputs
-Inventory of QAD, QMS and document sources and access paths
-Ranked list of 10 to 15 real quality and operations questions
-Data classification, including personal data

Phase 2 . 4 to 6 weeks

Pilot build

-Read-only access and replica
-Semantic model for lots, serials, work orders, suppliers and UDI
-Document index with revision metadata
-Private model serving and verified test set

Phase 3 . 3 to 5 weeks

Assessment

-Accuracy review with quality and regulatory staff
-Domain and role segregation tests
-Support for your software validation or assurance activities
-Go or no-go note with measured results

Phase 4 . 2 to 4 weeks

Controlled rollout

-Production deployment with monitoring
-Training with explicit guidance on what the assistant must not be used for
-Change control runbook for model and prompt updates
-Backlog of next use cases

Questions to ask any vendor, including us

A short list that separates real QAD Adaptive ERP AI work from a chatbot demo.

What is the written intended use of the AI layer, and how do we keep it outside quality record creation and approval?
How do you support our software validation or computer software assurance activities?
How do you enforce QAD domains and sites, and prove segregation?
Where is complaint data processed, and does any of it reach a third party?
Can every number and statement be traced to source records and effective document versions?
How do you handle personal data in complaint records?
What is the change control process for model, prompt and data model updates?
What would you not recommend using this for in our QMS?

Frequently asked questions

Is AI allowed in a medical device QMS?

Nothing in 21 CFR Part 820 or ISO 13485 bans it, but software used in the QMS must be controlled, and validated in proportion to risk where it affects quality records or decisions. The safest starting point is read-only retrieval and summarisation with a documented intended use, human review of everything, and a validation assessment before wider use.

Does this replace our QMS or DHR process?

No. The QMS and the DHR remain your system of record, with named owners and signatures. The assistant helps staff find and compare records, for example by listing missing steps before QA review. A qualified person still reviews, decides and signs, and the assistant is never the record.

How does it help with traceability for a field action?

It can draft the forward and backward genealogy from component lots through work orders to finished lots and shipments, based on QAD transactions. A quality engineer then verifies the result against source records. The value is speed in assembling a first view when time matters; accuracy depends on how consistently lots are recorded.

Can it read complaints that contain patient information?

It can, if you choose to include them, but we recommend minimising personal data by redacting identifying fields unless a use case requires them. A private deployment keeps data in your environment, and access controls and logs apply. Your privacy and regulatory staff should approve the scope before any complaint data is ingested.

Which models does it use?

Open-weight models such as Llama, Qwen, Mistral, Gemma or gpt-oss class, served with vLLM or Ollama on your GPUs or private cloud. Versions are pinned and changes go through change control, which supports reproducibility. Your data is not used to train a shared model.

Could it write to QAD or the QMS?

By default no. It is read-only, and we recommend keeping it that way in a regulated environment. If a write action is later justified, such as drafting a CAPA for review, it would be a narrowly defined action, approved by a named user in the system of record, and assessed under your validation procedure.

How long does a controlled pilot take?

Typically eight to fourteen weeks including the assessment phase, longer if formal validation is required before use. The timeline depends on QAD hosting, the number of source systems and how quickly your quality team can review accuracy. A short, tightly scoped intended use shortens it.

Related guides

QAD + on-prem AI

AI for QAD Adaptive ERP in automotive and industrial manufacturing

Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.

Faster paperwork, same standard

AI for NCR, CAPA, and 8D Drafting in AS9100 and ISO 9001 Quality Systems

AI drafts NCR, CAPA, and 8D reports from ERP quality data for engineer review, cutting drafting time under AS9100 and ISO 9001 without changing sign-off.

ETQ Reliance + private AI

AI for ETQ Reliance: Joining Your Quality Records to Your ERP Data

Add grounded AI to ETQ Reliance for CAPA, complaints, audits and document control, joined to ERP lots, suppliers and work orders, with private deployment options.

MasterControl + private AI

AI for MasterControl: Controlled Documents and Quality Events Joined to Your ERP

Private AI for MasterControl QMS: document control, training, CAPA and batch records joined to ERP lots and suppliers, with human sign-off and audit trails.

RAG + SQL + permissions

A Private LLM Grounded on Your ERP Data

How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.

ERP AI readiness

Is Your ERP Ready for AI? A Readiness Assessment Checklist

Is your ERP actually ready for AI? A practical checklist covering master data quality, access and permissions, GPU sizing, and governance before you fund a pilot.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows QAD Adaptive ERP

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides