MISRA C in the medical sector: are you ready?

Last update: May 2022

The European Medical Device Regulation (MDR) came into force on 26 May 2021. While this is good news for public safety, it puts considerable extra pressure on medical device manufacturers. It also brings some new, perhaps not strictly medical, products into regulatory scope.

In response, companies are rapidly revising their processes. In particular, many are embracing the MISRA coding standards for C and C++. Here’s an overview of what’s changing and how it affects safety-critical software developers and project managers.

What products and circumstances does the MDR cover?

The MDR stipulates the regulations for "placing on the market, making available on the market or putting into service of medical devices for human use and accessories for such devices." It also regulates "devices used in the context of a commercial activity to provide a diagnostic or therapeutic service to persons," even when the devices are not themselves placed on the market. Even devices that are not intended for medical use, such as "lasers and intense pulsed light equipment for skin resurfacing, tattoo or hair removal or other skin treatment" are covered by the MDR.

What has changed?

Until recently, medical device manufacturers could choose between the EU Conformité Européenne (CE) mark or US Food and Drug Administration (FDA) approval. The CE mark was easier to obtain than FDA approval. However, FDA approval meant that the device was approved for use worldwide, whereas the CE mark was limited to the European Union.

From 26 May 2021, manufacturers have to comply with MDR if they want to access the EU market. There is an implementation period, but from 27 May 2024 no medical device may be placed on the EU market unless it conforms to the MDR and has a valid EU certificate of conformity.

The MDR is considerably more comprehensive than FDA market authorization. Among many other things, the MDR details the obligations of the involved economic operators, the marking process requirements for identification and traceability of devices, and the post-market surveillance of marketed devices. It also establishes penalties for non-compliance.

What does this mean for software in medical devices?

Given the importance of software in medical devices, it is no surprise the MDR pays particular attention to it. In some circumstances, software is itself considered to be a medical device. The regulations clarify this: "when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, [software in its own right] qualifies as a medical device."

Why is the medical sector embracing MISRA C/C++?

We discussed this with Flex, a leading company in the medical sector:

“Flex has been using a subset of the C language for programming embedded medical systems for over ten years. Using a subset is a pragmatic solution which helps us address most of the vulnerabilities in the core programming language. For example, when programming safety critical applications we use a subset of C specifically to address any potentially dangerous flaws. MISRA C is the obvious solution that allows us to approach the world of critical applications with extra safety. Code-reviews combined with static analysis and the automatic enforcement of sound coding guidelines by means of high-quality tools are the basis of most effective defect removal strategies.”

There are two clauses in the MDR that go beyond the general principle already present in directives 90/385/EEC and 93/42/EEC, namely that all safety practices employed must, at any time, comply with the generally acknowledged state-of-the-art standards.

• MDR Clause 17.2

This clause states that for devices that incorporate software, or for software that are devices in themselves, the software must be developed and manufactured in accordance with the state-of-the- art standards. These standards must take into account the principles of development life cycle and risk management, including information security, verification and validation.

MISRA Guidelines represent state-of-the-art coding standards for the development of high-integrity, safety-critical devices. Without ruling out the undefined and unspecified behaviors of the C and C++ programming language, no verification and validation is possible. This is the main focus of the MISRA Guidelines.

• MDR Annex ll, Clause 6

This gives more detail on software verification and validation. In particular, it prescribes the provision of information concerning all aspects of software design, development process and evidence of verification and validation addressing all hardware configurations and operating systems. All this is matched by prescriptions in MISRA Compliance: 2020, the document that regulates all claims of MISRA compliance.

The MISRA Guidelines have been applied many times in the context of IEC 62304, for the part of the requirements that deal with the selection of coding standards. They align pretty well with the requirements of the MDR (and FDA) for a traceability methodology and for auditable processes.

If you’d like to delve into this in more detail, Frank Büchner, Principal Engineer Software Quality with our German distributor Hitex, has written an excellent article in Medical Electronics. In his article (you’ll find it on page 22), Frank takes a detailed look at how to comply with the new regulations, including the use of our static analysis tool, ECLAIR, for verifying programming procedures and coding standards.

For safety-critical devices, such as medical devices, there is more to just obtaining approval or a (revised) CE mark; when things go wrong, the consequences of not following the generally acknowledged state-of-the-art standards can be catastrophic. We designed ECLAIR, from the outset, to provide support for traceability, auditability and qualifiability with respect to the strictest functional safety standards. Among the features we incorporated are:

• Accuracy combined with productivity

Most checkers for MISRA guidelines are exact (that means no false negatives, no false positives). With ECLAIR, imprecisions are handled in a way that maximizes productivity by emitting "caution" messages.

• Precise tracking and reporting

ECLAIR reports every source file, build command and configuration. It also includes robust checks to ensure perfect reproducibility so that the software that has been analyzed precisely matches the software that is running on the device.

• Auditable configurations

Tool configuration is automatically explained in English and in checklist form. That means the configuration is auditable, even without a precise knowledge of the configuration language.

• Automatic reporting

Summary reports are automatically generated and cover all MDR requirements.

The changes contained in the MDR are significant and the implementation date is fast approaching. If you’d like to see for yourself exactly how ECLAIR can help you comply with the new requirements you can head over to eclairit.com and get in touch with us for a free MISRA strategy talk! Don't wait, get ahead in the queue while there is still time.

Join our LinkedIn community to keep up to date with all our news.