Diagnostics as a Service is how digital health products ship lab testing

Most teams building a health product can get to a polished, working app in a few months. Then they add lab testing, and the roadmap quietly loses two quarters. Not because the code is hard, but because a lab integration is never one integration. It is order routing, requisition forms, kit fulfilment, courier windows, barcode reconciliation, result parsing, unit conversion, reference ranges, a patient-facing view of all of it, and a compliance stack underneath that a lawyer has to sign before a single sample moves.

Diagnostics as a Service is the layer that removes that work, in the same way payment providers removed the acquiring bank, the gateway and the terminal supplier from the average checkout project. This piece covers what the model includes, what the integration actually looks like, how it compares with building it in-house, and what to ask a provider before you commit your roadmap to them.

What does Diagnostics as a Service mean for a product team?

Diagnostics as a Service, or DaaS, means ordering laboratory tests through an API and receiving structured results back, while a single provider runs the labs, the kits, the logistics and the regulatory framework behind that API. Your product decides who gets tested and what happens with the answer. Everything between the order and the result is somebody else's operational problem.

The comparison people reach for is Stripe, and it holds up better than most analogies. Stripe did not invent card payments, it collapsed a five-vendor project into one API and one dashboard. A diagnostics platform does the same thing to a stack that currently looks like a lab, a kit supplier, a courier, a results parser and a data-protection agreement per party. You are not buying a laboratory. You are buying the removal of an integration project.

Worth being precise about one thing, because it decides how you evaluate providers: a DaaS platform is usually not the lab. It orchestrates accredited labs. Accreditation belongs to whoever runs the analysis, while the API, the catalogue, the logistics and the compliance paperwork belong to the platform.

Why does a lab integration take longer than anyone estimates?

The estimate is usually made by looking at the lab's interface document, which describes a data format. The work is everywhere else. Six things account for most of the overrun.

Then multiply by the number of labs, because the lab that runs routine chemistry cheaply is rarely the one that runs your sequencing, your proteomics or your microbiome panels. Every additional modality is another interface, another contract and another format.

What does the integration look like with a DaaS API?

Short, when the platform is doing its job. With Aniva's API the path from a new user to a result is four calls, and only the first three involve you making a decision.

The create-appointment call in full, so you can see the shape of it:

# 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" }


What is absent from that list is the interesting part. No kit fulfilment logic, no courier scheduling, no barcode range management, no HL7 parser, no unit conversion table, no per-lab reference range database, and no separate contract for each specialty modality. Those exist, they are simply on the other side of the API.

How does a DaaS API compare with building it yourself?

Three approaches are viable, and the honest version of the comparison depends on whether diagnostics is your product or an input to your product.

Building the whole thing in-house is correct when the lab relationship, the panel design or the analysis itself is your differentiator, and when you have the volume to justify a permanent internal service with an on-call owner. Integrating labs directly, one at a time, keeps unit prices visible and works if you sell exactly one panel in exactly one market. A DaaS API trades some pricing granularity and some control for one integration, one contract and a launch measured in weeks.

The hidden cost in the middle column is not the build, it is the upkeep. A diagnostics integration is a living system: labs change formats, panels get renamed, couriers change windows, and regulations move. Someone on your team owns that forever, and it is rarely the work they joined to do.

What sits inside a DaaS stack?

When a provider claims to cover diagnostics end to end, this is what the claim has to include. Read any proposal against the list, because the gaps become your backlog.

Which products actually use Diagnostics as a Service?

The pattern is consistent. DaaS earns its place where a test result unlocks the rest of the product, and where nobody on the team wants to own a courier relationship.

If your product is the laboratory, or the analysis method is your patent, this model is not for you. Everyone else is buying infrastructure.

What does the EU compliance stack have to cover?

For a product operating in Germany or the wider EU, five things decide whether an integration is launchable. A provider should be able to answer all five without going away to check.

Ten questions to ask before you build against a provider

Where Aniva fits

Aniva is a Diagnostics-as-a-Service platform built for European health products. One REST API reaches more than 2,500 parameters, from a routine blood panel through hormones, vitamins and immunology to whole-genome and whole-exome sequencing, transcriptomics, proteomics and microbiome analysis. Results come back as structured JSON, there is a sandbox to build against, and the API documentation is public.

Underneath, the routine and specialty bloodwork runs at ZOTZ|KLIMAS, which holds the RiliBÄK and ISO 15189 coverage, with specialty partners behind the multi-omics modalities. Core blood panels return within 24 hours of pickup. Data processing is EU-native and hosted in Germany, and the processing agreement is part of standard onboarding rather than a negotiation. The patient-facing dashboard and PDF can carry your brand, or you can skip them and render results in your own interface.

If you want to see the model from the buying side of a clinic rather than an engineering team, the companion article covers Diagnostics as a Service for clinics, including the procurement questions and the cost comparison. If you would rather just read the endpoints, start with Aniva for Developers and request a sandbox key.

The bottom line

Diagnostics is the least glamorous integration in health tech and one of the easiest to underestimate, because the interface document describes a data format while the real work is physical samples, exception paths and compliance. Diagnostics as a Service moves that work behind an API, which is worth doing whenever the test result is an input to your product rather than the product itself.

The test of a provider is not the marketing page, it is whether you can read the docs, get a sandbox key, build the unhappy paths against realistic data, and have your lawyer read the processing agreement before you commit. If all four are possible in a week, the integration is probably as short as it looks.

Frequently asked questions

What is Diagnostics as a Service?

Diagnostics as a Service is a model where a product orders laboratory tests through a single API and receives structured results back, while the provider runs the labs, the collection kits, the courier logistics and the regulatory framework behind that API. It replaces a stack that would otherwise involve a lab contract, a kit supplier, a courier, a results parser and a separate data processing agreement for each party.

How long does a diagnostics API integration take?

With a documented REST API and a sandbox, days to a first test order and weeks to production is realistic, because the work is limited to your own ordering flow, your result rendering and your exception handling. Building the same capability in-house against individual labs is usually a multi-quarter project, and each additional lab or modality repeats a large part of it.

Is a diagnostics platform the same as a laboratory?

Usually not. Most platforms orchestrate accredited laboratories rather than owning one. Quality accreditation such as RiliBÄK and ISO 15189 sits with the lab running the analysis, while the API, the catalogue, the logistics and the compliance framework sit with the platform. Ask any provider to name the labs behind their catalogue and what each is accredited for.

What do lab results look like coming out of an API?

The useful answer is structured JSON with a marker identifier, a value, a unit and the reference range the analysing lab applied, because ranges are lab-specific and depend on factors like age and sex. A PDF should be an output you can hand to a user, not the format your code has to parse. Ask for a real sample payload before you design your data model.

Can I white-label the patient experience?

Yes, in most offers, though the depth varies. Look for your logo and colours on the patient dashboard, your branding on the result PDF, your own sub-domain, and your sender identity on patient emails. If you would rather build the interface yourself, check that the API exposes everything the provider's own dashboard shows.

Is my product a medical device if it shows lab results?

Displaying results with reference ranges and plain-language context is normally designed to be non-qualifying under MDR, IVDR and MPDG, with interpretation remaining with a clinician. Adding risk scoring, diagnosis or treatment advice changes that analysis, and the classification of your product is your responsibility rather than the platform's. Get the provider's documented position in writing and take your own regulatory advice on anything you build on top.

Where is patient data stored in a DaaS setup?

It depends entirely on the provider, which is why it belongs in the first technical call. Ask where data is physically hosted, which sub-processors touch the patient data path, whether any of them sit outside the EEA, and whether the processing agreement enumerates them with a defined change process. For a product operating in Germany, EU-only hosting is the answer to aim for.

Can Diagnostics as a Service handle at-home sample collection?

Yes. Mailed kits with prepaid return, capillary finger-prick collection, saliva, stool and urine are all standard parts of a DaaS catalogue alongside venous draws at partner locations. The question that matters for your build is whether every collection method shares one ordering flow, one status model and one result format, or whether each one is a special case in your code.

Terms explained quickly

Sources

Get a sandbox key

Aniva gives a product team one REST API to more than 2,500 parameters, structured JSON results, a sandbox and public docs, with the labs, kits, couriers and EU compliance stack running underneath. Start with Aniva for Developers, read the API documentation, and request a key when you want to build the unhappy paths against real payloads.

This article is general information for product and engineering teams about how diagnostics infrastructure is built and procured. It is not medical, legal or regulatory advice, and it does not describe any diagnosis or treatment. Laboratory accreditation and reference ranges belong to the analysing laboratory, and interpretation of any individual result remains with a treating clinician. Endpoint details reflect the public API documentation at the time of writing and may change, so build against the current docs.