What Is IEC 62304 for Medical GUI Software?

IEC 62304 is the international standard for medical device software lifecycle processes — published jointly by IEC and ISO. It applies to all software embedded in or used by a medical device, including the HMI and display layer, and requires that development processes be applied proportionally to the software's safety classification. IEC 62304 classifies software into three safety classes: Class A (no injury risk), Class B (non-serious injury possible), and Class C (serious injury or death possible). Most patient-facing clinical display software falls under Class B or Class C.

The standard is recognised by the FDA (via FDA's software guidance documents and 21 CFR Part 820) and by the EU Medical Device Regulation (MDR 2017/745) as the appropriate framework for medical device software development. Products seeking 510(k) clearance, CE marking under MDR, or other regulatory approval that include embedded display software must demonstrate IEC 62304 compliance for that software component.

Choosing an embedded GUI framework that does not support IEC 62304 compliance creates a documentation gap that regulatory reviewers will identify. Sparklet provides the MISRA C compliant source code and engineering support that medical device teams need to include their GUI layer in a credible IEC 62304 safety case.

IEC 62304 Software Classes for Medical Display Software

Class A — No Safety Hazard

Class A applies to software where failure cannot result in injury to the patient or user. In a medical device context, Class A display software includes administrative screens (user account management, maintenance logs, calibration history records, service mode displays) where incorrect display cannot affect clinical decision-making or patient therapy.

Class A carries the lightest development lifecycle requirements — a basic software development plan and a maintenance process are sufficient. No formal architecture documentation, no unit testing evidence, and no coding standard mandate applies at Class A. However, using a MISRA C compliant framework like Sparklet throughout the device software — even for Class A components — simplifies the system boundary analysis and avoids questions about software partition contamination between Class A and Class B/C components in a mixed-class device architecture.

Class B — Clinical Display Software

Class B is the most common classification for clinical display functions where software failure could cause injury that is not immediately life-threatening. This encompasses the majority of patient-facing display functions on medical monitoring equipment:

Vital signs display — heart rate, blood pressure, SpO2, temperature
Drug infusion rate, volume, and dose display
Device status, mode indication, and battery/power display
Diagnostic measurement overlays where errors could result in suboptimal clinical decisions

Class B requires a software development plan, software requirements specification, software architecture design documentation, software integration and system testing, and anomaly management. MISRA C compliance substantially reduces the audit burden for Class B software components. Sparklet's complete source, documented 7-layer architecture, and Embien's anomaly register directly satisfy these requirements. See Medical Device GUI applications.

Class C — Critical Alarm Display

Class C is required for display software where failure could directly contribute to life-threatening injury. This applies to critical alarm display functions:

Ventilator high-pressure and disconnect alarm indicators
Defibrillator charge-ready and energy-delivered confirmation displays
High-risk infusion system drug delivery confirmation
Operating theatre patient monitoring critical parameter alarms

Class C adds additional requirements to Class B: unit-level testing for all software units, software unit verification evidence, and formal software detailed design documentation. Sparklet's source code access, MISRA C compliance, and documented 7-layer architecture provide the technical foundation for Class C component integration. Embien's engineering team supports the required documentation activities for Class C regulatory submissions, including design history file (DHF) artefact generation and FDA/MDR regulatory reviewer queries.

Why Medical Device Display Software Is in the IEC 62304 Safety Chain

Safety engineers sometimes attempt to argue the display layer is not safety-relevant — that the underlying measurement, sensing, and actuation logic carries the safety function. This argument does not survive regulatory review. Consider the clinical consequences of display software failure:

A patient monitor that fails to render a SpO2 alarm due to a GUI rendering bug — the nurse at the station is not alerted to the deteriorating patient.
An infusion pump that displays a drug concentration or rate incorrectly due to a floating-point display rendering error — the clinician programmes the incorrect dose.
A diagnostic imaging device that renders a measurement overlay at the wrong screen position — the clinician misinterprets an anatomical measurement.
A ventilator whose pressure alarm indicator fails to illuminate during a circuit fault — the respiratory therapist is not alerted.

In each scenario, the software causing the harm is the display layer. IEC 62304 explicitly includes display software in its scope. Regulatory bodies have issued post-market safety actions related to display software errors in medical devices, confirming that the GUI layer is unambiguously within the IEC 62304 software safety chain.

The implication is clear: the embedded GUI framework underpinning medical device displays must be developed and documented in a manner consistent with the device's IEC 62304 software class. A GUI framework that cannot demonstrate MISRA C compliance, does not provide source code access, and has no professional engineering support is not a credible component in a Class B or Class C medical device safety case.

IEC 62304 Requirements by Software Class: Sparklet's Contribution

Requirement	Class A	Class B	Class C	Sparklet Support
Software development plan	Required	Required	Required	Embien provides component description for DHF
Software requirements specification	Not required	Required	Required	Widget API documentation as requirements baseline
Software architecture design	Not required	Required	Required	7-layer architecture documentation provided
Software detailed design	Not required	Not required	Required	Module-level design documentation on request
Software unit implementation	Not required	Required	Required	Full source code delivered; MISRA C compliant
Software unit verification	Not required	Not required	Required	Source code enables customer unit testing
Coding standard (MISRA C)	Optional	Recommended	Required	Full MISRA C compliance, static analysis provided
Anomaly management	Not required	Required	Required	Embien anomaly register provided to customers
SOUP documentation	Basic	Full	Full	Embien provides SOUP assessment artefacts

IEC 62304 Process Requirements: SOUP Documentation and Sparklet Integration

Four key process areas where Sparklet's engineering properties support IEC 62304 compliance activities.

Software Development Plan — Known-Provenance Component

The software development plan must address how SOUP (Software of Unknown Provenance) — commercial or open-source software components not developed under IEC 62304 — will be managed. Sparklet is supplied with source code and documentation by Embien, enabling customers to characterise it as a known-provenance software component rather than generic SOUP, reducing the uncertainty in the safety case.

Software Architecture Documentation — 7-Layer Structure

IEC 62304 requires documented software architecture identifying all software items and their interfaces. Sparklet's 7-layer architecture (APP → WID → GDI → EXEC → RS_MIN → UTIL → HAL) provides a clean module boundary structure that maps directly to IEC 62304 software item decomposition. Embien provides architecture documentation for Class B and Class C DHF submissions, with module-level detailed design documentation available on request for Class C.

Coding Standard and Static Analysis — MISRA C Throughout

IEC 62304 requires that a coding standard appropriate to the software class be applied. MISRA C is the most widely accepted coding standard for embedded C software in regulated industries. Sparklet's MISRA C compliant codebase and Embien's static analysis evidence satisfy this requirement without requiring the medical device team to audit every line of the GUI library independently.

Anomaly Management — Formal Issue Register Provided

IEC 62304 requires that software anomalies be tracked, evaluated for safety impact, and resolved or documented. Embien maintains a formal anomaly tracking process for Sparklet and provides customers with information about known anomalies and their safety significance as part of the product support relationship — satisfying the SOUP anomaly documentation requirement for Class B and Class C submissions. See Safety-Critical HMI for a cross-standard comparison.

Sparklet's IEC 62304 Support Capabilities

Properties that enable medical device teams to integrate Sparklet into a credible IEC 62304 Class B or Class C embedded display software safety case.

MISRA C Compliant Source Code

Sparklet's entire codebase is MISRA C compliant — verified with static analysis. MISRA C eliminates the classes of undefined C behaviour (heap fragmentation, implicit type errors, unbounded execution) that are particularly dangerous in patient-safety display software. Static analysis evidence is provided for the customer's IEC 62304 design documentation.

Full Source Code — Class C Unit Testing

Sparklet is delivered as complete C source code. IEC 62304 Class C requires software unit verification — which requires source-level access to the GUI component. Binary-only libraries cannot satisfy Class C unit testing requirements. Sparklet's source delivery enables code review, static analysis, and widget behaviour verification at the unit level.

Documented 7-Layer Software Architecture

Sparklet's 7-layer architecture (APP → WID → GDI → EXEC → RS_MIN → UTIL → HAL) defines clean module boundaries with documented interfaces — directly supporting IEC 62304's software architecture decomposition requirement and DHF submission formats.

Direct Engineering Support for Regulatory Submissions

Embien provides direct-to-engineer technical support for medical device customers navigating IEC 62304 integration. Our team has experience supporting regulatory submissions that include Sparklet as a display software component — answering regulatory reviewer questions about software architecture, coding standards, and anomaly management.

Frequently Asked Questions: IEC 62304 Medical GUI

Is Sparklet IEC 62304 certified?

Sparklet is not sold as a pre-certified IEC 62304 software component. Instead, Sparklet provides MISRA C compliant source code, architecture documentation, and engineering support that medical device teams integrate into their IEC 62304 development lifecycle as a software component. This is the standard model for third-party embedded software in medical device development — the device manufacturer is responsible for the overall software development lifecycle and regulatory submission; Embien provides the technical artefacts needed to include Sparklet in the design history file.

What software class is a patient monitor display?

Does MISRA C compliance satisfy IEC 62304 requirements?

Can I use Sparklet in an FDA-cleared medical device?

How do I document a third-party GUI library in an IEC 62304 safety case?

What is the difference between IEC 62304 Class B and Class C for display software?

IEC 62304 Medical GUI: Embedded Display Software for Regulated Medical Devices