Installed Base
Im Maschinenbau ist die installierte Basis eine Vertriebschance. Bei einem Medizinproduktehersteller ist sie eine regulatorische Datenstruktur. Wenn eine Sicherheitskorrekturmaßnahme im Feld ansteht, entscheidet die Qualität dieser Daten darüber, ob Sie die betroffenen Geräte in Stunden benennen können oder in Wochen. Dieser Beitrag beschreibt, welche Angaben die installierte Basis enthalten sollte, wo die Systemgrenze zwischen ERP und Service verläuft und welche Pflichten dabei den Hersteller und welche den Betreiber treffen.
Vertrieb und technischer Service bei AENUMA · ERP für Medizinproduktehersteller
Eine installierte Basis, die diesen Namen verdient, beantwortet für jedes ausgelieferte Gerät sechs Fragen: Welches Produkt mit welcher Seriennummer. In welchem Konfigurations- und Softwarestand. An welchem physischen Standort, bis auf Gebäude und Raum. Bei welchem Betreiber, nicht beim ursprünglichen Rechnungsempfänger. Seit wann. Und mit welcher Historie aus Einsätzen, Tauschteilen, Prüfungen und Beanstandungen.
Fehlt eine dieser Angaben, ist die Liste nicht falsch, nur nicht belastbar. Ohne Standort beantwortet sie die Rückruffrage nicht, ohne Softwarestand nicht die Frage nach einem sicherheitsrelevanten Softwarefehler. Ohne aktuellen Betreiber schickt sie Ihre Sicherheitsanweisung an eine Adresse, an der das Gerät seit zwei Jahren nicht mehr steht.
Die MDR verpflichtet den Hersteller in Artikel 10 zu einem Qualitätsmanagementsystem und einem System zur Überwachung nach dem Inverkehrbringen. Artikel 83 bis 86 beschreiben dieses Post-Market-Surveillance-System, den zugehörigen Plan und die Berichtspflichten; Anhang III legt den Inhalt des Plans fest. Der Teil, der die installierte Basis unmittelbar trifft, steht in Artikel 87. Ein schwerwiegendes Vorkommnis ist unverzüglich, spätestens 15 Tage nach Kenntnis zu melden. Bei Tod oder einer unerwarteten schwerwiegenden Verschlechterung des Gesundheitszustands verkürzt sich die Frist auf 10 Tage, bei einer schwerwiegenden Gefahr für die öffentliche Gesundheit auf 2 Tage. Für die Sicherheitskorrekturmaßnahme im Feld, definiert in Artikel 2 Nummer 68, gilt die Meldepflicht ebenfalls; kommuniziert wird sie über die Sicherheitsanweisung im Feld, definiert in Artikel 2 Nummer 69, mit Pflicht und Inhalt nach Artikel 89 Absatz 8.
Innerhalb dieser Fristen ist keine Zeit für Datenrecherche. Wer im Extremfall in zwei Tagen melden und anschließend eine Feldmaßnahme durchführen muss, braucht die Antwort auf „welche Geräte, wo, bei wem“ als Abfrage, nicht als Projekt. Genau das unterscheidet den Medizintechnik-Service vom Maschinenbau: Dort ist eine gepflegte Anlagenliste ein Wettbewerbsvorteil, hier ist sie die Voraussetzung dafür, eine gesetzliche Pflicht überhaupt erfüllen zu können.
Eine Präzisierung, die häufig untergeht: Artikel 25 verlangt die Identifizierbarkeit innerhalb der Lieferkette. Wirtschaftsakteure müssen jeden Wirtschaftsakteur benennen können, der ihnen ein Produkt geliefert hat oder an den sie eines abgegeben haben, und ebenso jede Gesundheitseinrichtung und jeden Angehörigen der Gesundheitsberufe, an die sie unmittelbar abgegeben haben. Für den unmittelbar belieferten Betreiber folgt die Kenntnis also sehr wohl aus Artikel 25. Nicht erfasst ist die Kette danach: spätere Weitergaben und Standortverlagerungen. Deren Kenntnis ergibt sich aus der praktischen Unmöglichkeit, eine Sicherheitskorrekturmaßnahme durchzuführen, ohne zu wissen, wo die Geräte stehen. Ergänzt wird das durch das UDI-System nach Artikel 27 und die Produktregistrierung nach Artikel 29. Wie sich diese Kennzeichnung technisch abbilden lässt, behandeln wir unter UDI-Daten im ERP abbilden.
Ein Gerät wird an eine Klinikkette verkauft, drei Jahre später an ein Medizinisches Versorgungszentrum abgegeben, dann von dessen Zentrale in eine Zweigpraxis verlagert. Kennt Ihr System nur den ursprünglichen Käufer, hat die installierte Basis nach fünf Jahren eine Trefferquote, die niemand kennt und niemand verantworten will.
Betreiber- und Standortwechsel müssen deshalb als eigene, datierte Ereignisse am Gerätesatz geführt werden, nicht als Überschreiben eines Feldes. Der Techniker im Einsatz ist die verlässlichste Quelle: Er steht vor dem Gerät. Wenn die mobile Anwendung ihn bei jedem Einsatz die Standortangabe bestätigen oder korrigieren lässt, pflegt sich die installierte Basis über den normalen Betrieb statt über eine Datenpflegeaktion.
Sobald Software Teil des Produkts ist, verschiebt sich die Frage. Nicht mehr „welche Geräte sind betroffen?“, sondern „welche Geräte laufen in welchem Stand?“ Ein Softwarefehler betrifft selten die gesamte Baureihe, sondern die Geräte zwischen zwei Versionsständen. Ohne Historie der Aktualisierungen am einzelnen Gerät bleibt nur die Maximalannahme, und die kostet: mehr betroffene Geräte, mehr Einsätze, ein größerer Adressatenkreis.
Führen Sie den Softwarestand deshalb als Attribut der installierten Einheit, nicht als Feld am Artikelstamm, und schreiben Sie jede Aktualisierung als datierten Eintrag in die Servicehistorie. Anhang I Kapitel III Nummer 23.4 der MDR verlangt Angaben zu Instandhaltung und Kalibrierung in der Gebrauchsanweisung. Die gerätebezogene Dokumentation der durchgeführten Maßnahmen ist in Deutschland Sache des Betreibers im Medizinproduktebuch. Für den Hersteller ist die Versionshistorie am Gerät deshalb kein Rechtsgebot, sondern die Voraussetzung dafür, eine Feldmaßnahme sauber eingrenzen zu können.
Hier wird häufig falsch zugeordnet. Die sicherheitstechnischen Kontrollen und die messtechnischen Kontrollen nach der deutschen Medizinprodukte-Betreiberverordnung, neu gefasst durch die Verordnung vom 14. Februar 2025, BGBl. 2025 I Nr. 38, sind Pflichten des Betreibers, nicht des Herstellers. Der Betreiber muss sie veranlassen, fristgerecht durchführen lassen und dokumentieren.
Der Hersteller ist davon zweifach betroffen. Erstens wirkt er über seine Angaben mit: Art und Umfang der sicherheitstechnischen Kontrolle folgen den allgemein anerkannten Regeln der Technik, die Fristen stehen in der Verordnung selbst, und die Instandhaltungsangaben des Herstellers sind dabei zu berücksichtigen. Zweitens erbringt er die Leistung in der Praxis häufig selbst oder über autorisierte Partner. Daraus folgt ein Geschäftsmodell mit planbaren Terminen und Nachweispflicht statt Kulanzservice auf Zuruf. Ein Servicevertrag in dieser Logik enthält Intervall, Leistungsumfang je Gerätetyp, Reaktionszeit, Preisstellung und den Prüfnachweis, den der Betreiber für seine eigene Dokumentation benötigt.
In Dynamics 365 Field Service bilden Vereinbarungen das ab: Eine Vereinbarung erzeugt aus einer Terminserie automatisch Arbeitsaufträge, die auf die konkrete installierte Einheit verweisen und deren Ergebnisse in ihre Servicehistorie zurücklaufen. Der Nachweis entsteht als Nebenprodukt der Ausführung. Welche Bausteine wir dafür einsetzen, beschreibt unsere Technologiebasis für regulierte Umgebungen.
Nach unserer Projekterfahrung ist die häufigste Ursache für eine unbrauchbare installierte Basis keine fehlende Funktion, sondern unklare Zuständigkeit. Diese Aufteilung verwenden wir als Referenz.
| Datenobjekt | Führendes System | Warum dort |
|---|---|---|
| Artikel, Stückliste, Fertigungsauftrag, Charge | ERP | Herkunft und Fertigungsnachweis entstehen dort |
| Seriennummer | ERP, Vergabe in der Fertigung | Erst die Vergabe am Entstehungsort verbindet Gerät und Chargen der verbauten Komponenten |
| Lieferung, Empfänger, Auslieferungsdatum, UDI | ERP | Auslieferungsnachweis ist kaufmännischer und regulatorischer Beleg zugleich |
| Installierte Einheit mit Betreiber und Standort | CRM und Field Service | Das Objekt bewegt sich nach der Auslieferung weiter |
| Vereinbarung, Terminserie, abgeleitete Fälligkeiten | Field Service | Erzeugt wiederkehrende Aufträge und deren Nachweise |
| Servicehistorie, Einsätze, Inspektionsergebnisse | Field Service | Entsteht am Gerät, nicht am Auftrag |
| Ersatzteilverbrauch mit Seriennummer | Field Service in Verbindung mit Supply Chain Management | Verbrauch am Gerät, Bewertung und Bestand im ERP. Serien- und Chargennummern am Arbeitsauftragsprodukt entstehen erst über die Integration mit Finance. |
| Reklamation und Bewertung auf Meldepflicht | QM-System | Die Bewertung ist ein Qualitätsprozess mit Frist, kein Serviceschritt |
Der gemeinsame Schlüssel über alle Systeme hinweg ist die Seriennummer. Sie identifiziert das einzelne Exemplar über den gesamten Lebensweg und bleibt dabei stabil, während Kundennummern sich ändern, Standorte sich ändern und Artikelnummern abgelöst werden. Regulatorisch ist sie Bestandteil des UDI-PI und ergänzt damit die UDI-DI, sie tritt nicht an deren Stelle. Wird sie im ERP vergeben und steht dasselbe Zeichen in der installierten Einheit, lässt sich jede Feldfrage in einer Abfrage beantworten. Wie das mit der Chargenebene zusammenspielt, zeigen wir unter Chargen durchgängig im ERP führen.
Wenn ein Betreiber anruft, weil ein Gerät nicht das tut, was es soll, entsteht in aller Regel ein Serviceticket. Das ist richtig und reicht nicht. ISO 13485:2016 verlangt ein dokumentiertes Verfahren zur Beschwerdebearbeitung, und dieses Verfahren entscheidet, ob eine Meldepflicht nach MDR Artikel 87 ausgelöst wird. Bleibt die Reklamation im CRM stehen, weil das Gerät nach dem Technikereinsatz wieder läuft, findet die Bewertung nicht statt. Der Fall gilt intern als gelöst und ist regulatorisch offen.
Der Übergabepunkt muss deshalb technisch erzwungen werden, nicht organisatorisch erhofft. Ein Serviceticket, das als potenzielle Beschwerde gekennzeichnet ist, erzeugt automatisch einen Vorgang im Qualitätsprozess: eigene Frist, eigene Verantwortung, eigener Abschluss. Erst wenn beide Vorgänge geschlossen sind, ist der Fall erledigt.
Reicht ein CRM, um die installierte Basis zu führen?
Nein. Das CRM führt Betreiber, Standort und Servicehistorie. Herkunft, Fertigungsdaten, Charge und Auslieferungsnachweis entstehen im ERP. Ohne die Seriennummer als Verbindung haben Sie zwei unvollständige Wahrheiten.
Muss der Hersteller die sicherheitstechnischen Kontrollen durchführen?
Die Pflicht trifft den Betreiber. Der Hersteller macht die Instandhaltungsangaben, die der Betreiber zu berücksichtigen hat, und erbringt die Leistung häufig vertraglich. Art und Umfang folgen den allgemein anerkannten Regeln der Technik, die Fristen der Verordnung. Das ist eine Marktchance, keine gesetzliche Herstellerpflicht.
Wie schnell muss ein Hersteller bei einem schwerwiegenden Vorkommnis reagieren?
Nach MDR Artikel 87 unverzüglich, spätestens 15 Tage nach Kenntnis. Bei Tod oder unerwarteter schwerwiegender Verschlechterung 10 Tage, bei schwerwiegender Gefahr für die öffentliche Gesundheit 2 Tage.
Was passiert, wenn wir nur den ursprünglichen Käufer kennen?
Ihre Sicherheitsanweisung erreicht die falsche Adresse, und Sie können der Behörde nicht belegen, welche Geräte betroffen sind. Führen Sie Betreiber- und Standortwechsel als datierte Ereignisse und lassen Sie die Angabe bei jedem Einsatz bestätigen. Passend dazu: EUDAMED- und UDI-Datenhaushalt aufbauen.
Beginnen Sie nicht mit der Systemauswahl, sondern mit einer Stichprobe: Nehmen Sie zehn Geräte aus den letzten fünf Jahren und belegen Sie für jedes Gerät Betreiber, Standort, Softwarestand und den letzten Prüftermin aus dem System. Das Ergebnis dieser halben Stunde sagt nach unserer Erfahrung mehr über Ihre Reaktionsfähigkeit im Feldmaßnahmefall aus als jedes Lastenheft.
Nächster Schritt: Digitalisierungs-Standortbestimmung oder Service-Zielbild für Medizintechnik.
Weiterlesen: Wartung, Kalibrierung und Nachweis am Gerät
Alle Fachbeiträge im Überblick
Verordnung (EU) 2017/745 über Medizinprodukte (MDR), EUR-Lex
MDCG 2025-10, Guidance on post-market surveillance of medical devices and IVDs
ISO 13485:2016, Medical devices, Quality management systems, Requirements for regulatory purposes
Medizinprodukte-Betreiberverordnung vom 14. Februar 2025 (BGBl. 2025 I Nr. 38), zuletzt geändert durch Artikel 1 der Verordnung vom 31. Oktober 2025 (BGBl. 2025 I Nr. 263)
Medizinprodukte-Betreiberverordnung (MPBetreibV), Gesamtfassung
Microsoft Learn: Work with customer assets (Dynamics 365 Field Service)
Microsoft Learn: Build a service history for assets
Microsoft Learn: Set up agreements to automatically generate work orders
Microsoft Learn: Integrate Dynamics 365 Field Service and Supply Chain Management
Dieser Beitrag gibt den Rechts- und Produktstand vom 21. August 2026 wieder. Er ersetzt keine Rechtsberatung und keine Prüfung des Einzelfalls. Maßgeblich ist der Wortlaut der jeweils geltenden Fassung der zitierten Rechtsakte und Normen.
AENUMA Redaktion · Stand: 21. August 2026 · Wie diese Beiträge entstehen
