[Interest] List traffic disappearing?

Roland Hughes roland at logikalsolutions.com
Tue Sep 14 14:12:28 CEST 2021

On 9/14/21 5:00 AM, Dan Allen wrote:
> My question, did Qt ever claim it was safe for use in such devices?
> Especially devices that are life critical?
> And also, are the device manufacturers not ultimately responsible for
> ensuring a device is safe?
> I was always of the assumption there were compilers, software libraries
> etc that were medical device safe.
> Apologies if these questions are stupid, I'm not a medical device
> expert. They came more from a personal concern as some of the things you
> state sound scary to me.

Your questions aren't stupid sir. Honestly I wished more people asked 
them. As to your first question



    Wide use within Medical Devices

Whether you are developing FDA or EU Class II or Class III products such 
as surgical robots, infusion pumps, patient monitoring systems or 
medical imaging applications, Qt gives you the technology to make robust 
and reliable systems. What you create with Qt will not only impress your 
end users, but provide them with a natural and seamless user experience.

Qt fully supports your FDA, EN, ISO, IEC and other major and emerging 
medical market's certification and compliance efforts. Leveraging this 
support with Qt's development services and partnerships with leading 
medical services companies, you can create more, code less, and deploy 
everywhere- and ahead of the rest .

In addition, Qt has tools certified to IEC 62304:2015 up to safety class C.


Your second and third questions are a bit more of a sticky wicket.

There are many different categories of software compliance.


Lots of different product classifications


Yes, products get recalled for software failures. It's not a bug if you 
are recalled, it's a failure.


There is actually a name for this stuff, a real name, not just IEC 62304 
as referred to in this BlackBerry documentation



Regulatory requirements are driving the demand for software that is 

to the IEC 62304 standard for “Medical device software – Software life 

processes.” IEC 62304 requires that manufacturers follow good 
development practices to produce high-quality software for medical 


I know they are pitching their RTOS in that thing, but it is a good 
informative read and unlike the earlier links won't induce sudden deep 
sleep. Much of what I skimmed seems lifted directly from FDA training 
documentation. One of the "good development practices" is you cannot use 
Git. At least you cannot use what people know as the free-wheeling 
default configuration of Git. You have to use a completely locked down 
source management system like the ones put out by Perforce and sometimes 
Team Foundation Server can be properly configured for use. It has to do 
with all of the audit tracking and the fact you can actually delete 
stuff out of Git which is a massive no-no.

Ah! SOUP - Software of Unknown Providence



Instead of pre-certification, in medical devices, Linux is generally 
handled using a concept from IEC 62304 called Software of Unknown 
Providence, or SOUP. Under these guidelines the use of Linux is 
considered as part of the risk assessment of the overall device, and 
potential failures of Linux as used in the device must be considered, 
and mitigated if they might cause harm to a patient.


That statement is both true and false. It's true if you are rolling your 
own Yocto or other Linux build. Manufacturers of SoMs (System on 
Modules) tend to spin up and get certification for custom Linux builds. 
This increases both sales and the value of their modules.

There are also companies like this


that have various previously certified builds and methods of getting new 
builds certified faster by assembling previously certified components of 
other builds.

There is another term that I'm brain spasming on right now. It ties into 
the previous discussion. This is where you reference previous 
certification as justification. Getting something like the Gnu C/C++ 
compiler through certification is a big expensive process. That's why we 
don't willy-nilly change versions on the systems creating final builds. 
There are third party certification companies that push such things 
through and you can pay money to obtain the sacred documentation.

So, depending on the classification of your medical device/application 
(apps running on a phone meant to control a medical device fall under 
said regs too) the manufacture isn't responsible for getting everything 
certified. I don't know of anyone who has certified an iPhone that could 
have a zillion different security breaching apps installed on it by the 
user, but I'm not on that side of the biz. I've never certified one of 
those apps. I ASS-U-ME they are allowed to use a clean phone but that 
may well be a false assumption.

A manufacturer can, with the proper paperwork and payments to the people 
who pushed it through, utilize "prior art." CoM (Computer on Modules) 
and SoM (System on Module) and SoC (System on Chips) manufacturers like 
this one:


spend a lot of time and money pushing their products along with BSP 
(Board Support Package) and embedded OSes through FDA certification to 
dramatically increase the price of their product.

The RTOS (Real-Time Operating System) vendors also spend a lot of time 
getting their wares certified on various hardware. Back in the day Wind 
River Systems went so far as to buy the Zinc cross platform GUI and roll 
it into their product so they would be the only RTOS on the market with 
a GUI. If you want to read a book for free on that dead product you can 
read it for free on Google Books.


Yes, I wrote that one too, very long ago.

Ultimately the manufacturer is responsible for eating the recall. There 
used to be a time when, after X FDA mandated product recalls you 
couldn't get product liability insurance anymore. Given the names 
appearing year after year with multiple devices on the FDA list, I must 
assume that time is mostly over.

Where things go pear shaped and sideways at the same time is when you 
produce Medical-Device-A and push it through to market. Jane Smith dies 
(or suffers significant injury) using Medical-Device-A. This gets 
reported up through the medical staff/hospital to the FDA either through 
the company or the company is notified by the FDA. A review, inquiry, 
investigation of the root cause occurs. That's when you, they, and 
everyone else finds out SOUP testing didn't manage to translate the test 
conditions for an 8+ year old race condition/abend level bug into your 
test plan. That's when the class action and personal injury lawyers come 
out of the woodwork like roaches in a New York tenement.

I know you wanted a straight answer but we are talking about government 
regulations and court cases. A bent cork screw is about as straight as 
it gets.

It sounds like such a simple phrase though, doesn't it?

"IEC 62304 requires that manufacturers follow good development practices 
to produce high-quality software for medical applications. "

That one phrase creates an alternate universe where everything fun and 
free wheeling about software goes away. It becomes physically impossible 
to defend yourself when using a product that allows race/abend bugs to 
remain in their bug database for years.

If you have further questions, please just email me off-list. I don't 
really check the interest emails much as none of my clients are using Qt 

Roland Hughes, President
Logikal Solutions


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210914/228ef25d/attachment.html>

More information about the Interest mailing list