[Interest] the path forward - that 7 year thing - was, , willy-nilly

[Roland Hughes]

On 3/26/21 1:39 PM, Michael Jackson wrote:
>      I'll start off by acknowledging your points, but we will just agree to disagree. I acknowledge that you have a*lot*  of years making/maintaining software for medical devices. But I'm with Hamish on this. I don't understand.
>
> What you are saying is that Qt was designed "perfectly" from day one with no extra API, not one bad API implementation and no cruft. Qt should never be updated to run on modern compilers against modern C++ specifications. Updated to run on modern operating systems. Qt should not explore adding APIs/Toolkits to the Qt ecosystem to allow Qt to be used on the billions of devices that we use every day. Qt should just stick with its technology from 20 years ago. TQtC shouldn't go after paying customers in order to, you know, pay its developers. TQtC should rely solely on an industry that, by your own writings, have a 15 year horizon. Not much of a business case for that. (For the record, I don't particularly agree with TQtC current licensing or LTS strategy.)

No. Not what I'm saying at all. I have no idea how you got there from 
what I've said.

Stable API.  Nothing ever gets deleted until it has a direct or mostly 
replacement *within* the existing product.

When Qt chased these markets it knew what the lifetimes would be. Now it 
has abandoned them.

> I also don't understand your argument that you want to update a medical device from 20 years ago with the latest and greatest toolkits. I can't imagine anything electronic from 20 years ago being able to actually load and run anything like Qt? How is the hardware even powerful enough to do this? You can't convince me that the medical hardware device manufacturers were thinking 15 years into the future for the next upgrade, 15 years ago.
The surgical robots being sold today will require 20 year support 
lifespans. Many of the devices sold over the past decade were sold with 
a minimum 10 year support and maintenance requirement. The development 
effort on these devices runs into the millions. You can't make a bet 
like that and find out a year later the supplier flew off to the Cayman 
Islands with Ted Cruz and your money.
> 50 Year Old equipment. You make the case even more for TQtC to pursue customers with a much shorter timeline. If TQtC concentrated on markets with 20-50 year timelines for updates how much revenue do you think they would make? Enough to sustain Qt development in any real capacity? Doubtful.

Okay. There's an education situation here.

I've never worked for a one-trick-pony medical device company. For 
certain there are the grant/research funded things coming out of college 
labs. That Phd. student doesn't take it to production. A Baxter, 
Hill-Rom, GE, etc. type player will be who said thing gets sold to. They 
will take it through FDA approval and to full production. Usually they 
end up hiring the person or small college team that created it.

Baxter (and I imagine all the rest) actually invest in many tiny startup 
medical device companies if there is a good idea that has already had 
some fundamental work. They invest with the intent of consuming some/all 
of it when it is obvious the thing will work. Here, this might help.

https://www.gehealthcare.com/products/accessories-and-supplies/clinical-accessories-and-supplies

Click on Products & Services and then click Equipment and follow across. 
Those are just the devices GE puts out under its *own* brand. It owns 
whole or in part lots of other little companies putting out medical 
devices under their own brand. Hill-Rom is much the same from that 
perspective.

You are thinking in terms of the x86 world where there are oceans of 
one-trick-ponies. Companies like Install-Shield that had one big hit 
followed by some flame-outs. Last I heard they were still just a one 
product company. It's a cultural thing tied to that platform.

Here's reality in the medical device world.

Year one you get told to create a new patient monitor that looks like 
any of the ones in this list of images.

https://duckduckgo.com/?t=canonical&q=patient+monitor+image&iax=images&ia=images

It has a pump for blood pressure cuff, SP/O2, thermometer, and ability 
to record/display some patient info like weight and body mass. The UX 
team comes up with a style, fantastic graphics, even a custom font to 
support all of the supported languages. Management tells you what they 
are going to buy for a processor and RAM. They put a stake in the ground 
on battery life and recharge time, etc.

You work like dog for 6-8 months. Product goes off for FDA approval. The 
day __after__ everybody goes out for drinks management team tells 
hardware team to split into two groups.

Group 1: Design and build a new & improved hospital bed with built in 
scale so nursing homes don't have to get immobile people up to weigh 
them. (For those who don't know, they are required to record resident 
weight at least monthly. One of the dead give-aways for abuse is 
significant weight loss without doctor visit.)

Group 2: Design a mattress or mattress cover to be a patient monitor for 
burn victims and other people whose skin is in such a condition you 
cannot use a blood pressure cuff or the SP/O2 finger clip.

Group 1 won't need much for software people. None if they purchase a 
prepacked scale display. Group 2 is going to re-use much of the source 
code from the just completed patient monitor for the UI and device 
messaging. If they've never built one of these before the real work is 
in the mattress or mattress pad. I don't know how they do it, but some 
of them manage to get blood pressure.

When you are just about done with that product management pulls the bulk 
of the software team off to work on a surgical robot.

These companies purchase a tool set and usually purchase support 
contracts for it. They pay lots more for tool sets that have already 
done all of the paperwork for the FDA. When it is a tool set suffering 
"massive churn" the constant testing and re-certification gets 
prohibitively expensive.

BlackBerry makes a lot of money with its certified QNX.

https://blackberry.qnx.com/en/software-solutions/embedded-software/medical

I think there is also someone selling a certified version of FreeRTOS.

If the tool(s) you use don't already have this proof and haven't already 
been blessed by the FDA, you have to get it done. Here is a write-up 
that I just quickly skimmed and won't be offended if you don't actually 
read.

https://www.integrasources.com/blog/linux-os-for-medical-devices/

The only phrase you have to worry about is SOUP. Software Of Unknown 
Provenance. Your Yocto build of Linux falls under that. If Qt is 
churning, it also falls under that unless QtC is continually going 
through FDA approval. CI has to include FDA approval process which is 
neither automated nor quick.

In a previous message I gave you the different layers going up from bare 
metal to RTOS (hard certifications required, no dynamic memory, etc.) 
Then I told you about the COMM module most manufacturers are moving to. 
This is a physical thing that can be certified independently then used 
on any number of devices. It removes all penetration threat because 
there now is no outside world connection for the device. It has a serial 
connection that accepts only a fixed group of messages throwing the rest 
away. Your Yocto build doesn't have a network stack, just the PPP type 
driver.

So, putting this into a shot glass for everyone, when you are working 
for a medical device company you are on something of a device treadmill. 
Once a device is launched it is expected to have a 15+ year life. You 
**will** have to support it for 15+ years, but you won't re-engineer it 
until then.

While that device is out there making lots of money and saving lives, 
you will use the same tools to work on many other devices.

You can't keep re-introducing SOUP every few months. Someone either has 
to get SOUP certified __or__ you have to mitigate RISK by removing all 
potential for SOUP to cause patient harm. One of the main mitigations is 
the message based design. Another main mitigation is the inclusion of an 
"easily accessible during emergency yet physically protected" physical 
off switch. You can't have a touch screen power down icon be your only 
method of shutting something off.

It is impossible to mitigate all RISK with something like an infusion 
pump. You can have the most perfect drug library in the world. It can 
have the most perfect of rules for dosages and one stupid bug that 
slipped through testing could send down 7L/hr instead of 7ml/hr. The 
driver for the pump motor has to have safety built into it that caps 
volume at a safe level. 7L/hr is going to blow a vein.


Because of SOUP and certification costs these companies tend to pay big 
bucks up front for good tools and they also tend to purchase support 
contracts.

The *do not* do subscription licensing. They generally don't do per-seat 
licensing.

When they pay for something like a support contract they expect 
**actual** support, not bugs rotting in a bug database for 12+ years and 
definitely don't take kindly being told "it's too hard to fix" or "if we 
fix it then other things will break."

If they pay for support on RHEL 6, you don't get to just drop the 
platform because it is inconvenient.

The entire purpose of choosing a high level application framework is so 
the kernel doesn't matter. The stable API remains the stable API. Under 
the hood remains under the hood.

-- 

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