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
https://www.qt.io/industry/qt-in-medical/
=====
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.
https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/fda-bioresearch-monitoring-information/guidance-industry-computerized-systems-used-clinical-trials
Lots of different product classifications
https://www.fda.gov/medical-devices/device-software-functions-including-mobile-medical-applications/examples-device-software-functions-fda-regulates
Yes, products get recalled for software failures. It's not a bug if you
are recalled, it's a failure.
https://www.fda.gov/medical-devices/medical-device-recalls/baxter-healthcare-recalls-dose-iq-software-version-90x-used-spectrum-iq-infusion-pumps-software
There is actually a name for this stuff, a real name, not just IEC 62304
as referred to in this BlackBerry documentation
https://blackberry.qnx.com/content/dam/qnx/static-linuxlanding/static/QNX-Medical-White-Paper-f7124c5376aac812a5822f2523946dcb.pdf
====
Regulatory requirements are driving the demand for software that is
compliant
to the IEC 62304 standard for “Medical device software – Software life
cycle
processes.” IEC 62304 requires that manufacturers follow good
development practices to produce high-quality software for medical
applications.
====
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
https://semiwiki.com/eda/285176-linux-for-medical-devices-qa/
=====
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
https://www.timesys.com/industries/medical/
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:
https://www.toradex.com/computer-on-modules
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.
https://books.google.com/books?id=cdx_nLaqMn0C&pg=PP1&dq=Zinc+It&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwju-oWss_7yAhVC-J4KHfYjCj8Q6AF6BAgKEAI#v=onepage&q=Zinc%20It&f=false
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
anymore.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
