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.

• Ordering is not a POST. A valid order needs a patient identity, a panel that the lab actually offers under the code you used, a requisition document, and a barcode that ties a physical tube to that record. Get the last part wrong and you have results you cannot attribute.
• Physical logistics enters your codebase. Kits have to be sourced, shipped and returned. Couriers have collection windows. Samples degrade. Suddenly your product has states like "in transit" and "pickup missed", and someone has to decide what the user sees for each of them.
• Result formats are not a standard in practice. One lab sends HL7, another a CSV over SFTP, a third a PDF that a human is expected to read. Even where you get structured data, units differ, marker names differ, and reference ranges depend on age, sex and method.
• Reference ranges are lab-specific. A value is meaningless without the range the analysing lab used, so your data model needs to carry ranges alongside values rather than hard-coding them once.
• Exceptions are the actual product. Haemolysed samples, insufficient volume, a marker that failed to run, a re-draw. The happy path is a week of work and the exception paths are the rest of the quarter.
• Compliance is a dependency, not a phase. A processing agreement per vendor, a sub-processor list, hosting location, and a defensible answer to whether your interface is a medical device. None of that can be retrofitted after launch.

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.

1. Create a profile with POST /api/v1/profiles, passing the details the lab requires, such as first name, sex, date of birth and the profile group the person belongs to.
2. Schedule an appointment with POST /api/v1/appointments, passing a profile_id, a location_id from GET /api/v1/locations, and a scheduled_at timestamp. Panels are attached in a separate call, so the booking and the basket stay independent.
3. Confirm the draw with POST /api/v1/appointments/{id}/confirm and the tube barcode. This is the call that starts the lab pipeline, which means the physical sample and the digital record are tied together at exactly one point in the flow.
4. Read the results with GET /api/v1/appointments/{id}/results once processing has finished.

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.

• Lab network. An accredited partner for routine bloodwork, plus specialty partners for genomics, transcriptomics, proteomics and microbiome analysis, all reachable under the one contract you signed.
• Test catalogue with stable identifiers. Panels and single markers you can reference programmatically, and a way to define a custom panel for your own product rather than only buying what is on the shelf.
• Sample collection and logistics. Venous draws at partner locations, capillary kits, at-home kits with prepaid return, plus saliva, stool and urine where a panel needs them, all barcoded through the same flow.
• REST API and documentation you can read without a call. Predictable resources, clear errors, and docs a new engineer can follow on their first afternoon.
• A sandbox. Realistic test data before you touch a real patient or a real tube, so your exception handling is written against something other than your imagination.
• Structured results. Values, units, reference ranges and marker identifiers in JSON, with the PDF as an output rather than the interface.
• White-label surfaces. A branded patient dashboard and result PDF if you want them, and the option to render everything in your own UI if you would rather.
• Compliance layer. Processing agreement, enumerated sub-processors, EU hosting, and a documented position on medical device classification.

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.

• Telehealth and digital clinics that need objective data before a consultation, and a way to close the loop afterwards without asking the patient to go elsewhere.
• Longevity and health-tracking apps built on repeat panels, where the trend across tests is the product and a single result is only a starting point.
• Corporate health platforms running screening at volume across many sites, where the logistics rather than the analysis is the hard constraint.
• Supplement and nutrition brands that want recommendations grounded in a measured deficiency rather than a questionnaire.
• Digital therapeutics and decentralised trials that need protocol-defined panels collected at home with a documented chain of custody.
• Insurers and preventive programmes that need a repeatable baseline measurement across a population.
• Clinic software vendors embedding diagnostics as a feature for their own customers, so their clinics order tests without leaving the product they already use.

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.

• Lab quality standards. RiliBÄK for German laboratory quality assurance and ISO 15189 for medical laboratory accreditation. Both belong to the analysing lab, so ask which lab and confirm the coverage sits with them.
• GDPR and the processing agreement. An Auftragsverarbeitungsvertrag with the sub-processor list enumerated and a defined process for changing it, not a generic template.
• Data location. Where the data physically lives and whether any sub-processor in the patient data path sits outside the EEA. This is a yes or no question.
• MDR, IVDR and MPDG. Displaying results with reference ranges and context is normally designed to be non-qualifying as a medical device, with interpretation staying with a clinician. If your product adds scoring, risk prediction or advice on top, that is your classification question to answer, and the provider's documentation should make clear where their responsibility ends.
• Professional conduct and anti-kickback rules. In Germany, Sec. 299a StGB and Sec. 31 MBO-Ä shape how money may flow between a provider and whoever refers patients. Fees for orchestration and software access are a different thing from fees tied to referral volume, and the contract should be explicit enough for your counsel to sign off.

Ten questions to ask before you build against a provider

1. Can I see the docs and get a sandbox key before signing anything? If the API is only visible after a contract, you are committing your roadmap to something you have not read.
2. Which labs run the samples, and what are they accredited for? Names and standards, not "our partner network".
3. Are results structured, with units and reference ranges per marker? Ask for a real sample payload for a real panel, not an abstract schema.
4. How are marker and panel identifiers versioned? Renamed panels and shifting codes are a quiet source of breakage, so ask what happens to your integration when the catalogue changes.
5. How do I learn that a result is ready? Polling an endpoint, a webhook, or a callback. Get the current answer rather than the roadmap answer, and design for what exists today.
6. What are the error semantics and are writes idempotent? Ordering a physical test twice because of a retry is an expensive class of bug.
7. How are exceptions surfaced? A haemolysed sample, a missed pickup, a marker that failed. Ask what your system receives and who talks to the patient.
8. Which collection methods and which countries are live today? Coverage claims often describe the roadmap. Ask which cities have same-day pickup this month.
9. What does the compliance pack contain, and can my lawyer read it first? Processing agreement, sub-processor list, hosting location, device classification position.
10. What happens to my data if we stop working together? Export format, exit window, and whether records are locked behind proprietary identifiers. Your users' history should stay portable.

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

• Diagnostics as a Service (DaaS) is ordering laboratory tests through one API while the provider runs the labs, the kits, the logistics and the regulatory framework behind it.
• Structured results means a marker identifier, a value, a unit and a reference range in machine-readable form, rather than a PDF your code has to parse.
• Reference range is the interval the analysing laboratory applies to a value, which depends on method, age and sex, so it travels with the result rather than living in your codebase.
• Sandbox is a non-production environment with realistic payloads, which is where exception handling should be written before a real tube exists.
• White-label means the end user sees your product's brand on the dashboard, the PDF and the domain, with the platform invisible behind it.

Sources

• Aniva API documentation
• ISO 15189:2022, Medical laboratories, requirements for quality and competence
• Regulation (EU) 2016/679, General Data Protection Regulation
• Regulation (EU) 2017/745 on medical devices (MDR)
• Regulation (EU) 2017/746 on in vitro diagnostic medical devices (IVDR)
• Medizinprodukterecht-Durchführungsgesetz (MPDG)
• Sec. 299a StGB, corruption in the healthcare sector

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.