Ein Unified Namespace (UNS) in der Medizintechnik verbindet Produktions-, Qualitäts- und Umgebungsdaten zu einer durchgängigen Echtzeit-Datenbasis. UDI-Traceability, Sterilisationsnachweise und Reinraum-Monitoring werden bereits heute über QMS, Sterilisationsanlagen und Umgebungsmonitoring-Systeme erfasst. Der Unified Namespace ersetzt diese Systeme nicht, sondern führt ihre Daten in Echtzeit zusammen und macht sie geräte- und chargengenau über den gesamten Fertigungsprozess verfügbar. So lassen sich regulatorische Anforderungen wie die MDR oder 21 CFR Part 11 effizient erfüllen, ohne Daten nachträglich aus SPS-, MES- und QMS-Systemen zusammenführen zu müssen.
Dieser Artikel zeigt, was einen Unified Namespace in der Medizintechnik von einer generischen Manufacturing-Architektur unterscheidet. Der Artikel liefert branchenspezifische Use Cases für KI und digitalen Zwilling sowie konkrete Best Practices. Die technischen Grundlagen des UNS erklärt der Artikel Was ist der Unified Namespace (UNS)?
Unified Namespace Anforderungen in der Medizintechnik
Digitalisierungsprojekte in der Medizintechnik-Fertigung stehen unter regulatorischem Druck, der über generische Manufacturing-Anforderungen hinausgeht. Die folgenden Treiber bestimmen, wie Daten modelliert, gespeichert und ausgewertet werden müssen.
Regulatorische Treiber: ISO 13485, FDA 21 CFR 820, EU MDR und 21 CFR Part 11
ISO 13485 verlangt ein dokumentiertes Qualitätsmanagementsystem, das jeden Fertigungsschritt nachvollziehbar macht. Die FDA-Vorschrift 21 CFR 820 wurde 2024 zur Quality Management System Regulation (QMSR) harmonisiert. Zusammen mit der EU-Medizinprodukteverordnung (MDR) 2017/745 verlangt sie eine eindeutige Geräteidentifikation über die UDI. Eine UDI besteht aus zwei Teilen: dem Device Identifier (DI), der ein Katalogmodell fix identifiziert, und dem Production Identifier (PI), der Seriennummer, Herstelldatum und Verfallsdatum eines konkreten Geräts trägt. Damit identifiziert die UDI ein einzelnes Gerät, nicht eine Gruppe von Einheiten. IEC 62304 und ISO 14971 ergänzen dies um Anforderungen an Software-Lebenszyklus und Risikomanagement. 21 CFR Part 11 schließlich verlangt, dass elektronische Aufzeichnungen und Signaturen nach dem ALCOA+-Prinzip manipulationssicher, zeitnah und vollständig nachvollziehbar sind.
Warum sich die Medizintechnik-Fertigung von anderen Branchen unterscheidet
Die Lebensmittelindustrie verfolgt Produkte auf Chargenebene, die Automobilindustrie auf Bauteilebene. Die Medizintechnik kombiniert beides auf strengere Weise: Jedes einzelne Gerät trägt über die UDI eine eigene, weltweit eindeutige Identität – vergleichbar mit der Pharma-Serialisierung nach DSCSA oder EU-FMD. Hinzu kommen zwei Ereignisse, die für diese Branche gelten: die Sterilisation und das Reinraum-Umgebungsmonitoring. Ein Sterilisationszyklus – etwa mittels Ethylenoxid (EtO) oder Gammabestrahlung – behandelt üblicherweise eine ganze Sterilisationscharge (Load) mehrerer Geräte gleichzeitig und muss über einen biologischen Indikator nachgewiesen werden. Reinraumbedingungen wie Partikelzahl oder Keimbelastung werden dagegen kontinuierlich überwacht, unabhängig davon, welches Gerät sich gerade im Raum befindet. Diese Eigenschaften prägen, wie ein Unified Namespace in der Medizintechnik modelliert werden muss: UDI, Sterilisationszyklus und Reinraumdaten sind eigenständige Datenobjekte mit jeweils eigener Granularität.
Medizintechnik-spezifische Topic-Struktur
In einem Unified Namespace in der Medizintechnik bleibt die physische Hierarchie stabil: Werk, Linie, Anlage, Messgröße. Sie ändert sich nicht mit dem aktuell gefertigten Gerät. Das folgt denselben ISA-95-Grundsätzen wie in MQTT Topic Namespace Best Practices. Branchenspezifisch ist auch hier nicht die Topic-Hierarchie selbst, sondern die Frage, wo UDI-, Sterilisations- und Reinraumdaten im UNS abgelegt werden.
Typische Topic-Hierarchie, unabhängig vom Gerät:
tuttlingen/linie03/reinraum/partikelzahl/istwerttuttlingen/linie03/reinraum/partikelzahl/status
Geräte- und Prozessereignisse erhalten dagegen eigene, einmalige Topics:
tuttlingen/linie03/geraet/SN20260718-0045/dhrtuttlingen/linie03/sterilisation/eto-2026-07-18t06-30/zyklusnachweis
Die folgende Datenmodellierung weist drei medizintechnikspezifische Eigenschaften auf:
- Die Reinraum-Partikelmessung bleibt unabhängig vom Gerät: Ein Partikelzähler publiziert kontinuierlich auf einem festen Topic, ohne UDI im Pfad. Anders als eine Charge betrifft die Raumluft kein einzelnes Gerät, sondern den gesamten Reinraum zu einem Zeitpunkt.
- Ein Sterilisationszyklus behandelt meist mehrere Geräte gleichzeitig als Load. Er erhält ein eigenständiges, zeitgestempeltes Topic mit den beteiligten Seriennummern im Payload.
- Der Device History Record ist dagegen inhärent pro Gerät: Er wird über die Seriennummer im Topic geführt, weil jedes Gerät seine eigene, unveränderliche Historie trägt.
Die folgenden Use Cases zeigen diese Struktur an einem durchgängigen Beispielgerät: einem implantierbaren Herzschrittmacher, Seriennummer SN20260718-0045, Werk Tuttlingen, Linie 3.
UNS Use Cases in der Medizintechnik
Die folgenden Use Cases zeigen, wie sich dieses Datenmodell in der Praxis auszahlt – von der klassischen UDI-Traceability bis zu KI-gestützten Erkenntnissen und digitalen Zwillingen.
Device History Record (DHR) und UDI-Traceability
Statt DHR-Daten nachträglich aus MES-, Labor- und QMS-Exporten zusammenzuführen, liefert der Unified Namespace die vollständige Historie eines Geräts in Echtzeit. Komponentenchargen, Prozessschritte, Sterilisationsnachweis und Freigabestatus sind über die UDI direkt verknüpft. Ein Audit, der bei ISO 13485 den kompletten Fertigungsnachweis eines einzelnen Geräts verlangt, wird damit zur Abfrage statt zum manuellen Rechercheprojekt.
Topic: tuttlingen/linie03/geraet/SN20260718-0045/dhr
JSON Payload:
{
"udiDi": "04056789012348",
"udiPi": {
"serialNumber": "SN20260718-0045",
"manufacturingDate": "2026-07-18",
"expirationDate": "2029-07-18"
},
"product": "Implantable Pacemaker Model X200",
"componentLots": [
{
"component": "Battery Cell",
"supplierLot": "BAT-LOT-88231"
},
{
"component": "Header Assembly",
"supplierLot": "HDR-LOT-44210"
}
],
"processSteps": [
"assembly",
"functional_test",
"sterilization",
"packaging"
],
"productionSite": "plant-tuttlingen",
"productionLine": "line03",
"startTime": "2026-07-18T02:10:00Z",
"endTime": "2026-07-18T04:45:00Z",
"status": "released",
"iso13485Record": "dhr_entry"
}
Sterilisationszyklus-Monitoring und Sterility-Assurance-Nachweis
Die Kammersteuerung bewertet Gaskonzentration, Temperatur, Feuchte und Dauer bereits lokal gegen das validierte Zyklusrezept. Der biologische Indikator wird jedoch extern bebrütet und liefert sein Ergebnis oft erst ein bis drei Tage später als separater Laborbefund. Eine Regel im UNS verknüpft dieses verspätete BI-Ergebnis automatisch mit dem bereits abgeschlossenen Kammerzyklus und markiert die Load erst dann als final bestanden oder fehlgeschlagen – statt beides manuell zwischen Kammerprotokoll und Laborbefund abzugleichen. Der Sterility-Assurance-Nachweis für den nächsten Audit entsteht damit ohne nachträgliche Zusammenführung getrennter Quellen.
Topic: tuttlingen/linie03/sterilisation/eto-2026-07-18t06-30/zyklusnachweis
JSON Payload:
{
"sterilizationCycleId": "ETO-20260718-0630",
"method": "ethylene_oxide",
"devicesInLoad": [
"SN20260718-0045",
"SN20260718-0046",
"SN20260718-0047"
],
"phases": [
{
"phase": "preconditioning",
"durationMin": 60,
"humidityPercent": 55,
"temperatureC": 45
},
{
"phase": "gas_exposure",
"durationMin": 240,
"eoConcentrationMgL": 600,
"temperatureC": 45
},
{
"phase": "aeration",
"durationHours": 12,
"temperatureC": 40
}
],
"biologicalIndicatorResult": "negative",
"sterilityAssuranceLevel": "1e-6",
"cycleResult": "passed",
"approvedBy": "system-auto",
"timestamp": "2026-07-18T18:30:00Z"
}
Reinraum- und Umgebungsmonitoring
Partikelzähler und Keimsammler im Reinraum publizieren kontinuierlich unter einer festen Sensor-Adresse in den UNS. Überschreitet ein Wert die Klassifizierungsgrenze der ISO 14644, lässt sich sofort erkennen, welche Fertigungsschritte im betroffenen Zeitraum stattfanden – und welche Geräte davon betroffen sein könnten.
Topic: tuttlingen/linie03/reinraum/partikelzahl/istwert
JSON Payload:
{
"sensorId": "PARTICLE-ISO7-ROOM3",
"cleanroomClass": "ISO_7",
"particleCount_0_5um": 8200,
"particleCount_5um": 25,
"limit_0_5um": 352000,
"limit_5um": 2930,
"status": "within_limits",
"timestamp": "2026-07-18T10:00:00Z"
}
KI-Anwendungsfälle in der Medizintechnik-Fertigung
KI-Anwendungsfälle für den Unified Namespace in der Medizintechnik entfalten ihren Wert erst durch die Verknüpfung von Prozess-, Labor- und Umgebungsdaten – nicht durch generische Anomalieerkennung.
Bioburden-Risikobewertung vor der Sterilisation
Ein Modell verknüpft Bioburden-Trenddaten aus dem Labor mit Komponentendaten aus dem UNS und markiert Loads mit erhöhtem Bioburden-Risiko schon vor der Sterilisation. Das hilft QA, gezielt zusätzliche Stichproben zu ziehen. Freigegeben wird eine Load weiterhin ausschließlich über den validierten Zyklus und den biologischen Indikator – das Modell ersetzt keinen dieser Nachweise.
Topic: tuttlingen/linie03/ki/bioburden-risiko/ETO-20260718-0630
JSON Payload:
{
"sterilizationCycleId": "ETO-20260718-0630",
"model": "bioburden-risk-v1.4",
"devicesInLoad": [
"SN20260718-0045",
"SN20260718-0046",
"SN20260718-0047"
],
"bioburdenRiskScore": 0.18,
"riskLevel": "low",
"contributingFactors": [
{
"source": "component_lot_history",
"factor": "battery_lot_bioburden_trend_cfu",
"value": 45
},
{
"source": "environment",
"factor": "cleanroom_particle_trend_deviation_percent",
"value": 1.8
}
],
"recommendation": "standard_bi_sampling_sufficient",
"replacesBiologicalIndicator": false,
"timestamp": "2026-07-18T05:00:00Z"
}
Anomalieerkennung im Sterilisationszyklus
Statt starrer Schwellenwerte bewertet ein Modell Gaskonzentration und Dauer gemeinsam. Es schätzt die tatsächliche Auswirkung auf alle Geräte der betroffenen Load ein, nicht nur auf ein einzelnes Gerät.
Topic: tuttlingen/linie03/ki/sterilisation-anomalie/ETO-20260718-0630
JSON Payload:
{
"sterilizationCycleId": "ETO-20260718-0630",
"devicesInLoad": [
"SN20260718-0045",
"SN20260718-0046",
"SN20260718-0047"
],
"anomaly": true,
"parameter": "eo_concentration",
"deviationPercent": 8.5,
"durationMin": 22,
"estimatedSterilityImpact": "requires_biological_indicator_review",
"recommendation": "quarantine_load_pending_bi_result",
"timestamp": "2026-07-18T14:10:00Z"
}
Digitaler Zwilling in der Medizintechnik
Der digitale Zwilling im Unified Namespace ist insbesondere dann interessant, sobald er neben Anlagenparametern auch gerätespezifische Sterilisations- und Reinraumdaten integriert.
Sterilisationszyklus-Zwilling
Der digitale Zwilling simuliert Gaskonzentration und Belüftungsdauer, bevor ein neuer Zyklusparameter freigegeben wird. So lässt sich die erreichbare Sterility Assurance Level absichern, ohne eine reale Load zu riskieren.
Topic: tuttlingen/linie03/zwilling/sterilisation/simulation
JSON Payload:
{
"simulationId": "SIM-ETO-2026071801",
"method": "ethylene_oxide",
"scenario": "reduced_aeration_time_test",
"input": {
"gasExposureMin": 240,
"aerationHours": 10
},
"predictedSterilityAssuranceLevel": "1.5e-6",
"requiredSal": "1e-6",
"result": "sufficient",
"recommendedForLiveOperation": false,
"timestamp": "2026-07-18T00:30:00Z"
}
Reinraum- und Linienqualifizierungszwilling
Bei Layoutänderungen oder neuen Arbeitsplätzen simuliert der Zwilling die Auswirkung auf Partikelzahl und Luftwechselrate, bevor der Reinraum real umgebaut wird.
Topic: tuttlingen/linie03/zwilling/reinraum/qualifizierung
JSON Payload:
{
"simulationId": "SIM-CLNRM-2026071802",
"scenario": "additional_workstation_layout_test",
"input": {
"additionalOperators": 2,
"newEquipmentHeatLoadW": 450
},
"predictedParticleCount_0_5um": 9100,
"limit_0_5um": 352000,
"predictedAirChangesRequired": 32,
"result": "compliant",
"recommendedForLiveOperation": true,
"timestamp": "2026-07-17T20:00:00Z"
}
Best Practices für die UNS Einführung in der Medizintechnik
Do
- UDI (DI+PI) als Pflichtfeld modellieren: Die UDI gehört auf Geräte-Ebene, nicht als optionales Attribut irgendwo im Payload verstreut.
- DHR anbinden: Erst die Verknüpfung von Fertigungs-, Sterilisations- und Prüfdaten über die UDI macht einen vollständigen Device History Record möglich.
- Audit-Trails nach 21 CFR Part 11 ausrichten: Elektronische Aufzeichnungen müssen ALCOA+-konform sein, mit Zeitstempel, Nutzerkennung und unveränderlichem Verlauf.
- Kalibrierstatus mitführen: Der Kalibrierstatus von Reinraum- und Sterilisationssensoren gehört in den UNS, damit Audits die Messgenauigkeit lückenlos nachvollziehen können.
Avoid
- UDI nur im ERP pflegen, getrennt von Fertigungsereignissen: Erschwert die DHR-Konsolidierung und macht UDI-Abfragen über Prozessdaten hinweg mühsam.
- Sterilisationsdaten nur am lokalen Autoklaven- oder EtO-Kammer-HMI belassen: Ohne Sichtbarkeit im UNS lässt sich der Sterility-Assurance-Nachweis nicht zentral auswerten.
- Feldnutzungsdaten vernetzter Geräte als separates Silo führen: Verhindert, dass Felddaten jemals mit Fertigungs- und Qualitätsdaten desselben Geräts korreliert werden können.
Fazit
Ein Unified Namespace in der Medizintechnik ist mehr als eine generische Manufacturing-Architektur mit Medizintechnik-Etikett. UDI, Sterilisationszyklus und Reinraumdaten sind eigenständige Datenobjekte, die die Topic-Struktur von Grund auf mitbestimmen. Das macht Audits nach ISO 13485, Vorgaben aus 21 CFR Part 11 und die Rückverfolgung einzelner Geräte praktisch beherrschbar. Drei zentrale Erkenntnisse:
- Branchenspezifische Datenmodellierung vor genereller Architektur: UDI, Sterilisationszyklus und Reinraumdaten sind eigenständige Felder, nicht eine andere Broker-Wahl. Das unterscheidet einen Unified Namespace in der Medizintechnik von generischen Manufacturing-Architekturen.
- KI und digitaler Zwilling brauchen Kontext, nicht nur Daten: Ihr Wert entsteht erst durch die Verknüpfung von Fertigungs-, Labor- und Felddaten eines Geräts, nicht durch generische Anomalieerkennung.
- Regulatorik ist Architekturtreiber, nicht Compliance-Anhängsel: ISO 13485, EU MDR und 21 CFR Part 11 bestimmen, welche Daten auf welcher Granularität wie lange vorliegen müssen.
Wer diese branchenspezifischen Anforderungen von Beginn an in die Topic-Struktur einbaut, spart sich spätere Umbauten – und ist zugleich vorbereitet, KI- und Digital-Twin-Anwendungsfälle direkt auf einer belastbaren Datenbasis aufzusetzen.
