How to Read the IEC 60601-1 4th Edition: 12 Fragments, Not Clauses

The IEC 60601-1 4th edition is organized by hazard, not by clause. That is not a cosmetic change, and it decides how you read every draft that follows.

Edition 3.2 of IEC 60601-1 is organized by clause. You want leakage current, you go to Clause 8. You want mechanical hazards, you go to Clause 9. You want excessive temperatures, you go to Clause 11.

The 4th edition is not built that way, and the difference is not cosmetic. It changes what you look up, how you scope your project, and what a gap analysis against it actually has to do.

Here is what sits underneath the change, why it was made, and how to read the drafts without getting lost in them.

The two documents almost nobody reads

There are two public specifications behind the 4th edition. Both are publicly available; both have been sitting on the IEC servers for years, and almost nobody outside the working groups has opened them.

The Architecture Specification (V3.0) was approved on 5 May 2020, and it sets the philosophy for the 4th edition. Sharpen the focus on basic safety and essential performance. Clarify the concepts. Give a rationale for every requirement. Push the standard toward discrete, atomic, design-ready requirements written in consistent terminology (IEV 60050-880), rather than prose that has to be interpreted before it can be applied. It aligns the standard with the IMDRF Essential Principles (N47 and N52) so that it is regulatory-ready. And it looks past publication to a machine-readable database version of the standard.

I wrote about where all of this came from, including the 2015 SC 62A decision in Kobe that started it, in a LinkedIn post on 20 July 2026.

The Design Specification Outline followed on 30 November 2023. It is the road map that implements the architecture: which parts of the 3rd edition map to which working group, what other standards feed in, what is new, and what is being removed. It is the document that actually carves the work into the twelve hazard concepts. It also merges the collateral standards into the general standard, and that merge is a large part of why roughly 500 pages becomes more than 1,000.

Both specifications are on the IEC servers and free to download:

• Architecture Specification (2020)
• Design Specification Outline (2023)

The Design Specification has evolved since these documents were released, shaped by AG 50 editing team feedback. They are still the best available window into why the edition is shaped the way it is. If you are going to read one thing before you read a fragment, read the Design Specification Outline.

Why hazard, and not clause

A clause-organized standard answers the question what does this clause require? A hazard-organized standard answers a different question: what can hurt someone, and what do we do about it?

That matters for three practical reasons.

It matches how risk management already works. IEC 60601-1 has been built on ISO 14971 since Edition 3.0. That is not new in the 4th edition, and anyone telling you the risk-management foundation is the change has it wrong. What is new is that the structure of the document now follows the same hazard logic your risk file already uses. The standard stops making you translate between two organizing principles.

It stops the same hazard being addressed in multiple places. In Edition 3.2, thermal considerations show up in the enclosure clause (13.1.2), in the single-fault clause (13), in the applicable components clauses, and so on. Grouping by hazard forces the working groups to write each hazard once and to keep cross-references few and deliberate. The Architecture Specification asks for exactly that: limited cross-referencing, used on purpose rather than by accident. The move runs the other way too. Construction and ME systems (MES) are clauses of their own in Edition 3.2, Clauses 15 and 16. In the 4th edition they are not clauses at all. Those requirements are distributed across the standard, into the hazard fragments wherever they apply.

It makes the requirements addressable. A requirement written as a discrete, traceable statement can be tagged, filtered and pulled into a requirements database. A requirement buried in a paragraph of qualified prose cannot. That is the quiet ambition of the architecture, and it is the reason the drafts read differently from Edition 3.2 the moment you open one.

The map: twelve fragments, twelve working groups

The mapping is mechanical. Fragment N is written by Working Group 36 + N.

For current draft status of each fragment, see the fragment table in the 4th-edition hub, which is kept up to date as drafts circulate.

One reader described the map as a table of contents for the future standard. That is close to right, with one caveat worth holding onto: it is a table of contents for twelve documents that do not yet read as one. Making them read as one is the job of the merge, and of AG 50.

AG 50, and the problem of twelve authors

Twelve working groups drafting in parallel produce twelve dialects. One group writes “verify basic safety.” Another writes out the specific tests. One uses a term the way its own sector uses it; another uses the same term to mean something adjacent. Left alone, you get a standard that contradicts itself in the seams.

AG 50 is the editing team that stops that. It is made up of the leadership of all twelve working groups plus the project leadership, and it meets weekly. Its output is consistency: shared terminology, a shared style guide (the Design Specification, with a great deal more added), agreement on where a requirement belongs when two groups both have a claim on it, and a set of drafting rules that keep the fragments compatible before anyone tries to merge them. That work can reach into the starting concepts behind requirements, not only the words used to express them.

That is unglamorous work, and it is the reason the edition is slow. It is also the reason the merged document will be readable at all.

What CD1, CD2 and CD3 actually mean when you are reading a draft

This is the practical part, and it is where most people reading fragment drafts go wrong.

A committee draft is a snapshot, and it is frozen the day it is circulated. Nothing is edited into it afterwards. Here is the sequence, because it is the part that catches people.

It runs in five stages, and Fragment 1 makes a clean worked example because every document in the sequence exists.

1. The CD is circulated to the National Committees. Fragment 1’s first committee draft went out as 62A/1628/CD.
2. The comments are compiled into a CC. The national committees and their experts read the draft and file comments, and the comments are gathered up and circulated back as a compilation of comments. For Fragment 1 that was 62A/1656/CC.
3. The working group resolves them. Accepting some, partially accepting others, editing others, and rejecting others, often over several months or more. Nothing circulates while that is going on.
4. The resolutions are issued as a revised CC. In this case 62A/1656A/CC, carrying the full resolution of every comment, and it goes to the National Committees.
5. The next CD circulates with the resolved text in it. For Fragment 1 that was 62A/1759/CD, the CD2 that is open for comment until 16 October 2026. It is built from 62A/1628/CD and 62A/1656A/CC together: the previous draft, plus what the working group decided to do about every comment on it. ⚠️ 16 October is the IEC date, not yours: see the comment windows are the part people miss.

Two things follow from that sequence, and they pull in different directions.

The resolutions are not secret. The revised CC goes to the National Committees, so if you are active in yours, or you ask someone who is, you can find out what happened to a comment without waiting a year for the next draft. Note what that means: none of these documents sit on the open web. Every one of them, the CDs included, reaches you through your National Committee. That is a good reason to be connected to yours rather than watching from outside.

But the draft itself never changes. So there is still a long stretch where the newest circulated draft (CD, CDV or FDIS) is at the same time the most current draft available to you and materially out of date. A requirement you read in it may already have been resolved into something else. That is not a failure of process. It is how consensus standards development works, and it is why the draft in your hands has to be read as a direction of travel rather than as the answer.

That describes what circulates. The work itself lives somewhere else. Drafting happens in the OSD, the IEC’s online standards development database, and it is there from the start of a project through to publication of the standard. This is the database-driven way standards are now developed: the text is written and revised in the OSD, and the comments and the edits made in response to them are tracked in it as the project moves. So there is a continuous record of how a requirement got to where it is. Committee members can see it. If you are not on a working group you cannot, so the practical thing you can do is keep track of which stage has actually been circulated for each fragment, CD, CDV or FDIS, and read whatever you are holding knowing the work has carried on since it was frozen.

So when you read a fragment:

• CD1 is a first pass. Treat the direction as real and the specifics as provisional. Do not build a design decision on CD1 wording.
• CD2 has been through a full round of National Committee comment and resolution, so the thinking is more settled than CD1. It is still a committee draft.
• CD3 is unusual. Fragment 4 is on CD3 and will probably be the only one in the IEC 60601-1 4th edition project to run a CD3. For most fragments the intent is to publish a CD2, take the comments and move on toward the merge CDVs, which will be AG 50’s responsibility.

The thing that surprises people about the page count

Edition 3.2 runs about 500 pages. The 4th edition is heading past 1,000, and the number gets quoted as though the requirements have doubled.

They have not, quite. Two things inflate it.

First, Clause 3, terms and definitions, repeats in every fragment. Each fragment has to stand alone as a readable draft, so each carries its own definitions. That duplication disappears at the merge.

Second, the edition carries far more supporting material than Edition 3.2 ever did. The Architecture Specification requires each requirement to be accompanied by guidance, rationale, and an explanation of what changed from Edition 3.2. The old IEC TR 62348, which was a standalone document explaining the changes, is now built into an annex per subclause. That is genuinely useful to a reader, and it is a lot of pages.

It is also the single biggest reason the project takes as long as it does. Rationale was never written for every subclause of Edition 3.2, and writing a differences explanation for every subclause of a thousand-page standard is a very heavy lift.

How to actually read this thing

Seven steps, in order. Part of this came from a mentor of mine, and the sequence he drilled into me has held up ever since. Read the terms and definitions first, because you have to understand the language of the standard before anything else in it makes sense. Then read the rationale, because that is where the background and the context sit, and the more of it you carry up front, the easier the implementation gets later. Then go back and reread the terms and definitions, which land differently once the rationale has given them weight. Only then get your hands dirty in the requirements themselves.

1. Start with the Scope. Understand the scope of the standard and how it applies to your products: what is in scope and what is not. More products have been brought into scope under the broader scope that has been written, including SaMD. Do not assume that because the current edition did not reach your product, the 4th edition will not either.
2. Read the terms and definitions. Clause 3 of Fragment 1. Check them against the current IEC 60050-880 and any amendments, including the latest drafts where a published version has not caught up. Fragment 1’s terms should sync with 60050-880, but depending on which copies (Frag 1 and IEC 60050-880) you can get hold of they may not, so work from the most recent versions available to you.
3. Read the rationale annexes. This is where your gap analysis should start. The committee’s own “what changed and why” statements are a better source for it than reconstructing the diff yourself, and they are the closest thing the 4th edition has to the old IEC TR 62348, which is now built into an annex per subclause.
4. Reread the terms and definitions. Now that the rationale has given them context. This is the step people skip, and it is the one that makes the rest of the reading go faster.
5. Then Fragment 1, the general requirements. These decide what applies to you at all. Use specification drives what is in scope. Categorization points you to the requirements that apply and lets you set the rest aside. Nothing downstream is scopeable until this is done. This is also the point to start putting your conformity evaluation plan together, and you can do that today rather than waiting for the 4th edition: see what part of Fragment 1 is critical to start early.
6. Then read the fragments your device clearly touches. For most devices that is most of them, to differing degrees. Only ionizing radiation is genuinely device-specific.
7. Reread the rationale annexes. A second pass, now against the requirements that apply to your product(s).

What part of Fragment 1 is critical to start early: the plan and the file

Start with Frag 1 and you arrive, fairly quickly, at Clause 8 of Frag 1. It is called Conformity evaluation, and it is a clause in its own right, sitting after use specification and categorization. This is the part of the 4th edition that changes how you work rather than what you build, and it is the part you can start on today.

Two documents sit at the centre of it, and one contains the other.

The conformity evaluation plan is where you decide, in advance and in writing, what compliant means for your device: which requirements apply, what evidence shows each one is met, and who owns that evidence. The conformity evaluation file holds the plan and it holds the results. That is the whole shape of it:

The planning side is where the work sits. The plan pins down how your device is categorized, what your use specification says, which clauses you are evaluating and which you are not, what samples you will use and the worst-case test scenarios, and what order the evaluations run in. That is not a small job. It is also the job that decides whether everything downstream holds together, because a scope nobody agreed at the start is a scope everyone inherits later.

The record side is a chain, and the chain is the point:

Pull any link and the next one should be right there. That is what a reviewer is checking for when they ask the question you did not prepare for.

Two things surprise people about this.

None of it has to live in a new set of binders. The draft is explicit that the records forming the file may form part of other documents and files you already keep, and it names the risk management file and the usability engineering file as examples. Most organizations already produce or contract most of this evidence: safety and EMC reports, risk analysis, usability, software, design reviews, labeling assessments. What is usually missing is the plan that ties them to requirements.

It is not an invention of this committee. The Fragment 1 draft cites the FDA ASCA programme, the Accreditation Scheme for Conformity Assessment, in its bibliography, and attributes part of the specific-plan requirements to it directly. If ASCA is familiar to you, a good deal of this will be too. ISO/IEC 17025 is cited alongside it for third-party evaluating organizations.

And nothing in Edition 3.2 stops you working this way today. Edition 3.2 has no explicit requirement for a conformity evaluation plan, which is a different thing from prohibiting one. The teams already working this way have an easier time on every test project submission, and they will not be building this from nothing in the year they are trying to launch against the new edition.

The short version of this section ran on LinkedIn on 25 August 2026, where the discussion in the comments is worth reading on its own.

The comment windows are the part people miss

Every one of these drafts is open for a defined period, and then it is not. If you are not one of the experts writing the document, the comment window is your route into the text.

Two IEC dates worth having on a calendar as of 31 August 2026: Fragments 2, 4 and 10 close on 25 September 2026, and Fragment 1 closes on 16 October 2026.

The current status of every fragment, and the deadlines as they change, live on the 4th-edition hub.