Affected software

Potentially Affected Types of Software

So what types of present day software uses might end up in the CDS category? Here is our best guess of the types of software at risk of being regulated:

  1. We do not see FDA backing off of the CDS the agency already regulates, so look back at the first section of this paper for the discussion of accessory software and presently regulated standalone software. This includes such things as calculators, medication reminders, advanced analytics, data transmitters, storage devices, data converters, display devices, or any software that connects to or accessorizes a medical device.
  2. EHRs that do more than simply passively store medical information for later retrieval. If they use algorithms and other such conversion tools, expect them to be considered for regulation. For more information about FDA's approach to regulation of EHRs, check out "Is FDA's EHR Exemption Becoming Extinct?"
  3. Consumer-targeted software that facilitates diagnosis or makes treatment recommendations based on manually entered data. This could include websites or mobile apps that allow a consumer to enter symptoms and get something more than textbook-like information about possible medical conditions associated with those symptoms. Depending on the degree of specificity and the messaging involved, another example might be a website that analyzes search strings (e.g., "HIV" or "migraine") and targets the consumer with specific diagnoses or treatment options (e.g., advertisements for branded test kits or a specific drug).
  4. Supercomputers that crunch large volumes of data in an effort to improve patient diagnosis. An example might be software that analyzes physician notes stored in a patient's EHR for trends in observations or symptoms over time in order to diagnose a medical condition (e.g., seasonal allergies).
  5. Software that makes treatment recommendations for whole groups of patients, where the intent is to act upon the recommendation, as opposed to simply learn something. For example, if a mobile app not only informs you of the daily pollen count for your location but also suggests an antihistamine to protect against an allergic reaction, FDA might regulate.
  6. Software that performs other advanced analytics that have a direct impact on patient safety. Examples include software that evaluates a patient's treatment regimen for drug-drug interactions or that directs where to biopsy or the type of cancer treatment to use.
  7. Software that monitors patients on research and treatment protocols or that manages patient work-flow, if such software significantly impacts patient safety. For example, this would include software that prioritizes a specific patient over other patients for clinician review due to anticipated criticality of the individual's symptoms.
  8. Software that promotes the use of in-office best practices based on condition-specific clinical guidelines and population-based management (to the extent that such software is intended to influence decision-making for individuals or groups of patients). This might include, for example, software that recommends that a nurse wear a mask when entering a specific patient's room due to increased susceptibility to infection.
  9. Software that analyzes intra-operative data for recommendations on patient-specific surgical planning.

Open Issues

Resolving the broad issue of what types of CDS software FDA should regulate will require detailed analysis in at least the following 12 areas:

  1. The impact of competent human intervention on the scope of what gets regulated: Does software that merely replaces paper and pencil warrant regulation? For example, software that merely serves to facilitate what would otherwise be routine calculations should not pose sufficient risk to warrant regulation. Adding the capability of producing information that is used to aid in the decision-making process of a competent health care professional may or may not involve greater risk. A variety of factors may influence this determination (e.g., the significance that the information has for the decision-making process, the level of competence of the targeted decision-maker(s), the possible clinical alternatives, etc.).
  2. The impact of the data input process: In the past, FDA has paid significant attention to whether the data come from medical devices and whether the data are automatically imported into the software. When data flow directly from a medical device into a piece of software, FDA has tended to call that subsequent software an "accessory" to the medical device and, therefore, itself a regulated product. In the September hearing, FDA seemed to move away from that model, taking the position that the mechanism for data input is no longer relevant. This new approach would expand greatly the types of software that might be regulated, even including software that involves manual data entry.
  3. The types of data manipulation and mining that qualify for regulation: In the past, using a computer to simply reduce mathematical errors and handle high-volume calculations that were clinically useful was acceptably outside of FDA regulation. So long as the algorithms employed were well-accepted clinically and involved a certain level of transparency-that is to allow the user to understand the algorithm being applied and to double-check the output-then the software fell outside of FDA regulation. Based on the September hearing, it's not clear whether FDA intends to preserve this approach. We would, therefore, need to determine when data analysis crosses the line from simply being a minor aid, for example graphing the data, into the territory of producing new information.
  4. The types of information output that should be regulated: At the September hearing, FDA generally expressed the desire to regulate software that produces "actionable information." It is far from clear what FDA contemplates that concept to encompass. What we do know is that embedded in this broad concept of "actionable information" is patient-specific information. What we do not know is the point at which information crosses the line from being general medical information to patient-specific diagnosis or treatment recommendations.
  5. The types of marketing claims that should be regulated: Cutting across all of the functionalities listed above is the issue of how vendors can describe their software and yet remain in unregulated territory. For example, would the use of any of the following terms in marketing materials result in regulation?
    1. "Decision support," "artificial intelligence," or other similar terms;
    2. "Real-time" or "active" (suggesting no time for the exercise of professional judgment of a healthcare professional);
    3. "Patient-specific" or "personalized" (suggesting that the software somehow produces individualized actionable information);
    4. "Integrated" (suggesting that a regulated medical device can easily transfer information into the software); and
    5. "Flags," "notifications," or "alarms" (suggesting there is a real-time alert that should be acted on by a healthcare professional).
  6. The freedom of end users to tailor software to their individual needs without regulatory oversight: There has always been an ambiguity around how much tinkering hospitals and other end-users could do to software without themselves becoming an FDA-regulated manufacturer. In the final rule on MDDS, FDA basically said that whoever does manufacturing gets regulated, whether they might also be a hospital or not. Defining exactly what constitutes manufacturing therefore has become extremely important.
  7. The regulatory significance of modules: In other industries, like aerospace, there are accepted principles for breaking software down into modules. That's important here, where each module could have a different regulatory status. Without modules, all connected software may well be regulated to the most demanding level.
  8. International harmonization: Many of these software products are being deployed globally. To be efficient, we need to harmonize regulatory standards globally as much as possible.
  9. Wellness versus disease: Intended use determines the regulatory status of a product. Sometimes the mere mention of the use of a product in connection with a disease is enough to fall into FDA regulated territory. We may wish to propose that FDA ease up on some of these rules to allow for patient education, for example, in regard to chronic diseases.
  10. Legacy products: If FDA pursues a major change in policy, we need to have a discussion around how those new requirements might be applied. Imposing quality system requirements invariably creates a problem when it comes to retrospective compliance with design controls.
  11. Hardware versus software: While much of the discussion focuses on software, often these products are deployed as systems that include hardware. FDA will need to address how the associated hardware is treated in these system products.
  12. Who should regulate: As the Nov. 7, 2011 Institute of Medicine report on Health IT and Patient Safety: Building Safer Systems for Better Care explains, there are numerous federal agencies that have their fingers in the HIT pie. It's important to explore which regulator, if any, might be most appropriate for a given regulatory requirement. It doesn't have to be monolithic where one agency takes complete responsibility.


FDA's regulatory approach for CDS appears destined to change significantly in 2012.  If the future of this software category is important to you, you'll want to monitor it closely and get engaged.

Affected software