← Imedex: die Geschichte bisher

Imedex-Journey · Update #3 · September 2026

Das Serviceprotokoll wurde zum lebenden Datensatz.

Update #1 handelte von KI, Update #2 vom Wissen, mit dem die KI arbeitet. Dieses handelt vom unscheinbarsten und am stärksten regulierten Teil im Leben eines Medtech-Distributors: dem Service. Am 9. September übergab uns der Serviceleiter von Imedex zwei kurze Listen — eine zur installierten Technik, eine zur periodischen sicherheitstechnischen Kontrolle. Acht Tage später waren 22 der 26 Punkte live im Produktivsystem, einzeln geprüft in der laufenden Instanz und in den erzeugten PDFs. Nichts auf der Restliste wartet auf Entwicklung; offen sind zwei Entscheidungen.

Das Problem, in einem Dokument

Jedes in einem Krankenhaus installierte Medizinprodukt muss eine periodische sicherheitstechnische Kontrolle bestehen — in Tschechien gesetzlich alle 12 Monate — und das Krankenhaus behält das unterschriebene Protokoll. Ein Besuch, mehrere Geräte, ein Protokoll pro Gerät. Dieses Protokoll ist der ganze Zweck des Besuchs, und doch waren die beiden wichtigsten Daten darauf — wann die Kontrolle durchgeführt wurde und wann die nächste fällig ist — bis zu dieser Runde nirgends echte Daten. Das System hielt einen geplanten Zeitraum; das Durchführungsdatum war, was jemand eintippte; das nächste Datum war Arithmetik, die niemand korrigieren konnte. Standort, Garantiestatus, Bestellnummer des Kunden und Name des Technikers wurden auf jedem Protokoll neu eingetippt. Der Ausdruck trug zudem interne Nummern, die einem Krankenhaus nichts sagen.

Was sich geändert hat

Die Termine sind vollwertige Daten. Durchführungsdatum und nächster Fälligkeitstermin leben jetzt auf jeder Serviceaktivität — editierbar, vorbelegt nach der eigenen Regel des Kunden (zwölf Monate weiter, auf Monatsende gerundet), im Kopf sichtbar und gedruckt. Die Garantie wird abgeleitet, nie gespeichert — aus den Garantiedaten des Geräts, sodass sie nicht von der Wahrheit abdriften kann. Der Standort kommt aus der installierten Basis, nicht aus dem Gedächtnis des Technikers. Die Bestellnummer des Kunden hat ein Zuhause: einmal am Auftrag erfasst, auf jedem Protokoll dieses Besuchs gedruckt und durchsuchbar — „finde den Auftrag zu dieser Bestellung" ist jetzt ein Filter, kein Telefonat. Der Techniker ist eine Rolle, die man wählt, kein Name, den man tippt. Und das Protokoll verlor die drei internen Felder, die der Serviceleiter auf einer gedruckten Kopie durchgestrichen hatte.

Eine sicherheitstechnische Prüfaktivität in Healtek mit dem Titel „PM due — NebuMist Pro Nebulizer Station“, mit Feldern für Zeitraum von und bis, Durchführungsdatum, nächster Fälligkeitstermin, Bestellnummer des Kunden, Bestelleingangsdatum und Standort, und einem geöffneten Druckfenster, das die BTK-Dokumentvorlage als PDF, Word, Excel oder JSON in Englisch, Tschechisch oder Slowakisch anbietet.
Die Prüfung, wie sie das Büro sieht: Durchführungsdatum und nächster Fälligkeitstermin sind eigene Felder, neben der Bestellnummer des Kunden und dem Standort. Rechts das Protokoll, das gleich aus der BTK-Vorlage erzeugt wird — und die Sprache, in der es druckt, ist eine Auswahl auf demselben Datensatz, kein zweites System. Gezeigt auf einer Demonstrationsinstanz; Krankenhaus und Kontaktperson darin sind fiktiv.

Die installierte Basis selbst spricht jetzt die Sprache des Kunden: Installierte Positionen statt generischer Bezeichnungen, Gerätezustand und Installationsdatum statt Mengen, drei Felder, die bei Imedex niemand nutzt, ausgeblendet (nicht gelöscht — die Werte bleiben), und der Standort wird bereits beim Anlegen eines Geräts gesetzt. An ein Krankenhaus verliehene Geräte und vermietete Geräte sind jetzt zwei verschiedene Zustände, weil sie zwei verschiedene Realitäten sind.

Warum das größer ist als ein Kunde

Nichts im Code kennt das Wort „BTK". Die Termine, die Bestellnummer, der Leihzustand und der Standort wurden zu Plattformfähigkeiten, die durch die Konfiguration eines Aktivitätstyps eingeschaltet werden. Ein Dental- oder Labor-Serviceunternehmen mit anderem Prüfzyklus und anderer Rechtsordnung startet vom selben Punkt — und eines davon hat die klarere Benennung bereits übernommen, ohne selbst eine Anfrage zu stellen.

Wie es weitergeht

Imedex führt zwei Gesellschaften — eine tschechische in CZK und eine slowakische in EUR — auf einer Instanz mit einem gemeinsamen Produktkatalog. Die nächste Welle überträgt diese Servicekonfiguration auf die slowakische Gesellschaft und ergänzt Produkttexte in drei Sprachen, damit derselbe Katalog in Prag wie in Bratislava korrekt druckt. Die zwei offenen Entscheidungen auf der Liste treffen wir gemeinsam mit dem Serviceleiter — es sind keine Funktionen, die gebaut werden müssen. Warum ein Gerät eine Grenze innerhalb seiner Gruppe ohne zweites System überqueren sollte — und was die EU daraus macht — steht in „Geräte ohne Grenzen".

Sprechen Sie mit uns über Ihr Serviceprotokoll →

Verantwortlich: Jan Safka · Healtek-Feldnotizen, September 2026. Die Zahlen (26 Anforderungen, 22 live) stammen aus dem Prüfdurchgang in der Produktivinstanz des Kunden am 17. September 2026 — nicht aus einem Testsystem.

← Zurück zur Imedex-Geschichte

Möchten Sie die nächste Geschichte sein?