Can your engineers work inside our IEC 62304 lifecycle and ISO 13485 QMS from the first change?

Yes. They follow your procedures, templates and review workflow. Every change carries its requirement, risk assessment and verification, and the records are made in your system, so the auditor sees one quality system.

How fast can engineers start, and how large can the team get?

The first engineers can start within two to three weeks of signature. The team grows one work package at a time.

Do you take over QA and DevOps as well as development?

Yes. Our engineers take over development, verification and the build and release chain together, or only the part where your team needs capacity. The work runs inside your lifecycle, and the records go into your quality system.

Which languages and tools do your engineers use on imaging platforms?

The ones your platform uses. Our engineers work in C++, C#, .NET and Python, with the common imaging and DICOM libraries and the usual build and cloud tools.

Do you build auto segmentation models?

Yes, when you have the data to train them on. We train and validate segmentation models on your data, or take your existing model, and build the product around it. That covers the inference service, the DICOM SEG export of the results, model version control and the evidence for the technical file.

How does a first engagement start?

With a technical call. Then we agree on the first step: one or two engineers who join your team, a defined work package, or an IEC 62304 gap analysis. The team grows in small steps as the work needs it. Each step is quoted individually and agreed in writing.

Branchen · OEMs für medizinische Bildgebung

Hersteller bildgebender Systeme, deren Plattform-Releases termingerecht erscheinen und Audits bestehen.

CT, MR, Röntgen, Ultraschall und PET sowie die Software zum Befunden und zur Nachbearbeitung laufen auf großen Softwareplattformen. Der Release-Termin steht fest, und der Umfang ändert sich, während das Release läuft. Wir verstärken das Team dort, wo der Engpass liegt: in der Entwicklung, in der Verifizierung oder in der Dokumentation. So haben die geplanten Funktionen die Ingenieure, die sie brauchen, in Ihrem IEC-62304-Lebenszyklus und Qualitätssystem, für die EU-MDR und die FDA.

30-minütiges Gespräch buchen Schreiben Sie uns

Systeme: Modalitäten · Befundungssoftware · PACS
Normen: IEC 62304 · ISO 13485 · EU MDR · FDA
Erster Schritt: Kostenloses 30-minütiges Gespräch mit der Entwicklung

Der Weg der Software

Wie eine Plattformänderung ins Feld kommt.

Anforderung

Der Release-Termin steht fest, der Umfang wächst, und Updates für DICOM (der Standard für medizinische Bilder und deren Austausch) sowie Fehler aus dem Feld warten auf dieselben Ingenieure.

VerbesserungUnsere Entwickler unterstützen Sie dort, wo Engpässe entstehen, in der Entwicklung, Verifizierung oder Dokumentation. Dabei halten sie sich an Ihren Release-Plan.

Design

Designentscheidungen in einer großen Plattform werden erst nach der Programmierung dokumentiert. Den Bezug zur Anforderung ergänzt das Team kurz vor dem Audit.

VerbesserungWir dokumentieren das Design vor der Programmierung und verknüpfen es in Ihren Werkzeugen mit den zugehörigen Anforderungen und Risikobewertungen.

Implementierung

Neue Entwickler brauchen Monate, bevor sie Änderungen an der Plattform sicher vornehmen können.

VerbesserungUnsere Entwickler beginnen mit einem kleinen Arbeitspaket, das Sie prüfen. So können Sie die Codequalität beurteilen, bevor das Team wächst.

Verifizierung

Tests werden spät erstellt und ausgeführt. Dadurch bleibt die Verifizierung vor jedem Audit hinter der Entwicklung zurück.

VerbesserungAutomatisierte Regressionstests laufen bei jeder Änderung. So hält die Verifizierung mit der Entwicklung Schritt.

Freigabe

Manuelle Build- und Testschritte verzögern jedes Release.

VerbesserungEine automatisierte Build- und Testkette übernimmt diese Schritte bei jedem Release.

Feldsupport

Die Ursachenanalyse bei Fehlern aus dem klinischen Betrieb hält Entwickler von geplanten Aufgaben ab.

VerbesserungUnsere Entwickler übernehmen die Ursachenanalyse und ergänzen jede Fehlerkorrektur um einen Regressionstest.

Änderung

Nach Änderungen führen Lücken in der Rückverfolgbarkeit zu Beanstandungen bei Audits.

VerbesserungWir dokumentieren für jede Änderung, ob die Benannte Stelle informiert werden muss oder eine neue FDA-Einreichung erforderlich ist. Zugleich aktualisieren wir die Rückverfolgbarkeit von der Anforderung bis zum Release. So ist die Dokumentation vor dem Audit vollständig.

Das Ziel

Eine Plattform, die termingerecht erscheint und deren Dokumentation für das Audit bereitsteht.

Für den Hersteller

Releases nach Plan mit vollständigen Verifizierungsnachweisen
Lückenlose Rückverfolgbarkeit von der Anforderung bis zum Testergebnis, die der Auditor nachvollziehen kann
Dieselben Entwickler betreuen die Plattform über mehrere Releases hinweg

Für das klinische Personal, das die Geräte nutzt

Eine Plattform, die sich nach einem Update unverändert verhält
Neue DICOM-Versionen und Supplements, die mit den vor Ort installierten Systemen zusammenarbeiten
Fehler aus dem klinischen Betrieb beheben und mit Regressionstests absichern

Für Patienten

Schnellere und sicherere Untersuchungen, weil neue Funktionen früher auf den Scannern verfügbar sind
Fehler schnell beheben und Korrekturen zügig auf den installierten Systemen bereitstellen
Bilder und Ergebnisse, auf die sie sich nach jedem Update verlassen können

Probleme und Lösungswege

Was wir hören und was wir dagegen tun

Der Release-Termin oder der Funktionsumfang steht fest und das Plattformteam ist bereits ausgelastet.

Unsere Entwickler unterstützen Sie bei Engpässen in der Entwicklung, Verifizierung oder Dokumentation. Dabei folgen sie Ihrem Entwicklungsprozess und Review-Workflow. Jede Änderung wird mit der zugehörigen Anforderung und Risikobewertung dokumentiert. Wächst der Umfang, erweitern wir das Team für ein weiteres Arbeitspaket.

Teamerweiterung

Die Verifizierung bleibt vor jedem Audit hinter der Entwicklung zurück.

Wir übernehmen die Testautomatisierung sowie die Build- und Release-Kette. So läuft die Verifizierung bei jeder Änderung mit. Die Rückverfolgbarkeit von der Anforderung bis zum Release halten wir in den Aufzeichnungen fest.

QA, Compliance und regulatorische Unterstützung

Ein Forschungsalgorithmus läuft auf einer Workstation, kann aber in Krankenhäusern nicht eingesetzt werden.

Wir betreiben den Algorithmus als isolierten Service und verbinden ihn über einen sicheren DICOM-Übertragungsweg mit dem PACS. Segmentierungen geben wir als DICOM SEG und Befunde als DICOM SR aus. Wir erstellen die Softwareunterlagen für die technische Dokumentation. Klassifizierung und klinische Evidenz planen wir gemeinsam mit Ihrem Regulatory-Team.

Software für die medizinische und zahnmedizinische Bildgebung

Unsere Befundungssoftware und die zugehörigen klinischen Systeme müssen mit Systemen anderer Hersteller kommunizieren.

Wir spezifizieren und entwickeln die Schnittstellen für HL7 (ein Standard für den Austausch klinischer Nachrichten) und FHIR (ein Webstandard für den Austausch von Gesundheitsakten), die Daten-Gateways für Geräte und die DICOM-Integration. Die Integrationstests liegen in der Verifizierungsakte.

Interoperabilität

Security-Befunde kommen schneller, als das Plattformteam sie untersuchen kann.

Unsere Entwickler härten die Plattform, untersuchen Schwachstellen und erstellen die Cybersicherheitsanalyse. Dabei folgen sie demselben Entwicklungsprozess wie bei der Plattformsoftware.

Cybersecurity für Medizinprodukte

Die Einarbeitung neuer Entwickler dauert Monate und die Codequalität sinkt.

Jede Änderung durchläuft Ihren Review-Workflow und Ihre Release-Gates, ab der ersten Codezeile. Das erste Arbeitspaket ist klein, sodass Sie den Code an echten Änderungen beurteilen, bevor das Team wächst.

Wie wir arbeiten

Ein externes Team bedeutet beim Audit ein zweites Qualitätssystem.

Ihre Verfahren, Ihr Review-Workflow und Ihre Release-Gates bleiben bestehen, und unsere Ingenieure arbeiten darin mit Ihren Vorlagen. Bibliotheken von Drittanbietern werden in Ihrer Liste als SOUP (Software unbekannter Herkunft, also Code von Drittanbietern, der im Gerät verwendet wird) geführt, und Code und Aufzeichnungen liegen in Ihren Repositories, sodass der Auditor ein einziges System sieht.

Entwicklung medizinischer Software

Systeme

Die Systeme rund um die Plattform und ihre Schnittstellen.

System	Was es enthält	Schnittstelle	Unsere Arbeit
Modalitäten	CT-, MR-, Röntgen-, Ultraschall- und PET-Bilder sowie Aufnahmedaten	DICOM	Wir integrieren neue DICOM-Versionen, Supplements und Transfer Syntaxes in eine bestehende Plattform und aktualisieren das DICOM Conformance Statement.
PACS und Archiv	Untersuchungen, Befunde und strukturierte Befunddaten	DICOM · DICOMweb · DICOM SEG · DICOM SR	Wir exportieren Segmentierungen und Befunde als DICOM-SEG- und DICOM-SR-Objekte.
KIS und RIS	Aufträge, Arbeitslisten und Befunde	HL7 v2 · FHIR · DICOM MWL und MPPS	Wir spezifizieren und entwickeln die Schnittstellen und testen sie mit den in der Klinik installierten Systemen.
Produkte für Patientenüberwachung und klinische Information	Gerätedaten und klinische Dokumentation	HL7 · FHIR · Geräte-Gateways	Wir entwickeln Gateways für Gerätedaten und dokumentieren die Integrationstests in den Verifizierungsunterlagen.
Algorithmus-Hosting	Forschungs- und KI-Algorithmen als Services	DICOM · Cloud-Microservices	Wir betreiben Algorithmen als isolierte Services, die je nach Bedarf skalieren. Wir binden sie an das PACS des Krankenhauses an und erstellen die Unterlagen für die technische Dokumentation.
Build- und Testkette	Code, Builds und Testnachweise	CI/CD · Rückverfolgbarkeit	Wir richten die Build-, Test- und Release-Kette ein und dokumentieren die Rückverfolgbarkeit von der Anforderung bis zum Release.

Eignung

Wann wir der richtige Partner sind

Sprechen Sie uns an, wenn

Sie für das nächste Release zusätzliche Entwickler benötigen, die bereits nach IEC 62304 arbeiten
die Verifizierung vor dem nächsten Audit mit der Entwicklung Schritt halten soll
ein Forschungsalgorithmus als regulierter Service neben dem PACS laufen soll
Ihre DICOM- und HL7-Schnittstellen mit Systemen anderer Hersteller funktionieren sollen

Sprechen Sie mit uns

Sagen Sie uns, woran Sie arbeiten.

Ein Release, das mehr Entwickler braucht, Verifizierung vor einem Audit, ein DICOM-Update oder Feldfehler. Schreiben Sie ein paar Zeilen oder buchen Sie ein kostenloses 30-minütiges Gespräch mit der Entwicklung.

30-minütiges Fachgespräch buchen

FAQ

Häufige Fragen.

Können Ihre Entwickler bereits ab der ersten Änderung nach unserem Entwicklungsprozess gemäß IEC 62304 und unserem QMS nach ISO 13485 arbeiten?

Ja. Sie arbeiten nach Ihren Verfahren und Vorlagen und folgen Ihrem Review-Workflow. Jede Änderung dokumentieren sie mit der zugehörigen Anforderung, Risikobewertung und Verifizierung. Die Aufzeichnungen entstehen in Ihrem System. So sieht der Auditor ein einheitliches Qualitätssystem.

Wie schnell können Entwickler beginnen und wie groß kann das Team werden?

Die ersten Entwickler können zwei bis drei Wochen nach der Unterzeichnung beginnen. Das Team wächst Arbeitspaket für Arbeitspaket.

Übernehmen Sie neben der Entwicklung auch Qualitätssicherung und DevOps?

Ja. Unsere Entwickler übernehmen die Entwicklung, Verifizierung und die Build- und Release-Kette gemeinsam oder gezielt dort, wo Ihrem Team Kapazität fehlt. Dabei folgen sie Ihrem Entwicklungsprozess und dokumentieren ihre Arbeit in Ihrem Qualitätsmanagementsystem.

Welche Programmiersprachen und Werkzeuge nutzen Ihre Entwickler bei Bildgebungsplattformen?

Die Ihrer Plattform. Unsere Entwickler arbeiten mit C++, C#, .NET und Python sowie gängigen Bildgebungs- und DICOM-Bibliotheken und üblichen Build- und Cloud-Werkzeugen.

Entwickeln Sie Modelle zur automatischen Segmentierung?

Ja, wenn Sie die Daten zum Training haben. Wir trainieren und validieren Segmentierungsmodelle mit Ihren Daten oder übernehmen Ihr bestehendes Modell und bauen das Produkt darum herum. Dazu gehören der Inferenzdienst, der DICOM-SEG-Export der Ergebnisse, die Versionsverwaltung der Modelle und die Nachweise für die technische Dokumentation.

Wie beginnt eine erste Zusammenarbeit?

Mit einem Fachgespräch. Danach vereinbaren wir den ersten Schritt: ein oder zwei Ingenieure, die zu Ihrem Team stoßen, ein definiertes Arbeitspaket oder eine Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt) nach IEC 62304. Das Team wächst in kleinen Schritten, wie die Arbeit es verlangt. Jeder Schritt wird einzeln angeboten und schriftlich vereinbart.

Weiterführend

Weitere Leistungen und Branchen.

Teamerweiterung Dedizierte Entwicklungsteams Software für die medizinische und zahnmedizinische Bildgebung Verifizierung und Validierung Interoperabilität Cybersecurity für Medizinprodukte OEMs der Strahlentherapie