Info for: Home | Site Map | Archives | About Us

Medical Device School

Safety and Efficacy First

Medical Supplies
 

 

Medical Devices

FEATURED PRODUCT:  Interpretation of FDA's (QSR) With QSIT references

A complete compendium to FDA's Quality System Regulation (QSR) with relative references to FDA's Quality System Inspection Technique (QSIT). Now ONLY $99 (limited time)

Developing policies and procedures
Preparing for FDA audits
Responding to 483 Observations and Warning Letters
Conducting Internal Audits or determining Gap Analysis  

Search This Site

 Medical Device Software

The FDA recently updated their guidance document for the content of premarket submissions for software contained in medical devices. The changes were substantial in content.

Let's compare the two versions of the guidance side-by-side.
Major Differences

Definition of Level of Concern

2005

Level of Concern refers to an estimate of the severity of injury that a device could permit or inflict, either directly or indirectly, on a patient or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use. We recommend that you describe the role of the software in causing, controlling, and/or mitigating hazards that could result in injury to the patient or the operator, because this is also a factor in determining the appropriate Level of Concern for your device.

1998

FDA/CDRH uses the term "level of concern" as an estimate of the severity of injury that a device could permit or inflict (directly or indirectly) on a patient or operator as a result of latent failures, design flaws, or using the medical device software. The extent of the premarket review process pertaining to software products is proportional to the level of concern. Therefore, it is important to clarify the role of the software in causing, controlling, and/or mitigating hazards which could result in injury to the patient or the operator.

The 2005 guidance distinguishes the use of the device according to it’s Intended Use (as opposed to what can also be executed in an off-label manner).

Level’s of Concern
2005

Major - We believe the level of concern is Major if a failure or latent flaw could directly result in death or serious injury to the patient or operator. The level of concern is also Major if a failure or latent flaw could indirectly result in death or serious injury of the patient or operator through incorrect or delayed information or through the action of a care provider.

1998

Major - The level of concern is major if operation of the software associated with device function directly affects the patient and/or operator so that failures or latent flaws could result in death or serious injury to the patient and/or operator, or if it indirectly affects the patient and/or operator (e.g., through the action of care provider) such that incorrect or delayed information could result in death or serious injury of the patient and/or operator.

--------------------------------------------------

2005

Moderate

We believe the level of concern is Moderate if a failure or latent design flaw could directly result in minor injury to the patient or operator. The level of concern is also Moderate if a failure or latent flaw could indirectly result in minor injury to the patient or operator through incorrect or delayed information or through the action of a care provider.

1998

Moderate - The level of concern is moderate if the operation of the software associated with device function directly affects the patient and/or operator so that failures or latent design flaws could result in non-serious injury to the patient and/or operator, or if it indirectly affects the patient and/or operator (e.g., through the action of a care provider) where incorrect or delayed information could result in non-serious injury of the patient and/or operator.

-----------------------------------------------------

2005

Minor

We believe the level of concern is Minor if failures or latent design flaws are unlikely to cause any injury to the patient or operator.

1998

Minor - The level of concern is minor if failures or latent design flaws would not be expected to result in any injury to the patient and/or operator.

Guidance Questions:

The new questions the FDA provides in establishing the Level of Concern is different from the flowchart provided in the 1998 guidance version. The new questions are more concise and provide a more definitive approach to determining the level of concern associated with your software.

In the new (2005) document the questions used to determine the level of concern are different:

If the answer to any one question below is Yes, the Level of Concern for the Software Device is likely to be Major.

Does the Software Device qualify as Blood Establishment Computer Software?

(Blood Establishment Computer Software is defined as software products intended for use in the manufacture of blood and blood components or for the maintenance of data that blood establishment personnel use in making decisions regarding the suitability of donors and the release of blood or blood components for transfusion or further manufacture.)

Is the Software Device intended to be used in combination with a drug or biologic?

Is the Software Device an accessory to a medical device that has a Major Level of Concern?

Prior to mitigation of hazards, could a failure of the Software Device result in death or serious injury, either to a patient or to a user of the device? Examples of this include the following:

Does the Software Device control a life supporting or life sustaining function?

Does the Software Device control the delivery of potentially harmful energy that could result in death or serious injury, such as radiation treatment systems, defibrillators, and ablation generators?

Does the Software Device control the delivery of treatment or therapy such that an error or malfunction could result in death or serious injury?

Does the Software Device provide diagnostic information that directly drives a decision regarding treatment or therapy, such that if misapplied it could result in serious injury or death?

Does the Software Device provide vital signs monitoring and alarms for potentially life threatening situations in which medical intervention is necessary?

If the Software Device is not Major Level of Concern and the answer to any one question below is Yes, the Level of Concern is likely to be Moderate.
Is the Software Device an accessory to a medical device that has a Moderate Level of Concern?

Prior to mitigation of hazards, could a failure of the Software Device result in Minor Injury, either to a patient or to a user of the device?

Could a malfunction of, or a latent design flaw in, the Software Device lead to an erroneous diagnosis or a delay in delivery of appropriate medical care that would likely lead to Minor Injury?

If the answers to all of these questions are No, the Level of Concern is Minor.

In 1998 the questions were different:

Does the device software control a life supporting or life sustaining device?

Does the device software control the delivery of potentially harmful energy which could result in death or serious injury, such as radiation treatment systems, defibrillators, and so forth?

Does the device software control treatment delivery, such that an error or malfunction with the delivery could result in death or serious injury?

Does the device software provide diagnostic information on which treatment or therapy is based, such that if misapplied it could result in serious injury or death?

If yes, then the device may be of a "major" level of concern, especially in cases where diagnostic information would be misleading or inaccurate, or inappropriate therapy would be delivered. These situations may result in serious injury to the patient through an improper diagnosis of a serious medical condition or improper treatment.

A device may provide data for which it is unlikely that the clinician will exercise independent judgment. The following are examples of scenarios that might arise:

Major: a radiation treatment system delivering potentially harmful radiation therapy without user knowledge; and

Moderate: a system providing incorrect diagnostic information which is readily and easily detected and overridden based on patient demographics, symptoms, and other tests.

In the latter case, one in which clinical judgment would be exercised to override the information provided by a medical device (even in cases of incorrect data), the device would be considered one of lower level of concern.

Does the device software provide vital signs monitoring and alarms for potentially life threatening situations in which intervention is necessary?

If the answer is yes to any of the above questions, the following question should be answered:

Does the software directly affect the patient so that failures or latent design flaws could result in death or serious injury to the patient, or does it indirectly affect the patient such that incorrect or delayed information could result in death or serious injury to the patient?

If the answer is yes, the level of concern is major. If the answer is no, then the following should be answered:
Does the software directly affect the patient so that failures or latent design flaws could result in minor to moderate injury to the patient, or does it indirectly affect the patient such that incorrect or delayed information could result in non-serious injury to the patient?

If the answer is yes, the level of concern is moderate. If the answer is no, then the level of concern is minor.

THE DOCUMENTATION REQUIRED (BASED ON LEVEL OF CONCERN):

The following are the actual tables that were presented in the respective version of the FDA guidance. The major differences are noted in red (in the 2005 version only):

Actual Charts

2005

 

1998 Chart (for comparison to 2005)

 

2005
Minor Level of Concern Devices

For Minor Level of Concern devices, we recommend that you submit documentation of system or device level testing, and, where appropriate, integration testing. The documentation submitted should include system or device level test pass/fail criteria and a summary of the test results.

1998

a) for a device in which the software is considered of minor level of concern:

- a software functional test plan with pass/fail criteria, data, and an analysis of the results;

2005

Moderate Level of Concern Devices

For Moderate Level of Concern devices, we recommend that you submit a summary list of validation and verification activities and the results of these activities. We also recommend that you submit your pass/fail criteria. You should ensure that the Traceability Analysis effectively links these activities and results to your design requirements and specifications.

1998

b) for a device in which the software is considered of moderate level of concern:

- a description of the verification activities at the unit, integration and system level,

- a system level test protocol including pass/fail criteria, and test results;

2005

Major Level of Concern Devices

For Major Level of Concern devices, we recommend that you submit the information recommended above for Moderate Level of Concern devices and a description of any tests that were not passed. We also recommend that you include any modifications made in response to failed tests and documentation of results demonstrating that the modifications were effective. Documentation provided in your submission should include examples of unit integration testing and a summary of the results.

1998

c) for a device in which the software is considered of major level of concern:

- a description of the verification activities at the unit, integration and system level,

unit, integration and system level test protocols including pass/fail criteria, test report, summary, and test results.

OTHER DIFFERENCES

The new 2005 document comes with description of what to submit for the different types of submission (special, abbreviated, etc)

Special 510(k)

In a Special 510(k), you should follow the recommendations in this guidance on the documentation to submit, but submit only the documentation related to the modification that prompted the submission.

Abbreviated 510(k)

An Abbreviated 510(k) submission must include the required elements identified in 21 CFR 807.87. In an Abbreviated 510(k), FDA may consider the contents of the documentation recommended in this guidance to be appropriate supporting data within the meaning of 21 CFR 807.87(f) or (g). Therefore, we recommend that you submit the documentation described in this guidance.

Software of Unknown Pedigree (SOUP)
Another (rather refreshing) comment (addressed in the new standard) has to do with Software of Unknown Pedigree (or SOUP). There will be times when you come across software (as in the case of 3rd party suppliers) for which adequate documentation may be difficult to obtain.

The FDA recommends: that you explain the origin of the software and the circumstances surrounding the software documentation. Additionally, your Hazard Analysis should encompass the risks associated with the SOUP regarding missing or incomplete documentation or lack of documentation of prior testing. Nonetheless, the responsibility for adequate testing of the device and for providing appropriate documentation of software test plans and results remains with you.

Conclusion

As is the trend with FDA document revisions, the revision to the new guidance for the content of premarket submissions for software contained in Medical Devices seem logical and easy to understand. The FDA has no doubt taken the understanding that in most cases the end user reading the document is most likely not a lawyer.

Site Map »

Media package available for advertisers looking to advertise on this site.

Contact us | About Us | Sitemap
© Medical Device School 2003-2011