Die meisten Teams, die ein Gesundheitsprodukt entwickeln, haben in wenigen Monaten eine funktionierende, schicke App. Dann nehmen sie Labortests dazu – und die Roadmap verliert still und leise zwei Quartale. Nicht, weil der Code kompliziert ist, sondern weil eine Laborintegration niemals nur eine Integration ist. Es geht um Auftragsrouting, Begleitscheine, Kit-Logistik, Kurierzeiten, Barcode-Abgleich, Ergebnis-Parsing, Einheitenumrechnung, Referenzbereiche, eine Ansicht für den Patienten für das alles und einen Compliance-Stack, den ein Anwalt absegnen muss, bevor sich auch nur eine Probe bewegt.
Diagnostics as a Service nimmt dir diese Arbeit ab – ähnlich wie Zahlungsdienstleister das Acquiring, das Gateway und die Terminal-Lieferanten aus dem Checkout-Prozess herausgenommen haben. Hier erfährst du, was das Modell beinhaltet, wie die Integration aussieht, wie es im Vergleich zu einer Eigenentwicklung abschneidet und was du einen Anbieter fragen solltest, bevor du dich festlegst.
Was bedeutet Diagnostics as a Service für ein Produktteam?
Diagnostics as a Service, kurz DaaS, bedeutet, Labortests über eine API zu bestellen und strukturierte Ergebnisse zu erhalten, während ein einzelner Anbieter die Labore, Kits, Logistik und den regulatorischen Rahmen im Hintergrund regelt. Dein Produkt entscheidet, wer getestet wird und was mit dem Ergebnis passiert. Alles zwischen Bestellung und Ergebnis ist das operationelle Problem von jemand anderem.
Der naheliegendste Vergleich ist Stripe – und der hält besser als die meisten Analogien. Stripe hat das Bezahlen per Karte nicht erfunden, aber es hat ein Projekt mit fünf Anbietern in eine API und ein Dashboard komprimiert. Eine Diagnostik-Plattform macht genau dasselbe mit einem Setup, das sonst aus Labor, Kit-Lieferant, Kurier, Parser und Datenschutzvereinbarungen pro Partei besteht. Du kaufst kein Labor. Du kaufst das Ende eines Integrationsprojekts.
Eine Sache sollte man genau nehmen, denn sie entscheidet darüber, wie du Anbieter bewertest: Eine DaaS-Plattform ist in der Regel nicht das Labor. Sie koordiniert akkreditierte Labore. Die Akkreditierung liegt bei demjenigen, der die Analyse durchführt, während API, Katalog, Logistik und Compliance-Papierkram zur Plattform gehören.
Warum dauert eine Laborintegration länger als gedacht?
Die Schätzung basiert meist auf dem Schnittstellendokument des Labors, das ein Datenformat beschreibt. Die echte Arbeit steckt jedoch überall sonst. Sechs Dinge machen den Großteil der Verzögerung aus.
Multipliziere das Ganze dann mit der Anzahl der Labore. Denn das Labor, das Routinediagnostik günstig durchführt, ist selten dasselbe, das deine Sequenzierung, Proteomik oder Mikrobiom-Panels macht. Jedes weitere Analyseverfahren bedeutet eine weitere Schnittstelle, einen weiteren Vertrag und ein weiteres Format.
Wie sieht die Integration mit einer DaaS-API aus?
Kurz, wenn die Plattform ihren Job macht. Mit der Aniva-API sind es von einem neuen Nutzer zum Ergebnis vier Aufrufe – und nur bei den ersten drei triffst du eine Entscheidung.
Der API-Aufruf zum Erstellen eines Termins im Detail, damit du siehst, wie er aufgebaut ist:
# Schedule a blood draw appointment for a profile
curl -X POST https://anivahealth.com/api/v1/appointments \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"profile_id": "a3f1c2d4-8b7e-4f2a-9c1d-2e3f4a5b6c7d",
"location_id": "b7e2d1f5-3c4a-4e8b-a2f1-9d0c1e2f3a4b",
"scheduled_at": "2026-05-15T12:30:00+02:00"
}'
# -> 201 Created
{ "id": "c9f3e2a1-...-1f0e9d8c7b6a",
"status": "confirmed" }
Das Interessante ist das, was auf dieser Liste fehlt: Keine Kit-Logistik, keine Kurierplanung, keine Barcode-Verwaltung, kein HL7-Parser, keine Einheitentabelle, keine laborspezifische Referenzdatenbank und kein separater Vertrag für jede Fachrichtung. All das existiert zwar, befindet sich aber einfach auf der anderen Seite der API.
Wie schlägt sich eine DaaS-API im Vergleich zum Eigenbau?
Drei Ansätze sind sinnvoll, und der ehrliche Vergleich hängt davon ab, ob Diagnostik dein eigentliches Produkt ist oder nur ein Baustein dafür.
Etwas komplett selbst zu bauen ist dann sinnvoll, wenn die Laborpartnerschaft, das Panel-Design oder die Auswertung selbst dein Alleinstellungsmerkmal sind und du das Volumen hast, um einen internen Service mit fester Zuständigkeit zu rechtfertigen. Direkte Laborintegrationen nacheinander machen Stückpreise sichtbar und funktionieren, wenn du genau ein Panel in genau einem Markt anbietest. Eine DaaS-API tauscht etwas Preiskontrolle gegen eine einzige Integration, einen Vertrag und einen Start in wenigen Wochen.
Drei Wege, um ein Gesundheitsprodukt um Labordiagnostik zu erweitern – im Vergleich
| Kriterium |
Diagnostics as a Service API |
Eigenbau |
Direkte Laborschnittstellen |
| Zeit bis zur ersten Live-Bestellung |
Tage für Sandbox, Wochen bis zur Produktion |
Sechs bis zwölf Monate Entwicklung vor dem ersten Ergebnis |
Zwei bis vier Monate pro Labor, dann von vorn |
| Wogegen du integrierst |
Eine REST-API und eine Dokumentation |
Dein eigener Dienst plus jede nachgeschaltete Schnittstelle |
Eine Schnittstelle pro Labor, jeweils mit einem eigenen Format |
| Ergebnisdaten |
Strukturiertes JSON mit Einheiten und Referenzbereichen |
Alles, was du selbst parsest und normalisierst |
HL7, CSV, PDF oder Fax, je nach Labor |
| Probenlogistik |
Kits, Kuriere und Rücksendungen werden von der Plattform übernommen |
Eigene Kit-Beschaffung, Kurierverträge und Sendungsverfolgung |
Normalerweise nicht enthalten, muss separat geregelt werden |
| Katalogumfang |
Von Routineuntersuchungen bis hin zu Genomik und Multi-Omics in einem Paket |
Begrenzt durch deine Laborpartnerschaften |
Nur breit aufgestellt, wenn du mehrere Speziallabore anbindest |
| Compliance-Paket |
Auftragsverarbeitung, EU-Hosting und Laborakkreditierung über Partner |
Musst du selbst zusammenstellen und verantworten |
Ein Vertrag pro Labor, von dir zusammengestellt |
| Tests vor dem Start |
Eine Testumgebung mit realen Daten |
Alles, was du simulieren kannst |
Selten verfügbar, oft nur echte Aufträge |
| Technischer Aufwand |
Nur eine Schnittstelle zu pflegen |
Ein permanenter interner Dienst mit einem zuständigen Ansprechpartner |
Eine Schnittstelle pro Labor plus Formatänderungen |
| Bereich für Patienten |
Eigenes Dashboard und PDF verfügbar oder nutze deine eigene Benutzeroberfläche |
Selbst entwickeln, worauf es oft ankommt |
Nicht enthalten |
| Beste Wahl |
Produktteams, die Diagnostik als Funktion und nicht als Geschäft anbieten |
Unternehmen, deren Kernprodukt das Labor selbst ist |
Produkte für einen Markt mit einem einzigen Panel |
Die versteckten Kosten in der mittleren Spalte liegen nicht in der Entwicklung, sondern in der Pflege. Eine Diagnostikschnittstelle ist ein lebendiges System: Labore ändern Formate, Panels erhalten neue Namen, Kuriere wechseln ihre Zeiten und Gesetze ändern sich. Jemand in deinem Team kümmert sich darum für immer, und das ist selten die Arbeit, für die sie eingestellt wurden.
Was steckt in einem DaaS-Stack?
Wenn ein Anbieter behauptet, Diagnostik komplett abzudecken, muss dies alles enthalten sein. Prüfe jedes Angebot anhand dieser Liste, denn Lücken landen in deinem Backlog.
Welche Produkte nutzen eigentlich Diagnostics as a Service?
Das Muster ist klar. DaaS lohnt sich dort, wo ein Testergebnis den Rest des Produkts freischaltet und niemand im Team die Beziehung zum Kurierdienst betreuen möchte.
Wenn dein Produkt das Labor ist oder die Analysemethode dein Patent, ist dieses Modell nichts für dich. Alle anderen kaufen Infrastruktur.
Was muss der EU-Compliance-Stack abdecken?
Für ein Produkt in Deutschland oder der EU entscheiden fünf Dinge darüber, ob eine Schnittstelle startklar ist. Ein Anbieter sollte alle fünf sofort beantworten können.
Zehn Fragen vor der Anbindung an einen Anbieter
Wo Aniva ins Bild passt
Aniva ist eine Diagnostics-as-a-Service-Plattform für europäische Health-Produkte. Über eine einzige REST-API erreichst du mehr als 2.500 Parameter – von Routinelaboren über Hormone, Vitamine und Immunologie bis hin zu Genom- und Exomsequenzierung, Transkriptomik, Proteomik und Mikrobiom-Analysen. Die Ergebnisse kommen als strukturiertes JSON zurück, es gibt eine Sandbox zum Testen und die API-Dokumentation ist öffentlich.
Im Hintergrund laufen die Standard- und Spezialbluttests bei ZOTZ|KLIMAS, das die RiliBÄK- und ISO 15189-Zulassungen besitzt, während Spezialpartner die Multi-Omics-Methoden abdecken. Blut-Core-Panels liegen innerhalb von 24 Stunden nach der Abholung vor. Die Datenverarbeitung erfolgt in der EU und wird in Deutschland gehostet. Die Auftragsverarbeitung ist Teil des Standard-Onboardings und erfordert keine Verhandlungen. Das Dashboard und das PDF für Patienten können in deinem Branding erscheinen oder du nutzt deine eigene Benutzeroberfläche.
Wenn du das Modell eher aus der Perspektive einer Klinik als aus der eines Entwicklerteams betrachten möchtest, befasst sich der Begleitartikel mit Diagnostics as a Service für Kliniken, einschließlich der Fragen zur Beschaffung und des Kostenvergleichs. Wenn du lieber nur die Endpunkte lesen möchtest, fang mit Aniva für Entwickler an und fordere einen Sandbox-Schlüssel an.
Das Fazit
Diagnostik ist oft der unspannendste Teil in Health-Tech und wird am leichtesten unterschätzt. Während die Schnittstelle nur ein Datenformat beschreibt, stecken dahinter physische Proben, Ausnahmefälle und Compliance. Diagnostics as a Service packt diesen Aufwand hinter eine API – genau dann sinnvoll, wenn das Testergebnis ein Baustein für dein Produkt ist und nicht das Produkt selbst.
Der Test eines Anbieters ist nicht die Marketingseite, sondern ob du die Doks lesen, einen Sandbox-Schlüssel bekommen, Fehlerfälle mit realistischen Daten testen und den Vertrag prüfen kannst. Wenn all das in einer Woche klappt, ist die Integration so kurz wie versprochen.
Häufig gestellte Fragen
Was ist Diagnostics as a Service?
Diagnostics as a Service ist ein Modell, bei dem ein Produkt Labortests über eine einzige API bestellt und strukturierte Ergebnisse zurückerhält, während der Anbieter im Hintergrund die Labore, die Proben-Kits, die Kurierlogistik und den regulatorischen Rahmen betreibt. Es ersetzt einen Tech-Stack, der sonst für jede einzelne Partei einen Laborvertrag, einen Kit-Lieferanten, einen Kurier, einen Parser für die Ergebnisse und eine separate Vereinbarung zur Datenverarbeitung erfordern würde.
Wie lange dauert eine Diagnostik-API-Integration?
Mit einer dokumentierten REST-API und einer Sandbox sind es nur Tage bis zum ersten Testauftrag und Wochen bis zum Livegang. Denn die Arbeit beschränkt sich auf deinen eigenen Bestellprozess, die Darstellung der Ergebnisse und die Fehlerbehandlung. Dieselbe Funktion intern für einzelne Labore aufzubauen, ist meist ein Projekt über mehrere Quartale – und jedes weitere Lab oder Analyse-Verfahren wiederholt einen Großteil davon.
Ist eine Diagnostikplattform dasselbe wie ein Labor?
Meistens nicht. Die meisten Plattformen koordinieren akkreditierte Labore, statt selbst eines zu besitzen. Qualitätsstandards wie RiliBÄK und ISO 15189 liegen beim Labor, während API, Katalog, Logistik und Compliance bei der Plattform liegen.
Wie sehen Laborergebnisse aus einer API aus?
Die einzig sinnvolle Antwort ist strukturiertes JSON mit einer Biomarker-ID, einem Wert, einer Einheit und dem Referenzbereich des analysierenden Labors. Denn Bereiche sind laborspezifisch und hängen von Faktoren wie Alter und Geschlecht ab. Ein PDF sollte für den Endnutzer da sein, nicht als Format, das dein Code auslesen muss. Fordere einen echten Testdatensatz an, bevor du dein Datenmodell entwirfst.
Kann ich die Patientenerfahrung an meine Marke anpassen?
Ja, bei den meisten Angeboten – auch wenn die Tiefe variiert. Achte auf dein Logo und deine Farben im Patientendashboard, dein Branding auf dem Ergebnis-PDF, eine eigene Subdomain und deine Absenderadresse bei E-Mails an Patienten. Wenn du die Benutzeroberfläche lieber selbst bauen möchtest, prüfe, ob die API alles bereitstellt, was das Dashboard des Anbieters zeigt.
Ist mein Produkt ein Medizinprodukt, wenn es Laborwerte anzeigt?
Die Anzeige von Ergebnissen mit Referenzbereichen und leicht verständlichem Kontext ist in der Regel so gestaltet, dass sie nicht unter MDR, IVDR und MPDG fällt, solange die Interpretation bei Ärztinnen und Ärzten bleibt. Risikobewertungen, Diagnosen oder Behandlungsempfehlungen verändern diese Analyse jedoch, und die Klassifizierung deines Produkts liegt in deiner Verantwortung, nicht bei der Plattform. Hol dir die dokumentierte Position des Anbieters schriftlich und lass dich für alles, was du darauf aufbaust, rechtlich beraten.
Wo werden Patientendaten in einem DaaS-Setup gespeichert?
Das hängt ganz vom Anbieter ab – deshalb gehört das ins erste technische Gespräch. Frag nach dem physischen Hosting der Daten, welche Unterauftragsverarbeiter auf die Patientendaten zugreifen, ob welche davon außerhalb des EWR sitzen und ob der Auftragsverarbeitungsvertrag diese mit einem festgelegten Änderungsprozess aufführt. Für ein Produkt, das in Deutschland läuft, ist EU-Hosting das Ziel.
Kann Diagnostics as a Service auch Probenahmen zu Hause abwickeln?
Ja. Per Post versendete Kits mit Rücksende-Etikett, Kapillarblut aus dem Finger, Speichel, Stuhl und Urin gehören neben venösen Blutabnahmen an Partnerstandorten standardmäßig zu einem DaaS-Katalog. Die entscheidende Frage für deine Entwicklung ist, ob alle Probenarten denselben Bestellprozess, Statusmodell und Ergebnisformat nutzen oder ob jede im Code eine Sonderlocke ist.
Begriffe schnell erklärt
Quellen
Sandbox-Schlüssel anfordern
Mit Aniva bekommt dein Team eine einzige REST-API für über 2.500 Parameter, strukturierte JSON-Ergebnisse, eine Sandbox und öffentliche Dokumentation – inklusive Laboren, Kits, Kurieren und EU-Compliance im Hintergrund. Starte mit Aniva for Developers, lies die API-Dokumentation und fordere einen Key an, um Fehlerfälle mit echten Payloads zu testen.
Dieser Artikel dient Produkt- und Tech-Teams als allgemeine Information über den Aufbau von Diagnostik-Infrastruktur. Er ist keine medizinische oder rechtliche Beratung. Laborakkreditierungen und Referenzbereiche gehören zum ausführenden Labor, und die Auswertung von Ergebnissen obliegt dem behandelnden Arzt.
