# AI for QAD in Medical Devices: Traceability, DHR Review and CAPA Trends Without Exposing Regulated Data > Source: https://netray.co/erp-ai/qad-medical-devices-ai > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: AI for ERP ## 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. ## Kind industry ## Erp Family other ## Erp Products - QAD Adaptive ERP - QAD Enterprise Edition - QAD Cloud ERP ## Industries - Medical devices - Life sciences - Contract manufacturing - Diagnostics ## Region Global ## Persona Quality or Regulatory Manager at a medical device manufacturer ## Eyebrow QAD + medical devices ## Intro 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. ## Pain Points ### Traceability assembly is slow and error-prone **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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 **Detail:** 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. ## Use Cases ### Forward and backward lot traceability **Description:** 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. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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 **Description:** Regulatory asks which items lack a UDI-DI mapping, and which shipped lots carry labeling data that differs from the master record. **Erp Objects:** 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 **Description:** Supplier quality asks which approved suppliers have expiring certificates, repeat rejects or overdue audits, and which components depend on them. **Erp Objects:** 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 **Description:** Operations asks which lots are near expiry, in quarantine or on hold, and which open work orders depend on them. **Erp Objects:** 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 **Description:** 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. **Erp Objects:** 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. ## Architecture **Overview:** 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. **Layers:** #### Read-only data access **Detail:** 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. #### Semantic model with domain control **Detail:** 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. #### Document and record retrieval **Detail:** Controlled documents, SOPs, supplier files and audit reports are indexed with revision and approval status so the assistant cites effective versions only. #### Private model serving **Detail:** 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. #### Governance and audit trail **Detail:** 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. ## Deployment Options ### On-prem next to QAD **Fit:** Manufacturers hosting QAD themselves with strict data handling requirements for complaint and design data. **Detail:** 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 **Fit:** Companies with cloud governance already in place for regulated workloads. **Detail:** 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 **Fit:** Teams that want to prove value before formal validation. **Detail:** 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 ### 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. **Framework:** FDA 21 CFR Part 820 (QMSR) and ISO 13485:2016 ### 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. **Framework:** FDA 21 CFR Part 11 for electronic records and signatures ### UDI and lot data can be checked for consistency, with regulatory staff owning submissions and corrections. **Framework:** UDI (21 CFR 830) and EU MDR 2017/745 traceability ### Complaint and CAPA trend summaries can inform risk file reviews. Judgments on risk acceptability remain with qualified people. **Framework:** ISO 14971 risk management and post-market surveillance ### 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. **Framework:** Data protection (HIPAA where applicable, GDPR) ## Integration Notes - 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. ## Product Fit ### ERPray **Why:** 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 **Why:** Lets quality ask questions across QAD, the QMS, controlled documents and audit files on-prem, which suits evidence assembly and CAPA trend review. ## Engagement ### Discovery and intended use **Duration:** 1 to 2 weeks **Deliverables:** - 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 ### Pilot build **Duration:** 4 to 6 weeks **Deliverables:** - 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 ### Assessment **Duration:** 3 to 5 weeks **Deliverables:** - 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 ### Controlled rollout **Duration:** 2 to 4 weeks **Deliverables:** - 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 ## Buyer Questions - 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? ## Faq ### Is AI allowed in a medical device QMS? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms QAD medical device AI, AI for QAD ERP medical devices, QMSR ERP AI, ISO 13485 ERP AI, device history record AI review, UDI lot traceability ERP AI, private AI medical device manufacturer, QAD FDA 21 CFR 820 AI, CAPA complaint trend AI ERP, QAD lot traceability medical, medical device ERP on-prem AI, AI QMS read-only retrieval --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json