„Diagnostics as a Service“ – so werden Labortests bei digitalen Gesundheitsprodukten bereitgestellt

Die meisten Teams, die ein Gesundheitsprodukt entwickeln, schaffen es innerhalb weniger Monate, eine ausgefeilte, funktionierende App auf die Beine zu stellen. Dann kommen Labortests dazu, und schon verliert der Zeitplan still und leise zwei Quartale. Nicht, weil der Code so kompliziert wäre, sondern weil eine Laborintegration nie nur aus einer einzigen Integration besteht. Es geht um Auftragsweiterleitung, Anforderungsformulare, die Bereitstellung von Testkits, Kuriertermine, Barcode-Abgleich, die Auswertung von Ergebnissen, Einheitenumrechnung, Referenzbereiche, eine für Patienten sichtbare Übersicht über all das und einen Compliance-Stapel im Hintergrund, den ein Anwalt unterschreiben muss, bevor auch nur eine einzige Probe verschickt wird.

„Diagnostics as a Service“ ist die Ebene, die dir diese Arbeit abnimmt – genauso wie Zahlungsanbieter bei einem typischen Checkout-Projekt die akquirierende Bank, das Gateway und den Terminal-Anbieter aus dem Prozess herausgenommen haben. In diesem Beitrag geht es darum, was das Modell umfasst, wie die Integration konkret aussieht, wie es im Vergleich zu einer Eigenentwicklung abschneidet und welche Fragen du einem Anbieter stellen solltest, bevor du ihm deine Roadmap anvertraust.

Was bedeutet „Diagnostics as a Service“ für ein Produktteam?

„Diagnostics as a Service“ (DaaS) bedeutet, dass du Labortests über eine API in Auftrag gibst und strukturierte Ergebnisse zurückerhältst, während ein einziger Anbieter die Labore, die Testkits, die Logistik und die rechtlichen Rahmenbedingungen hinter dieser API verwaltet. Dein Produkt entscheidet, wer getestet wird und was mit dem Ergebnis geschieht. Alles zwischen der Bestellung und dem Ergebnis ist das operative Problem eines anderen.

Der Vergleich, auf den die Leute zurückgreifen, ist Stripe, und der hält besser stand als die meisten anderen Analogien. Stripe hat Kartenzahlungen nicht erfunden, sondern ein Projekt mit fünf Anbietern auf eine einzige API und ein einziges Dashboard reduziert. Eine Diagnoseplattform macht dasselbe mit einem Stack, der derzeit aus einem Labor, einem Kit-Lieferanten, einem Kurierdienst, einem Ergebnisauswerter und einer Datenschutzvereinbarung pro Partei besteht. Du kaufst kein Labor. Du kaufst dir die Entlastung von einem Integrationsprojekt.

Eines sollte man genau klären, denn davon hängt ab, wie du Anbieter bewertest: Eine DaaS-Plattform ist in der Regel nicht das Labor selbst. Sie koordiniert akkreditierte Labore. Die Akkreditierung liegt bei demjenigen, der die Analyse durchführt, während die API, der Katalog, die Logistik und die Compliance-Unterlagen zur Plattform gehören.

Warum dauert eine Laborintegration länger, als alle denken?

Die Schätzung erfolgt in der Regel anhand des Schnittstellendokuments des Labors, in dem ein Datenformat beschrieben wird. Die eigentliche Arbeit findet überall sonst statt. Sechs Faktoren sind für den Großteil der Zeitüberschreitung verantwortlich.

• Eine Bestellung ist kein POST. Eine gültige Bestellung benötigt die Identität des Patienten, ein Testpanel, das das Labor unter dem von dir verwendeten Code tatsächlich anbietet, einen Befundbogen und einen Barcode, der ein physisches Röhrchen mit diesem Datensatz verknüpft. Wenn du den letzten Teil falsch machst, bekommst du Ergebnisse, die du nicht zuordnen kannst.
• Die physische Logistik hält Einzug in deinen Code. Sets müssen beschafft, versendet und zurückgeschickt werden. Kurierdienste haben Abholzeitfenster. Proben verderben. Plötzlich hat dein Produkt Status wie „unterwegs“ und „Abholung verpasst“, und jemand muss entscheiden, was der Nutzer bei jedem dieser Status sieht.
• Die Formate der Ergebnisse sind in der Praxis nicht einheitlich. Ein Labor sendet HL7, ein anderes eine CSV-Datei über SFTP, ein drittes ein PDF, das eigentlich von einem Menschen gelesen werden soll. Selbst wenn du strukturierte Daten erhältst, unterscheiden sich die Einheiten, die Bezeichnungen der Marker und die Referenzbereiche hängen von Alter, Geschlecht und Methode ab.
• Referenzbereiche sind laborspezifisch. Ein Wert ist ohne den vom analysierenden Labor verwendeten Bereich bedeutungslos; daher muss dein Datenmodell die Bereiche zusammen mit den Werten speichern, anstatt sie einmalig fest zu programmieren.
• Ausnahmen sind das eigentliche Produkt. Hämolysierte Proben, unzureichendes Volumen, ein Marker, der nicht ausgewertet werden konnte, eine erneute Probenentnahme. Der „Happy Path“ entspricht einer Woche Arbeit, und die Ausnahmepfade machen den Rest des Quartals aus.
• Compliance ist eine Grundvoraussetzung, keine vorübergehende Phase. Eine Auftragsverarbeitungsvereinbarung pro Anbieter, eine Liste der Unterauftragsverarbeiter, der Standort des Hostings und eine stichhaltige Antwort auf die Frage, ob deine Schnittstelle ein Medizinprodukt ist. Nichts davon lässt sich nach dem Start nachträglich einrichten.

Dann multipliziere das mit der Anzahl der Labore, denn das Labor, das Routine-Chemieuntersuchungen günstig durchführt, ist selten dasselbe, das deine Sequenzierungen, deine Proteomik oder deine Mikrobiom-Panels durchführt. Jede zusätzliche Untersuchungsmethode bedeutet eine weitere Schnittstelle, einen weiteren Vertrag und ein weiteres Format.

Wie sieht die Integration mit einer DaaS-API aus?

Kurz gesagt: wenn die Plattform das tut, was sie soll. Mit der API Aniva umfasst der Weg vom neuen Nutzer bis zum Ergebnis vier Aufrufe, und nur bei den ersten drei musst du eine Entscheidung treffen.

1. Ein Profil erstellen mit POST /api/v1/profiles, wobei die vom Labor benötigten Angaben wie Vorname, Geschlecht, Geburtsdatum und die Profilgruppe, zu der die Person gehört, übermittelt werden.
2. Vereinbare einen Termin mit POST /api/v1/appointments, indem man ein profile_id, ein location_id ab GET /api/v1/locations, und ein scheduled_at Zeitstempel. Die Panels werden in einem separaten Aufruf angehängt, sodass die Buchung und der Warenkorb unabhängig voneinander bleiben.
3. Bestätige die Auslosung mit POST /api/v1/appointments/{id}/confirm und den Barcode des Röhrchens. Das ist der Schritt, der die Labor-Pipeline in Gang setzt, was bedeutet, dass die physische Probe und der digitale Datensatz an genau einem Punkt im Ablauf miteinander verknüpft werden.
4. Lies dir die Ergebnisse durch mit GET /api/v1/appointments/{id}/results sobald die Verarbeitung abgeschlossen ist.

Hier ist der „create-appointment“-Aufruf in voller Länge, damit du sehen kannst, wie er aussieht:

# 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 daran ist, was in dieser Liste fehlt. Keine Logik zur Kit-Bereitstellung, keine Kurierplanung, kein Barcode-Bereichsmanagement, kein HL7-Parser, keine Einheitenumrechnungstabelle, keine Referenzbereichsdatenbank pro Labor und kein separater Vertrag für jede Spezialuntersuchungsmethode. Das alles gibt es zwar, es befindet sich nur auf der anderen Seite der API.

Wie schneidet eine DaaS-API im Vergleich zur Eigenentwicklung ab?

Es gibt drei mögliche Ansätze, und wie der Vergleich ehrlich ausfällt, hängt davon ab, ob die Diagnostik dein Produkt ist oder ein Bestandteil deines Produkts.

Das Ganze intern aufzubauen ist der richtige Weg, wenn die Beziehung zum Labor, die Gestaltung des Testpanels oder die Analyse selbst dein Alleinstellungsmerkmal ist und wenn du das Volumen hast, das einen festen internen Service mit einem Verantwortlichen im Bereitschaftsdienst rechtfertigt. Die direkte Integration einzelner Labore nacheinander sorgt für überschaubare Stückpreise und funktioniert, wenn du genau ein Testpanel in genau einem Markt verkaufst. Eine DaaS-API tauscht etwas Preisgestaltungsflexibilität und Kontrolle gegen eine einzige Integration, einen einzigen Vertrag und eine Markteinführung innerhalb weniger Wochen ein.

Die versteckten Kosten in der mittleren Spalte entstehen nicht beim Aufbau, sondern bei der Wartung. Eine Diagnostik-Integration ist ein lebendiges System: Labore ändern ihre Formate, Testpanels werden umbenannt, Kurierdienste ändern ihre Zeitfenster und Vorschriften ändern sich. Jemand in deinem Team ist dafür auf Dauer verantwortlich – und das ist selten die Aufgabe, für die diese Person eigentlich eingestellt wurde.

Was gehört zu einem DaaS-Stack?

Wenn ein Anbieter behauptet, die Diagnostik von Anfang bis Ende abzudecken, muss diese Behauptung genau das beinhalten. Vergleiche jedes Angebot mit dieser Liste, denn die Lücken werden zu deinem Rückstand.

• Labornetzwerk. Ein akkreditierter Partner für Routineblutuntersuchungen sowie spezialisierte Partner für Genomik, Transkriptomik, Proteomik und Mikrobiomanalyse – alle sind im Rahmen des einen Vertrags, den du unterzeichnet hast, erreichbar.
• Testkatalog mit festen Bezeichnern. Panels und einzelne Marker, auf die du programmgesteuert zugreifen kannst, sowie die Möglichkeit, ein individuelles Panel für dein eigenes Produkt zu definieren, anstatt nur das zu kaufen, was es im Regal gibt.
• Probenentnahme und Logistik. Venenblutentnahmen an Partnerstandorten, Kapillarblut-Kits, Heimtest-Kits mit vorfrankierter Rücksendung sowie Speichel-, Stuhl- und Urinproben, wenn ein Testpanel diese benötigt – alles mit Barcode über denselben Arbeitsablauf abgewickelt.
• REST-API und Dokumentation, die du auch ohne Aufruf lesen kannst. Vorhersehbare Ressourcen, klare Fehlermeldungen und eine Dokumentation, der ein neuer Entwickler schon am ersten Nachmittag folgen kann.
• Eine Sandbox. Realistische Testdaten, bevor du einen echten Patienten oder einen echten Schlauch anfasst, damit du deine Ausnahmebehandlung nicht nur auf der Grundlage deiner Vorstellungskraft schreibst.
• Strukturierte Ergebnisse. Werte, Einheiten, Referenzbereiche und Marker-IDs im JSON-Format, wobei das PDF als Ausgabe dient und nicht die Benutzeroberfläche.
• White-Label-Oberflächen. Ein patientenspezifisches Dashboard mit deinem Branding und ein Ergebnis-PDF, falls du das möchtest – und die Möglichkeit, alles in deiner eigenen Benutzeroberfläche darzustellen, wenn dir das lieber ist.
• Compliance-Ebene. Auftragsverarbeitungsvereinbarung, Auflistung der Unterauftragsverarbeiter, EU-Hosting und eine dokumentierte Stellungnahme zur Einstufung von Medizinprodukten.

Welche Produkte nutzen „Diagnostics as a Service“ eigentlich?

Das Muster ist immer dasselbe. DaaS bewährt sich dort, wo ein Testergebnis den Zugang zum Rest des Produkts freischaltet und wo niemand im Team die Verantwortung für die Kommunikation mit dem Kurierdienst übernehmen will.

• Telemedizin und digitale Kliniken, die vor einer Konsultation objektive Daten benötigen und nach der Konsultation den Prozess abschließen möchten, ohne dass der Patient woanders hingehen muss.
• Apps zur Erfassung von Lebenserwartung und Gesundheitsdaten, die auf wiederholten Erhebungen basieren, bei denen der Trend über mehrere Tests hinweg das Ergebnis ist und ein einzelnes Ergebnis nur ein Ausgangspunkt ist.
• Betriebliche Gesundheitsplattformen, die an vielen Standorten Screening-Maßnahmen in großem Umfang durchführen, wobei nicht die Analyse, sondern die Logistik die größte Herausforderung darstellt.
• Marken für Nahrungsergänzungsmittel und Ernährung, die Empfehlungen wünschen, die auf einem nachgewiesenen Mangel basieren und nicht auf einem Fragebogen.
• Digitale Therapeutika und dezentrale Studien, bei denen gemäß Protokoll festgelegte Proben zu Hause entnommen und mit einer dokumentierten Nachverfolgungskette erfasst werden müssen.
• Versicherer und Präventionsprogramme, die eine wiederholbare Basismessung für eine gesamte Bevölkerungsgruppe benötigen.
• Anbieter von Praxissoftware integrieren Diagnostik als Funktion für ihre eigenen Kunden, sodass deren Praxen Untersuchungen anfordern können, ohne die von ihnen bereits genutzte Software verlassen zu müssen.

Wenn dein Produkt das Labor ist oder die Analysemethode dein Patent ist, ist dieses Modell nichts für dich. Alle anderen kaufen Infrastruktur.

Was muss der EU-Compliance-Stack abdecken?

Bei einem Produkt, das in Deutschland oder der gesamten EU zum Einsatz kommt, entscheiden fünf Faktoren darüber, ob eine Integration startbereit ist. Ein Anbieter sollte alle fünf Fragen beantworten können, ohne erst nachschauen zu müssen.

• Qualitätsstandards für Labore. RiliBÄK für die deutsche Laborqualitätssicherung und ISO 15189 für die Akkreditierung medizinischer Labore. Beide gelten für das analysierende Labor – frag also nach, um welches Labor es sich handelt, und vergewissere dich, dass die Abdeckung dort gewährleistet ist.
• DSGVO und der Auftragsverarbeitungsvertrag. Ein Auftragsverarbeitungsvertrag, in dem die Liste der Unterauftragsverarbeiter aufgeführt ist und ein festgelegtes Verfahren für deren Änderung vorgesehen ist – keine allgemeine Vorlage.
• Speicherort der Daten. Wo sich die Daten physisch befinden und ob sich ein Unterauftragsverarbeiter im Patienten-Datenpfad außerhalb des EWR befindet. Das ist eine Ja-oder-Nein-Frage.
• MDR, IVDR und MPDG. Die Darstellung von Ergebnissen mit Referenzbereichen und Kontext ist normalerweise so konzipiert, dass sie nicht als Medizinprodukt gilt, wobei die Interpretation beim Arzt bleibt. Wenn dein Produkt zusätzlich eine Bewertung, eine Risikovorhersage oder eine Empfehlung enthält, musst du diese Einstufungsfrage selbst klären, und in der Dokumentation des Anbieters sollte klar zum Ausdruck kommen, wo dessen Verantwortung endet.
• Berufsrecht und Vorschriften gegen Schmiergeldzahlungen. In Deutschland regeln § 299a StGB und § 31 MBO-Ä, wie Geld zwischen einem Anbieter und demjenigen fließen darf, der Patienten vermittelt. Gebühren für die Koordination und den Softwarezugang sind etwas anderes als Gebühren, die an das Überweisungsvolumen gekoppelt sind, und der Vertrag sollte so eindeutig formuliert sein, dass dein Anwalt ihn genehmigen kann.

Zehn Fragen, die du dir stellen solltest, bevor du auf der Plattform eines Anbieters entwickelst

1. Kann ich mir die Dokumentation ansehen und einen Sandbox-Schlüssel bekommen, bevor ich irgendwas unterschreibe? Wenn die API erst nach Vertragsabschluss zugänglich ist, legst du deine Roadmap auf etwas fest, das du noch gar nicht gelesen hast.
2. Welche Labore untersuchen die Proben und wofür sind sie akkreditiert? Nenn uns Namen und Normen, nicht „unser Partnernetzwerk“.
3. Sind die Ergebnisse strukturiert, mit Einheiten und Referenzbereichen pro Marker? Frag nach einer echten Beispielauswertung für ein echtes Panel, nicht nach einem abstrakten Schema.
4. Wie werden Marker- und Panel-Identifikatoren versioniert? Umbenannte Panels und sich ändernde Codes sind eine heimtückische Fehlerquelle – frag also nach, was mit deiner Integration passiert, wenn sich der Katalog ändert.
5. Wie erfahre ich, dass ein Ergebnis vorliegt? Durch Abfrage eines Endpunkts, eines Webhooks oder eines Callbacks. Orientiere dich an der aktuellen Situation statt an der Roadmap und entwickle Lösungen für das, was heute bereits existiert.
6. Wie sieht die Fehlersemantik aus und sind Schreibvorgänge idempotent? Einen physikalischen Test wegen eines Wiederholungsversuchs zweimal auszuführen, ist eine besonders kostspielige Art von Fehler.
7. Wie werden Ausnahmen gemeldet? Eine hämolysierte Probe, eine versäumte Abholung, ein defekter Marker. Frag dich, welche Informationen dein System erhält und wer mit dem Patienten spricht.
8. Welche Abholmethoden und welche Länder sind derzeit verfügbar? In den Angaben zur Abdeckung wird oft der Zeitplan beschrieben. Frag nach, in welchen Städten es diesen Monat eine Abholung am selben Tag gibt.
9. Was ist im Compliance-Paket enthalten, und kann mein Anwalt es sich erst mal durchlesen? Verarbeitungsvereinbarung, Liste der Unterauftragsverarbeiter, Standort des Hostings, Stellungnahme zur Geräteklassifizierung.
10. Was passiert mit meinen Daten, wenn wir unsere Zusammenarbeit beenden? Exportformat, Ausstiegsoption und ob Datensätze durch proprietäre Identifikatoren gesperrt sind. Der Verlauf deiner Nutzer sollte übertragbar bleiben.

Wo Aniva

Aniva eine „Diagnostics-as-a-Service“-Plattform, die speziell für europäische Gesundheitsprodukte entwickelt wurde. Über eine einzige REST-API kannst du auf mehr als 2.500 Parameter zugreifen – von Routine-Blutuntersuchungen über Hormone, Vitamine und Immunologie bis hin zu Gesamtgenom- und Gesamtexom-Sequenzierung, Transkriptomik, Proteomik und Mikrobiomanalyse. Die Ergebnisse werden als strukturiertes JSON zurückgegeben, es gibt eine Sandbox zum Testen und die API-Dokumentation ist öffentlich zugänglich.

Die routinemäßigen und spezialisierten Blutuntersuchungen werden bei ZOTZ|KLIMAS durchgeführt, das über die Zertifizierungen nach RiliBÄK und ISO 15189 verfügt, wobei Spezialpartner die Multi-Omics-Verfahren übernehmen. Die Ergebnisse der Kernblutuntersuchungen liegen innerhalb von 24 Stunden nach Abholung vor. Die Datenverarbeitung erfolgt innerhalb der EU und wird in Deutschland gehostet; die Verarbeitungsvereinbarung ist Teil des Standard-Onboardings und muss nicht gesondert ausgehandelt werden. Das patientenorientierte Dashboard und die PDF-Datei können mit deinem Branding versehen werden, oder du kannst darauf verzichten und die Ergebnisse in deiner eigenen Benutzeroberfläche anzeigen lassen.

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 Beschaffungsfragen und des Kostenvergleichs. Wenn du lieber direkt die Endpunkte lesen möchtest, fang mit Aniva Developers“ an und fordere einen Sandbox-Schlüssel an.

Unterm Strich

Die Diagnostik ist der am wenigsten glamouröse Integrationsbereich in der Gesundheits-Tech-Branche und einer derjenigen, die am leichtesten unterschätzt werden, denn das Schnittstellendokument beschreibt zwar ein Datenformat, doch die eigentliche Arbeit besteht aus physischen Proben, Ausnahmepfaden und der Einhaltung von Vorschriften. „Diagnostics as a Service“ verlagert diese Arbeit hinter eine API – was sich immer dann lohnt, wenn das Testergebnis eine Eingabe für dein Produkt ist und nicht das Produkt selbst.

Der Lackmustest für einen Anbieter ist nicht die Marketing-Seite, sondern ob du die Dokumentation lesen, einen Sandbox-Schlüssel erhalten, die „Unhappy Paths“ anhand realistischer Daten durchspielen und deine Rechtsabteilung die Verarbeitungsvereinbarung prüfen lassen kannst, bevor du dich festlegst. Wenn all das innerhalb einer Woche möglich ist, ist die Integration wahrscheinlich so schnell, wie es aussieht.

Häufig gestellte Fragen

Was ist „Diagnostics as a Service“?

„Diagnostics as a Service“ ist ein Modell, bei dem ein Produkt über eine einzige API Labortests in Auftrag gibt und strukturierte Ergebnisse zurückerhält, während der Anbieter die Labore, die Probenentnahmekits, die Kurierlogistik und den rechtlichen Rahmen hinter dieser API übernimmt. Es ersetzt eine ganze Reihe von Komponenten, die sonst einen Laborvertrag, einen Kit-Lieferanten, einen Kurierdienst, einen Ergebnis-Parser und für jede Partei eine separate Vereinbarung zur Datenverarbeitung erfordern würden.

Wie lange dauert die Integration einer Diagnose-API?

Mit einer dokumentierten REST-API und einer Sandbox ist es realistisch, innerhalb weniger Tage eine erste Testbestellung und innerhalb weniger Wochen den Produktivbetrieb zu erreichen, da sich die Arbeit auf deinen eigenen Bestellablauf, die Darstellung der Ergebnisse und die Ausnahmebehandlung beschränkt. Die Entwicklung derselben Funktionalität intern für einzelne Labore ist in der Regel ein Projekt, das mehrere Quartale in Anspruch nimmt, und bei jedem weiteren Labor oder jeder weiteren Untersuchungsmethode muss ein großer Teil davon wiederholt werden.

Ist eine Diagnostikplattform dasselbe wie ein Labor?

Normalerweise nicht. Die meisten Plattformen koordinieren akkreditierte Labore, anstatt selbst eines zu besitzen. Die Qualitätsakkreditierung wie RiliBÄK und ISO 15189 liegt beim Labor, das die Analyse durchführt, während die API, der Katalog, die Logistik und die Compliance-Rahmenbedingungen bei der Plattform liegen. Frag einfach einen beliebigen Anbieter, welche Labore hinter seinem Katalog stehen und wofür jedes einzelne akkreditiert ist.

Wie sehen Laborergebnisse aus, die über eine API ausgegeben werden?

Die sinnvolle Antwort ist strukturiertes JSON mit einer Kennung, einem Wert, einer Einheit und dem vom Analyselabor verwendeten Referenzbereich, da diese Bereiche laborspezifisch sind und von Faktoren wie Alter und Geschlecht abhängen. Ein PDF sollte ein Ergebnis sein, das du einem Nutzer aushändigen kannst, und nicht das Format, das dein Code auswerten muss. Frag nach einer echten Beispiel-Nutzlast, bevor du dein Datenmodell entwirfst.

Kann ich das Patientenerlebnis als White-Label-Lösung anbieten?

Ja, in den meisten Angeboten ist das der Fall, auch wenn der Umfang variiert. Achte auf dein Logo und deine Farben im Patienten-Dashboard, dein Branding im Ergebnis-PDF, deine eigene Subdomain und deine Absenderidentität in den E-Mails an die Patienten. Wenn du die Benutzeroberfläche lieber selbst erstellen möchtest, überprüfe, ob die API alle Funktionen bereitstellt, die auch im Dashboard des Anbieters angezeigt werden.

Ist mein Produkt ein Medizinprodukt, wenn es Laborergebnisse anzeigt?

Die Darstellung von Ergebnissen mit Referenzbereichen und Erläuterungen in einfacher Sprache ist normalerweise so konzipiert, dass sie gemäß MDR, IVDR und MPDG nicht als qualifizierende Aussage gilt, wobei die Interpretation beim Arzt bleibt. Das Hinzufügen von Risikobewertungen, Diagnosen oder Behandlungsempfehlungen verändert diese Einstufung, und die Klassifizierung deines Produkts liegt in deiner Verantwortung und nicht in der der Plattform. Hol dir die dokumentierte Stellungnahme des Anbieters schriftlich ein und hol dir eigene regulatorische Beratung zu allem, was du darauf aufbaust.

Wo werden Patientendaten in einer DaaS-Umgebung gespeichert?

Das hängt ganz vom Anbieter ab, weshalb diese Frage beim ersten technischen Gespräch geklärt werden sollte. Frag nach, wo die Daten physisch gehostet werden, welche Unterauftragsverarbeiter mit den Patientendaten in Berührung kommen, ob sich einige davon außerhalb des EWR befinden und ob sie in der Auftragsverarbeitungsvereinbarung mit einem festgelegten Änderungsprozess aufgeführt sind. Bei einem Produkt, das in Deutschland eingesetzt wird, solltest du darauf hinarbeiten, dass das Hosting ausschließlich innerhalb der EU erfolgt.

Kann „Diagnostics as a Service“ die Probenentnahme zu Hause abwickeln?

Ja. Per Post versandte Testkits mit vorfrankierter Rücksendung, Kapillarblutentnahme per Fingerstich, Speichel-, Stuhl- und Urinproben sind neben venösen Blutentnahmen an Partnerstandorten allesamt Standardbestandteile eines DaaS-Katalogs. Die entscheidende Frage für deine Entwicklung ist, ob alle Entnahmemethoden denselben Bestellablauf, dasselbe Statusmodell und dasselbe Ergebnisformat nutzen oder ob jede einzelne in deinem Code als Sonderfall behandelt wird.

Begriffe kurz erklärt

• Bei „Diagnostics as a Service“ (DaaS) bestellst du Labortests über eine einzige API, während der Anbieter sich um die Labore, die Testkits, die Logistik und die damit verbundenen rechtlichen Rahmenbedingungen kümmert.
• Unter „strukturierten Ergebnissen“ versteht man eine Markerkennung, einen Wert, eine Einheit und einen Referenzbereich in maschinenlesbarer Form – und nicht etwa ein PDF, das dein Code erst auswerten muss.
• Der Referenzbereich ist das Intervall, das das Analyselabor auf einen Wert anwendet; er hängt von der Methode, dem Alter und dem Geschlecht ab und wird daher zusammen mit dem Ergebnis weitergegeben, anstatt in deinem Code festgeschrieben zu sein.
• Sandbox ist eine Nicht-Produktionsumgebung mit realistischen Daten, in der die Ausnahmebehandlung geschrieben werden sollte, bevor es eine echte Tube gibt.
• „White-Label“ bedeutet, dass der Endnutzer die Marke deines Produkts auf dem Dashboard, im PDF und in der Domain sieht, während die Plattform dahinter unsichtbar bleibt.

Quellen

• Aniva -Dokumentation
• ISO 15189:2022, Medizinische Laboratorien – Anforderungen an Qualität und Kompetenz
• Verordnung (EU) 2016/679, Datenschutz-Grundverordnung
• Verordnung (EU) 2017/745 über Medizinprodukte (MDR)
• Verordnung (EU) 2017/746 über In-vitro-Diagnostika (IVDR)
• Gesetz zur Durchführung des Medizinproduktegesetzes (MPDG)
• § 299a StGB, Bestechung im Gesundheitswesen

Hol dir einen Sandbox-Schlüssel

Aniva einem Produktteam eine einzige REST-API mit Zugriff auf mehr als 2.500 Parameter, strukturierte JSON-Ergebnisse, eine Sandbox und öffentliche Dokumentation, während im Hintergrund die Labore, Testkits, Kurierdienste und die EU-Konformitätsplattform laufen. Fang mit Aniva Developers“ an, lies dir die API-Dokumentation durch und beantrage einen Schlüssel, wenn du die „Unhappy Paths“ anhand echter Payloads testen möchtest.

Dieser Artikel enthält allgemeine Informationen für Produkt- und Entwicklungsteams darüber, wie eine Diagnoseinfrastruktur aufgebaut und beschafft wird. Er stellt keine medizinische, rechtliche oder behördliche Beratung dar und beschreibt keine Diagnosen oder Behandlungen. Die Laborakkreditierung und die Referenzbereiche liegen in der Verantwortung des analysierenden Labors, und die Interpretation einzelner Ergebnisse obliegt dem behandelnden Arzt. Die Angaben zu den Endpunkten entsprechen der öffentlichen API-Dokumentation zum Zeitpunkt der Erstellung und können sich ändern. Orientiere dich daher bei der Entwicklung an der aktuellen Dokumentation.