Regulatory context

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.

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 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 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

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.

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 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

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)

mixedas at 2026-09-02

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

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.

Don’t

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.

Don’t

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.

Don’t

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

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

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

Last read through against the system on 2026-09-02. Due for review every 6 months; expiry is reported by pnpm run check:freshness.

Regulatory context

On this page