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

MDR-Vigilance-Tickets w 15 dniach - sklasyfikowane Severity, gotowe do raportowania BfArM, gotowe do audytu Notified Body. Mostek do URPL Polska.

MDR-Vigilance-Tickets z 64 krajów w 15-dniowym terminie. Klasyfikacja Severity, raportowanie BfArM, IEC 62304, ISO 13485. URPL Polska bridge.

Warsztat w Grindelberg Wszystkie 7 use case'ów ←

Rozdział 1 — 15-dniowy termin jako wąskie gardło

80 Service-Tickets dziennie z 64 krajów. Klasyfikacja Severity w 15 dniach obowiązkowa.

Hamburski producent medtech (specjalizacja endoskopia, ~1 200 pracowników, w tym 240 w serwisie/przedstawicielstwie zagranicznym na świecie) przetwarza 80 Service-Tickets dziennie z 64 krajów. Angielski-kanał główny z mixem języków lokalnych: hiszpański z Ameryki Łacińskiej, portugalski z Brazylii, japoński, polski ze szpitali w Warszawie/Krakowie/Trójmieście. MDR EU 2017/745 Art. 87 wymaga klasyfikacji Severity i raportowania BfArM w ciągu 15 dni dla serious incidents, 30 dni dla trends. Dla rynku polskiego: dodatkowo równoległa notyfikacja do URPL na polskie wyroby z tym samym oknem czasowym.

Aktualna praktyka: 4 osoby pełnoetatowo w Compliance-Team, dyżur weekendowy krytyczny. Klasyfikacja Severity według MDCG 2019-11 (skala B/C/D). Przy Severity B (Serious Incident: śmierć, zagrożenie życia, trwała utrata zdrowia) automatyczne raportowanie BfArM. Przy Severity D (Reportable Field Safety Corrective Action) ścieżka Field-Safety-Corrective-Action z notyfikacją Notified Body.

Podział Decision-Layer typowy dla triażu MDR-Vigilance: 50% REGUŁY (status 15-dniowego terminu, drzewa klasyfikacji BfArM, walidacja pól obowiązkowych produkt/nr seryjny/incydent), 30% KI AUTONOM (wykrywanie języka, dopasowanie Severity względem Risk-Management-File, klasyfikacja symptomów), 20% CZŁOWIEK (ocena incydentu Severity B, eskalacja Notified Body, analiza trendu przy powtarzających się incydentach).

W lutym 2026 hamburski organ ochrony danych opublikował katalog wymagań dotyczących AI w wyrobach medycznych - transparentność algorytmów przy diagnostyce obrazowej, audit-trail nad danymi treningowymi, ocena ryzyka certyfikowana przez Notified Body. Architektura Decision-Layer spełnia te wymagania architektonicznie. Dla rynku polskiego: równolegle stosuje się Wytyczne Prezesa UODO o profilowaniu (2023).

Rozdział 2 — Decision-Record dla MDR-Vigilance-Ticket

Jak napływający Service-Ticket z São Paulo jest triażowany w Decision-Layer.

Zanonimizowany decision-record dla napływającego Service-Ticket z Brazylii (São Paulo) u hamburskiego producenta endoskopii. Przyjęcie ticketu dzień 1 z 15. Klasyfikacja Severity i przygotowanie raportowania BfArM. Ten sam workflow działa dla URPL-raportowania przy polskim wyrobie.

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

Service-Ticket · Endoskop EN450 · São Paulo BR · Przyjęcie 15.05.2026 09:18 · Dzień 1 z 15

Wynik Podejrzenie Severity B · Raportowanie BfArM zainicjowane
  1. 01 REGEL

    Walidacja przyjęcia + start terminu

    Ticket z Brazylii (Service-Center São Paulo) po standardowym formularzu. Pola obowiązkowe produkt (EN450), numer seryjny (SN-2024-0488123), opis incydentu w PT-BR. Start terminu 15.05.2026 09:18, dzień 1 z 15. Reguła vig_przyjecie_v3.4.

    ✓ Przyjęcie ważne
  2. 02 KI

    Wykrywanie języka + tłumaczenie

    Opis incydentu w PT-BR (portugalski Brazylia) wykryty. Tłumaczenie na EN dla wewnętrznego triażu. Oryginał PT-BR pozostaje dla audit-trail. Model multilingual-medtech-v3.1.

    Confidence 0,96 · próg 0,85

    ✓ Przetłumaczone
  3. 03 KI

    Klasyfikacja symptomów względem Risk-Management-File

    Opisany symptom (przegrzanie endoskopu podczas zabiegu, obrażenia pacjenta stopnia 2) zmapowany względem Risk-Management-File produktu EN450. Match: Risk-ID R-EN450-007 (Thermal Hazard). Model medtech-symptom-classifier-v2.5.

    Confidence 0,91 · próg 0,85

    ✓ Risk R-EN450-007
  4. 04 REGEL

    Klasyfikacja MDCG 2019-11

    Obrażenia pacjenta stopnia 2 + Thermal Hazard + istotne dla zabiegu = Severity B (Serious Incident: trwała utrata zdrowia możliwa). Drzewo klasyfikacji zgodnie z MDCG 2019-11. Reguła mdcg_2019_11_v1.7.

    ▲ Severity B
  5. 05 MENSCH

    Compliance-Officer obowiązkowy review

    Stop obowiązkowy przy podejrzeniu Severity B. Compliance-Officer pani B. (MDR-certyfikowana) otrzymuje ustrukturyzowany zestaw danych z symptomem, Risk-ID, językiem oryginału i uzasadnieniem klasyfikacji. Potwierdza Severity B po 35 min review. Udokumentowane ze znacznikiem czasu.

    ✓ Severity B potwierdzona
  6. 06 REGEL

    Przygotowanie raportowania BfArM

    Severity B wyzwala raportowanie BfArM w ciągu 15 dni (dzień 1 biegnie). Ustrukturyzowany zestaw danych dla obowiązkowego formularza BfArM wygenerowany (produkt, numer seryjny, incydent, status pacjenta, klasyfikacja ryzyka, środki producenta). Równolegle formularz URPL przygotowany jeśli polska rejestracja produktu istnieje. Reguła bfarm_urpl_reporting_v4.2.

    ✓ BfArM + URPL formularze wstępnie wypełnione
  7. 07 KI

    Analiza trendu względem bazy poprzednich incydentów

    Symptom + produkt + Risk-ID porównane z incydentami z ostatnich 24 miesięcy. 2 podobne incydenty (Lima 2024-11, Frankfurt 2025-08). Wskaźnik trendu: 'rosnący' nie spełniony (3/24 miesiące < próg trendu 5/24). Model trend-analyzer-v2.0.

    ✓ Brak trendu
  8. 08 REGEL

    Aktualizacja PMS + pre-notification Notified Body

    Incydent zintegrowany w Post-Market-Surveillance-Plan. Aktualizacja PSUR na następny okres oznaczona. TÜV SÜD (Notified Body dla EN450) otrzymuje pre-notification z tracking-ID (obowiązek przy Severity B). Dla rynku polskiego: PCBC (Polskie Centrum Badań i Certyfikacji) jako polski Notified Body równolegle notyfikowane. Reguła pms_psur_v3.1.

    ✓ PMS zaktualizowany
  9. 09 REGEL

    Audit-Trail + ISO 13485 QMS-Persist

    Kompletny decision-record z wersjami modeli, hash input, interwencją człowieka (pani B. znacznik czasu + uzasadnienie), statusem raportowania BfArM/URPL utrwalony. Widok audit-trail dla audytu Notified Body Surveillance. Rekord ISO 13485 QMS automatycznie stworzony. Reguła iso13485_audit_v1.4.

    ✓ Audit-Trail utrwalony

Rozdział 3 — IEC 62304 + warsztat Notified Body w Grindelberg

Hauptsitz Hallerstraße 8 - 12 min do klastra medtech Hamburg-Mitte.

Hauptsitz Hallerstraße 8 jest w 12 min samochodem od klastra medtech Hamburg-Mitte (producenci endoskopii, specjaliści imaging, dostawcy klinik). Spotkania on-site u Compliance-Officerów lub audytorów Notified Body w tym samym dniu osiągalne. Engineering-Counterpart siedzi w Hamburgu, zna rzeczywistość MDR, nie w Berlinie czy Monachium. Dla polskich klientów z niemiecką filią: warsztat obejmuje MDR + polskie wymagania URPL dual-stack.

IEC 62304 cykl życia oprogramowania: Decision-Layer jest sklasyfikowany jako oprogramowanie wewnątrz QMS (nie zewnętrzne). Software-Safety-Class jest ustalana w warsztacie Discovery - typowo Class B dla narzędzi Vigilance-Workflow (brak bezpośrednich obrażeń, ale możliwy wpływ pośredni). Verification + Validation Records automatyzowane, aktualizacje Risk-Management-File ustrukturyzowane wygenerowane. Przy aktualizacjach firmware produktu medtech Decision-Layer równolegle nosi aktualizację dokumentacji cyklu życia.

Warsztat w Grindelberg adresuje rzeczywistość Notified Body: szkolenia audytorów TÜV-SÜD/BSI/DEKRA w osobnym pomieszczeniu z live demo audit-trail. Compliance-Officer z walk-through klasyfikacji MDR-Vigilance. Integracja ISO 13485 QMS z mock Surveillance-Audit. Dla rynku polskiego: dedykowana sesja na URPL + PCBC + polskie wytyczne MDR. Kod źródłowy Decision-Layer idzie z handover repozytorium do producenta medtech - włącznie z dokumentacją QMS dla Notified Body Surveillance.

Opcjonalny medtech-co-pilot: Na życzenie przyprowadzamy doświadczone w Notified Body doradztwo Compliance (np. partnerstwo Johner-Institut, MT-Procons) jako co-pilot do warsztatu - dla oceny zgodności QMS, MDR-Audit-Prep, IEC-62304-Reviews. Decision-Layer pozostaje obszarem Gosign, doradztwo Compliance jest co-pilotem. Dla polskich klientów dostępne polskie partnerstwo z Maximetrix lub QSCert.

Powiązane use case'y

Często zadawane pytania

Jakie regulacje MDR pokrywa Decision-Layer?
MDR EU 2017/745 (rozporządzenie o wyrobach medycznych), szczególnie Art. 87 (raportowanie Vigilance z 15-dniowym terminem dla serious incidents, 30 dni dla trends), MDCG 2019-11 (klasyfikacja MDSW Medical Device Software), IEC 62304 (cykl życia oprogramowania), ISO 13485 (zarządzanie jakością wyrobów medycznych), Post-Market-Surveillance-Plan (PMS) zgodnie z Art. 83-86. Plus FDA 21 CFR Part 820 dla rynku USA, jeśli hamburski producent medtech ma licencję US. Plus polski URPL (Urząd Rejestracji Produktów Leczniczych, Wyrobów Medycznych i Produktów Biobójczych) jako krajowy organ nadzoru - obowiązek równoległej notyfikacji incydentów na polskie wyroby. Audyty Notified Body przez TÜV SÜD, BSI, DEKRA z rocznym Surveillance + 5-letnim Re-Certification.
Jak dotrzymywany jest 15-dniowy termin klasyfikacji Severity?
Service-Tickets z 64 krajów napływające, często po angielsku z mixem języków lokalnych (hiszpański z Ameryki Łacińskiej, portugalski z Brazylii, japoński, polski z polskich szpitali). Wzorzec Decision-Layer: krok REGUŁY sprawdza status terminu (dzień 1 z 15) i pola obowiązkowe (produkt, numer seryjny, opis incydentu). KI AUTONOM klasyfikuje Severity według MDCG 2019-11 (skala B/C/D), wykrywanie języka, dopasowanie symptomów względem Risk-Management-File. CZŁOWIEK obowiązkowy przy Severity B (Serious Incident) - Compliance-Officer sprawdza, raportowanie BfArM jest przygotowywane. Przy Severity D (Reportable Field Safety Corrective Action) automatyczna ścieżka eskalacji.
Jak odwzorowany jest cykl życia oprogramowania IEC 62304 przy aktualizacjach firmware?
Aktualizacja firmware endoskopu oznacza aktualizację dokumentacji cyklu życia IEC 62304, ponowną ocenę ryzyka, notyfikację Notified Body. Aktualne wyprzedzenie: 14 tygodni na aktualizację, klienci czekają. Decision-Layer składuje Software-Safety-Class IEC 62304 (A/B/C) jako constraint, automatyzuje Verification + Validation Records, generuje aktualizacje Risk-Management-File. Notyfikacja Notified Body ustrukturyzowana z audit-trail. Obowiązek człowieka przy Risk-Acceptance-Decision przez Risk-Managera.
Co z pismem HmbBfDI z lutego 2026 o AI w wyrobach medycznych?
Hamburski organ ochrony danych opublikował w lutym 2026 katalog wymagań dotyczących transparentności algorytmów przy diagnostyce obrazowej wspieranej AI. Wymagania: wyjaśnialność decyzji diagnostycznych, audit-trail nad danymi treningowymi, ocena ryzyka certyfikowana przez Notified Body. Architektura Decision-Layer spełnia te wymagania: każda ocena obrazu AI z wersją modelu, hash input, confidence-score, ścieżką eskalacji do radiologa przy niskiej confidence. Plus RODO Art. 22 prawo do zaskarżenia dla dotkniętych pacjentów. Plus polski UODO Wytyczne o profilowaniu wymagają tej samej transparentności w polskim systemie ochrony zdrowia.
Czy Decision-Layer adresuje również przygotowanie do audytu Notified Body z ISO 13485?
Tak. ISO 13485 jest obowiązkowym standardem QMS dla wyrobów medycznych z certyfikatem CE. Decision-Layer jest sklasyfikowany jako oprogramowanie wewnątrz QMS (nie zewnętrzne). Software-Safety-Class IEC 62304 jest ustalana w warsztacie Discovery (typowo Class B dla narzędzi Vigilance-Workflow). MDR Annex IX/X ocena zgodności udokumentowana. Post-Market-Surveillance-Plan (PMS), PSUR i Trending są zintegrowane. Przy audycie Notified Body (TÜV SÜD/BSI/DEKRA) możliwy jest 1-klikowy eksport widoku audit-trail. Dla rynku polskiego: dodatkowy eksport URPL-kompatybilny.

Umów warsztat w Grindelberg

3 dni discovery: Dzień 1 analiza procesów, Dzień 2 mapowanie Decision-Layer, Dzień 3 priorytetyzacja use case'ów.

Umów termin

Discovery workshop poniżej 10.000 EUR. Cena ryczałtowa pilota po warsztacie.

← Wróć do przeglądu: AI Agents Hamburg