Friday 19 January 2018
By Mitch on Friday 19 January 2018, 14:15 - Regulations
Here is a quick follow-up of the new version of the FDA Guidance titled Medical Device Accessories – Describing Accessories and Classification Pathways, published in December 2017. This comes a bit in parallel to the Section 3060 guidance described in the previous post on the 21st Century Cures Act.
Friday 12 January 2018
By Mitch on Friday 12 January 2018, 15:00 - Regulations
Since the last blog post on US FDA guidance on software classification, things evolved quickly with the FDA. We know where they want to go with software as medical device, but not exactly how they will implement it.
Let's do a review of what has been done since the publication of the 21st Century Cures Act.
Friday 22 July 2016
By Mitch on Friday 22 July 2016, 13:28 - Regulations
The final version of the negotiated text of the new Medical Device Regulation (MDR) was published by the European Commission in June 2016. It is a big upheaval for all medical device manufacturers. Contrary to what the draft version of September 2015 contained, software is invited to the party.
Wednesday 17 February 2016
By Mitch on Wednesday 17 February 2016, 10:13 - Regulations
Warning: obsolete content. Please read: Is my software in class I, IIa, IIb or III.
Last update on 2016/07/31.
The British Standard Institute published in February 2016 a white paper titled How to prepare for and implement the upcoming MDR – Dos and don’ts. Register on BSI website to download the paper.
This white paper gives top-notch recommendations on the way to compliance with the future EU Medical Device Regulation (MDR), based on the draft version. But their interpretation of MDR classification rules on standalone software are somewhat surprising.
Monday 26 May 2014
By Mitch on Monday 26 May 2014, 00:02 - Misc
After MHRA's guidance on standalone software, we continue with another official document published by the International Medical Device Regulators Forum (IMDRF): the consultation on software as a medical device: Possible Framework for Risk Categorization and Corresponding Controls.
Wednesday 25 September 2013
By Mitch on Wednesday 25 September 2013, 17:28 - Regulations
After two years of gestation, FDA issues final Guidance on Mobile Medical Apps!
Friday 1 March 2013
By Mitch on Friday 1 March 2013, 14:31 - Standards
We've seen in the last post how to manage changes in legacy software. Let's see it from another point of view: the type of legacy software.
Friday 22 February 2013
By Mitch on Friday 22 February 2013, 14:09 - Standards
Most of medical devices manufacturers have legacy software that was not designed according to IEC 62304. The devices that embed legacy software were once verified and validated. These devices and their software work well and no major adverse event were raised by software issues.
But one day, the manufacturer decides that it's time to bring that legacy software into line with IEC 62304, to align the technical file of that software (or the contribution of software to technical file content) with up-to-date standard or regulatory requirements.
Monday 21 January 2013
By Mitch on Monday 21 January 2013, 15:34 - Standards
In the last two posts, we've seen what a software unit is, and when to do software detailed design, according to IEC 62304 and FDA Guidances.
Saturday 30 June 2012
By Mitch on Saturday 30 June 2012, 10:13 - Misc
After a long series of posts about agile methods, let's continue with
something less serious!
If you saw Prometheus, the sci-fi movie about a team of astronauts who search
for human origins, you were probably amazed by the Weyland Corp Medical Pod
720i. Like me.
Monday 23 April 2012
By Mitch on Monday 23 April 2012, 05:02 - Misc
I didn't have time to post anything worth it this week.
To give a side view of my last post about software classes, here is a link to DO-178B on wikipedia. It is the reference about software embarked in aircrafts.
If you take time to read this document, you will see that it goes very further than what we have today in IEC 62304. The constraints about design on high classes are very very hard to respect. That's normal, when you think that software is used in flight commands and other stuff in the cockpit.
It has some side effects, mainly to stretch software development projects, and to ban software from some parts of the plane, for cost-driven reasons.
For example, a microcontroler plus software plus electric motors would be perfect to memorize and retreive the position settings of the pilot's seat. But the cost to develop such software is very high, as the pilot's seat is seen as a critical component. Aircraft manufacturers prefer replacing software and microcontroler by good old analogic electronics to do the same task on some models.
In my humble opinion, the constraints of the two highest classes for software in aircrafts would be to high for medical devices. There is always a pratician, or an emergency medical service, able to "catch" the patient if something goes wrong. Whereas there is nobody to "catch" a falling plane if its flight commands fail. The consequences of risks are far higher in aircrafts, with potentially hundreds of victims in an accident.
That is why classes A, B and C, and their design constraints are enough for medical devices.
Next week, I'll talk about exemptions of ISO13485 for standalone software medical devices.
Saturday 14 April 2012
By Mitch on Saturday 14 April 2012, 23:35 - Standards
IEC 62304 defines three safety classes for software:
- Class A: No injury or damage to health is possible
- Class B: Non-SERIOUS INJURY is possible
- Class C: Death or SERIOUS INJURY is possible
Here comes the eternal question: Which class my software belongs to?
Friday 6 April 2012
By Mitch on Friday 6 April 2012, 11:08 - Misc
This article is the last of three articles which deal with the concept of
"inflation" of medical devices. The first
one was on inflation of standards, the second
about inflation of regulations. This one, the most interesting to my eyes, is
about multiplication of apps on mobile devices, especially smartphones and
More that 6000 apps are classified in the "heath", "heathcare" or "medical"
categories of the Apple or Android appstores. Many of these apps are classified
as medical devices and are in the scope of regulations like FDA and CE Mark.
Note that some apps may be regulated the FDA but not the CE Mark or
Friday 30 March 2012
By Mitch on Friday 30 March 2012, 10:51 - Regulations
Today I’m going to talk about the inflation to regulations in the world of
software for medical devices. In my previous
post, I had a look at the inflation of standards for medical devices. As
the medical devices industry is heavily controlled by regulations, they deserve
a dedicated post.
Monday 6 February 2012
By Mitch on Monday 6 February 2012, 18:14 - Regulations
New! MEDDEV 2.1/6 Guidelines on classification of standalone software released!
HIS, CIS, PDMS, RIS, PACS, LIMS … Which ones are medical devices, which ones are not?
To answer this question, the European Commission issued a new Guidelines document: MEDDEV 2.1/6, about the qualification and classification of standalone software as Medical Devices or In Vitro Diagnosis Devices.
After the draft guidance of the FDA about mobile apps, after the guide on regulation of health apps by a UK medical charity, this MEDEV is the third document released in a few months about standalone software.
Monday 28 November 2011
By Mitch on Monday 28 November 2011, 17:19 - Regulations
The GHTF (Global Harmonization Task Force) issued a draft of a new guidance on medical
device classification They recommend to implement four classes for medical
devices based on intended use: from class A (lowest risk) to class D (highest
risk). And they give a set of rules on how to choose the classification of the
Comparison with regulations
Wait, I've already seen this elsewhere. Classification of devices in Europe
(CE mark) and in Canada have systems very similar to what GHTF recommends. This
is a good thing to have an ongoing harmonization process. National regulations
copy what GHTF recommends and GHTF copies what national regulations require.
This is a virtuous circle. Maybe one day the FDA will implement this
Friday 25 November 2011
By Mitch on Friday 25 November 2011, 15:51 - Regulations
In How to
classify and CE mark software, I tried to make a thorough explanation about
how to obtain CE mark for software medical devices. Here is a short explanation
about Canadian rules.
Friday 4 November 2011
By Mitch on Friday 4 November 2011, 14:20 - Regulations
Medical devices shall have CE mark before being sold in the EU. The process to have CE mark can be summarized this way:
- Determining the class of the device,
- Choosing the CE procedure to apply,
- Declaring CE conformity of the device.
Software follows exactly the same process as other devices. Here are the steps to follow to CE mark software.