The most consequential decision in a digital health build is usually made by whoever writes the website, and usually without them knowing it.
Regulatory status for software does not turn primarily on how the product works. It turns on what the product is claimed to do, and those claims are established by what the company says about it, including on its own marketing pages. Two products with identical code can sit on opposite sides of the line because one of them describes its output as information and the other describes it as a finding.
That is why engineering teams building digital health products discover their regulatory position late, and why it is usually the marketing site rather than the pull request that moved them.
Below are six sentences of the kind that appear on real product pages. The exercise is not to give you a ruling. It is to show you where the question lives, because the answer changes what you build.
Necessary caveat, and it is load-bearing here. This is engineering guidance, not regulatory advice. Whether a specific product is a regulated device is a determination for regulatory counsel, and getting it from an article is how companies end up in trouble. What follows is about recognising which decisions to take to counsel early enough that the answer is still cheap.
Six sentences
1. "Track your daily step count and see your weekly trend."
General wellness framing. Describes an activity, makes no claim about a disease or condition, and the output is a record of what the user did.
2. "Log your blood pressure readings and share the history with your doctor."
Still a record. The product is a container for data the user supplies, and the clinical interpretation stays with the clinician. Note what is doing the work here: the product is not saying anything about the readings.
3. "Your readings suggest your blood pressure may not be well controlled."
This is a different sentence. The product has moved from holding data to characterising it against a clinical concept. Whether that crosses a regulatory line is a counsel question, but it is unambiguously the sentence where the question starts existing.
4. "Flags patients at elevated risk of deterioration in the next 48 hours."
A prediction about a specific clinical outcome, presented to a clinician to act on. This is squarely in the territory where regulatory status has to be established before launch, not after.
5. "Helps clinicians identify possible findings on chest imaging."
Image analysis producing a clinical finding. This is the category that dominates authorised AI devices, and companies building here generally know it.
6. "Our AI reviews your symptoms and tells you what condition you likely have."
Diagnosis, offered directly to a consumer. Whatever else is true, no product should ship this sentence without having taken the regulatory question seriously first.
The pattern running through all six: the code did not change much between sentence two and sentence three. The claim did.
What changes once you are on the regulated side
Four things, and none of them are quick to retrofit.
Design controls become the process. Requirements, traceability from requirement to test, design history, and documented verification and validation stop being good practice and start being the artifact you are judged on. Teams that were shipping from a loose backlog have to reconstruct months of decisions.
Software changes carry a regulatory question. In an ordinary product, a change ships when it passes review. In a regulated one, each significant change raises whether a new submission is required before it can reach users. That single difference is what most founders underestimate, because it turns a continuous delivery pipeline into a gated one.
The evidence bar rises and shifts. Validation has to demonstrate that the product performs as claimed on a population resembling the intended users, which is a different exercise from demonstrating that the software works.
Post-market obligations attach. Monitoring, complaint handling, and reporting continue for the life of the product. This is the part that is invisible at launch and permanent afterwards.
None of this makes the regulated path wrong. Plenty of the most valuable digital health products are regulated devices. It makes the path expensive to enter accidentally, which is the only real argument for settling the question early.
The mechanism that decides whether you can ship
For anyone building with models, one regulatory development matters more than the rest, because it directly governs whether a product can be improved after launch.
FDA issued final guidance on Predetermined Change Control Plans on 4 December 2024. A PCCP lets a manufacturer specify, at the time of the original submission, a set of modifications that may be implemented later without a separate authorisation for each one. Without it, a significant change means going back. With it, pre-specified changes can ship under the plan already reviewed.
The guidance sets out three components. A description of the modifications, specifying whether changes are automatic or manual, global or local, and how often updates are expected. A modification protocol, covering how changes will be developed, validated, and implemented, including data management, retraining practices, performance evaluation, and monitoring. And an impact assessment, documenting the benefits and risks of the modifications and how risks are mitigated.
There are limits. A PCCP cannot cover modifications that would require a separate authorisation, and it cannot cover changes that depart from the intended use or would break substantial equivalence to the predicate device. It is a mechanism for planned evolution within a defined envelope, not a general licence to change the product.
Why this is an engineering article rather than a regulatory one. Read those three components again as build requirements. The modification protocol describes a retraining and validation pipeline. The impact assessment requires that you can characterise what a change does to performance. The description requires knowing whether your updates are automatic or manual, and at what cadence.
A team that built its training pipeline without version control over datasets, without reproducible validation runs, and without the ability to state what changed between two model versions cannot write a credible modification protocol, because the protocol describes machinery they do not have. That machinery is backend development and cloud engineering work, and it is dramatically cheaper to build before the first submission than to reconstruct after it.
What to settle before you build
Five questions, in order.
What is the strongest claim anyone will make about this product? Not the careful one in the spec. The one the website will make and the sales deck will repeat.
Who is the output for, and what do they do with it? Information for a patient to consider and a finding for a clinician to act on are different products regulatorily, even when the computation is identical.
Have we asked counsel, and when? Before architecture, not before launch.
If we are regulated, what is our update story? Whether you intend to file a PCCP shapes the training and validation pipeline you should be building now.
Who owns the claim language permanently? Marketing copy drifts. A product that was carefully worded at launch can be re-described by a new campaign two years later, and nobody tells engineering.
That last one is the trap that catches established companies rather than startups. The regulatory position was settled once, correctly, and then the website changed.
Where Woltrio fits
Woltrio builds the software and the engineering process underneath digital health products, including the parts a regulated product has to be able to evidence.
In practice that means version-controlled data and model pipelines where any release can be reproduced, validation harnesses that produce the performance record rather than a slide about it, and change infrastructure designed around the possibility that updates will need to be pre-specified rather than shipped freely. Where a product is still finding its shape, a scoped MVP built with those foundations costs marginally more than one without them and saves a rebuild if the regulatory answer comes back differently than hoped. Where models are central, that work runs alongside AI development, and where the product touches clinical systems it extends into custom EMR and EHR development. The wider capability set sits under services.
The summary worth keeping: the regulatory line is drawn by claims, the engineering consequences of being on either side are large, and the cheapest moment to find out which side you are on is before anyone writes the architecture. Ask counsel early and build as though the answer might be yes.
Start with a scoped discovery from Woltrio.