AI in Healthcare
PHI De-identification Methods: A Practical HIPAA Guide
Compare PHI de-identification methods under HIPAA: Safe Harbor, Expert Determination, tokenization, free-text redaction and re-identification risk.
November 05, 2026Read more
The safety class you assign under IEC 62304 decides how much engineering evidence your software owes for the rest of its lifecycle. IEC 62304 software safety classification sorts software into three classes, A, B and C, based on worst-case harm after external controls are accounted for.
That last phrase carries the weight. Hardware mitigations, architectural segregation and external risk controls can all shift an item's class, which means design decisions made before sprint planning change your obligations for detailed design, unit verification and documentation. Get the classification reasoning right early, and the lifecycle workload matches the actual risk; get it wrong, and you either over-engineer a low-risk component or face a redesign mid-project when an auditor reclassifies it.
Scope of IEC 62304 and the edition that applies today
The edition in use today is IEC 62304:2006 with Amendment 1:2015, sold as one consolidated publication. The IEC Webstore entry for IEC 62304 records first publication in 2006 and Amendment 1 on June 26, 2015, and that amendment updated software safety classification to a risk-based approach.
The standard applies when software is itself a medical device, such as standalone SaMD, and when it's embedded in or integral to a hardware device. Its scope covers processes, activities and tasks for developing and maintaining medical device software. It explicitly excludes medical device validation and final release, even when the complete device consists entirely of software, so those duties remain in your quality system and regulatory pathway.
The U.S. Food and Drug Administration lists the consolidated edition as a recognized consensus standard. Check current status on the FDA standards and conformity assessment program page before you cite recognition in a submission. Recognition gives teams a shared lifecycle baseline across markets, but jurisdiction-specific obligations still apply. Confirm which edition your regulator and notified body reference now, and use SaMD engineering support if you need help applying that lifecycle to a product plan.
IEC 62304 safety classes and the lifecycle work each adds
The class letter on your software system decides how much lifecycle evidence your team owes reviewers. IEC 62304 assigns each software system a class from the worst-case harm it can contribute to after risk controls external to the software are applied, and the ISO catalogue entry for IEC 62304 sets out the three classes, A, B and C, on that basis.
Lines of code, feature count and cybersecurity exposure don't set the class. A small component can be Class C if its wrong output can drive a harmful therapy decision. A large reporting component can sit lower when a clinician verifies its output through an independent path before acting. Your hazard analysis, harm severity and the independence of external controls drive the answer.
What each class adds to the core lifecycle
Every class carries core work for development planning, unit implementation, system testing, configuration management and problem resolution. Higher classes add design depth and verification evidence on top of that core. The practical effect is schedule impact: architecture reviews, unit-level records and traceability checks need owners and time in the plan, rather than a documentation pass at release.
IEC 62304 safety classes at a glance
| Class | Worst-case harm after external controls | Lifecycle obligations added |
|---|---|---|
| A | Software cannot contribute to a hazardous situation, or the resulting risk is acceptable | Core processes only, development planning, unit implementation, system testing, configuration management and problem resolution |
| B | Unacceptable risk with harm limited to non-serious injury | Core processes plus architectural design and unit verification |
| C | Unacceptable risk with harm that can include death or serious injury | Core processes plus architectural design, detailed design, unit verification and unit-acceptance criteria |
Read the table as a staffing signal. Class B means someone has to own an architecture record that reviewers can test against requirements, plus unit verification evidence that survives an audit sample. Class C means detailed design must exist at a level where an independent reviewer can follow each software unit, its interfaces and its acceptance criteria before implementation is accepted. If you discover that obligation after code is written, you'll rebuild records from commits and memory, and reviewers will see the gaps.
Decomposition changes the workload
The highest class among components sets the overall system class, so weak decomposition raises the evidence burden for the whole product. Narrow interfaces, clear item boundaries and documented data flows let you argue for different classes at item level where the hazard analysis supports it. Broad shared services, shared databases with no access boundaries and undocumented callbacks make that argument hard to defend. Reviewers test the argument against the interface documentation: what crosses each boundary, in which direction, and what each side does when the data is missing or out of range.
Take a product with two items. A reporting module formats results for clinician review and, on its own analysis, fits Class B because an error could delay follow-up while a clinician checks source values in the EHR. The system it ships in carries Class C because a wrong output, accepted without an independent check, could cause serious injury. Unless you separate the reporting module through narrow, documented interfaces and show that its failure can't propagate into the items carrying the serious-harm scenario, the system-level Class C evidence set will cover work you planned at Class B rigor. Architecture review is a classification activity as much as a design activity.
Data flow matters in that review. Trace where each clinical value originates, which item transforms it, who or what can act on it, and which independent control can stop harm. If a FHIR integration layer passes an unverified value straight into a calculation item, the integration layer may share the higher class. If it validates, logs and hands off through a defined interface that the calculation item rechecks, you have a cleaner boundary to document.
Three hypothetical examples
A patient education content viewer that displays approved text and videos, with no path into diagnosis or treatment, fits the Class A pattern. If a video fails to load, the patient loses information without the software contributing to a hazardous situation. You still need planning, system testing, configuration management and problem resolution. You don't add architectural design or unit verification solely because the viewer sits in a clinical app.
A visualization tool that charts trends for clinician review can fit Class B when a misleading chart could contribute to a minor, non-serious harm and the clinician can verify values against the source record before acting. The independent verification step must be part of the intended workflow, visible in the interface and described in instructions for use. If clinicians in practice act on the chart alone, your assumed control won't hold and the class rationale weakens.
A dose calculation component with no independent check fits Class C when a wrong result can lead to a dose that causes serious injury or death. Test coverage and code quality don't lower that class by themselves, because the question is worst-case harm if the software contributes to the hazardous situation. An independent hardware limit, a second calculation path or a mandatory clinician confirmation against source data could change the analysis, and only when that control is independent of the failing software.
Before you estimate delivery, list every software item, its interfaces and the worst-case harm it can contribute to after external controls. That list is the input to sprint scope, review staffing and test planning.
How ISO 14971 risk analysis sets the class
The class comes from your ISO 14971 risk management process. Engineering doesn't pick a letter because it matches the budget, and product doesn't inherit the class from the device regulatory category. You start with hazards and hazardous situations, state how software can contribute, then judge worst credible harm after controls that sit outside the software itself. That work supports the broader clinical systems described in our healthcare AI and integration work, where EHR interfaces often supply the independent data path in the analysis.
External controls include independent alarms, hardware interlocks, clinician confirmation before use and verified alternative data paths. Each control must be real, defined and part of the intended system context before it can affect the class. A note in a design document saying a clinician will probably notice an error doesn't meet that bar.
Classification procedure
List each software item and its intended use. Keep item boundaries aligned with deployable or reviewable units.
Pull hazardous situations from the ISO 14971 analysis. Use the harm and severity language already in your risk file.
For each hazardous situation, state the software contribution. Name the failure or wrong output that could help cause it.
Identify external controls and confirm each one is independent of the software. Record how a reviewer can verify that independence.
Determine worst-case harm severity after those controls. Judge the credible worst case, not the most likely outcome.
Assign the class and record the rationale in the risk management file. Link hazard, contribution, controls, residual risk and severity in one traceable record.
Reassess when intended use, interfaces, controls or clinical function change. Treat reassessment as a release gate for affected items.
Worked example with a sepsis alert
Consider a hypothetical sepsis alert in two configurations. In the first, the alert only prompts a clinician to review a lab result that's already available through the normal results inbox in the EHR. The independent path exists, the clinician reviews source data before acting, and the worst-case harm after that control may support a lower class. In the second, the same alert creates a medication order that proceeds without clinician review of the underlying result. The software now contributes directly to therapy, and the analysis points to Class C if a wrong order can cause serious injury.
For AI or continuously learning components, classify the software system in its intended clinical context, not the model file in isolation. We treat a retrained model that changes outputs, thresholds or the clinical workflow as a reassessment trigger. Better accuracy on a test set doesn't lower a class on its own, because classification follows potential harm after controls.
Running agile development under IEC 62304
IEC 62304 defines required processes and outputs. It doesn't prescribe a waterfall sequence, so iterative sprints can comply when each release produces the evidence its class requires. The failure mode we watch for is informal delivery: stories close, code ships, and nobody can show which requirement, design record or risk decision a change satisfied.
We recommend three anchors for each release. Keep a release-level software development plan that states scope, classes per item and planned verification. Baseline requirements per release so reviewers know which version a test result belongs to. Link sprint records to requirements, tests and risk items, so a story carries its evidence trail as it's built.
Your definition of done should name class-specific artifacts. For Class B and C items, done includes unit tests and unit verification records. For Class C items, done also includes design review records completed before implementation is accepted. If a story can't meet those conditions inside the sprint, it isn't done, however clean the demo looks.
Third-party libraries and frameworks, known in the standard as SOUP, need the same discipline. Identify each one with version and function, assess its risk in your system context, and monitor it for known anomalies that could affect safety. A dependency upgrade is a change to classify and verify, not routine maintenance to merge without review.
Change control ties the system together. Link version control tags to release records, and link your issue tracker to the problem resolution process so anomalies get evaluated, assigned and closed with rationale. Tooling alone doesn't create compliance. The traceable evidence trail does.
Run one check this week: pick a completed story from your current sprint and trace it to a requirement, a test result and a risk control decision. If any link is missing, fix the workflow before the next release adds more untraced work.
What Edition 2 changes and where it stands
As of writing, Edition 2 has not been published and is still moving through the IEC drafting and approval stages. Check the IEC Webstore for publication status before you rely on any Edition 2 text, and record the date of that check in your regulatory file. Until a final text is published and your regulators state how they'll recognize it, the consolidated 2006 edition with Amendment 1 stays your working baseline.
Draft descriptions circulating with the IEC document describe three proposed changes. Scope would widen from medical device software to health software. The draft adds lifecycle provisions for AI and machine learning. The three classes A, B and C would be replaced by two process rigor levels, labeled I and II in those draft descriptions.
Treat each of those points as a proposal until it appears in a published requirement. The level names come from draft text, and the final edition can still rename or redefine them. Don't map level I to Class A and level II to Class B or C in your procedures yet. A wrong guess cuts both ways: too little evidence for higher-risk items, or wasted effort on lower-risk ones.
Practical preparation doesn't need the final text. Keep your current Class A, B or C rationale complete in the risk management file, since any future mapping starts from that record. Flag AI and machine learning components now, with model change triggers that force reassessment. Watch the FDA recognition listing for any newer edition, and plan a gap assessment once the final text is available. Products already in development should finish their classification under the current edition rather than pause for a draft.
The material unknowns are specific: final scope wording, final level names and definitions, AI lifecycle requirements in normative form, and transition expectations from regulators. The same design decisions that set your class today, external risk controls and item boundaries, also determine how hard any future remapping hits your backlog.
Software safety classification is one part of building a compliant medical device. For the wider picture, see our guides to AI in MedTech engineering, FDA pathways for AI medical devices, and the predetermined change control plan.
Conclusion
The useful question now is which design decision would move a software item across a safety boundary. Run a short classification workshop before sprint planning: draw the candidate items, mark every proposed control that sits outside the software, and write down whether each control is independent, defined and part of the intended system context. If removing that control would raise the assumed harm, treat it as a class lever and price the added lifecycle work into the roadmap before the epic is split.
Make the pass concrete with a workflow view. On a product like Diagnoo's DICOM-to-subspecialty-report workflow, secure upload, case matching, radiologist review and PDF report delivery can expose different failure paths inside one product. Separation of items, independent review paths and monitored interfaces stop being design taste once they decide how much verification, documentation and change control each item must carry.
Keep the classification record close to the architecture, not in a regulatory folder no one opens. A boundary sketch, the harm scenario used for each item, the external controls being credited and the reassessment trigger are enough to make the next sprint honest about scope. When any of those inputs change, the team knows which artifact to revisit instead of guessing whether the release is still clean.
If you want a second review of item decomposition, control independence or readiness for Edition 2 planning, book a consultation with Ekipa's HealthTech engineers.
Frequently asked questions
What are the IEC 62304 software safety classes?
Class A applies when the software system cannot contribute to a hazardous situation, or can only do so without unacceptable risk after external risk controls, so no injury or damage to health is possible. Class B applies when non-serious injury is possible, and Class C applies when death or serious injury is possible.
How do you determine the software safety class?
Start from the ISO 14971 risk analysis. Identify the hazardous situations the software can contribute to, account for risk control measures external to the software system, and assign the class from the severity of the worst possible resulting harm.
Can different parts of the software have different classes?
Yes. Software items can be assigned lower classes than the system if you document how they are segregated and show that their failure cannot contribute to the higher-severity hazard. Without that evidence, items inherit the highest class of the system.
Does the FDA require IEC 62304?
Use of the standard is voluntary, but the FDA recognizes IEC 62304 as a consensus standard, and many manufacturers declare conformity to it in submissions. The FDA's premarket software guidance uses its own Basic and Enhanced documentation levels, which are assessed separately from IEC 62304 safety classes.
When will IEC 62304 Edition 2 apply?
Edition 2 has not been published yet. Keep working to IEC 62304:2006 with Amendment 1:2015, check the IEC publication status regularly, and plan a gap assessment once the final text and regulator recognition are available.
