ERP para fabricantes de dispositivos médicos: lo que Epicor Kinetic debe gestionar bajo QMSR
Los registros que detalla la QMSR, qué sistema debe conservar cada uno y qué configurar antes de la puesta en marcha.
Gonzalo Nuñez
Chief Technology Officer
Un ERP para dispositivos médicos opera ahora dentro de un nuevo marco regulatorio. Desde el 2 de febrero de 2026, la norma de calidad de dispositivos de la FDA tiene un nuevo título: Quality Management System Regulation, o QMSR. Según el texto vigente de 21 CFR Part 820, un fabricante documenta un sistema de gestión de la calidad que cumple con ISO 13485:2016, y se aplican las definiciones de ISO 13485 y de la Cláusula 3 de ISO 9000.
Ese cambio importa porque modifica la forma en que un equipo de implementación debe leer la norma. Y la pregunta práctica para cualquier equipo que opera o evalúa Epicor Kinetic no es si el ERP cumple con la norma. La mejor pregunta es qué registros sigue detallando Part 820 campo por campo, qué sistema debe ser responsable de cada uno y qué debe configurarse antes del arranque para que esos registros puedan crearse sin improvisación.
Este artículo lee los requisitos de registros de QMSR como si fueran una especificación de ERP. Asigna cada requisito al sistema que debería contenerlo en un entorno Kinetic y señala las decisiones de configuración que deben tomarse antes de que cierre el proyecto.
Qué cambió QMSR para un ERP de dispositivos médicos
Part 820 ha sido revisada. Desde el 2 de febrero de 2026, la norma incorpora ISO 13485:2016 por referencia. Las definiciones aplicables son las de ISO 13485 y las de la Cláusula 3 de ISO 9000. El término que usa el texto vigente es medical device file (archivo del dispositivo médico).
El texto vigente de Part 820 no contiene los términos device history record (registro histórico del dispositivo) ni device master record (registro maestro del dispositivo). Esos términos aparecían en la versión anterior de la norma. Si sus documentos internos de requisitos, instrucciones de trabajo o plantillas de proyecto aún los utilizan, el paso práctico es volver a leer el texto vigente de Part 820 e identificar qué registros sigue detallando. Es una tarea de lectura, no una obligación de cambiar nombres.
El marco más útil es el siguiente. QMSR no le indica a usted qué software comprar. Sí le indica que ciertos registros deben existir y, para algunos de ellos, qué debe contener cada registro. Esos campos no son conceptos regulatorios abstractos. Son decisiones de diseño del sistema.
Part 820 abarca el diseño, la fabricación, el empaque, el etiquetado, el almacenamiento, la instalación y el servicio de todos los dispositivos terminados destinados al uso humano. Un fabricante que realiza solo algunas de esas operaciones cumple únicamente con los requisitos de esas operaciones. Por lo tanto, el alcance correcto de la implementación parte de su operación real, no de una lista de verificación genérica.
Qué sigue detallando Part 820
QMSR agrega una breve lista de requisitos de registros con contenido especificado que se suma a la obligación del sistema de gestión de la calidad de ISO 13485:2016. Esos requisitos aparecen en:
- 820.10(b): El sistema documentado para la identificación única de dispositivos, los procedimientos de trazabilidad cuando corresponda y la vía de reporte de quejas que cumplen los criterios de Part 803.
- 820.35: Registros de quejas, incluidos los campos específicos requeridos para quejas reportables, quejas investigadas y quejas investigadas independientemente de su reportabilidad.
- 820.45: Examen del etiquetado y del empaque antes de su liberación o almacenamiento, liberación documentada y prevención de confusiones con los resultados de la inspección registrados.
Cada uno de esos requisitos produce datos. Esos datos tienen que residir en algún lugar. El resto de este artículo trata sobre dónde.
Los registros que Part 820 detalla, asignados al sistema que los contiene
La forma más útil de leer estas secciones es como un ejercicio de límites entre sistemas. La norma establece qué debe documentarse. Su implementación tiene que decidir dónde se crea cada campo, qué sistema es su responsable y qué sistemas conectados solo lo leen.
| Requirement | What the rule asks for | Where we recommend the data live | Decision to make |
|---|---|---|---|
| 820.10(b)(1) | A documented system to assign unique device identification under Part 830 | Quality system plus ERP-connected operational workflow | Where the UDI is captured, and which system is the source for assigned and carried identification |
| 820.35(a) | Complaint records with specified content for reportable complaints, complaints the manufacturer determines must be investigated, and complaints investigated anyway | Quality system as the complaint record owner, fed by CRM and ERP data | Which system owns the complaint record, and how customer, device, shipment, and corrective-action data feed it |
| 820.35(c) | The UDI must be recorded for each medical device or batch of medical devices | Operational record where device or batch traceability is captured, connected to ERP traceability data | Whether UDI is captured at device level or batch level, and at what point in the process it is recorded |
| 820.45 | Labeling and packaging examined for accuracy before release or storage, including correct UDI or UPC, expiration date, storage, handling, and additional processing instructions; release of labeling documented; mixup prevention with inspection results recorded | ERP-supported labeling and shipping workflow, with quality review where the manufacturer's process requires it | Which step checks label data, how release is documented, and how mixup prevention and inspection results are recorded |
La regla general: un sistema responsable por campo
La disciplina crítica aquí es la responsabilidad única. Un campo puede ser visible en más de un lugar, pero debe crearse en uno solo. Si un registro de queja necesita el nombre del dispositivo, ese valor no debe escribirse a mano en tres sistemas. Si una verificación de etiquetado necesita una fecha de vencimiento, esa fecha no debe mantenerse en una hoja de cálculo y luego volver a ingresarse en el flujo de liberación.
La tercera columna de la tabla anterior es una recomendación, no una afirmación sobre una arquitectura declarada por Epicor. La norma le indica a usted qué debe existir. No asigna módulos de software. Por eso, la postura correcta de implementación es recomendar un diseño que reduzca la captura duplicada y haga explícita la responsabilidad de cada registro antes del arranque.
En un entorno Kinetic, eso significa que la trazabilidad por lote y serie puede residir en los registros del ERP, donde ya ocurren las actividades de fabricación y envío. No significa que todo registro regulatorio deba declararse por defecto como un registro del ERP. La responsabilidad de las quejas, el punto de captura del UDI y la evidencia de liberación del etiquetado requieren una decisión de diseño deliberada antes de que cierre el proyecto.
Por qué la decisión importa antes de la migración
Esa decisión de diseño tiene una consecuencia posterior fácil de subestimar. La migración y la capacitación siguen a la decisión de responsabilidad. Si se decide tarde que servicio al cliente registra la queja en un sistema, calidad completa la investigación en otro y el ERP aporta los datos de envío desde un tercero, no se está cambiando una preferencia. Se están cambiando campos, roles, integraciones e instrucciones de trabajo. Definir bien y a tiempo el mapa de responsabilidades hace que el sistema que se configura y el sistema en el que se capacita a los usuarios sean el mismo.
Trazabilidad por lote y serie: qué debe contener Kinetic
Part 820 exige un sistema documentado para asignar la identificación única de dispositivos conforme a Part 830. También exige procedimientos de trazabilidad conforme a Part 821 cuando corresponda. Y en su sección de registros establece que el UDI debe registrarse para cada dispositivo médico o lote de dispositivos médicos.
Ahí es donde Kinetic entra en escena de manera concreta. Epicor enumera Lot and Serial Tracked Parts, WIP PCIDs, Serial Genealogy of components and products y la capacidad de asignar piezas a clientes por designación de lote y serie entre sus capacidades para dispositivos médicos. Son capacidades de fabricación y trazabilidad. Son directamente relevantes porque determinan si el ERP puede conservar la evidencia de producción y envío necesaria cuando posteriormente deba identificarse un dispositivo o un lote.
Pero la decisión de implementación es más acotada que la etiqueta de la capacidad. Kinetic puede contener datos de lote y serie. Su equipo todavía tiene que decidir dónde se captura el UDI, cómo se vincula con el dispositivo o el lote y cómo viaja esa identificación hacia los registros posteriores.
Las decisiones de configuración en la trazabilidad
- Qué piezas se rastrean por lote y cuáles por serie.
Es una decisión de producto y de proceso antes de ser una decisión de configuración. Si se asigna el modo de rastreo equivocado, la genealogía y el historial de envíos posteriores pierden valor. - Dónde se captura el UDI en el proceso.
Part 820 exige un sistema documentado para asignar el UDI, pero su implementación debe decidir si la captura ocurre en la fabricación, el etiquetado, el empaque u otro paso controlado. Esa decisión determina qué flujo de trabajo se convierte en la fuente de los registros posteriores. - Qué profundidad debe tener la genealogía.
Epicor describe la genealogía de series de componentes y productos. El proyecto aún debe decidir qué tan hacia atrás y hacia adelante debe ser visible la genealogía para su operación y sus tipos de producto. - Cómo los registros de envío conservan la designación de lote y serie.
Epicor indica que las piezas pueden asignarse a clientes por designación de lote y serie. Esto importa porque el lado del envío es donde la trazabilidad se encuentra con el registro del cliente, y donde comenzará la búsqueda de una queja si más adelante surge un problema.
El UDI no es lo mismo que el lote y la serie
El error práctico aquí es reducir el UDI a lote y serie sin pensar en el punto de captura. Los datos de lote y serie son datos de trazabilidad centrales en Kinetic. Respaldan la identificación, la genealogía y el historial de envíos. La decisión sobre el UDI es más amplia. Debe considerar el punto en que se asigna o registra el identificador, la forma en que se transporta y el sistema que se convierte en la fuente de las consultas posteriores de quejas, etiquetado o envíos.
Kinetic suministra datos de lote y serie. Dónde se captura el UDI y qué sistema se convierte en el registro de esa captura es la decisión que su equipo debe tomar antes de que comience el paso de configuración. Si esa decisión se aplaza, el diseño de trazabilidad se construirá sobre un supuesto que quizá no se sostenga.
Verificaciones de etiquetado, liberación y retención de envíos
La sección 820.45 es un control de etiquetado y empaque. Exige que el etiquetado y el empaque se examinen para verificar su exactitud antes de su liberación o almacenamiento. Ese examen abarca cinco elementos que la norma nombra:
- El UDI o UPC correcto
- Fecha de vencimiento
- Instrucciones de almacenamiento
- Instrucciones de manejo
- Cualquier instrucción de procesamiento adicional
También exige que la liberación del etiquetado se documente y que las operaciones se configuren para prevenir confusiones, con los resultados de la inspección registrados.
Eso es más acotado que una lista de verificación de liberación general. El requisito se refiere a la exactitud del etiquetado y del empaque, la liberación documentada y la prevención de confusiones. No es un registro de liberación del dispositivo terminado en el sentido más amplio.
Qué contiene el ERP para esto
Para el diseño de un ERP, eso significa que el sistema debe respaldar los datos y los pasos del proceso relacionados con la exactitud del contenido de las etiquetas y la documentación de la liberación. Los módulos de Kinetic enumerados incluyen Inventory Management, Warehouse Management, Shipping and Receiving y Quality Management. Son las áreas donde los datos de producto, lote, vencimiento y movimiento pueden organizarse en un flujo controlado de etiquetado y liberación.
La pregunta práctica de implementación no es si una sola pantalla puede mostrarlo todo. Es si los datos utilizados en las verificaciones de etiquetado y empaque provienen de una fuente consistente, y si la documentación de liberación y los resultados de inspección se capturan donde realmente ocurre el proceso.
Un equipo también debe decidir cómo prevenir confusiones en la operación. Eso puede incluir cómo se generan las etiquetas, cómo se hace coincidir el empaque con el dispositivo o lote correcto, qué se inspecciona antes de la liberación o el almacenamiento y dónde se registra el resultado de la inspección. Si esos controles residen en parte en el ERP y en parte en un flujo de calidad adyacente, la transferencia entre ambos debe ser explícita.
La barrera comercial junto al control de etiquetado
Existe una regla de negocio separada, del lado de la liberación, que se sitúa junto al control de 820.45 pero no es el mismo requisito. En la configuración de SugarAI descrita en la página CRM para MedTech, operaciones no liberará producto a un sitio a menos que haya un médico certificado en él. La marca de certificación en la ubicación es de solo lectura y se establece únicamente cuando se completa el proceso de firma. Un representante no puede marcar una casilla para enviar producto.
Esa es una barrera comercial y operativa vinculada a la preparación del cliente. Debe diseñarse junto con la lógica de envíos del ERP porque puede detener un envío. Pero no es un requisito de 820.45. El control de etiquetado y empaque y la barrera de certificación atienden cosas distintas y deben configurarse con esa distinción presente.
Las quejas comienzan fuera de la planta
Una queja no comienza como un registro de calidad. Comienza como un evento. Un representante se entera. Servicio al cliente recibe una llamada. Un contacto del hospital plantea un problema. Para cuando calidad lo revisa, partes del registro ya existen en otros sistemas, o deberían existir.
Por eso 820.35(a) es tan importante para el diseño del ERP. Para las quejas reportables conforme a Part 803, las quejas que el fabricante determina que deben investigarse y las que investigó de todos modos, la norma especifica siete elementos que el registro debe contener. Esos elementos deben asignarse deliberadamente antes de que el sistema entre en operación.
Los siete elementos y de dónde debe provenir cada uno
1. El nombre del dispositivo.
Debe provenir de los datos de producto ya gobernados en el sistema operativo. No debe ser texto libre escrito en el flujo de la queja por quien se encargue de la recepción.
2. La fecha de recepción.
Pertenece al evento de recepción. El sistema que registra primero la queja debe crear este campo. Si la recepción ocurre en un CRM o en una herramienta de servicio al cliente, la fecha debe trasladarse en lugar de volver a ingresarse después.
3. Cualquier UDI o UPC, y cualquier otra identificación del dispositivo.
Esta es la redacción propia de la norma, y es más amplia que lote y serie. De dónde proviene esta identificación depende de dónde se capture el UDI, la decisión de trazabilidad descrita arriba. Kinetic suministra datos de lote y serie, que respaldan la identificación y la trazabilidad. El campo de identificación más amplio debe obtenerse del sistema que sea responsable del punto de captura del UDI.
4. El nombre, la dirección y el teléfono de quien presenta la queja.
Son campos del lado del cliente. Deben provenir del lado del entorno orientado al cliente, no ser reconstruidos desde cero por el equipo de calidad que atiende la queja.
5. La naturaleza y los detalles de la queja.
Esto comienza con la recepción y debe conservarse en el registro responsable de la queja. Si el sistema de recepción no es el sistema responsable de la queja, la transferencia debe ser explícita, no un copiar y pegar.
6. Cualquier corrección o acción correctiva.
Pertenece al proceso de calidad que evalúa la queja y actúa sobre ella. Se origina en el sistema de calidad y no en el ERP ni en el CRM.
7. Cualquier respuesta a quien presentó la queja.
Puede originarse en los equipos orientados al cliente, pero debe adjuntarse al registro de la queja para que todo el historial permanezca en un solo lugar.
Qué sistema es responsable del registro de la queja
Su equipo debe decidir qué sistema es el responsable del registro de la queja. Nuestro diseño recomendado es que el sistema de calidad sea responsable del registro de la queja, con el ERP y el CRM aportando los campos que ya controlan. Eso mantiene la acción correctiva dentro del flujo de calidad y, al mismo tiempo, incorpora los datos de producto, envío y cliente necesarios para completar el registro sin volver a capturarlos.
La integración entre Kinetic y SugarAI importa aquí porque las cuentas, las piezas, las cotizaciones, los pedidos, los envíos y las facturas fluyen entre ambos. Si el historial comercial y de clientes ya reside en Kinetic y SugarAI, la recepción de quejas debe usar ese contexto compartido en lugar de crear un registro paralelo.
Epicor describe capacidades para dispositivos médicos que incluyen el manejo de quejas y el Medical Device Reporting electrónico, así como soporte integrado para CAPA, Supplier Corrective Action Requests y desviaciones planificadas. Es un contexto útil. Muestra que los procesos de quejas forman parte del conjunto de capacidades para dispositivos médicos que describe Epicor. No elimina la decisión de implementación sobre qué sistema es responsable del registro de la queja.
Part 820 también exige que las quejas que cumplen los criterios de reporte de Part 803 se reporten a la FDA. Esa es una consecuencia del proceso de evaluación de la queja, no un campo separado del ERP. Pero sí significa que el flujo de la queja debe incluir un paso en el que se evalúe y se documente la reportabilidad.
Si su equipo también está definiendo la transferencia entre los flujos orientados al cliente y los datos del ERP, lea ERP vs CRM para fabricantes de dispositivos médicos para conocer la cuestión del límite. Este artículo trata la consecuencia de ese límite sobre el registro de la queja, no el límite en sí.
Vea cómo TCP implementa Epicor Kinetic
Proveedores y planta de producción
La evidencia de proveedores y de producción no debe tratarse como trabajo de limpieza posterior. En un entorno Kinetic, esos registros son más sólidos cuando se crean mientras el trabajo se ejecuta, y no cuando se reconstruyen de memoria y con notas en papel.
Del lado de los proveedores, Kinetic enumera Supplier Relationship Management y Purchase Management entre sus módulos. Epicor también describe Supplier Corrective Action Requests (SCAR) y CAPA como parte de su conjunto de capacidades para dispositivos médicos. Eso importa porque los problemas de proveedores no permanecen aislados. Afectan el control de material entrante, las decisiones de compra, el seguimiento de calidad y, en algunos casos, el historial de quejas o acciones correctivas. La decisión de implementación es cómo se conectan esos flujos y qué sistema activa cada acción cuando se identifica un problema de proveedor.
Evidencia de planta creada en tiempo real
En la planta de producción, Advanced MES agrega otro tipo de creación de evidencia. Advanced MES captura datos de máquinas y operadores en tiempo real, aplica SPC y SQC, registra desperdicio, rendimiento y métricas de calidad, y los devuelve al ERP.
Eso cambia la postura de implementación de forma práctica. La captura en tiempo real significa que la evidencia de producción se genera donde ocurre el trabajo y luego se alimenta al conjunto de registros del ERP que operaciones y calidad ya utilizan. La alternativa, reunir la evidencia de producción después a partir de la memoria de los operadores y de bitácoras en papel, introduce vacíos difíciles de cerrar más adelante.
Los roles del ERP y del MES siguen siendo distintos. El ERP es responsable del registro operativo más amplio. El MES aporta datos a nivel de ejecución que el ERP no debería pedir a los usuarios que recreen manualmente. Si desea conocer con más detalle el límite entre ambos, lea Epicor MES vs ERP. Para una planta de dispositivos, el punto relevante es más simple: si el MES está dentro del alcance, el flujo de datos de regreso al ERP debe diseñarse antes del arranque, no descubrirse durante la capacitación.
Decisiones que deben tomarse antes de que Kinetic entre en operación
Si un fabricante de dispositivos espera hasta las pruebas o la capacitación para responder estas preguntas, el proyecto ya va tarde. Estas decisiones pertenecen a la etapa previa al arranque porque afectan la configuración, la migración, los roles y los flujos de trabajo conectados. Cada una se relaciona con una sección anterior de este artículo.
- Establezca el modo de rastreo por pieza.
Decida qué piezas se rastrean por lote y cuáles por serie. Esta elección determina la genealogía, el historial de envíos y la búsqueda posterior de quejas. Equivocarse al inicio significa deshacerlo cuando los datos ya están en el sistema. - Elija el punto de captura del UDI.
Part 820 exige un sistema documentado para asignar la identificación única de dispositivos conforme a Part 830. Su implementación debe decidir dónde ocurre esa captura, qué paso del proceso la crea o la registra y qué sistema se convierte en la fuente de los registros posteriores de quejas, etiquetado y envíos. - Defina los datos de las etiquetas y el paso de liberación del etiquetado.
Decida dónde se redactan, verifican y liberan el UDI o UPC correcto, la fecha de vencimiento, las instrucciones de almacenamiento, las instrucciones de manejo y las instrucciones de procesamiento adicionales. Decida cómo se documenta la liberación y cómo se registran los resultados de la inspección. - Elija al responsable del registro de quejas y defina los flujos de datos hacia él.
Decida qué sistema es responsable del registro de la queja y luego defina cómo lo alimentan los datos de producto, envío, cliente y acciones correctivas. El objetivo es un solo registro sin captura duplicada. - Defina el flujo de proveedores y de no conformidades.
Si los problemas de proveedores pueden activar SCAR, CAPA o acciones de calidad posteriores, decida cómo funciona esa transferencia antes de que los usuarios inventen sus propias soluciones alternativas. - Decida dónde ingresan los datos de la planta.
Si Advanced MES está dentro del alcance, decida qué se captura allí y cómo se devuelve al ERP. Ese diseño corresponde antes de la configuración, no después del arranque. - Gestione los lotes y series abiertos en la migración.
La migración abarca artículos, BOM, rutas, clientes, proveedores, pedidos abiertos y cuentas por pagar y por cobrar abiertas. En una planta de dispositivos, los lotes abiertos y los registros operativos vinculados a series también necesitan una regla de migración. Dejarlos fuera significa que el registro histórico de trazabilidad tendrá un vacío desde el primer día. - Trate la cadencia de despliegue como un insumo de su propio plan de validación.
Kinetic puede desplegarse como SaaS multiinquilino, nube privada, en las instalaciones o híbrido. Epicor indica que las actualizaciones de Kinetic se ejecutan con una cadencia diferida que respalda los requisitos de cumplimiento. Su sistema de calidad es responsable de las decisiones sobre cómo se gobierna y se valida ese entorno.
Si desea la visión más amplia de las fases de implementación, lea la guía de implementación de Epicor Kinetic. Este artículo es más acotado por diseño. Cubre las decisiones de registros y flujos de trabajo que deben resolverse antes de que comiencen esas fases.
TCP es Epicor Platinum Partner y SugarAI Elite Partner con más de 600 implementaciones en las Américas, y ha construido el rastreo por lote y serie para fabricantes médicos y de otros sectores regulados.
Su programa de calidad y asuntos regulatorios, y la responsabilidad final sobre él, permanecen con usted. Lo que un socio de implementación puede hacer es asegurar que cada registro que la norma detalla tenga un sistema responsable y que ese sistema esté configurado antes de que comience la capacitación, no después.
Hable con TCP sobre Kinetic para una planta de dispositivos
Si sus registros de QMSR aún residen en hojas de cálculo y unidades compartidas, TCP puede implementar Kinetic para que cada registro que la norma detalla tenga un sistema responsable.
Preguntas Frecuentes
No. La FDA afirma que no exigirá certificados de conformidad con ISO 13485, y contar con un certificado no exime a un fabricante de la inspección de la FDA. Conforme al QMSR, el requisito consiste en documentar un sistema de gestión de la calidad que cumpla con ISO 13485:2016, tal como se incorpora por referencia en la Parte 820. Un certificado puede ser relevante para fines comerciales o de clientes, pero no es el requisito de la FDA en sí. La consecuencia práctica es que un certificado no puede sustituir al sistema de calidad documentado ni a los registros que este genera, que siguen siendo responsabilidad del fabricante.
No. La Parte 820 permite que un fabricante no realice una nueva investigación cuando ya se ha investigado una queja similar y no es necesaria otra investigación. Pero eso no es un pase libre. El fabricante sigue teniendo que documentar el motivo por el cual no se realizó una nueva investigación. Esa justificación debe constar en el registro de la queja, no en una nota aparte ni en una explicación informal. La consecuencia práctica para el diseño del sistema es que el flujo de trabajo de quejas debe admitir esa decisión de ramificación y capturar la justificación en un campo controlado, no como una solución provisional en texto libre.
El conjunto completo de detalles especificados del registro de quejas se aplica a tres categorías de quejas conforme a la Parte 820: las quejas notificables conforme a la Parte 803, las quejas que el fabricante determina que deben investigarse y las quejas que el fabricante investigó de todos modos. No todos los eventos de recepción reciben el mismo tratamiento, pero una vez que una queja entra en una de esas categorías, se aplica el contenido especificado del registro. La consecuencia para el sistema es que el flujo de trabajo de quejas debe admitir esa lógica de ramificación y garantizar que los campos obligatorios se capturen en el registro controlado, no fuera de él.
La Parte 820 exige que el registro de servicio contenga, como mínimo, seis elementos: el nombre del dispositivo al que se dio servicio; cualquier UDI o UPC, y cualquier otra identificación del dispositivo; la fecha del servicio; la persona o las personas que dieron servicio al dispositivo; el servicio realizado; y cualquier dato de pruebas e inspección. Estos elementos se suman a la cláusula de actividades de servicio de la norma ISO 13485. En el diseño de sistemas, los registros de servicio son un requisito propio: no debe suponerse que están cubiertos porque ya existan en otro lugar del entorno datos de envíos, de reclamaciones o de órdenes de trabajo.
No. La Parte 820 establece que los fabricantes de componentes no están sujetos a la regulación, aunque se les anima a considerar sus disposiciones pertinentes. Eso no elimina la responsabilidad del fabricante del dispositivo terminado. Los controles de proveedores siguen formando parte del propio sistema de gestión de la calidad del fabricante. Por lo tanto, la consecuencia para la implementación es indirecta, pero real: la calificación de proveedores, los controles de compras y los registros de calidad relacionados con los proveedores deben seguir respaldando las obligaciones del fabricante del dispositivo terminado conforme a su propio QMS, independientemente de cuáles sean las prácticas internas del proveedor.
La Parte 820 exige la cláusula de Trazabilidad para dispositivos implantables de ISO 13485, cláusula 7.5.9.2, a los fabricantes de dispositivos que soportan o mantienen la vida y cuyo fallo de funcionamiento, cuando se usan correctamente conforme a las instrucciones de uso del etiquetado, puede razonablemente esperarse que cause una lesión significativa. La consecuencia práctica es que el fabricante debe clasificar qué productos entran en esa categoría y asegurarse de que el diseño de trazabilidad respalde el nivel de identificación y de continuidad de registros que esos dispositivos requieren. Esa decisión de clasificación debe quedar resuelta antes de construir la configuración de trazabilidad.
Sí. La FDA afirma que, conforme al QMSR, tiene la facultad de inspeccionar los registros de revisión por la dirección, los informes de auditoría de calidad y los informes de auditoría de proveedores. La FDA también señala que las inspecciones ahora se rigen por el Programa de Cumplimiento 7382.850, que sustituye al enfoque QSIT, ya retirado. Estos registros no quedan fuera del alcance de la inspección por ser confidenciales o internos. El diseño del sistema de un fabricante debe partir de la premisa de que los registros de calidad controlados tienen que poder recuperarse y entenderse en cualquier momento. La cuestión no es si existen en algún lugar, sino si se mantienen en una forma que la organización pueda respaldar.
El estado de certificación está controlado, no es algo que un representante de ventas pueda modificar manualmente. En el flujo de trabajo de CRM para MedTech descrito, el indicador de certificación de la ubicación es de solo lectura y se establece únicamente cuando concluye el proceso de firma. Un representante no puede marcar una casilla para enviar producto. Esto es importante porque la puerta de envío depende de un estado controlado y no de una acción discrecional del usuario. La configuración que sustenta esa puerta, y cómo se conecta con el flujo de trabajo de envíos, se explica en la página CRM for MedTech.
Sí. La recomendación de implementación es planificar el CRM al mismo tiempo, aunque la construcción se realice más adelante, cuando el equipo esté listo. La ventaja es que el maestro de clientes y los precios pueden diseñarse una sola vez desde el principio, en lugar de rehacerse después de que las decisiones del ERP ya estén fijadas. En un entorno de dispositivos, donde los registros de clientes, el historial de envíos, la recepción de reclamaciones y el estado de las certificaciones cruzan distintos sistemas, un CRM planificado por separado del ERP genera una deuda de integración que habrá que pagar más tarde. El Epicor Kinetic implementation service abarca cómo se pueden planificar de forma conjunta esas decisiones conectadas.
Sí. Una implementación de Kinetic que ya está en curso puede asumirse mediante un proceso estructurado de revisión del estado del proyecto, seguido de un plan de precio fijo para terminar o corregir el trabajo. Esto es importante cuando el problema no es la selección del software, sino la calidad de la ejecución, la desviación del alcance o las decisiones de diseño sin resolver en torno a los registros, la migración y la responsabilidad de los procesos. Un traspaso no borra lo que ya se ha construido, pero puede reorientar el proyecto con un plan claro. El servicio de implementación de Epicor Kinetic describe cómo funciona ese proceso.
