This says in part:
This guidance applies to:
- Software used as a component, part, or accessory of a medical device;
- Software that is itself a medical device (e.g., blood establishment software);
- Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment); and
- Software used in implementation of the device manufacturer's quality system (e.g., software that records and maintains the device history record).
This document is based on generally recognized software validation principles and, therefore, can be applied to any software. For FDA purposes, this guidance applies to any software related to a regulated medical device, as defined by Section 201(h) of the Federal Food, Drug, and Cosmetic Act (the Act) and by current FDA software and regulatory policy. This document does not specifically identify which software is or is not regulated."
Which from my perspective as someone with 40+ years of software experience seems reasonable. You also find this in FAA regulations for things like airplanes (and probably drones real soon).
I have numerous family members involved with and investments in things which this potentially applies to and, if you read the rest of the linked section above, seems reasonably well thought out. Software development is a complex process and they try to rationalize how someone who makes, say a defibrillator, would go about the process to ensure that it works reliably and doesn't harm people.
On the other hand in the deeming regs we see this (page #8):
"FDA may clarify the distinctions between ‘component’ and ‘part’ in the future. Specifically, "Component or Part" means "any software or assembly of materials intended or reasonably expected: 1) to alter or affect the tobacco product’s performance, composition, constituents or characteristics; or 2) to be used with or for the human consumption of a tobacco product. The term excludes anything that is an accessory of a tobacco product." Components and parts of the newly deemed tobacco products, but not their related accessories, are included in the scope of this final rule. The following is a nonexhaustive list of examples of components and parts used with electronic nicotine delivery systems (ENDS) (including ecigarettes): e-liquids; atomizers; batteries (with or without variable voltage); cartomizers (atomizer plus replaceable fluid-filled cartridge); digital display/lights to adjust settings; clearomisers, tank systems, flavors, vials that contain e-liquids, and programmable software."
Now reading a bit before this we see that the FDA is deeming anything it decides is a "tobacco product" into a "component" or "part" of a "tobacco product" - including batteries, software and digital displays.
This is quite a distinction from the medical software described above.
After some thought it seems to me that this is because of the Soterra decision (also this) that prevented the FDA from treating vaping and e-cigs as medical devices (which they lost in 2010). So they can't really apply the "software for medical devices" stuff for vaping because they can't call them "medical devices."
So I guess rather than coming up with something reasonable (or because they are unhappy about Soterra) the choice was to make software (or anything else listed in the regs) a "component" of a "tobacco product."
Now a "medical device" is a sensible term when discussing software. Most modern "devices" these days have some sort of computer in them, even if its just to "debounce" a power switch. "Software" in this context means the code running some bit of electronic computer hardware inside the "medical device." The discussion also makes perfect sense in their section "2.1" above when discussing how to develop said software.
On the other hand the new "deeming" regulations seem to lump e-liquid, bottles, flavors and software into the same "component" part model and lash them to the Electronic Nicotine Delivery System (ENDS) device such that these things are all in fact "tobacco products."
This seems a significant stretch because clearly software cannot be "derived from tobacco" primarily because its composed of electrons and does not have a physical embodiment.
Rationally it would seem that over the long haul you would want software regulations, such as the medical ones listed above, to apply to ENDS to ensure that the ENDS don't catch fire, burn someone, cause the batteries to explode, etc. to the extent reasonably possible.
Most devices today use standard chips of various sorts to perform these functions so I don't see a huge need - but I readily admit that there need to be some standards in place. After all, these devices do output heat at a significant wattage level. Unfortunately for vaping there seems to be zero interest in this type of regulation - save for the Chinese who build most devices. From disassembling Chinese devices it would seem that they are all using a relatively small subset of technologies which by this point should be properly vetted for safety.
So my thought is that we are being punished, as vapers, for the Soterra decision.
No one could reasonably argue if the FDA suggested the medical device process be applied to ENDS design and manufacture. (Though with the number of devices already in the field and the extremely small number of recorded "incidents" its seems the industry is doing a very good job policing itself in this area. Additionally, to acquire insurance when building and selling these devices there is significant impetus to "do the right thing" relative to testing and development.)
But that doesn't appear to be what's been done for ENDS.
Instead they've created a new notion: software as a tobacco product under a different set of rules.