---
title: "Regulatory context"
description: "A starting map of the regimes that may apply to a consumer health product, what each one asks of the product, and the large amount opsinjs does not contribute."
url: "https://opsinjs.pensievelabs.org/health/regulatory-context"
source: "https://opsinjs.pensievelabs.org/health/regulatory-context.md"
section: "Health"
kind: "health"
evidence: "mixed"
reviewed: "2026-09-02"
reviewer: "design"
aliases: ["DCB0129", "DCB0160", "MDR", "SaMD", "FDA", "CE mark", "UKCA", "regulation", "compliance"]
implements: ["disclaimer-note", "consent-sheet", "care-card", "source-citation", "dose-tracker", "questionnaire", "symptom-picker"]
---
> Elements written as `` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> Nothing is missing from this page. The data simply does not live in
> the prose.
This page is a map written by designers and engineers, to help you work out
which conversation to have and with whom. It is not legal or regulatory advice,
it is not current by definition, and it must not be used as a compliance
assessment. Every regime named here should be read in its current published
form with your regulatory, clinical safety and legal advisers.
## What this means [#what-this-means]
This page maps the regulatory regimes that a consumer health product may fall
under, so that the implementing team can establish which conversation to have and
with whom before the product is built. It names each regime, states the
jurisdiction it covers and the test that brings a product into its scope, and
stops short of restating what any of them requires.
The boundary between a regulated product and an unregulated one runs through the
middle of consumer health software. A step counter is not a medical device, and
software that takes a person's readings and tells them what to do about those
readings may well be one. Consumer health products live on the line between
displaying information and supporting a decision. Several of the design decisions
in this documentation are positioned with respect to that line: no diagnosis, no
prognosis, thresholds owned by the product team, and provenance stated on the
surface that carries the value.
opsinjs makes three kinds of evidence easier to produce. It supplies a documented,
versioned justification for interface decisions, measured accessibility
conformance for its own tokens and, where components exist, for those components,
and a statement of which decisions the system took and which it left to the
product team. None of the three confers regulatory status, and opsinjs cannot make
a product compliant with any regime.
## The rule [#the-rule]
**The implementing team establishes which regimes apply before designing the
surfaces that might trigger them, and cites opsinjs as documentation input rather
than as a compliance claim.**
### The regimes to ask about [#the-regimes-to-ask-about]
The five regimes below are the ones this page covers, each named in the form that
will find its current published text. A requirement appears in the table only
where this documentation can attribute it to the standard that imposes it, and an
empty cell records that this page names no requirement, not that the regime
imposes none.
| Regime | Jurisdiction | What brings a product into scope | Requirements named here | Who carries it |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| NHS clinical risk management standards: **DCB0129** for manufacture, **DCB0160** for deployment and use | England | Manufacturing a health IT system, or deploying and using one inside a health organisation | A named clinical safety officer, a hazard log, a clinical safety case, and evidence that identified hazards have been mitigated | The clinical safety officer, appointed ahead of an NHS procurement conversation rather than in response to one |
| EU medical device regulation, **Regulation (EU) 2017/745**, and the separate UK regime | EU and UK, which have diverged and have separate routes to market | The product's stated intended purpose. **Rule 11 in the Regulation's classification annex** pushes a great deal of decision-supporting software above the lowest risk class | | Whoever owns the statement of intended purpose, in marketing copy and in interface copy alike |
| **Software as a Medical Device**, the international framing; domestically, the **FDA**'s approach to clinical decision support software and the software provisions of the **21st Century Cures Act** | United States | Whether the software informs a person or directs a decision, read against the statutory exclusions for certain software functions introduced by the 21st Century Cures Act | | |
| Data protection: the **UK and EU GDPR**, and **HIPAA** | UK, EU and United States; other jurisdictions have their own regimes | Processing health data, which is a special category under the UK and EU GDPR. HIPAA applicability depends on which entity is processing rather than on what the data is, and a consumer app is frequently outside it | Additional conditions on the processing of special category data | |
| Accessibility law: the **European Accessibility Act**, the UK accessibility regulations and the **Equality Act**, the **ADA** and **Section 508** | EU, UK and United States | Certain consumer-facing digital products in the EU; public sector bodies in the UK, with the Equality Act applying more broadly; digital services under the ADA, and federal procurement under Section 508 | | The product-owning organisation, which may cite the measured evidence in the [Conformance report](../accessibility/conformance-report.mdx) |
Each regime is read in its current published form, including the two NHS
standards. The cells above name regimes and the tests that bring a product into
their scope, and they are a pointer into the published text rather than a summary
a team can rely on, this page included.
Intended purpose determines classification, and a product's own copy is evidence
of its intended purpose. The question that decides the medical device answer is
therefore what the product says it does, in marketing and in interface copy,
rather than what the team building it believes the product to be. The same
distinction governs the United States position, where software that informs a
person and software that directs a decision are treated differently and the
current guidance documents are where a product establishes which of the two it
is.
Health data is a special category under the UK and EU GDPR with additional
conditions on processing, and the consent surfaces that follow from those
conditions are covered in
[Consent and disclosure](./consent-and-disclosure.mdx).
### What opsinjs contributes [#what-opsinjs-contributes]
* **Design decisions with recorded rationale and dates.** A clinical safety case
that rests a hazard mitigation on interface behaviour needs a citable
justification for that behaviour, and these pages carry one that is versioned
and dated.
* **Measured accessibility conformance.** The measurements cover the system's own
tokens and, where components exist, those components, and each one is dated,
reproducible and published.
* **An explicit statement of the boundary.** Thresholds, ranges, clinical wording
and interpretation belong to the product team, and every page that touches them
says so.
* **A vocabulary for hazards.** The prohibitions on
[Clinical interaction guidelines](./clinical-interaction-guidelines.mdx) map
onto the interface hazards a hazard log records, and that mapping has not been
tested against a real log.
### What opsinjs does not do [#what-opsinjs-does-not-do]
* opsinjs does not confer, imply or support any regulatory status.
* opsinjs does not constitute a clinical safety case, a hazard log, or evidence
of clinical risk management under any standard.
* opsinjs does not make a product a non-device, and it does not keep a product
one.
* opsinjs does not provide legal, regulatory or clinical advice.
## Why (evidence) [#why-evidence]
**Cited by name rather than summarised.** DCB0129, DCB0160, Regulation (EU)
2017/745, the UK medical devices regime, the FDA's clinical decision support
guidance and the 21st Century Cures Act software provisions are all real,
published, findable documents, and this page names them so that a reader knows
what to search for. Their requirements are not paraphrased here, because
regulatory text changes on its own schedule and this page is reviewed every six
months.
**Opinion.** The claim that a design system can contribute usefully to a
clinical safety case is ours, and it is modest: documented, dated design
rationale is an input rather than a mitigation. No clinical safety officer has
yet assessed that claim against a real hazard log, and it stays at this strength
until one has.
**Opinion on sequencing.** The regulatory question is asked before the product's
copy is written, because intended purpose is established partly by what a
product says it does. Designing inside a stated boundary costs less than
rewriting an interface that has already claimed to interpret results.
What would change our mind: a clinical safety officer's assessment of what an
upstream design system can usefully supply to a hazard log and a safety case
would revise the contribution list above and the strength at which the opinion
is stated.
## Applying it [#applying-it]
Write your intended purpose down in one paragraph, early, and check every
piece of interface copy against it. "Helps you record and view your readings"
and "tells you what your readings mean" state two different intended
purposes.
Let marketing copy make a claim the product is not built or regulated to
make. Intended purpose is established by what the product says it does, and
the product's own screens are evidence of it.
Keep a hazard log from the first sprint, and add an entry each time a screen
could mislead someone. A hazard recorded during design is mitigated by
changing a specification.
Start clinical risk management when the NHS procurement questionnaire
arrives. Hazards identified after implementation are mitigated by changing
screens that have already been built, tested and released.
Cite opsinjs as design rationale where it helps, using wording such as "the
alert escalation model follows a published, dated specification", and give a
link and a version.
Present opsinjs as evidence of compliance. These pages state their own limits,
so a citation offered as compliance evidence misrepresents the document it
points at.
## Components that implement this [#components-that-implement-this]
{/* Generated from `implements`. Do not restate the list by hand. */}
`DisclaimerNote` is the one component in the system whose placement is governed by
rule rather than by judgement: where a surface could be read as clinical advice,
the disclaimer sits on that surface and not on a policy page. Its specification
requires the text to be supplied by the product, because a generic disclaimer
shipped by a design system would itself be the kind of claim this page warns
against.
## What this does not cover [#what-this-does-not-cover]
* **A survey of the field.** This page maps where to look and names the regimes
we most often see consumer health teams encounter, rather than surveying every
regime in force.
* **Jurisdictions beyond the UK, EU and US.** Other territories run their own
regimes and fall outside this page's scope.
* **Quality management systems.** Clinical evaluation, post-market surveillance
and vigilance are the substantial machinery that follows a device
classification, and none of it is covered here.
* **Clinical governance inside a health organisation.** Governance of clinical
practice sits with the organisation and is separate again from device
regulation.
* **Reimbursement, procurement and assurance frameworks.** These ask practical
questions of their own and are assessed separately from regulatory status.
* **Legal, regulatory and clinical advice.** The notice at the head of this page
states that these pages are none of the three, and nothing here substitutes for
a regulatory, clinical safety or legal adviser.
## Updates to this page [#updates-to-this-page]