Use-case Medtech · Hamburg-Mitte · MDR + IEC 62304 + AEMPS

Tickets MDR-Vigilance en 15 días - clasificados severity, ready para reporting BfArM, ready para auditoría Notified Body. Puente a AEMPS España.

Tickets de MDR-Vigilance desde 64 países en plazo de 15 días. Clasificación severity, reporting BfArM, IEC 62304, ISO 13485. AEMPS España + Fenin bridge.

Workshop en Grindelberg Todos los 7 casos de uso ←

Capítulo 1 — El plazo de 15 días como cuello de botella

80 service-tickets al día desde 64 países. Clasificación severity en 15 días obligatoria.

Fabricante medtech de Hamburgo (foco endoscopia, ~1.200 empleados, de los cuales 240 en servicio/campo en todo el mundo) procesa 80 service-tickets al día desde 64 países. Inglés-canal principal con mix de idioma local: español de Latinoamérica, portugués de Brasil, japonés, español de hospitales del SNS en España. MDR EU 2017/745 Art. 87 exige clasificación severity y reporting BfArM dentro de 15 días para serious incidents, 30 días para trends. Para mercado español: adicionalmente notificación paralela a AEMPS para productos comercializados en España con misma ventana de tiempo.

Práctica actual: 4 personas a tiempo completo en Compliance-Team, guardia de fin de semana crítica. Clasificación severity según MDCG 2019-11 (escala B/C/D). En severity B (Serious Incident: muerte, peligro vital, daño permanente) reporting BfArM automático. En severity D (Reportable Field Safety Corrective Action) ruta Field-Safety-Corrective-Action con notificación Notified Body.

División Decision-Layer típica para triaje MDR-Vigilance: 50% REGLAS (estado del plazo de 15 días, árboles de clasificación BfArM, validación de campos obligatorios producto/nº serie/incidente), 30% IA AUTÓNOMA (detección de idioma, severity-match contra Risk-Management-File, clasificación de síntomas), 20% HUMANO (evaluación incidente severity B, escalado Notified Body, análisis de trend en incidentes repetidos).

En febrero 2026 la autoridad de protección de datos de Hamburgo publicó un catálogo de requisitos sobre AI en productos sanitarios - transparencia de algoritmos en diagnóstico de imagen, audit-trail sobre datos de entrenamiento, evaluación de riesgo certificada por Notified Body. Arquitectura Decision-Layer cumple estos requisitos arquitectónicamente. Para mercado español: en paralelo AEPD Resolución sobre tratamiento de datos de salud (2024).

Capítulo 2 — Decision-Record para un MDR-Vigilance-Ticket

Cómo un service-ticket entrante de São Paulo se triaja en el Decision-Layer.

Decision-record anonimizado para service-ticket entrante de Brasil (São Paulo) en fabricante de endoscopia de Hamburgo. Intake ticket día 1 de 15. Clasificación severity y preparación reporting BfArM. Mismo workflow funciona para AEMPS reporting si producto comercializado en España.

VIG-2026-05-15-BR-SP-EN450-014

Service-Ticket · Endoscopio EN450 · São Paulo BR · Intake 15.05.2026 09:18 · Día 1 de 15

Resultado Severity B sospecha · Reporting BfArM iniciado
  1. 01 REGEL

    Validación intake + inicio plazo

    Ticket de Brasil (Service-Center São Paulo) por formulario estándar. Campos obligatorios producto (EN450), número de serie (SN-2024-0488123), descripción del incidente en PT-BR. Inicio plazo 15.05.2026 09:18, día 1 de 15. Regla vig_intake_v3.4.

    ✓ Intake válido
  2. 02 KI

    Detección de idioma + traducción

    Descripción del incidente en PT-BR (portugués Brasil) detectada. Traducción a EN para triaje interno. Original PT-BR permanece para audit-trail. Modelo multilingual-medtech-v3.1.

    Confidence 0,96 · umbral 0,85

    ✓ Traducido
  3. 03 KI

    Clasificación de síntomas contra Risk-Management-File

    Síntoma descrito (sobrecalentamiento de endoscopio durante intervención, lesión de paciente grado 2) mapeado contra Risk-Management-File del producto EN450. Match: Risk-ID R-EN450-007 (Thermal Hazard). Modelo medtech-symptom-classifier-v2.5.

    Confidence 0,91 · umbral 0,85

    ✓ Risk R-EN450-007
  4. 04 REGEL

    Clasificación MDCG 2019-11

    Lesión de paciente grado 2 + Thermal Hazard + relevante para intervención = severity B (Serious Incident: daño permanente posible). Árbol de clasificación según MDCG 2019-11. Regla mdcg_2019_11_v1.7.

    ▲ Severity B
  5. 05 MENSCH

    Compliance-Officer review obligatorio

    Parada obligatoria en sospecha severity B. Compliance-Officer Sra. B. (MDR-certificada) recibe conjunto estructurado de datos con síntoma, Risk-ID, idioma original y razonamiento de clasificación. Confirma severity B tras 35 min review. Documentado con marca de tiempo.

    ✓ Severity B confirmada
  6. 06 REGEL

    Preparación reporting BfArM

    Severity B dispara reporting BfArM dentro de 15 días (día 1 corriendo). Conjunto estructurado de datos para formulario obligatorio BfArM generado (producto, número de serie, incidente, estado paciente, clasificación riesgo, medidas fabricante). Paralelamente formulario AEMPS preparado si producto comercializado en España. Regla bfarm_aemps_reporting_v4.2.

    ✓ BfArM + AEMPS formularios pre-rellenados
  7. 07 KI

    Análisis de trend contra base de incidentes previos

    Síntoma + producto + Risk-ID comparados contra últimos 24 meses incidentes. 2 incidentes similares (Lima 2024-11, Frankfurt 2025-08). Indicador trend: 'creciente' no cumplido (3/24 meses < umbral trend 5/24). Modelo trend-analyzer-v2.0.

    ✓ Sin trend
  8. 08 REGEL

    Actualización PMS + pre-notificación Notified Body

    Incidente integrado en Post-Market-Surveillance-Plan. Actualización PSUR para próximo periodo marcada. TÜV SÜD (Notified Body para EN450) recibe pre-notificación con tracking-ID (obligatorio en severity B). Para mercado español: AENOR como organismo notificado español paralelamente notificado. Regla pms_psur_v3.1.

    ✓ PMS actualizado
  9. 09 REGEL

    Audit-Trail + ISO 13485 QMS persist

    Decision-record completo con versiones de modelos, hash inputs, intervención humana (Sra. B. marca de tiempo + razonamiento), estado reporting BfArM/AEMPS persistido. Vista audit-trail para auditoría Notified Body Surveillance. Record ISO 13485 QMS automáticamente creado. Regla iso13485_audit_v1.4.

    ✓ Audit-trail persistido

Capítulo 3 — IEC 62304 + workshop Notified Body en Grindelberg

Sede Hallerstraße 8 - 12 min al cluster medtech Hamburg-Mitte.

Sede Hallerstraße 8 está en 12 min en coche al cluster medtech Hamburg-Mitte (fabricantes de endoscopia, especialistas imaging, suministradores de hospital). Reuniones on-site en Compliance-Officers o auditores Notified Body alcanzables el mismo día. Engineering-Counterpart está en Hamburgo, conoce realidad MDR, no en Berlín o Múnich. Para clientes españoles con filial alemana: workshop abarca MDR + requisitos AEMPS dual-stack.

IEC 62304 ciclo de vida del software: Decision-Layer está clasificado como software dentro del QMS (no externo). Software-Safety-Class se establece en workshop Discovery - típicamente Class B para herramientas Vigilance-Workflow (sin lesión directa, pero posible impacto indirecto). Verification + Validation Records automatizados, actualizaciones Risk-Management-File estructuradas generadas. En actualizaciones de firmware del producto medtech el Decision-Layer carga paralelamente la actualización de documentación de ciclo de vida.

Workshop en Grindelberg aborda realidad Notified Body: trainings de auditores TÜV SÜD/BSI/DEKRA en sala separada con demo en vivo audit-trail. Compliance-Officer con walk-through clasificación MDR-Vigilance. Integración ISO 13485 QMS con mock Surveillance-Audit. Para mercado español: sesión dedicada sobre AEMPS + AENOR + guías españolas MDR. Código fuente del Decision-Layer va con handover de repositorio al fabricante medtech - incluyendo documentación QMS para Notified Body Surveillance.

Co-pilot medtech opcional: A demanda traemos consultoría Compliance experimentada en Notified Body (p.ej. partnership Johner-Institut, MT-Procons) como co-pilot al workshop - para evaluación de conformidad QMS, MDR-Audit-Prep, IEC-62304-Reviews. Decision-Layer permanece área Gosign, consultoría Compliance es co-pilot. Para clientes españoles disponible partnership español con Asecal o Fenin.

Casos de uso relacionados

Preguntas frecuentes

¿Qué regulaciones MDR cubre el Decision-Layer?
MDR EU 2017/745 (Reglamento de Productos Sanitarios), en particular Art. 87 (reporting vigilance con plazo de 15 días para serious incidents, 30 días para trends), MDCG 2019-11 (clasificación MDSW Medical Device Software), IEC 62304 (ciclo de vida del software), ISO 13485 (gestión de calidad de productos sanitarios), Post-Market-Surveillance-Plan (PMS) según Art. 83-86. Plus FDA 21 CFR Part 820 para mercado USA si fabricante medtech Hamburgo tiene licencia US. Plus AEMPS (Agencia Española de Medicamentos y Productos Sanitarios) como autoridad nacional española - obligación de notificación paralela de incidentes para productos comercializados en España. Auditorías Notified Body por TÜV SÜD, BSI, DEKRA con Surveillance anual + Re-Certification cada 5 años.
¿Cómo se cumple el plazo de 15 días para clasificación severity?
Service-Tickets desde 64 países entrantes, frecuentemente en inglés con mix de idioma local (español de Latinoamérica, portugués de Brasil, japonés). Patrón Decision-Layer: paso REGLAS comprueba estado del plazo (día 1 de 15) y campos obligatorios (producto, número de serie, descripción del incidente). IA AUTÓNOMA clasifica severity según MDCG 2019-11 (escala B/C/D), detección de idioma, symptom-match contra Risk-Management-File. HUMANO obligatorio en severity B (Serious Incident) - Compliance-Officer revisa, reporting BfArM se prepara. En severity D (Reportable Field Safety Corrective Action) ruta de escalado automática.
¿Cómo se mapea el ciclo de vida del software IEC 62304 en actualizaciones de firmware?
Actualización de firmware de endoscopio significa actualización de documentación de ciclo de vida IEC 62304, reassessment de riesgo, notificación Notified Body. Plazo actual: 14 semanas por actualización, clientes esperando. Decision-Layer almacena Software-Safety-Class IEC 62304 (A/B/C) como constraint, automatiza Verification + Validation Records, genera actualizaciones de Risk-Management-File. Notificación Notified Body estructurada con audit-trail. Humano obligatorio en Risk-Acceptance-Decision por Risk-Manager.
¿Qué hay sobre la carta HmbBfDI 2026-02 sobre AI en productos sanitarios?
La autoridad de protección de datos de Hamburgo publicó en febrero 2026 un catálogo de requisitos sobre transparencia de algoritmos en diagnóstico de imagen apoyado por AI. Requisitos: explicabilidad de decisiones diagnósticas, audit-trail sobre datos de entrenamiento, evaluación de riesgo certificada por Notified Body. Arquitectura Decision-Layer cumple estos requisitos: cada evaluación de imagen AI con versión de modelo, hash de input, confidence-score, ruta de escalado a radiólogo en baja confidence. Plus RGPD Art. 22 derecho de impugnación para pacientes afectados. Paralelo español: AEPD Resolución sobre tratamiento de datos de salud (2024) requiere transparencia equivalente en sistema sanitario español.
¿El Decision-Layer también aborda preparación de auditoría Notified Body con ISO 13485?
Sí. ISO 13485 es estándar QMS obligatorio para productos sanitarios con marcado CE. Decision-Layer está clasificado como software dentro del QMS (no externo). Software-Safety-Class IEC 62304 se establece en workshop Discovery (típicamente Class B para herramientas Vigilance-Workflow). MDR Annex IX/X evaluación de conformidad documentada. Post-Market-Surveillance-Plan (PMS), PSUR y Trending integrados. En auditoría Notified Body (TÜV SÜD/BSI/DEKRA) posible exportación de un clic de vista audit-trail. Para mercado español: exportación adicional compatible con AEMPS.

Agendar workshop en Grindelberg

3 días de discovery: Día 1 análisis de procesos, Día 2 mapeo Decision-Layer, Día 3 priorización de casos.

Agendar cita

Discovery workshop bajo EUR 10.000. Precio fijo de piloto tras el workshop.

← Volver a la vista general: AI Agents Hamburgo