Die meisten Teams, die ein Gesundheitsprojekt entwickeln, haben nach ein paar Monaten eine ausgefeilte, funktionierende App. Dann fügen sie Labortests hinzu, und plötzlich verliert die Roadmap zwei Quartale. Nicht, weil der Code so kompliziert ist, sondern weil eine Laborintegration eben nie nur eine Integration ist. Es geht um Auftragsrouting, Begleitscheine, Kit-Versand, Kurierzeiten, Barcode-Abgleich, Ergebnisaufbereitung, Einheitenumrechnung, Referenzbereiche, eine patientenfreundliche Ansicht von alledem und eine Compliance-Struktur im Hintergrund, die ein Anwalt absegnen muss, bevor sich auch nur eine Probe bewegt.
Diagnostics as a Service ist die Ebene, die dir diese Arbeit abnimmt – ganz ähnlich wie Zahlungsdienstleister den Acquirer, das Gateway und den Terminal-Anbieter aus dem typischen Checkout-Projekt entfernt haben. Dieser Artikel zeigt, was das Modell beinhaltet, wie die Integration konkret aussieht, wie es im Vergleich zur 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 (oder kurz DaaS) bedeutet, Labortests über eine API zu bestellen und strukturierte Ergebnisse zu erhalten, während ein einziger Anbieter im Hintergrund die Labore, Kits, Logistik und den regulatorischen Rahmen verwaltet. Dein Produkt entscheidet, wer getestet wird und was mit den Ergebnissen passiert. Alles zwischen Bestellung und Ergebnis ist das operative Problem von jemand anderem.
Der naheliegende Vergleich ist Stripe, und der hält besser als die meisten Analogien. Stripe hat Kartenzahlungen nicht erfunden, sondern ein Projekt mit fünf Anbietern in eine einzige API und ein Dashboard verwandelt. Eine Diagnoseplattform macht genau dasselbe mit einer Architektur, die sonst aus einem Labor, einem Kit-Lieferanten, einem Kurier, einem Ergebnis-Parser und einem Datenschutzvertrag pro Partei besteht. Du kaufst kein Labor. Du kaufst dir die Vermeidung eines Integrationsprojekts.
Eine Sache sollte man genau wissen, da sie bestimmt, wie du Anbieter bewertest: Eine DaaS-Plattform ist in der Regel nicht das Labor selbst, sondern 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 von allen geschätzt?
Die Schätzung basiert meist auf dem Schnittstellendokument des Labors, das ein Datenformat beschreibt. Die eigentliche Arbeit steckt jedoch überall sonst. Sechs Dinge sind für die meiste Verzögerung verantwortlich.
Multipliziere das Ganze mit der Anzahl der Labore – denn das Labor, das die klinische Chemie günstig durchführt, ist selten dasselbe, das deine Sequenzierung, Proteomik oder Mikrobiom-Analysen macht. Jede weitere Methode 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 API von Aniva führt der Weg von einem neuen Nutzer zum Ergebnis über vier Aufrufe, und nur bei den ersten drei triffst du eine Entscheidung.
Der Erstellen-Termin-Aufruf in voller Länge, damit du den Aufbau siehst:
# 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, was auf dieser Liste fehlt. Keine Kit-Logistik, keine Kurierplanung, keine Barcode-Verwaltung, kein HL7-Parser, keine Einheitentabelle, keine laborbezogene Referenzwert-Datenbank und kein separater Vertrag für jede Fachrichtung. All das gibt es zwar, aber es befindet sich einfach auf der anderen Seite der API.
Wie schlägt sich eine DaaS-API im Vergleich zum Eigenbau?
Drei Ansätze sind machbar. Ein fairer Vergleich hängt davon ab, ob die Diagnostik dein eigentliches Produkt ist oder nur ein Baustein dafür.
Alles selbst zu entwickeln macht Sinn, wenn die Laborbeziehung, das Panel-Design oder die Analyse dein Alleinstellungsmerkmal sind und du genug Volumen hast, um ein internes Team zu rechtfertigen. Labore einzeln direkt anzubinden hält die Stückpreise im Blick und funktioniert, wenn du genau ein Panel in einem Markt anbietest. Eine DaaS-API tauscht etwas Preiskontrolle gegen eine einzige Integration, einen Vertrag und einen Start in wenigen Wochen.
Drei Wege zur Integration von Labordiagnostik im Vergleich
| Kriterium |
Diagnostics-as-a-Service-API |
Eigenbau |
Direkte Labor-Integrationen |
| Zeit bis zur ersten Live-Bestellung |
Tage für eine Testumgebung, Wochen bis zur Live-Schaltung |
Sechs bis zwölf Monate Entwicklungszeit vor dem ersten Ergebnis |
Zwei bis vier Monate pro Labor, dann von vorn |
| Wogegen du integrierst |
Eine REST-API und ein Satz Dokumentation |
Dein eigener Dienst plus jede nachgelagerte 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 nach Hause werden von der Plattform übernommen |
Deine eigene Kit-Beschaffung, Kurierverträge und Sendungsverfolgung |
Normalerweise nicht enthalten, separat zu organisieren |
| Katalogbreite |
Von Routineuntersuchungen bis hin zu Genomik und Multi-Omik in einem Paket |
Begrenzt durch deine Laborpartnerschaften |
Nur dann breit gefächert, wenn du mehrere Speziallabore unter Vertrag nimmst |
| Compliance-Struktur |
Auftragsverarbeitung, EU-Hosting und Laborakkreditierung über Partner |
Von dir zusammenzustellen und zu verantworten |
Eine Vereinbarung pro Labor, von dir organisiert |
| Tests vor dem Launch |
Eine Testumgebung mit realistischen Daten |
Alles, was du simulieren kannst |
Selten verfügbar, oft nur Live-Bestellungen |
| Wartungsaufwand |
Eine zu wartende Schnittstelle |
Ein permanenter interner Dienst mit zuständigem Ansprechpartner |
Eine Schnittstelle pro Labor plus Formatänderungen |
| Benutzeroberfläche für Patienten |
Gebrandetes Dashboard und PDF verfügbar oder eigenes Design |
Eigenbau, was oft der Sinn der Sache ist |
Nicht enthalten |
| Beste Passform |
Produktteams, die Diagnostik als Feature und nicht als Geschäft anbieten |
Unternehmen, deren Kernprodukt das Labor selbst ist |
Produkte für einen Markt mit einem einzigen, schmalen Panel |
Die versteckten Kosten in der mittleren Spalte liegen nicht in der Entwicklung, sondern in der Wartung. Eine Diagnostik-Schnittstelle ist ein lebendes System: Labore ändern Formate, Panels erhalten neue Namen, Kurierdienste wechseln Zeitfenster und Vorschriften ändern sich. Irgendjemand in deinem Team kümmert sich darum – und das ist selten die Arbeit, für die diese Person eingestellt wurde.
Was steckt in einem DaaS-Stack?
Wenn ein Anbieter verspricht, die Diagnostik von A bis Z abzudecken, muss dies alles enthalten sein. Prüfe jedes Angebot anhand dieser Liste, denn die Lücken landen in deinem Backlog.
Welche Produkte nutzen eigentlich Diagnostics as a Service?
Das Muster ist konsistent. DaaS lohnt sich überall dort, wo ein Testergebnis den Rest des Produkts freischaltet und niemand im Team Lust auf eine eigene Kurierkoordination hat.
Wenn dein Produkt das Labor ist oder die Analysemethode dein Patent darstellt, ist dieses Modell nichts für dich. Alle anderen kaufen Infrastruktur.
Was muss der EU-Compliance-Stack abdecken?
Für ein Produkt, das in Deutschland oder der restlichen EU aktiv ist, entscheiden fünf Dinge darüber, ob eine Integration gestartet werden kann. Ein Anbieter sollte alle fünf beantworten können, ohne erst nachschauen zu müssen.
Zehn Fragen, die du einem Anbieter stellen solltest, bevor du darauf aufbaust
Wo Aniva ins Spiel kommt
Aniva ist eine Diagnostics-as-a-Service-Plattform, die für europäische Gesundheitsprodukte entwickelt wurde. Eine REST-API bietet Zugriff auf über 2.500 Parameter – von Standard-Blutwerten über Hormone, Vitamine und Immunologie bis hin zu Ganzgenom- und Exomsequenzierung, Transkriptomik, Proteomik und Mikrobiomanalyse. Ergebnisse kommen als strukturiertes JSON zurück, es gibt eine Sandbox zum Testen und die API-Dokumentation ist öffentlich.
Im Hintergrund werden die Routine- und Spezialblutuntersuchungen bei ZOTZ|KLIMAS durchgeführt, das die RiliBÄK- und ISO 15189-Zertifizierung hält, während für die Multi-Omics-Verfahren Spezialpartner im Hintergrund stehen. Standard-Blutbilder liegen innerhalb von 24 Stunden nach der Abholung vor. Die Datenverarbeitung erfolgt EU-nativ und wird in Deutschland gehostet. Der Auftragsverarbeitungsvertrag ist Teil des Standard-Onboardings und erfordert keine Verhandlungen. Das Dashboard für Patienten und das PDF können deine Marke tragen – du kannst sie aber auch überspringen und die Ergebnisse in deiner eigenen Benutzeroberfläche anzeigen.
Wenn du das Modell aus der Perspektive des Einkäufers einer Klinik statt eines Entwicklerteams betrachten möchtest, behandelt der Begleitartikel Diagnostics as a Service für Kliniken, einschließlich der Beschaffungsfragen und des Kostenvergleichs. Wenn du lieber direkt die Endpunkte lesen möchtest, starte mit Aniva für Entwickler und fordere einen Sandbox-Schlüssel an.
Unterm Strich
Die Diagnostik ist die am wenigsten glamouröse Integration in der Gesundheitstechnologie und eine der am leichtesten zu unterschätzenden, da das Schnittstellendokument ein Datenformat beschreibt, während die eigentliche Arbeit aus physischen Proben, Ausnahmewegen und Compliance besteht. Diagnostics as a Service verlagert diese Arbeit hinter eine API. Das lohnt sich immer dann, wenn das Testergebnis ein Input für dein Produkt ist und nicht das Produkt selbst.
Der Prüfstein für einen Anbieter ist nicht die Marketingseite, sondern ob du die Dokumentation lesen, einen Sandbox-Schlüssel erhalten, die Fehlerfälle mit realistischen Daten durchspielen und den Auftragsverarbeitungsvertrag von deinem Anwalt prüfen lassen kannst, bevor du dich festlegst. Wenn all das innerhalb einer Woche möglich ist, ist die Integration wahrscheinlich so unkompliziert, wie sie aussieht.
Häufig gestellte Fragen
Was ist Diagnostics as a Service?
Diagnostics as a Service ist ein Modell, bei dem ein Produkt Laboruntersuchungen über eine einzige API bestellt und strukturierte Ergebnisse zurückerhält, während der Anbieter die Labore, die Proben-Kets, die Kurierlogistik und den regulatorischen Rahmen hinter dieser API betreibt. Es ersetzt einen Tech-Stack, für den du sonst einen Laborkontrakt, einen Kit-Lieferanten, einen Kurier, einen PDF-Parser und für jede Partei einen eigenen Datenverarbeitungsvertrag bräuchtest.
Wie lange dauert eine Diagnostik-API-Integration?
Dank einer dokumentierten REST-API und einer Sandbox sind wenige Tage bis zur ersten Testbestellung und wenige Wochen bis zum Live-Start realistisch. Denn die Arbeit beschränkt sich auf deinen eigenen Bestellprozess, die Darstellung der Ergebnisse und die Fehlerbehandlung. Dieselbe Funktion intern für einzelne Labore zu entwickeln, ist meist ein Projekt über mehrere Quartale – und jedes weitere Labor oder Testverfahren wiederholt einen großen Teil davon.
Ist eine Diagnostik-Plattform dasselbe wie ein Labor?
Normalerweise nicht. Die meisten Plattformen orchestrieren akkreditierte Labore, anstatt selbst eines zu besitzen. Die Qualitätsakkreditierung wie RiliBÄK und ISO 15189 liegt beim analysierenden Labor, während API, Katalog, Logistik und Compliance-Framework bei der Plattform liegen. Bitte jeden Anbieter, die Labore hinter seinem Katalog zu nennen und anzugeben, wofür sie jeweils akkreditiert sind.
Wie sehen Laborergebnisse aus, die über eine API ausgegeben werden?
Die einzig sinnvolle Antwort ist strukturiertes JSON mit Marker-ID, Wert, Einheit und dem vom analysierenden Labor angewendeten Referenzbereich – denn Bereiche sind laborspezifisch und hängen von Faktoren wie Alter und Geschlecht ab. Ein PDF sollte etwas sein, das du an den Nutzer weitergibst, aber nicht das Format, das dein Code parsen muss. Fordere einen echten Beispieldatensatz an, bevor du dein Datenmodell entwirfst.
Kann ich die Benutzeroberfläche für Patienten unter meiner eigenen Marke anbieten?
Ja, bei den meisten Angeboten ist das der Fall, auch wenn der Umfang variiert. Achte auf dein Logo und deine Farben im Patienten-Dashboard, dein Branding auf dem Ergebnis-PDF, eine eigene Subdomain und deine Absenderadresse in E-Mails an Patienten. Wenn du die Benutzeroberfläche lieber selbst bauen möchtest, prüfe, ob die API alles bietet, was das Dashboard des Anbieters zeigt.
Ist mein Produkt ein Medizinprodukt, wenn es Laborergebnisse anzeigt?
Die Anzeige von Ergebnissen mit Referenzbereichen und einfachen Erklärungen ist normalerweise so konzipiert, dass sie nicht unter MDR, IVDR und MPDG fällt, wobei die Interpretation bei einem Arzt verbleibt. Das Hinzufügen von Risikobewertungen, Diagnosen oder Behandlungsempfehlungen ändert diese Einschätzung, und die Klassifizierung deines Produkts liegt in deiner Verantwortung und nicht beim Anbieter. Hole dir die dokumentierte Position des Anbieters schriftlich ein und lass dich zu allem, was du darauf aufbaust, regulatorisch beraten.
Wo werden die Patientendaten bei einem DaaS-Setup gespeichert?
Das hängt ganz vom Anbieter ab, weshalb dies ein Thema für das erste technische Gespräch ist. Frage, wo die Daten physisch gehostet werden, welche Unterauftragsverarbeiter Zugriff auf die Patientendaten haben, ob sich welche davon außerhalb des EWR befinden und ob diese im Auftragsverarbeitungsvertrag mit einem definierten Änderungsprozess aufgeführt sind. Für ein Produkt, das in Deutschland betrieben wird, sollte das Ziel ein Hosting ausschließlich in der EU sein.
Kann Diagnostics as a Service die Probennahme zu Hause abwickeln?
Ja. Per Post verschickte Kits mit vorausbezahlter Rücksendung, Kapillarblut aus der Fingerkuppe, Speichel, Stuhl und Urin gehören neben venösen Blutabnahmen an Partnerstandorten zum Standardkatalog von DaaS. Die entscheidende Frage für deine Entwicklung ist, ob alle Entnahmemethoden denselben Bestellablauf, dasselbe Statusmodell und dasselbe Ergebnisformat nutzen oder ob jede Methode einen Sonderfall in deinem Code darstellt.
Begriffe schnell erklärt
Quellen
Sandbox-Schlüssel anfordern
Aniva bietet Produktteams eine einzige REST-API für über 2.500 Parameter, strukturierte JSON-Ergebnisse, eine Sandbox und öffentliche Dokumentationen – inklusive der im Hintergrund laufenden Labore, Testkits, Kuriere und EU-Compliance. Starte mit Aniva for Developers, lies die API-Dokumentation und fordere einen Schlüssel an, wenn du Fehlerszenarien mit echten Daten testen möchtest.
Dieser Artikel dient Produkt- und Entwicklungsteams als allgemeine Information darüber, wie Diagnoseinfrastruktur aufgebaut und beschafft wird. Er stellt keine medizinische, rechtliche oder regulatorische Beratung dar und beschreibt keine Diagnosen oder Behandlungen. Die Akkreditierung der Labore und die Referenzbereiche liegen beim analysierenden Labor, und die Interpretation einzelner Ergebnisse obliegt stets dem behandelnden Arzt. Die Angaben zu den Schnittstellen entsprechen der öffentlichen API-Dokumentation zum Zeitpunkt der Erstellung und können sich ändern – richte dich daher bei der Entwicklung nach der aktuellen Dokumentation.
