Newsgroups: comp.risks
X-issue: 12.58
Date: Fri, 25 Oct 1991 16:38 EST
From: HORN%athena@leia.polaroid.com
Subject: FDA-HIMA Conference on Regulation of Software

On 9 and 10 October 1991, the Health Industry Manufacturers Association (HIMA)
and the Food and Drug Authority (FDA) had a joint conference to explain FDA
regulation of software.  The following is a summary of highlights from that
conference.  (If you are actually involved with potentially regulated software,
contact the FDA for the complete rules and contact an expert.  This area is as
complex in its details as the tax laws.)

First, what does the FDA regulate?
  1) Under the 1936 Act, any medical device, drug, or practice.
  2) Under the 1990 Safe Medical Devices Act, authority to examine
     devices was expanded.

Software may be involved in any of four ways:
  1) It may be a device
  2) It may be used in the manufacture of a device or drug
  3) It may be used in record keeping
  4) It may be contracted or purchased from a third party for one of the above.

FDA approval involves two steps: approval to market and approval to sell.
Approval to market involves one of two things: 1) A PMA for new medical
technologies (see an expert now).  2) A 510(k) for equivalent medical
technologies (substitutes for some previously approved device).

For a 510(k) approval there are three categories of approval difficulty based
upon the hazard to patients and others:
 1) minor, little risk of injury either direct or indirect
 2) moderate,
 3) major, risk of death

An example of a minor is a urological machine comprised of a funnel, flask,
scale, and computer for measuring urinary function.  It is very hard to hurt
anyone when this machine malfunctions.  A misdiagnosis injury is also very
unlikely because many other measurements and human interventions will take
place before a decision is made.  An example of major is the remote programmer
for a pacemaker.  Death is a likely direct result of a malfunction.

The FDA examination for a 510(k) is proportionate to the risk.  For a minor
risk item the FDA will probably accept a detailed development plan, and
defendable development, configuration control, and validation methodologies.
For a major risk item, they will examine all the validation results in detail
and demand thorough hazard analysis.  They will challenge many details to
assure themselves by spot inspection that the validation is probably complete.

For more details ask the FDA for a copy of the 510(k) reviewers guidance.  This
is the document used by the 510(k) reviewer and is freely available to the
public.

Then comes approval to sell.  This is based upon a Good Manufacturing Practices
(GMP) inspection.  Again, the inspection detail will be a function of the risk
to the patient and others.

For a minor risk item, they might not inspect at all.  Most likely, they just
verify by spot checks that the claims made in the 510(k) are being kept.  For a
major risk item, they may inspect a lot.  If someone actually gets hurt, expect
an army of inspectors swarming over everything.

For software there was little surprise that the inspectors verify all the
claims in the 510(k).  The surprise was in how ancillary manufacturing software
and purchased software are treated.  First, any software might be inspected.
If its failure could lead to injury it is subject to inspection.  This means
that a spreadsheet program on a PC will be subject to inspection if it is used
to compute a quality parameter.  Second, there is no assumption of validity for
off the shelf software.

For more details, the FDA provides copies of GMP practices regulations to
anyone who asks.

In a recent GMP inspection a drug maker was hit with violation notices because
an off-line PC was being used to run a statistical process control package as
part of a process improvement effort.  The SPC was not directly used to control
manufacture or determine quality.  Other equipment handled that.  The problems
listed were:
 1) The PC was not under strict hardware maintenance schedule with
    change control and serial number tracking of components.
 2) The specific PC hardware configuration was not validated.
 3) The SPC program validation was inadequate (the drug manufacturer had
    run and documented test cases before placing it in use).
 4) The PC was not regularly backed up
 5) There were no documented procedures for disk space management.
 6) There was not a documented procedure and records for software
    change and update validation.
 7) There was not sufficient security and auditing to assure that
    the software was not changed during use.
The manufacturer was told to fix these problems.  If they were not fixed, the
factory would eventually be shut down.

This attention to software is new at the FDA.  It went into effect this summer
and more regulations take effect this fall.

The other area that is catching people by surprise is the extent of the
definition of device and manufacture.  Most recently, the makers of blood bank
software were hit.  They had not previously realized that the database software
for tracking blood donations was a medical device and probably a class 3
device.  Big time mistake.  About a third of the blood bank software vendors
have been closed, and their software recalled by the FDA.  There is an open
issue around hospital and laboratory information systems.  These may also be
medical devices depending upon how they are used.

As an example: a mainframe manufacturer M ran an advertisement claiming that
since hospital X used M's machines, it could deliver superior care.  By doing
this, manufacturer M has made a medical efficacy claim and converted their
mainframe into a medical device.  In theory, they must now get a 510(k), GMP
inspected, prove the safety of their mainframe, and demonstrate that it does in
fact improve medical care.  In practice, they get a phone call telling them
``Don't be fools.  Stop running that ad.  You don't realize what you are
doing.''

The HIS and LIS vendors are at more risk.  If a failure in an HIS or LIS
software leads to incorrect recording of critical patient information that can
then cause death, they may be class 3.  It depends upon what other safeguards
exist.  If the usage label does not require other safeguards exist, class 3 may
follow.

The FDA approach differs from that of MoD and others in that there is no FDA
approved methodology.  The FDA will not state that anything is guaranteed
acceptable.  Instead you are always subject to challenge.  They claim that this
allows them to accept new methodologies as they are proven.  It also lets them
reject anything and not expose them to the risk of making a decision.  If
anything goes wrong, its your fault and you (not the FDA) are liable.

Rob Horn     horn%hydra@polaroid.com