Scope
The document fixes the shared principles, concepts and terms for safety, effectiveness and security of health software and health IT systems across the whole life cycle, from concept to decommissioning, and names the points where responsibility passes between parties.
What the public record carries
The public abstract says the document gives health software and health IT systems their shared concepts and words, and does the same for the three key properties: safety, effectiveness and security. Its reach runs from the first idea to the point where a system is retired. It names the moments when one party hands responsibility to another, and the kinds of exchange that have to happen between several parties at those moments. It also gives other standards a common vocabulary, where those standards cover particular sides of the same properties, privacy included. It lists six groups of parties: organisations and professionals who design, develop, integrate, implement and operate these systems; healthcare delivery organisations and providers; governments, funders, monitoring agencies and customers; organisations seeking a common understanding of the concepts; trainers and advisers; and developers of related standards.
Basis. The abstract on the ISO record is public and is the basis for this page. The clause text of the draft is not public.
Why it matters in a health estate
A scope that covers everyone is easy to read as covering no one in particular. The practical question for a CISO is narrower: which of those six parties is my organisation, which transition points do I own, and which of the eight foundational elements in Clause 5 does my evidence have to answer for. The abstract answers the first question by naming the parties, and the contents answer the second and third at the level of clause titles.
What to do now
Write a one-page scope note for the organisation. Name the party you are, the systems you operate or supply, the transition points you own and the ones you rely on another party for. Keep it beside the register and revise it when a new system or supplier enters the estate.
The evidence a reviewer will ask for
| Evidence | What it is |
|---|---|
| Scope note | A dated note naming the party, the systems in scope and the transition points owned |
| Party map | The other parties across each transition point, with the responsibility each carries |
| Boundary statement | What the document does not cover, stated in the organisation's own words |
| Edition log | The edition relied on today and the date it was checked |
What a reviewer will ask
An auditor will ask which party the organisation is and where its responsibility starts and stops. A scope note that cannot answer in one line leaves every later claim open.
Common gaps
- The organisation is named as a party but no system is listed against it
- Two parties each assume the other owns a transition point, so no one holds the evidence
- A supplier is treated as out of scope because it is a cloud provider, although the abstract names cloud and other IT service providers
- The scope note cites the draft as if it were published and enforceable today
Before the draft publishes
List every system and supplier in the estate and mark the party and the transition point for each. Strike any line that cannot name both.
If the draft changes this row
The draft is edition 2 and 62 pages, one page more than the first edition. Its text and any change summary are not public as at 21 October 2026. This row follows the published first edition's structure, which is what your procedure should name today. The change watch emails you when the record changes or the draft text lands, and the row is re-read then. No one can tell you what moved before that, and this page does not guess.
Related rows
Who this binds. Every party in the life cycle of health software and health IT systems: developers, medical device manufacturers, integrators, system administrators including cloud providers, healthcare delivery organisations, funders, monitoring agencies and trainers.