Zurück zum Blog
Strategie & Wachstum

Software für das Gesundheitswesen entwickeln — Anforderungen, Kosten und Fallstricke

Gesundheitssoftware zu bauen ist komplexer als Standard-Individualentwicklung. Welche Anforderungen gelten, was kostet es realistisch und welche Fallstricke sollten Sie vermeiden?

Ontwikkelaars Team28. März 20269 Min. Lesezeit
GesundheitssoftwareDigitalisierung GesundheitswesenNEN 7510DSGVO GesundheitswesenMedizinsoftware
Software für das Gesundheitswesen entwickeln — Anforderungen, Kosten und Fallstricke

Maßgeschneiderte Software für das Gesundheitswesen entwickeln zu lassen ist grundlegend anders als ein Webshop oder ein internes Dashboard. Das liegt nicht nur an der Technik — es liegt am Geflecht aus Anforderungen, Verantwortlichkeiten und Aufsicht, das den Gesundheitssektor umgibt. Wer das unterschätzt, zahlt später den Preis: in Verzögerungen, Nachbesserungen oder schlimmer noch, in einem Produkt, das nicht in Betrieb genommen werden darf.

Dieser Artikel richtet sich an Gesundheitseinrichtungen, Gesundheitsunternehmer und Entscheidungsträger, die erwägen, ein digitales Produkt entwickeln zu lassen — von einem Patientenportal bis zu einem Berichtssystem oder einer eigenen elektronischen Patientenakte. Er gibt ein ehrliches Bild davon, was dieses Projekt beinhaltet, was es kostet und was die häufigsten Fehler sind.

Die Vorschriften, die Sie nicht ignorieren können

NEN 7510 — Informationssicherheit im Gesundheitswesen

NEN 7510 ist die niederländische Norm für Informationssicherheit im Gesundheitssektor. Vergleichbar mit ISO 27001, aber speziell auf den Schutz medizinischer Daten ausgerichtet. Für viele Gesundheitsorganisationen ist die NEN-7510-Zertifizierung Pflicht oder vertraglich durch Krankenkassen und Dachorganisationen gefordert.

Was das in der Praxis für ein Softwareprojekt bedeutet: Der Anbieter muss nachweisbar machen, dass das System die Sicherheitsanforderungen der Norm erfüllt. Das erfordert rollenbasierte Zugriffskontrolle, Protokollierung, wer wann welche Daten eingesehen hat, Verschlüsselung von Daten in Transit und at rest sowie einen dokumentierten Incident-Response-Prozess. Das sind keine Optionen, die man nachträglich einbaut — sie müssen von Tag eins im Design stecken.

DSGVO und medizinische Daten

Medizinische Daten fallen unter die besonderen personenbezogenen Daten in der DSGVO. Ihre Verarbeitung ist grundsätzlich verboten, sofern keine explizite gesetzliche Grundlage vorliegt. Im Gesundheitswesen ist diese Grundlage oft das Behandlungsverhältnis (Art. 9 Abs. 2h DSGVO), aber das entbindet nicht von anderen Pflichten.

Eine Softwareagentur, die Gesundheitssoftware baut, tritt rechtlich als Auftragsverarbeiter auf. Das bedeutet: Ein Auftragsverarbeitungsvertrag ist verpflichtend, Datensparsamkeit muss im Design umgesetzt werden, und Datenpannen müssen innerhalb von 72 Stunden der zuständigen Aufsichtsbehörde gemeldet werden können. Gesundheitsorganisationen, die das an eine Agentur delegieren, ohne einen Auftragsverarbeitungsvertrag abzuschließen, sind selbst haftbar.

UZI-Karten und Authentifizierung

Für Systeme, die Zugang zum niederländischen Nationalen Vermittlungspunkt (LSP) ermöglichen oder mit dem BIG-Register arbeiten, ist die Authentifizierung über UZI-Karten (Unieke Zorgverlener Identificatie — eindeutige Identifikation von Gesundheitsdienstleistern) erforderlich. Das sind Chipkarten, die die Identität eines Gesundheitsdienstleisters festhalten. Nicht jede Agentur hat Erfahrung mit UZI-Integrationen — und es ist keine triviale technische Aufgabe.

Systeme, die keine direkte LSP-Anbindung benötigen, können auch mit DigiD (für Patienten) oder anderen zertifizierten Authentifizierungsmitteln arbeiten, abhängig vom Risikoniveau.

SMART on FHIR und Interoperabilität

Eine der am häufigsten unterschätzten Anforderungen in Gesundheitssoftware ist die Interoperabilität: die Anforderung, dass Systeme miteinander kommunizieren können. In den Niederlanden ist FHIR (Fast Healthcare Interoperability Resources) der Standard für den Austausch medizinischer Daten. SMART on FHIR ist ein Autorisierungsrahmen, der darauf aufbaut und eine sichere Anbindung an externe Systeme ermöglicht.

Wenn Ihr neues System auch nur ansatzweise mit einem EPD (Elektronische Patientenakte), einem Hausarztsystem oder dem LSP kommunizieren muss, ist FHIR-Unterstützung kein Luxus — es ist eine Grundvoraussetzung. Viele Standardsoftwarelösungen unterstützen das nicht oder nur unvollständig. Maßgeschneiderte Software kann das einbauen, erhöht aber die Komplexität und die Kosten.

Fragen Sie in einem Agentur-Gespräch immer explizit: Haben Sie bereits FHIR-Integrationen gebaut? Haben Sie Referenzen im Gesundheitswesen? Eine Agentur, die hier vage ist, hat es wahrscheinlich noch nicht getan.

Häufige Anwendungsfälle

Nicht jede Gesundheitssoftware ist gleich komplex. Einige häufige Anwendungsfälle, nach Komplexität geordnet:

Patientenportal — Eine gesicherte Umgebung, in der Patienten Termine einsehen, Fragebögen ausfüllen oder Nachrichten senden können. Relativ überschaubar im Scope, erfordert aber DSGVO-Compliance, DigiD-Integration und eine gute UX für eine diverse Nutzergruppe.

Planungssystem für Gesundheitsprofis — Dienstpläne, Termine, Verfügbarkeit. Die Herausforderung liegt in komplexer Planungslogik (Teilzeitverträge, Spezialisierungen, Standorte) und Integration mit bestehenden HR- oder EPD-Systemen.

Pflegedokumentation oder EPD — Der komplexeste Typ. Strukturierte Erfassung von Pflegeplänen, Behandlungsdaten, Medikation. Erfordert Standardisierung über FHIR, robustes Auditing und oft Integration mit externen Systemen wie Apothekensoftware oder dem LSP.

Berichterstattung an Gesundheitsbehörden — Viele Gesundheitsorganisationen müssen periodisch an die niederländische Gesundheitsbehörde (NZa) oder Krankenkassen berichten. Software, die das automatisiert, muss exakt an die erforderlichen DBC-Codierungen und Abrechnungsformate angepasst sein.

Warum Gesundheitssoftware teurer ist

Der Preisunterschied zwischen einer regulären Webanwendung und Gesundheitssoftware hat drei Ursachen.

Compliance-Overhead — Dokumentation, Sicherheitsaudit, Penetrationstest und der Nachweis der Erfüllung von NEN 7510 kosten zusätzliche Zeit. Das ist Arbeit, die in der Endnutzer-Oberfläche nicht sichtbar ist, aber notwendig ist, um das System in Betrieb zu nehmen.

Integrationskomplexität — Anbindungen an EPD-Systeme, UZI-Infrastruktur, LSP oder FHIR-Endpoints sind technisch anspruchsvoll. Es sind keine Standard-API-Anbindungen — sie erfordern Zertifikate, spezifische Protokolle und umfangreiches Testen.

Testanforderungen — Im Gesundheitswesen können Fehler direkte Folgen für die Patientensicherheit haben. Das erfordert eine umfangreichere Teststrategie, einschließlich funktionaler Abnahmetests mit Endnutzern (Gesundheitsprofis) und manchmal Zertifizierung als Medizinprodukt nach der MDR (Medical Device Regulation).

Realistische Budgetindikationen

Für Gesundheitssoftware gelten andere Budgetnormen als für reguläre maßgeschneiderte Entwicklung:

  • Patientenportal (Basis): €40.000 – €70.000. Inkl. DigiD, sicheres Messaging, Terminübersicht und DSGVO-Compliance. Ohne EPD-Integration.
  • Patientenportal mit EPD-Anbindung: €80.000 – €140.000. Abhängig vom EPD und den verfügbaren Schnittstellen.
  • Planungssystem: €60.000 – €120.000. Stark abhängig von der Planungskomplexität und der Anzahl der Integrationen.
  • Vollständige EPD-Lösung: €150.000 – €400.000+. Das ist maßgeschneiderte Entwicklung in der schwersten Kategorie. Erwarten Sie ein Projekt von 9 bis 18 Monaten mit einem multidisziplinären Team.

Zusätzlich zu den Entwicklungskosten kommen laufende Kosten: Hosting (vorzugsweise in den Niederlanden oder der EU, auf zertifizierter Infrastruktur), Wartung, jährliche Sicherheitsreviews und eventuelle Rezertifizierung.

Die Fallstricke, die Gesundheitseinrichtungen am häufigsten treffen

Eine Agentur ohne Gesundheitsreferenzen wählen. Technisch können viele Agenturen eine Anwendung bauen. Aber eine Agentur, die noch nie im Gesundheitssektor gearbeitet hat, kennt die Compliance-Anforderungen nicht von innen. Die Folge: Sie zahlen für einen Lernprozess, den der Anbieter auf Ihre Rechnung absolviert.

Compliance bis nach der Entwicklung verschieben. Sicherheit und DSGVO-Compliance sind keine Farbschicht, die man nachträglich aufträgt. Wer das nach dem ersten Release einbaut, baut das System effektiv neu. Planen Sie Compliance als erstklassige Anforderung, nicht als Nachprojekt.

Änderungen in Gesetzen und Vorschriften nicht berücksichtigen. Der Gesundheitssektor digitalisiert schnell, und die Regulierung entwickelt sich mit. Systeme, die heute konform sind, müssen möglicherweise in zwei Jahren angepasst werden. Sorgen Sie für einen Wartungsvertrag und stellen Sie sicher, dass die Agentur auch langfristig verfügbar ist.

Den Nutzer vergessen. Gesundheitsprofis sind beschäftigt. Ein System, das nicht intuitiv funktioniert, wird nicht genutzt — unabhängig davon, was es gekostet hat. Investieren Sie in Nutzerforschung und testen Sie früh mit echten Pflegenden und Patienten.

Die richtige Agentur finden

Fragen Sie in Gesprächen mit Agenturen nach konkreten Referenzen im Gesundheitssektor. Nicht nur „wir haben schon etwas im Gesundheitswesen gemacht", sondern: Welches System, für welche Organisation, mit welchen Integrationen und welchen Compliance-Anforderungen? Fragen Sie auch nach dem Auftragsverarbeitungsvertrag — eine Agentur, die darüber nicht direkt sprechen kann, hat wenig Erfahrung mit der DSGVO im Gesundheitswesen.

Prüfen Sie, ob die Agentur mit NEN 7510, FHIR und der niederländischen Gesundheitsinfrastruktur vertraut ist. Das sind keine Bonuspunkte — es sind Grundqualifikationen für diese Art von Arbeit.

Gesundheitssoftware zu bauen ist komplex, aber beherrschbar, wenn man weiß, was man einkauft. Die Organisationen, die erfolgreich digitalisieren, sind nicht die Organisationen mit dem größten Budget — es sind die Organisationen, die den richtigen Partner finden und die richtigen Fragen stellen.

Ontwikkelaars Team

Ontwikkelaars Team

Expertenteam bei Ontwikkelaars