CAFM: Medizintechnik

Das hier beschriebene Modul ist produktneutral formuliert und eignet sich als Lastenheft‑Baustein für eine Ausschreibung. Es beschreibt ein „Modul Medizintechnik / Medizinprodukte‑Management“ als Teil einer FM‑Software (on‑premises oder SaaS), mit dem Ziel, Betreiberpflichten effizient, prüfbar und revisionssicher umzusetzen. Die Anforderungen sind bewusst so gehalten, dass sie sowohl in CAFM‑Systemen als auch in integrierten FM‑Plattformen abbildbar sind, solange die Fachlogik (Medizinproduktebetrieb) vollumfänglich unterstützt wird.

• Inventarisierung & Identifikation aller medizintechnischen Geräte/Produkte (inkl. UDI und betrieblicher Identifikationsnummer).

• Planung, Durchführung, Nachweisführung für STK, MTK, elektrische Prüfungen sowie IT‑Sicherheitsüberprüfungen.

• Medizinproduktebuch als elektronisch geführtes Gerätebuch inkl. Inbetriebnahme, Einweisungen, Instandhaltungen, Störungen/Bedienfehler, Vorkommnismeldung und Aufbewahrung.

• Vorkommnis‑ und Maßnahmenmanagement inkl. Unterstützung der internen Koordination durch den Beauftragten für Medizinproduktesicherheit.

Einige zuvor hochgeladene Dateien sind in dieser Sitzung technisch nicht mehr abrufbar. Falls daraus konkrete Textbausteine oder organisationsspezifische Randbedingungen übernommen werden sollen, müssen diese Dateien erneut bereitgestellt werden.

• Medizinprodukt (Gerätestamm): Pflichtattribute orientieren sich an den Angaben, die typischerweise für das Bestandsverzeichnis eingefordert/empfohlen werden: Bezeichnung, Art/Typ/Modell, Loscode oder Seriennummer oder UDI, Anschaffungsjahr, Hersteller (bzw. Bevollmächtigter/Importeur), betriebliche Identifikationsnummer (falls vorhanden), Standort und betriebliche Zuordnung.

• Medizinproduktebuch (Geräteakte): Die Geräteakte muss die in Behördenvorlagen übliche Gliederung digital abbilden: Identifikation, Inbetriebnahme (inkl. Funktionsprüfung), Einweisungen, STK, MTK, Instandhaltungen, IT‑Sicherheitsüberprüfungen, Funktionsstörungen und wiederholte Bedienungsfehler, Meldung von Vorkommnissen sowie sonstige Informationen (z. B. Wartungsverträge, Hersteller- und Sicherheitsinformationen).

• Prüfung/Kontrolle (Ereignisobjekt): Für jede Kontrolle sind mindestens Datum, Messwerte/Ergebnisse, angewandte Messverfahren und Beurteilungsergebnisse sowie Prüfer-/Organisation und Qualifikationsnachweis zu erfassen; für STK und MTK wird ein Prüfprotokoll als notwendig dargestellt.

• Störung/Instandhaltung (Ticket/Arbeitsauftrag): Instandhaltungen sollen sich an Herstellerangaben orientieren und mit Datum, Art der Maßnahme, Ergebnis/Bemerkung sowie durchführender Person/Organisation dokumentiert werden.

• Vorkommnis & Maßnahmen (Safety Case im Betrieb): Das Objekt muss die interne Erfassung/Prüfung eines Ereignisses und die anschließende Koordination (z. B. Rückrufmaßnahmen, Sicherheitskorrekturmaßnahmen) unterstützen. Gleichzeitig muss das System die Anforderung berücksichtigen, dass Meldungen an die zuständige Stelle ohne patientenbezogene Daten erfolgen sollen.

• UDI‑Struktur: Für UDI‑fähige Produkte sind Felder für UDI‑DI und UDI‑PI vorzusehen; optional zusätzlich Basis‑UDI‑DI, je nach Datenverfügbarkeit. UDI‑Träger können u. a. als Strichcode (1D/2D) oder RFID vorliegen; das Modul sollte daher scannbare Erfassung (AIDC) unterstützen.

Die folgenden Anforderungen sind als Lastenheft‑Modulbeschreibung strukturiert. „Muss“‑Anforderungen sind vergaberelevant; „Soll“‑Anforderungen erhöhen den Nutzwert und sollten bepreist werden.

• Das System muss ein Bestandsverzeichnis für alle aktiven nichtimplantierbaren Produkte führen können und die dafür typischen Datenfelder mindestens bereitstellen (inkl. Seriennummer/UDI, Anschaffungsjahr, Hersteller, Standort).

• Das System muss Bestandsverzeichnisse je Betriebsstätte/Organisationseinheit filtern und als prüffähige Ausgabe (PDF/Export) bereitstellen können.

• Das System muss Standort- und Zuordnungsänderungen versioniert nachvollziehbar dokumentieren (Audit Trail), da Standort/Zuweisung explizite Bestandsverzeichnisangaben sind.

• Erfassung per Barcode/Datamatrix/RFID soll unterstützt werden, um UDI‑basierte Identifikation effizient zu ermöglichen.

• Eine optionale Verwaltung von Ausmusterung (Jahr/Grund) soll abbildbar sein, da Vorlagen dies praxisnah vorsehen.

• Für jedes Medizinprodukt, für das ein Medizinproduktebuch erforderlich ist, muss das System eine strukturierte elektronische Geräteakte bereitstellen, die mindestens die in Behördenvorlagen beschriebenen Kapitel abdeckt (Inbetriebnahme, STK/MTK, Instandhaltungen, IT‑Sicherheitsüberprüfungen, Störungen/Bedienfehler, Vorkommnisse, sonstige Informationen).

• Das System muss Nachweise als Dokumente anhängen können (Prüfprotokolle, Messwerte, Herstellerinformationen, Sicherheitsinformationen), inklusive Versions-/Änderungshistorie.

• Das System muss eine regelbasierte Aufbewahrung ermöglichen; als Mindestanforderung ist die Aufbewahrung des Medizinproduktebuchs nach Außerbetriebnahme für fünf Jahre als Muss zu unterstützen.

• Das System soll Vorlagen (Formularmasken) bereitstellen, die den gängigen Behördenmustern entsprechen (z. B. identische Datenstruktur/Spaltenlogik), um Inspektionen zu erleichtern.

• Das System muss wiederkehrende Kontrollen regelbasiert planen, terminieren und überwachen können, getrennt nach STK, MTK, elektrischen Prüfungen und IT‑Sicherheitsüberprüfungen.

• Für STK muss das System ein spätestes Intervall von 24 Monaten sowie die Pflicht zur Protokollierung und (für STK) zur Prüfplaketteninformation abbilden können.

• Für MTK muss das System gerätespezifische Intervalle verwalten können; als fachliche Referenz ist der Leitfaden zur MTK von Medizinprodukten mit Messfunktion zu berücksichtigen, der von der Physikalisch‑Technischen Bundesanstalt herausgegeben wurde.

• Für elektrische Prüfungen muss das System die Prüfgrundlage DIN EN 62353 unterstützen (Vor‑Inbetriebnahme, wiederkehrend, nach Instandsetzung), inklusive Messwertdokumentation.

• Für IT‑Sicherheitsüberprüfungen (wo einschlägig) muss das System mindestens Intervall, Ergebnisdokumentation und Protokollnachweis unterstützen.

• Das System soll ein Prüfplakettenmanagement unterstützen (Layout/Barcode/QR, nächster Termin, prüfende Stelle) bzw. die dafür erforderlichen Daten bereitstellen.

• Das System soll Toleranz- und Eskalationsregeln abbilden (Warnstufen, Überfälligkeit, Eskalation an Verantwortungsträger).

• Das System muss Instandhaltungen (Wartung, Inspektion, Reparatur) als nachvollziehbare Ereignisse erfassen, inklusive Datum, Durchführungsstelle/Person, Art der Maßnahme und Ergebnis/Bemerkung.

• Das System muss Einweisungen dokumentieren können (Datum, Einweisender, Eingewiesener, Unterschriften-/Bestätigungslogik), da Einweisungen in Behördenvorlagen explizit geführt werden.

• Das System muss Funktionsstörungen und wiederholte Bedienungsfehler im Gerätebuch erfassen können, um Muster zu erkennen und Folgemaßnahmen zu steuern.

• Das System muss eine strukturierte Erfassung von Vorkommnissen ermöglichen (Ereignisbeschreibung, Produktidentifikation, Zeitpunkt, Auswirkungen, Maßnahmenstatus).

• Das System muss Workflows unterstützen, in denen der Beauftragte für Medizinproduktesicherheit interne Prozesse zur Erfüllung von Melde- und Mitwirkungspflichten und zur Koordination von Korrekturmaßnahmen steuern kann (z. B. Aufgaben, Fristen, Nachverfolgung).

• Das System muss sicherstellen, dass Export-/Meldeunterlagen standardmäßig ohne patientenbezogene Daten erzeugt werden (Privacy by Default); bei Dokumentenanhängen muss eine Kennzeichnung/Prüfung möglich sein.

• Das System soll die Meldung an das Online‑Portal der zuständigen Stelle organisatorisch unterstützen (z. B. durch Checkliste, Pflichtfelder, Erzeugung eines Meldedokuments, Ablage der Eingangsbestätigung/Referenznummer).

Sofern die Organisation medizintechnische Aufbereitung/Endoskopie‑Equipment im gleichen System steuern will, soll das Modulsystem Aufbereitungsnachweise und validierte Verfahren dokumentieren können; dabei ist die KRINKO‑/BfArM‑Empfehlung als anerkannte Leitlinie zu referenzieren.

• UDI‑Erfassung: Unterstützung von Scanner‑Workflows (AIDC) zur Übernahme von UDI‑DI/UDI‑PI in den Gerätestamm; idealerweise inkl. Plausibilitätsprüfung und Trennung der Komponenten.

• MTK‑Referenzdaten: Möglichkeit, MTK‑Kategorien/Prüfumfänge und ggf. Leitfadenreferenzen für Medizinprodukte mit Messfunktion zu hinterlegen (mindestens als dokumentierte Regelbasis).

• Meldemanagement: Ablage und Nachverfolgung von Vorkommnismeldungen inkl. Dokumentation der Kommunikation; die Systemlogik muss mit dem Online‑Meldeweg kompatibel sein (z. B. Generierung eines ausfüllbaren Meldeformular‑Exports, strukturierter Datenauszug).

Für die Inbetriebnahme des Moduls ist eine Datenmigration aus Excel/Altverfahren typischerweise erforderlich. Mindestanforderung ist ein Import für Bestandsverzeichnisfelder (Bezeichnung/Typ/Seriennummer/UDI, Hersteller, Anschaffungsjahr, Standort, betriebliche ID) und die Möglichkeit, historische Prüf- und Instandhaltungsereignisse nachzuladen, damit die Einhaltung von Prüfintervallen (z. B. STK max. 24 Monate) von Beginn an korrekt überwacht werden kann.

Da Inspektionen, Prüfungen und Reparaturen oft dezentral stattfinden, sollte das Modul webbasiert bedienbar sein und mobile Nutzung (Tablet/Smartphone) unterstützen; dabei müssen Audit Trail, Berechtigungen und Offline‑Risiken (z. B. spätere Synchronisation) so umgesetzt sein, dass Nachweise (Prüfprotokolle, Gerätebuch) konsistent bleiben. Dieses Erfordernis leitet sich aus der hohen Dokumentationsdichte der Prüf- und Gerätebuchvorgaben ab.

Abnahmeziel ist, dass die Software aus Sicht von Betreiberpflichten „inspektionsfest“ ist: Bestandsverzeichnis und Medizinproduktebuch müssen vollständig, aktuell, filterbar und exportierbar sein, und die wiederkehrenden Kontrollen müssen mit Fristensteuerung und Protokollpflicht umgesetzt werden können.

• Berechtigungen: Rollenbasierte Zugänge (z. B. Medizintechnik, Pflege/Anwender, externe Prüfstelle, Beauftragter für Medizinproduktesicherheit).

• Audit Trail: Jede Änderung an kritischen Feldern (UDI/Seriennummer, Standort, Prüfergebnisse, Dokumente) muss nachvollziehbar sein.

• Datenschutz in Vorkommnissen: Standardmäßig dürfen Meldungen/Exports keine Patientendaten enthalten; das muss durch Vorlagen/Prüfmechanismen unterstützt werden.

• IT‑Sicherheitsüberprüfungen: Wo erforderlich, muss das System die turnusmäßige Dokumentation von IT‑Sicherheitsüberprüfungen abbilden.

• Ein Medizinprodukt wird neu angelegt (inkl. Seriennummer/UDI, Hersteller, Anschaffungsjahr, Standort) und erscheint korrekt im Bestandsverzeichnisexport.

• Für ein Anlage‑1‑Gerät wird eine STK geplant, durchgeführt und protokolliert; das System erzeugt einen Nachweis inkl. nächstem Termin (≤24 Monate), Prüferangabe und Prüfprotokoll.

• Für ein Anlage‑2‑Gerät wird eine MTK mit gerätespezifischem Intervall geplant und dokumentiert; die Prüfbasis ist als Leitfadenreferenz hinterlegt.

• Eine elektrische Prüfung nach DIN EN 62353 wird als Ereignis dokumentiert, Messwerte werden gespeichert, und der Nachweis ist im Gerätebuch abrufbar.

• Ein Vorkommnis wird erfasst, intern bearbeitet (Workflow), und ein Meldeexport wird erzeugt, der keine Patientendaten enthält; Eingangsbestätigung/Referenz kann am Vorgang abgelegt werden.

• Ein Gerät wird außer Betrieb genommen; das System setzt den Status, verhindert unbeabsichtigte Löschung und gewährleistet die Aufbewahrung des Medizinproduktebuchs für fünf Jahre.

Erfüllt die Lösung diese Kriterien, ist das Modul geeignet, die medizintechnischen Betreiberpflichten praktikabel in FM‑Prozesse zu integrieren: mit sauberer Inventarisierung, fristgerechter Prüfsteuerung, belastbarer Dokumentation (Bestandsverzeichnis/Medizinproduktebuch) und sicherem Vorkommnis‑/Maßnahmenmanagement.