risk-driven medical device security

Health Information Technology Patient Safety Action & Surveillance Plan

This is a quick update on two new documents released by the HHS and the IMDRF:

 Health Information Technology Patient Safety Action & Surveillance Plan

The US Department of Health and Human Services published on July 2, 2013 the Health Information Technology Patient Safety Action & Surveillance Plan. The FDA belongs to the HHS.

The plan defines several types of action in three categories: Learn, Improve, Lead.

·       Learn – focuses primarily on monitoring of safety of Health IT in the field.

·       Improve – includes investigating adverse events and taking corrective action. Also included are setting safety priorities and incorporating safety into certification criteria for Health IT.

·       Lead – encourages the private sector leadership for Health IT Safety and develops a risk-based regulatory framework for Health IT.

The plan is found at http://www.healthit.gov/sites/default/files/safety_plan_master.pdf .

 Standalone Medical Device Software: Key Definitions

The International Medical Device Regulators Forum, a medical device-focused regulators-only successor group to the Global Harmonization Task Force (GHTF), has released a new document for consultation regarding the definition of standalone software used for medical purposes.

The document, Standalone Medical Device Software: Key Definitions, was released on 1 July 2013 and is being coordinated by the FDA.

As the document explains, “Software for medical purposes is becoming increasingly important and … can appear in many forms and on many computing platforms.” For example, some software is embedded into a type of medical device, while others are sold as stand-alone software meant to work on a variety of devices (e.g. mobile devices) or settings (e.g. cloud-based computing or local networks).

A major issue with respect to regulators is the fast pace at which the technology is progressing. Accordingly, this leads to problems in understanding what is required and what is expected (note: what is required is not necessarily what is expected and what is expected is not necessarily what is required).

The document provides a detailed analysis and definition of standalone medical device software (SMDS). According to the IMDRF, medical device software – which is defined as a medical device — “may include but are not limited to” the following characteristics:

·       capable of running on general purpose (non-medical purpose) computing platforms

·       not necessary for a hardware medical device to achieve its intended medical purpose

·       may be used in combination (e.g., as a module) with other devices

·       may be interfaced with other medical devices, including hardware medical devices and other standalone medical devices software

Software that meets the definition of SMDS and is part of another software, regardless if the other software has a medical purpose or not, is still considered as a SMDS.

The document is found at http://www.imdrf.org/docs/imdrf/final/consultations/imdrf-cons-sskd-130701.pdf.

If there are any questions, please contact us.

 

Related Posts Plugin for WordPress, Blogger...
Tell your friends and colleagues about us. Thanks!
Share this

Leave a Reply

Your email address will not be published. Required fields are marked *