Zum Inhalt springen

Fallstudie · HealthTech · Diagnostik

Unilab — Labor-Patientenplattform für mehrere Städte

Veröffentlicht · Aktualisiert · Von YuSMP Group Engineering

Wie wir eine produktive Diagnostik-Patientenplattform ausgeliefert haben — native iOS- und Android-Apps, einen persönlichen Web-Bereich und den Adapter-Klebstoff zu bestehenden Termin- und Buchhaltungssystemen — auf Symfony aufgebaut, mit zuverlässigen Push-Pipelines über APNs und FCM, einem Testkatalog von 2.500 Einträgen und einer Datenschutz-Aufstellung, die von Tag eins an an der DSGVO für die Europäische Union und der CCPA für die USA ausgerichtet ist.

BrancheHealthTech · Diagnostik
Projektjahr2024
EngagementFestpreis + Support
Unilab — Patiententerminbuchung, digitale Laborbefunde, Healthcare-Plattform für die USA und die EU

Die Aufgabenstellung — ein Labornetzwerk, das eine Patientenoberfläche brauchte

Das Verwaltungspersonal von Unilab bearbeitete Terminanfragen, eingehende Anrufe, die Erfassung von Patientendaten und den E-Mail-Versand von Befunden über ein Netzwerk hinweg, das in mehr als vierzig Städten tätig ist, manuell. Die bestehenden Termin- und Buchhaltungs-Backends waren Arbeitstiere, doch sie waren Jahre vor der Zeit gebaut worden, in der mobiler Datenverkehr eine ernsthafte Lastklasse war, und stellten keine kundenseitige Oberfläche bereit, die ein Patient vom Smartphone aus erreichen konnte. Das Labor benötigte eine einheitliche Patientenplattform — Registrierung und persönlicher Bereich, Online-Terminbuchung, digitale Befunde, einen durchsuchbaren Katalog mit über 2.500 Tests, eine interaktive Karte der Standorte und Push-Erinnerungen — die sich in die bestehenden Termin- und Buchhaltungssysteme integriert, statt sie zu ersetzen. Die Plattform musste außerdem den Healthcare-Datenschutzanforderungen in den USA und der Europäischen Union standhalten: DSGVO für europäische Patienten, CCPA für kalifornische Patienten, HIPAA-fähige Architektur für etwaige künftige US-Launch-Szenarien. Wir haben die Plattform als Symfony-Backend mit Adapter-Diensten zu den Altsystemen entwickelt, kombiniert mit nativen iOS- (Swift) und Android- (Kotlin) Patienten-Clients und einem React-Web-Bereich. Das Ergebnis ist eine produktive Diagnostikplattform, die über Städte hinweg skaliert, die manuelle Verwaltungslast beseitigt und für einen konformen Betrieb in den USA und der EU positioniert ist.

Projekt-Highlights

Native Swift-iOS-Patienten-App Native Kotlin-Android-Patienten-App React-Web-Bereich Symfony-Backend + Adapter APNs- + FCM-Push-Pipelines Katalog mit 2.500+ Tests Integration des Terminsystems Bereit für mehrere Städte · USA & EU

In Zahlen

Ein Überblick darüber, was die Unilab-Entwicklung über iOS, Android, Web und ein in bestehende Termin- und Buchhaltungssysteme eingebundenes Symfony-Backend hinweg geliefert hat.

3Patientenoberflächen — natives iOS, natives Android und ein React-Web-Bereich
2.500+Testeinträge im Katalog mit strukturierter Suche, Filterung und Verfügbarkeit pro Stadt
2Alt-Adapter — einer zum Terminsystem, einer zur Buchhaltung — halten den Betrieb konsistent
2Push-Pipelines — Apple Push Notification service und Firebase Cloud Messaging parallel
40+Städte als erstklassige Mandanten im Datenmodell der Plattform unterstützt
14–22 Wo.typischer Lieferzeitraum für ein vergleichbares Labor-Patienten-MVP mit Integrationen
Persönlicher Patientenbereich von Unilab — natives iOS und Android, Healthcare-Patientenplattform für die USA und die EU

Warum natives iOS und Android statt Flutter oder eines WordPress-Portals

Die Plattformentscheidung dominiert die Zuverlässigkeitsgeschichte einer Healthcare-Patienten-App. Wir haben uns für natives Swift (iOS) und Kotlin (Android) gegenüber einem Flutter-MVP und einem WordPress-Patientenportal-Plugin entschieden, weil die Abwägungen sauber mit dem übereinstimmen, was ein Labor in mehreren Städten tatsächlich braucht. WordPress-Portale wirken im Verkaufsgespräch verlockend, brechen aber unter dem Lastprofil eines Labors schnell zusammen — Änderungen an Terminfenstern, Buchhaltungsabstimmungen, Push-Zustellung im Moment der Befundbereitschaft — und binden den Betreiber an ein Plugin-Ökosystem, das kein Healthcare-Auditor ernst nimmt. Flutter eignet sich hervorragend für formularlastige Apps, fügt aber eine Brücke zwischen Dart und den plattformeigenen Push-Pipelines und Biometrie-APIs hinzu, die sich Befund-bereit-Benachrichtigungen nicht leisten können.

Die Entwicklung stützt sich auf Apple Push Notification service auf iOS, Firebase Cloud Messaging auf Android und das Symfony-Framework im Backend — bewährte Primitive, die uns deterministisches Push-Verhalten, vorhersehbare Hintergrund-Sync-Semantik und eine Backend-Schicht geben, die Healthcare-Betreiber in den USA und der EU kennen und der sie vertrauen.

Natives iOS + Android vs. Flutter vs. WordPress-Patientenportal — auf einen Blick
Dimension Natives iOS + Android (Unilab) Flutter WordPress-Portal
Push-ZuverlässigkeitDirektes APNs / FCM; deterministische ZustellungBrücke zu Plattform-Pipelines; seltene Race ConditionsNur Web-Push; schwach auf iOS
Passung des Termin-AdaptersSaubere REST-Oberfläche vom Symfony-AdapterGleiches Backend erreichbar; identische PassungPlugin-gebunden; starres Mapping
Skalierung über mehrere StädteMandantenfähiges Datenmodell; Stadt nur per Konfiguration hinzufügenGleich; starke UI-ParitätNetzwerk von Websites oder Multisite-WP — betrieblich aufwendig
Latenz der BuchhaltungsintegrationAdapter-Dienst cacht Lesezugriffe; UI im SekundenbruchteilGleiches Backend; identische LatenzSynchrone Plugin-Aufrufe; für Nutzer sichtbare Wartezeiten
Biometrie & Face IDNatives LocalAuthentication / BiometricPromptPlugin-Brücke; meist in OrdnungAußerhalb eines nativen Wrappers nicht verfügbar
Passung der App-Store-PrüfungErstklassig — Healthcare-Berechtigungen sauberErstklassig; gleicher PrüfpfadOft als „Web-Wrapper" abgelehnt
Audit-Aufstellung (USA + EU)Betreibereigener Event-Store, unveränderlichIdentische Backend-GarantienPlugin-DB; schwache Audit-Lage

Referenzen: Dokumentation des Apple Push Notification service, Firebase-Cloud-Messaging-Leitfaden, Dokumentation des Symfony-Frameworks.

Terminbuchungsablauf von Unilab — Swift / SwiftUI auf iOS, Adapter für das Terminsystem, Standortkarte für mehrere Städte

iOS-Entwicklung — Swift, SwiftUI und der Terminbuchungsablauf

Der iOS-Client ist in Swift mit SwiftUI für die UI-Schicht und einer sauberen MVVM-Trennung entwickelt, die den Terminbuchungsablauf für den nächsten Entwickler lesbar hält, der ihn anfassen muss. Der Buchungsablauf ist das Rückgrat des Patientenerlebnisses: Ein Patient öffnet die App, durchsucht Tests, wählt Datum, Uhrzeit und Standort und bestätigt — wobei der Adapter-Dienst die Anfrage im Hintergrund in das Protokoll des Alt-Terminsystems übersetzt. Die interaktive Standortkarte ist ein eigener Ablauf mit einer MapKit-gestützten Ansicht und stadtbewusster Filterung, sodass ein Patient, der in einer Stadt lebt, nicht durch Standorte einer anderen waten muss, um einen Walk-in-Termin zu finden.

Push-Benachrichtigungen sind über APNs angebunden und nach Absicht segmentiert — Terminerinnerungen, Befund-bereit-Benachrichtigungen und Werbe-Pushes leben jeweils in ihrer eigenen Kategorie, sodass Nutzer sie unabhängig verwalten können. Der Background-Fetch hält den persönlichen Bereich warm, sodass ein Patient, der die App um 7 Uhr öffnet, den heutigen Termin sieht, ohne auf einen Netzwerk-Roundtrip zu warten. Die durchgängige iOS-Oberfläche wird im Rahmen unserer Praxis für Mobile App-Entwicklung geliefert, mit gemeinsamen Design-Tokens zwischen iOS und Android, sodass sich das Patientenerlebnis in beiden Stores als ein Produkt liest.

Digitale Befunde von Unilab — Kotlin-Android, sichere Befundzustellung, Testkatalog mit 2.500 Einträgen

Android-Entwicklung — Kotlin, Jetpack Compose und digitale Befunde

Der Android-Client ist in Kotlin mit Jetpack Compose für die UI und einem Foreground-Service für die Befundzustellung auf den Gerätefamilien Samsung, Xiaomi, OnePlus und Pixel geschrieben, wo aggressive Akku-Optimierer Hintergrunddienste ohne Vorwarnung beenden. Befunde kommen als verschlüsselte Blobs über einen durch den FCM-Push ausgelösten HTTPS-Pull an, niemals innerhalb der Push-Nutzlast selbst, und ein BiometricPrompt-Schritt sichert den Zugriff ab, sodass ein auf einem Café-Tisch liegengelassenes Smartphone das Blutbild eines Patienten keinem Fremden offenbart. WorkManager übernimmt nicht dringende Operationen — Katalogaktualisierungen, Aktualisierungen der Standortkarte, Telemetrie-Flush — mit Backoff-Semantik, die den Doze-Modus über Android 10 bis Android 14 respektiert.

Der Testkatalog mit 2.500 Einträgen ist der Bereich, in dem sich der Android-Client bewährt. Die strukturierte Suche über Kategorien, Unterkategorien und Freitext-Begriffe wird von einem Symfony-gestützten Suchindex bedient, mit stadtbewusster Verfügbarkeit, sodass ein Patient in einer Stadt nie einen Test sieht, der dort nicht angeboten wird. Die Detailangaben pro Test umfassen Vorbereitungshinweise, Bearbeitungszeiten und Preise — dieselben Felder, die das Alt-Buchhaltungssystem bereits pflegt, über den Buchhaltungs-Adapter bereitgestellt, sodass die Quelle der Wahrheit die Buchhaltungsdatenbank des Betreibers bleibt. Dasselbe Engineering-Team führt iOS und Android im Gleichschritt im Rahmen unserer Praxis für iOS- und Android-Engineering.

Termin- und Buchhaltungs-Adapter-Dienste von Unilab — Symfony-Backend, Healthcare-Compliance-Aufstellung für die USA und die EU

Termin-Adapter, Buchhaltungs-Adapter und prüfungssichere Aufstellung

Die Termin- und Buchhaltungs-Adapter tragen das Integrationsgewicht der Plattform. Jeder ist ein dediziertes Symfony-Modul, das zwischen den Patienten-Clients und dem entsprechenden Altsystem sitzt, mobil geformte Anfragen in das native Protokoll des Alt-Backends übersetzt und Gegendruck abfängt, wenn das Altsystem langsam ist. Der Termin-Adapter verwaltet das Connection-Pooling, cacht nicht-mutierende Lesezugriffe in Redis und schreibt einen Audit-Trail jeder Terminänderung, sodass der Betreiber die Aktivität auf Anfrage der Aufsichtsbehörde rekonstruieren kann. Der Buchhaltungs-Adapter tut das Äquivalent für Preis- und Rechnungsdaten, hält die Buchhaltungsdatenbank als einzige Quelle der Wahrheit und stellt den mobilen Clients eine saubere REST-Oberfläche bereit, ohne das Altsystem dem öffentlichen Internet auszusetzen.

Patientendaten leben hinter rollenbasierter Zugriffssteuerung und sind im Ruhezustand mit Schlüsselrotation verschlüsselt. Die Aufstellung ist darauf ausgelegt, die DSGVO-Verpflichtungen für Patienten in der Europäischen Union und die CCPA / CPRA-Verpflichtungen für Patienten in Kalifornien und den übrigen USA zu erfüllen, mit einer HIPAA-fähigen Architektur, die bereit ist, ein Business Associate Agreement aufzusetzen, wenn ein US-Launch-Szenario eines erfordert. Jede Befundzustellung, jede Terminänderung und jede Buchhaltungsabstimmung schreibt in ein unveränderliches Audit-Log, das das nächste Aufsichts-Audit als Dokumentationsaufgabe statt als archäologische Ausgrabung übersteht.

Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.

Liefermethodik

Eine fünfphasige Entwicklung, die Unilab von den Schmerzpunkten des Betreibers bis zur Produktion über iOS, Android, Web und die Integrations-Adapter brachte.

Phase 1

Discovery & Anforderungen

Patient-Journey-Mapping (Anruf-und-Papier-Ausgangslage), Erhebung der Altsystem-Protokolle, Mandantenmodell für mehrere Städte, US- und EU-Healthcare-Datenschutzprüfung (DSGVO, CCPA, HIPAA-fähiges Gerüst).

Phase 2

Backend- & Adapter-Design

Symfony-Backend-Grundgerüst, Spezifikation des Termin-System-Adapters, Spezifikation des Buchhaltungs-System-Adapters, REST-Oberfläche für mobile Clients, unveränderliches Audit-Log-Schema, rollenbasierte Zugriffssteuerung.

Phase 3

Plattform-Entwicklung

Nativer Swift-/SwiftUI-iOS-Client, nativer Kotlin-/Jetpack-Compose-Android-Client, React-Web-Bereich, Katalog mit 2.500 Einträgen und strukturierter Suche, MapKit-Standortfinder.

Phase 4

Healthcare-Härtung

Push-Pipelines über APNs und FCM, verschlüsselte Befundzustellung mit biometrischer Absicherung, Audit-Log-Tests, Prüfung der Rollenberechtigungen, Mehr-Städte-Lasttest bei prognostiziertem Patientenvolumen.

Phase 5

Launch & Telemetrie

Einreichung im App Store + Google Play über US- und EU-Storefronts, Choreografie des Rollouts pro Stadt, On-Call-Runbooks für die Adapter-Dienste, Abstimmung mit der Buchhaltung nach dem Launch.

Buchhaltungsintegration, Abrechnungsabstimmung und die Übergabe an den Betreiber

Das Buchhaltungs-Backend von Unilab war das Arbeitstier des bestehenden Betriebs, und die Patientenplattform wurde gebaut, um es zu verstärken, nicht zu ersetzen. Der Buchhaltungs-Adapter sitzt zwischen den Patienten-Clients und der Buchhaltungsdatenbank, übersetzt mobile Anfragen in das native Protokoll des Buchhaltungssystems und schreibt jede Transaktion in ein unveränderliches Abstimmungs-Log. Die Preisgestaltung für den Katalog mit 2.500 Einträgen liegt beim Buchhaltungssystem; der Adapter cacht Lesezugriffe in Redis mit kurzer TTL, sodass die Patienten-App aktuelle Preise anzeigt, ohne die Altdatenbank zu überlasten. Die Rechnungserstellung läuft auf der Buchhaltungsseite; der Adapter stellt nur eine schreibgeschützte Ansicht bereit, sodass ein Patient eine Quittung abrufen kann, ohne jemals die Buchführungsdaten des Betreibers zu berühren. Das Subsystem wurde mit Blick auf die Übergabe an den Betreiber gebaut: Ein Klinikadministrator öffnet die Betreiberkonsole, sieht die Termine des Tages pro Stadt und kann eingreifen — verschieben, erstatten, Patient kontaktieren — ohne die Plattform zu verlassen. Stadtübergreifende Betreiber können ihre Ansicht nach Region eingrenzen, sodass ein einzelner Administrator während ruhiger Schichten den Betrieb in mehreren Städten abdeckt, ohne den Audit-Trail pro Stadt zu verlieren.

Launch in den USA und der Europäischen Union

Die Unilab-Plattform wurde für Healthcare-Betreiber konzipiert, die Patienten in den USA und der Europäischen Union bedienen. Der englischsprachige Build bedient Patienten in Kalifornien, New York, Texas, Florida und Washington in den USA sowie Patienten in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU, ohne separate Codebasis pro Region. Einwilligungsabläufe sind auf der Client-Ebene regionsbewusst: Patienten in der EU und im EWR erhalten einen DSGVO-artigen granularen Einwilligungsbildschirm mit separaten Schaltern für Befundzustellkanäle und optionale Produktanalysen; Patienten in Kalifornien erhalten im selben Ablauf eine CCPA-artige Offenlegung „Do Not Sell or Share My Personal Information". Die Datenverarbeitungspraktiken sind an der DSGVO für europäische Patienten und am Flickenteppich der US-Bundesstaaten-Datenschutzgesetze ausgerichtet — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA. Die HIPAA-fähige Architektur bietet ein Gerüst für ein Business-Associate-Agreement-Szenario, auch wenn HIPAA nur gilt, wenn der Betreiber nach US-Recht ein Covered Entity ist.

Das Backend-Deployment läuft parallel über EU- und US-Regionen — Niederlande, Deutschland, Frankreich, Schweden und Irland für die EU-Abdeckung; US East und US West für Nordamerika — mit identisch über Terraform bereitgestellten Symfony-Diensten und PostgreSQL-Instanzen. Der Patientendatenspeicher und das Audit-Log können für künftige Datenstandort-Verpflichtungen entweder an US- oder EU-Regionen gebunden werden, und die Adapter-Dienste sind zustandslos, sodass sie pro Region unabhängig skaliert werden können. Sowohl die Altersfreigabe im App Store als auch die Inhaltsfreigabe bei Google Play wurden für eine Healthcare-App kalibriert, und die In-App-Datenschutzerklärung wurde so verfasst, dass sie genau die obige Architektur dokumentiert und direkt auf die DSGVO-Verpflichtungen und die kalifornischen CCPA-Verpflichtungen verweist. Das Engineering-Team hinter der Entwicklung arbeitet einen MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, die Choreografie der Store-Prüfung und die On-Call-Reaktion.

Tech-Stack und Roadmap

Swift SwiftUI MapKit LocalAuthentication Kotlin Jetpack Compose BiometricPrompt React PHP Symfony PostgreSQL Redis APNs Firebase Cloud Messaging REST API Docker Terraform Prometheus Grafana

Die aktive Roadmap für die individuelle Softwareentwicklung von Unilab umfasst eine Telehealth-Videoberatungsstufe, eine tiefere Integration mit dem Buchhaltungssystem des Betreibers für die direkte Übergabe von Versicherungsansprüchen, ein Portal pro Arzt für Partnerkliniken sowie eine JSON-LD-Ebene für strukturierte Befunde, sodass Patientenbefunde in Gesundheitsakten von Drittanbietern sauber dargestellt werden. Eine B2B-Stufe mit Bring-your-own-Domain, Teamverwaltung und SSO ist für US- und EU-Corporate-Health-Programme geplant. Die Infrastrukturpläne umfassen weiteres Sharding pro Stadt, ein internes Harness für kontinuierliche Verifizierung der Audit-Log-Invarianten sowie eine künftige unabhängige Bereitschaftsbewertung, eingebettet in die Cloud-&-DevOps-Roadmap.

Eine Healthcare-Patientenplattform wie diese entwickeln — sprechen Sie mit uns

Wenn Sie eine Diagnostik-Patientenplattform, eine Healthcare-App für mehrere Städte oder ein beliebiges mobiles Produkt planen, bei dem die Integrationsgeschichte mit bestehenden Termin- und Buchhaltungs-Backends einer Aufsichtsprüfung für Zielgruppen in den USA und der EU standhalten muss, haben wir diesen Stack durchgängig ausgeliefert und können den Entwicklungszeitplan deutlich verkürzen. Der live geschaltete iOS-Client ist im Apple App Store auf iOS und Android verfügbar, und das Engineering-Team dahinter sitzt innerhalb der YuSMP Group. Wir arbeiten zum Festpreis für gut abgegrenzte MVPs und mit dedizierten Entwicklerteams für die laufende Lieferung, mit einem MEZ-Arbeitstag und einem garantierten Überlappungsfenster mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und die Reaktion auf Störungen.

Discovery-Call buchen Mobile-Entwicklungsleistungen ansehen

Häufig gestellte Fragen

Wie viel kostet die Entwicklung einer Labor-Patienten-App auf iOS und Android mit Terminintegration?

Ein fokussiertes MVP mit nativen iOS- und Android-Patienten-Clients, einem persönlichen Web-Bereich, Terminbuchung, digitalen Befunden und einem Adapter für das Terminsystem kostet in der Regel 160.000–320.000 $. Mit einem Testkatalog von 2.500 Einträgen mit strukturierter Suche, einer interaktiven Standortkarte, Push-Benachrichtigungen, Integration des Buchhaltungssystems, Unterstützung mehrerer Städte und prüfungssicherer Healthcare-Protokollierung erreicht eine vollständige Plattform 360.000–700.000 $. Die dominierenden Kostentreiber sind der Adapter für das Alt-Terminsystem, die Buchhaltungsintegration und die plattformspezifischen Push-Pipelines über Apple Push Notification service und Firebase Cloud Messaging.

Warum natives iOS und Android statt Flutter für eine Healthcare-Patienten-App?

Healthcare-Patienten-Apps sind auf plattformspezifische Push-Zuverlässigkeit, Background-Fetch-Verhalten und biometrische Authentifizierungs-Primitive angewiesen, die nativ schneller ausreifen als in Flutter-Wrappern. Natives Kotlin und Swift stellen APNs und FCM, Face ID und biometrische Abfragen sowie Background-URL-Session- und WorkManager-Primitive direkt bereit, sodass Terminerinnerungen, Befund-bereit-Benachrichtigungen und stille Aktualisierungen über Samsung, Xiaomi, OnePlus, Pixel und iPhone hinweg zuverlässig ankommen. Flutter eignet sich hervorragend für formularlastige Apps, fügt aber eine Brücke zwischen Dart und den plattformeigenen Push- und Biometrie-Schichten hinzu, die sich Healthcare-Apps nicht leisten können.

Wie integriert man eine Patienten-App mit einem Alt-Terminsystem im Labor?

Die meisten Labor-Terminsysteme sind nicht internetfähig und wurden nicht für mobilen Datenverkehr entworfen. Die Integration sitzt hinter einem dedizierten Adapter-Dienst — einem Symfony-Modul, das Anfragen der Patienten-App in das native Protokoll des Terminsystems übersetzt, das Connection-Pooling verwaltet und Gegendruck abfängt, wenn das Altsystem langsam ist. Der Adapter cacht nicht-mutierende Lesezugriffe in Redis, stellt den mobilen Clients eine saubere REST-Oberfläche bereit und schreibt einen Audit-Trail jeder Terminänderung, sodass der Betreiber die Aktivität über US- und EU-Compliance-Audits hinweg rekonstruieren kann.

Wie skaliert man eine Labor-Patientenplattform auf Dutzende Städte?

Die Skalierung über mehrere Städte ist zunächst ein Datenmodellproblem, bevor sie ein Infrastrukturproblem ist. Standorte, Terminfenster, Testmenüs und Preise existieren als erstklassige Mandanten der Plattform — jede Stadt ist unabhängig konfigurierbar, und die Patienten-App liest nur den Katalog und die Standortkarte, die für den Standort des Nutzers relevant sind. Das Backend betreibt zustandslose Worker hinter einem stadtbewussten Router, sodass das Hinzufügen einer neuen Stadt eine Konfigurationsänderung am Mandantenspeicher statt eines Code-Releases ist, und die Caching-Schicht von Symfony verhindert, dass Katalog-Lesezugriffe eine einzelne Datenbank überlasten.

Wie lange dauert es, eine Labor-Patientenplattform mit iOS, Android und Web auszuliefern?

Ein fokussiertes MVP mit nativen iOS- und Android-Clients, einem persönlichen Web-Bereich, Terminbuchung, digitalen Befunden und einem Adapter für das Terminsystem dauert in der Regel 14–22 Wochen. Ein Testkatalog von 2.500 Einträgen, eine interaktive Standortkarte, Push-Pipelines, Buchhaltungsintegration und Mehr-Städte-Mandantenfähigkeit kommen mit 8–14 Wochen hinzu. Die Arbeit am Alt-Adapter wird häufig unterschätzt und sollte mit 4–6 Wochen dedizierten Aufwands eingeplant werden, da Terminsystem-Protokolle je nach Labornetzwerk variieren und beim ersten Durchgang selten zum Datenmodell der Patienten-App passen.

Diese Fallstudie teilen

LinkedIn X

Ein ähnliches Projekt planen

Discovery-Call buchen