I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

PowerPoint Slideshow about ' DRAFT FDASIA Committee Report' - khanh

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

The Food and Drug Administration Safety and Innovation Act (FDASIA) of 2012 calls for the HHS Secretary to “post a report—within 18 months (or by January 2014)—that contains a proposed strategy and recommendations on a risk-based regulatory framework pertaining to health IT, including mobile applications, that promotes innovation, protects patient safety, and avoids regulatory duplication”.

FDASIA Committee did not have to develop the framework itself—that will be done by FDA, ONC, and FCC—but has been asked to make recommendations which will guide the development of the framework

The patient-risk framework enumerates various important factors influencing the risk of software systems. It does not weight or “calculate” any specific risk score for a given software product. Rather, it serves as a framework to assess the factors to consider when evaluating the potential risk of patient harm arising out of the use of the software system. While the matrix characterizes the relative risk (ie. “lower risk”, “higher risk”) of certain conditions of each risk factor, these serve as directional guidance only. Exceptions for each relative risk condition exist.

Likelihood of the risky situation arising – likelihood of the risky situation arising when the system is used in the care of a patient with the possible condition (e.g., cancer, hospital admission, subject of a procedure)

Transparency of software operation, data, and knowledge content sources – visibility of the data, algorithms, and knowledge sources being used in the generation of the system’s output

The consumer of the system output could be a human user directly, or could be another system

On one end of the spectrum, the recipient of the system output can view all the data, algorithms, and knowledge content used to generate the system output

On the other end of the spectrum, the system could be operating as a black box

Ability to mitigate harmful condition – ability for a human to detect and take action to mitigate any potential for harm

Human intermediary could be mandatory (i.e., system output goes directly to a human), optional, or excluded (closed-loop operation)

Complexity of software and its maintenance – complexity of the system software and the process for updating/maintaining it

Software may be complex, but can be tested comprehensively and can be operated reliably; complexity is considered in the risk assessment, but does not determine the level of risk alone

Complexity of implementation and upgrades – complexity of human effort required to implement the software and its upgrade

Having a lot of “build” flexibility can allow helpful customization of the usability and effectiveness of the software, but it can provide many avenues for introducing risky situations not present in the “vanilla” system\

Methods and reliability of timely upgrades can affect patient-safety risk

Complexity of training and use – complexity of learning to use the software effectively

Proxy for this is number of hours required for training

Use as part of more comprehensive software/hardware system – the anticipated use as a part of a broader software system