re: docket no. fda-2017-d-6569: clinical and patient ... · guidance titled clinical and patient...

701 Pennsylvania Avenue, NW Suite 800 Washington, D.C. 20004–2654 Tel: 202 783 8700 Fax: 202 783 8750 www.AdvaMed.org

Bringing innovation to patient care worldwide

February 6, 2018

Division of Dockets Management (HFA-305)

Food and Drug Administration

5630 Fishers Lane, Room 1061

Rockville, MD 20852

Re: Docket No. FDA-2017-D-6569: Clinical and Patient Decision Support Software: Draft

Guidance for Industry and Food and Drug Administration Staff

To Whom It May Concern:

The Advanced Medical Technology Association (“AdvaMed”) appreciates the opportunity to

provide comment on the Food and Drug Administration’s (“FDA” or “Agency”) Draft

Guidance titled Clinical and Patient Decision Support Software (“CDS Draft Guidance”).1

AdvaMed represents manufacturers of digital health technologies, medical devices, and

diagnostic products that are transforming health care through earlier disease detection, less

invasive procedures, and more effective treatment. Our members range from the smallest to

the largest medical technology innovators and companies.

It is essential that FDA adopt the right policies to promote and encourage the development of

safe and effective medical devices, while also enabling efficient development of these

technologies. We believe the CDS Draft Guidance takes an important step in clarifying the

types of software that are, or are not, subject to FDA’s regulatory oversight. However, while

the CDS Draft Guidance assists firms in determining the regulatory status of a particular

product, we believe FDA should issue additional guidance describing how it will regulate

CDS that is subject to the Agency’s rules and regulations. Similarly, we suggest FDA

provide a risk-based framework to determine when certain CDS tools should not be regulated

as a medical device due to its risk profile (i.e. low-risk CDS).

We also appreciate FDA’s discussion here of artificial intelligence and machine learning

processes. Nevertheless, the concept of “transparency” conveyed in this CDS Guidance

should remain focused on the information underlying the recommendation within an artificial

intelligence and/or machine learning process, rather than the algorithm itself.

Lastly, we note that there a number of FDA guidance documents in the digital health space

that deem particular functions subject to FDA’s enforcement discretion. AdvaMed supports

publication of guidance documents and appropriate exercise of enforcement discretion when

understood and properly executed across the Agency. While the use of enforcement

1 Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug

Administration Staff (Dec. 8, 2017), available at

https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM58

7819.pdf.

http://www.advamed.org/

Docket No. FDA-2017-N-4301

February 6, 2018

of 2

discretion can offer a degree of flexibility and allow FDA to quickly address policy matters

for new technologies, we believe FDA should ultimately undertake an effort to codify its

existing enforcement discretion policies by establishing regulations and product codes for

these devices by defining them as Class I devices exempt from premarket notification and the

requirements of the Quality System Regulation, and other FDA regulatory requirements as

appropriate. We believe doing so will provide long-lasting clarity and reduce any regulatory

concerns companies may have.

Our specific comments to the Draft Guidance can be found in the attached chart.

* * *

AdvaMed would like to thank the FDA for its ongoing work related to digital health

technologies and looks forward to continuing to work with the Agency on these important

issues. Please do not hesitate to contact me at 202-434-7224 or [email protected] if

you have any questions.

Respectfully submitted,

/s/

Zachary A. Rothstein, Esq.

Associate Vice President

Technology and Regulatory Affairs

Attachment

AdvaMed Comment Form

Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff (FDA-2017-D-6569)

# Line Number Comment/Proposed Change1 Rationale

1 General We recommend revising the phrase “approved drug labeling” to “approved

drug or medical device labeling” whenever used in the CDS Draft Guidance.

CDS tools could analyze individual patient data to

suggest medical device treatment based on FDA-

approved medical device labeling.

2 120 We recommend adding after approval requirements: “(otherwise referred to

as enforcement discretion)”

This change maintains consistent terminology.

3 121-124 We recommend revising the text as follows:

This guidance does not address other FDA statutory or regulatory

requirements that may apply to certain decision support software, including

software disseminated by or on behalf of a sponsor, for use with one or more

of its drugs or biologics, such as requirements applicable to drug or biologic

labeling or combination products.

To the extent a software (device) and drug/biologic product meet the

definition of a combination product, the requirements for the device

constituent part should not change. If FDA plans on creating separate

guidance to implement section 3038 of the 21st Century Cures Act, then this

statement should be updated to reflect that these topics are (or will be)

described in separate guidance.

This statement is overly limiting, and it should be

clarified or deleted. The requirements for software

should be the same regardless of whether is it provided

for use with a drug, biologic, or device. This statement

may conflict with the inclusion of examples associated

with medication reminders and drug interactions.

4 144-145 Lines 214-216 and 223-225 express different concepts. Lines 214-216 state

the intended use of the basis of the recommendation (rationale or sources) is

to inform the user’s own judgement. However, lines 223-225 states that the

user should be able to reach the same conclusion. We recommend revising

the language in 223-225 per our comments below to be consistent with the

previous statement.

Also, when a manufacturer provides the supporting information, it is not

clear whether this means the information that is used by the software to

The phrase, “independently confirm the

recommendation” could be interpreted differently than

“providing the basis for the recommendations.” The

guidance should use consistent phrasing for these

concepts.

1 When applicable, additions are marked as underlined text and deletions are struck. These additions and deletions are also in red font.

AdvaMed Comments


2


inform selection of a recommendation or information to allow the intended

user to perform an independent/parallel assessment. To be clear, these are

not always the same.

5 149-168

Replace lines 149-168 with the following text:

“III. DEFINITIONS

For the purposes of this guidance, FDA is defining the terms Unregulated

CDS and Unregulated PDS based on section 520(o)(1)(E) as follows:

Unregulated Clinical Decision Support: Those software functions that are

(1) not intended to acquire, process, or analyze a medical image or a signal

from an in vitro diagnostic device or a pattern or signal from a signal

acquisition system; (2) intended for the purpose of displaying, analyzing, or

printing medical information (such as peer-reviewed clinical studies and

clinical practice guidelines); (3) intended for the purpose of supporting or

providing recommendations to a health care professional about prevention,

diagnosis, or treatment of a disease or condition; and (4) intended for the

purpose of enabling such health care professional to independently review

the basis for such recommendations that such software presents so that it is

not the intent that such health care professional rely primarily on any of such

recommendations to make a clinical diagnosis or treatment decision

regarding an individual patient.

Unregulated Patient Decision Support: Those software functions that are

(1) not intended to acquire, process, or analyze a medical image or a signal

from an in vitro diagnostic device or a pattern or signal from a signal

acquisition system; (2) intended for the purpose of displaying, analyzing, or

printing medical information about a patient or other medical information

(such as information derived from peer-reviewed clinical studies and clinical

practice guidelines); (3) intended for the purpose of supporting or providing

recommendations to a patient or non-health care professional caregiver, in

terms that are understandable to the patient or non-health care professional

caregiver, about prevention, diagnosis, or treatment of a disease or

condition; and (4) intended for the purpose of enabling such patient or non-

health care professional caregiver to independently review the basis for the

recommendation so that it is not the intent that such patient or non-health

To improve overall clarity, unregulated CDS and PDS

should be defined using a common structure, in the same

section of the guidance (proposed as “Definitions”), and

without references to 520(o)(1)(E) in either definition.

We recommend that FDA only define unregulated CDS

and unregulated PDS to the extent the statutory

provisions of section 3060 of the 21st Century Cures Act

apply. Section 3060 of the 21st Century Cures Act only

defines unregulated CDS; it does not purport to define

broadly what tools may be considered CDS (which could

include products that are not subject to FDA oversight).

Indeed, FDA’s proposed definition of CDS is not

consistent with well-understood parameters of what may

constitute CDS and is inconsistent with other

governmental and industry organizations’ definitions of

CDS. Accordingly, limiting the definition simply to what

the 21st Century Cures Act defines as unregulated CDS

will limit confusion.

AdvaMed Comments


3


care professional caregiver rely primarily on any of such recommendations

to make a decision regarding the patient.

6 177; Footnote 2

We recommend moving the definition of physiological signals to the body of

the guidance.

The definition of signal acquisition systems is too broad and could apply to

smartwatches and activity monitors that contain algorithms or that analyze

data. It is also unclear whether the term includes the electrochemical

response detected by a CGM sensor. As a result, we suggest modifying the

definition as follows:

“Physiological signals are those signals that require use of either an in vitro

diagnostic device or signal acquisition system. In the context of an in vitro

diagnostic device, a physiological signal is typically an electrochemical or

photometric response generated by an assay and instrument that must be

further processed by software to generate a clinical test result. A signal

acquisition system is the electronic circuitry and control processor that

receives, as inputs, signals from sensors that are within, attached to (e.g.,

EEG, ECG), or external to (e.g., CT, MRI) the human body or sample from

the human body (e.g., digital pathology). The fidelity with which a

physiologic signal is captured, processed, and analyzed is often critical to the

overall performance of a device.”

This is the first instance of FDA defining and using this

term, making it important to provide additional clarity to

ensure that the term “signal” is well understood. To that

end, we recommend adding the suggested

language. Clearly, software (either as part of an IVD

instrument or as standalone software) that is used to

process raw signal measurements, such as the

electrochemical or photometric responses generated by

IVD assays and instruments, is regulated as a

device. Such software typically converts these signals to

a test result, such as PaO2 test result or a hemoglobin

A1c test result. These test results may then be used by

CDS software to make clinical recommendations. As

highlighted in Section IV of this guidance (and

specifically in the examples described in lines 273-276

and 277-281), there are examples of CDS functions that

utilize such IVD test results and are not considered

devices. As such, we believe it important to make clear

in the guidance that, in the context of IVDs, “signal”

refers to the electrochemical or photometric response

generated by the IVD and not necessarily the final test

result. Otherwise, FDA could unintentionally regulate

any result, including for example a result residing in an

electronic health record, which we do not believe is

FDA’s intent.

7 185-186 We recommend revising the following text, “or analyze and interpret

genomic data (such as genetic variations to determine a patient’s risk for a

particular disease).”

To:

“or analyze and interpret genomic data to identify a patient’s genetic

variations for the purpose of determining a patient’s risk for a particular

disease.”

We believe this language is clearer.

AdvaMed Comments


4


8 187 We suggest including a discussion concerning the differences between

MDDS and CDS.

The relationship between CDS and MDDS isn’t clear,

particularly after reading this section.

9 191-195 Revise text to read:

FDA interprets this to include software functions that display, analyze, or

print patient-specific information, such as demographic information,

symptoms, and test results, and/or medical information, such as clinical

practice guidelines, peer-reviewed clinical studies, textbooks, approved drug

labeling, and government agency recommendations, and aggregated historic

information, such as real world evidence, on multiple patient treatments.

Aggregate or statistical information on patient diagnosis,

treatment and outcome by specific medical devices (big-

data mining) may support a HCP in the diagnosis and

treatment for specific patients.

This change would help clarify that, under the second

prong of the exclusion, data mining software are not

regulated as devices. These products aggregate patient

data, generally through the cloud, without processing the

data (images or signals), besides presenting statistics on

the data, such as averages, standard deviation, etc. An

example of these statistics are procedure time, disposable

utilization, patient demographics, treatment parameters

used, and treatment success rates.

10 203-205 Revise text to read:

“This means that software functions that support or provide

recommendations to patients – not health care professionals – are not

excluded from included in the definition of device.”

This change is more consistent with the language of the

statute, which indicates that the definition of device

“shall not include” the software functions identified by

the provisions. While the legislative language included a

series of double negatives, the guidance document would

be clearer if they were removed when possible.

11 218-231 Provide more information about the ways that manufacturers can provide the

information identified in lines 219-222, and whether the information needs

to be built into the software tool.

It would be helpful to understand FDA’s thinking on the

appropriate ways of providing this information. For

example, is it sufficient to provide a reference in the

software tool? Can the information be provided in

documentation that accompanies the software (user

guide, sell-sheet, or specifications)? What are the ways

that FDA anticipates this information to be provided?

12 223-224 We recommend FDA revise the phrase, “the intended user should be able to

reach the same recommendation on his or her own without relying primarily

on the software function.”

To:

Lines 216-217 and 223-224 imply different concepts

regarding what the basis for the recommendation is

intended to provide for the user. The first says the

intended use of the basis of the recommendation

(rationale or sources) is to inform the user’s own

AdvaMed Comments


5


“intended to enable health care professionals to independently review the

basis for the recommendations presented by the software so that they do not

rely primarily on such recommendations, but rather on their own judgment,

to make clinical decisions for individual patients.”

judgement and the second says that the user should be

able to reach the same conclusion.

13 223-231 We recommend FDA clarify what is meant by “easily accessible,”

“understandable,” and “well understood.” For example, information may be

“easily accessible” even if proprietary (e.g., curated database), when

accessible by request to a subscriber.

We appreciate clarification of the transparency element

of section 520(o)(1)(E)(iii), but the terms used in the

guidance are subjective and could lead to greater

confusion and inconsistency in practice. Greater clarity

and examples would be helpful.

Also, the literature and other sources (even peer-

reviewed) do not always agree; in fact, they often do

not. It should be recognized that software functions may

include judgments based on the weight of the evidence,

but still remain within the transparency element.

14 225 Industry interprets this statement to mean that either providing the

underlying rationale or the sources of supporting information are valid

approaches on presenting the basis of the recommendation.

The CDS Draft Guidance is not clear that FDA will

accept either method as a mechanism for satisfying the

fourth criterion.

15 228 We recommend revising the text as follows: “and publicly available to the

intended user (e.g., clinical practice guidelines, published literature, and real

world evidence).”

We recommend this change as there may be clinically

relevant content that is used as input to the software

function that may not be available to the general public

but would be available to the healthcare professional.

16 232 We recommend FDA provide rationales for the assigned regulatory

designation for all of the examples contained within the CDS Draft

Guidance.

It would be helpful to include rationales for each example

explaining why the described software is or is not a

medical device. FDA does an excellent job providing

such rationales in its recently issued Guidance, Deciding

When to Submit a 510(k) for a Software Change. We

recommend the Agency do the same here.

17 232-281 We recommend FDA provide examples of scoring algorithms that are not

devices.

It is helpful to use examples to facilitate the

understanding of requirements around the independent

evaluation of the recommendation. Section IV.B

includes an example of a software function that uses a

proprietary algorithm for which the basis of the

AdvaMed Comments


6


recommendation is not available for review. It would be

helpful to understand what makes the basis “available for

review.” For example, novel software algorithms may be

published in the medical literature. Does this satisfy the

requirement that the user can independently evaluate the

basis of the recommendation?

18 236 The Draft CDS Guidance should address whether it applies to software

functions that are part of a medical device by inserting the following

language after line 238: “CDS that is incorporated into a device, but does not

impact the intended use of the device, is still considered CDS.”

Devices contain highly modular software and even

separate computers.

19 246-248 We recommend revising the text to: “Software that helps to identify drug-

drug interaction and drug-allergy contraindication alerts, based on FDA-

approved drug labeling or other sources and patient-specific information, to

prevent adverse drug events”

Not all drug-drug interactions are described in approved

drug labeling. To reduce patient risk, all available

information on drug interactions should be included in

this example, not just in a footnote (in this case, footnote

6).

20 249-250 We recommend revising the text to: “Software that provides health care

professionals with recommendations on the use of a prescription drug or

medical device that are consistent with the FDA-required labeling, or that

are described in other sources such as those identified in the definition of

CDS.”

CDS tools could also provide recommendations on the

use of medical devices.

The scope of information contained in this software

should be expanded to match the description in lines 193-

195. Limiting the example to information found in the

FDA-required labeling could interfere with a physician’s

ability to prescribe medication in a way that is most

beneficial to the patient. This restrictive approach is not

consistent with the remainder of the draft guidance,

which relies on the judgement of the physician. If

information is included that is not consistent with the

drug’s labeling, this should be made transparent to the

user.

21 259 We propose adding the following language:

“Software that uses rule-based tools that compares patient-specific signs . . .

.”

We are concerned that reference to rule-based tools is

unnecessarily limiting given the speed of software

innovation. The concept of “transparency” conveyed in

this CDS Guidance should remain focused on the

information underlying the recommendation.

AdvaMed Comments


7


22 260 Clarify what is meant by “available practice guidelines” and state that local,

non-published, hospital guidelines are an institutional guideline.

Local, non-published, hospital guidelines should be

authoritative medical sources as they meet the

requirements listed in Footnote 3 on page 8, are available

to the user, and therefore, are considered an institutional

guideline under this example.

23 261 We propose adding the following language:

“based) or real world evidence data to recommend . . . .”

There may be clinically relevant content that is used as an

input to the software function that may not be available to

the general public but could be made available to the

healthcare professional that uses the device.

24 269-271 We recommend revising the example to read:

“Software that presents and prioritizes alternatives to orders, drugs, or

therapies using practice guidelines and other generally accepted practices,

such as rule-based tools allowing health care professionals to efficiently

select diagnostic tests, drugs, devices or therapies in accordance with clinical

practice guidelines, peer-reviewed clinical studies, textbooks, real world data

or other appropriate sources, and their approved or cleared labels.”

For many disease states, the current standard of care is

not included in the labeling for the medical products. Not

including all available information will increase patient

risk.

25 281

We recommend adding the following example to Section IV.A. (Examples

of CDS Functions that are not Devices) of the document:

“Software that generates patient specific surgical plans by analyzing patient

specific information with respect to available sources to assist health care

professionals in making diagnosis or treatment decisions, but ultimately the

health care professional must rely primarily on their own judgment to make

clinical decisions for individual patients.”

This should be excluded from the device definition to

differentiate between the examples given for products

that are devices that also talk about patient specific plans.

In this proposed example, the product does not meet the

definition of a medical device because: (1) it does not

acquire, process or analyze medical image or a signal

from an IVD or a pattern or signal from a signal

acquisition system, (2) it is intended for the purpose of

displaying and analyzing medical information about a

patient, (3) it is intended for the purpose of supporting or

providing recommendations to a HCP about diagnosis or

treatment of a disease or condition, and (4) it is intended

to enable HCPs to independently review the basis for the

recommendations so that it is not the intent that the HCP

relies primarily on any of such recommendations to make

a clinical diagnosis or treatment decision regarding an

individual patient.

AdvaMed Comments


8


26 281 We recommend adding the following example to Section IV.A. (Examples


Software that provides real world evidence to a health care provider to

facilitate discussions with the patient regarding their recovery; or helps

health care providers confirm appropriateness of treatment; or provides

benchmarking service for health care providers to compare their patients’

outcomes (e.g., to national norms).

This type of information for HCPs meets the criteria for

exclusion from the definition of a device, as it meets all

four of the criteria in section 520(o)(1)(E)

27 281 We recommend adding the following examples to Section IV.A. (Examples

of CDS Functions that are not Devices) of the document.

Example: Data flags are typically set by a healthcare provider (HCP) and

are used in conjunction with lab policies and procedures to make additional

sample processing decisions. Data flags are used to analyze patient results,

for the purpose of providing supporting information to the HCP, while

allowing the HCP to independently review the basis for such

recommendations, and does not play the primary role in making a clinical

diagnosis or treatment decision.

Example: Software that uses rule-based tools to compare patient specific

results to HCP-set or confirmed normal ranges.

In comparing this draft guidance with the simultaneously

released 21st Century Cures draft guidance, FDA applies

inconsistent standards to the regulation of software. For

example, in the 21st Century Cures draft guidance, FDA

maintains its jurisdiction over software that generates

alarms or alerts because the tool analyzes results. In

contrast, FDA removes CDS from its jurisdiction in this

guidance so long as the HCP can independently review

the basis for such recommendations and does not rely

primarily on the CDS recommendation in making a

clinical diagnosis or treatment decision. Arguably, data

flags are far more simple and straightforward than CDS

and under the control of the HCP. Data flags are used in

conjunction with lab policies and procedures. Therefore,

the HCP does not rely primarily on the data flag or alert

in making a clinical diagnosis or treatment decision.

Data flags are used to analyze patient results for the

purpose of providing supporting information to the HCP,

while allowing the HCP to independently review the

basis for such recommendations and to also apply

specific lab procedures and policies with regard to

additional sample processing decisions. FDA should

apply the same risk-based approach to alerts and flags as

is applied to CDS.

28 281 We recommend adding the following example to Section IV.A. (Examples


“Software tools that analyze stored clinical information to flag patient

This example appears in lines 478-487 of the 21st Century

Cures draft guidance and should be included in this

guidance, instead of an example of a software function

that is not a device. It contains many similarities to the

AdvaMed Comments


9


results based on specific clinical parameters (e.g., out of range results,

potential drug interactions, opportunities for complementary tests, create

disease registries, summarize patient- specific information in an integrated

report, and/or track a patient’s treatment or disease outcome) provided that

the healthcare professional does not rely primarily on the recommendation

and does not represent a unique interpretation function but rather

summarizes standard interpretation of individual variables that healthcare

practitioners could do themselves.”

examples already provided and should be excluded from

the device definition because: (1) The software function

is not intended to analyze a signal (as defined in the

guidance) or medical image from an IVD or from a signal

acquisition system; (2) The software function is intended

for the purpose of displaying and analyzing patient or

medical information; (3) The software is intended to

support recommendations to an HCP about prevention,

diagnosis, and treatment of a disease or condition; and (4)

The software function enables the HCP to independently

review the basis for the recommendation and it is not

intended that the HCP rely primarily on the

recommendation - the flags are based on established

guidelines and are readily available for independent

review by an HCP.

29 298-300 We recommend revising the example to read:

Software that helps create custom implants and/or customizes the patient-

specific surgical plan and instrumentation based on analysis of imaging and

device characteristics for orthopedic implant or dental implant procedures.

The current proposed language creates confusion,

particularly with respect to patient specific plans. It is

unclear if the end goal is to focus on implant only

procedures and associated instrumentation that has been

customized for those procedures. There are examples of

patient specific plans that clearly meet the definition of a

clinical decision support product that does not meet the

definition of a medical device.

30 301-303 We recommend providing additional examples of medical episodes that may

be assessed in real time by software functions that use inputs from regulated

medical devices.

FDA has provided two examples: heart attack and

narcolepsy. It would be useful to provide examples that

are more nuanced and to explain whether medical

episodes that are not medical emergencies (e.g.,

depression, Attention Deficit Hyperactivity Disorder,

Parkinson’s Disease) would also be included.

31 325-328

We recommend revising this example to: “Software intended for health care

professionals where the basis for the recommendation is not disclosed to the

user to analyze patient information (including noninvasive blood pressure

(NIBP) monitoring systems) to determine which anti-hypertensive drug class

is likely to be most effective in lowering the patient’s blood pressure.”

It is critical to revise these examples to explain that

FDA’s thinking about the medical device status in the

example is due to the fact that the basis for the

recommendation has not been provided.

AdvaMed Comments


10


32 329-331

We recommend revising this example to: “Software that analyzes a patient’s

laboratory results to recommend a specific radiation treatment, for which the

basis of the recommendation is unavailable for the HCP to review.”

It is critical to revise these examples to explain that

FDA’s thinking about the medical device status in the

example is due to the fact that the basis for the

recommendation has not been provided.

33 331 Add the following example to Section IV.B. (Examples of CDS and Other

Software Functions for Health Care Professionals that Remain Devices):

“Software intended to generate an alarm or an alert to notify a caregiver,

and the caregiver relies primarily on this alarm or alert to take immediate

clinically relevant action.”

This example is currently in the 21st Century Cures draft

guidance and should be referenced in this guidance as

well because it discusses the threshold at which data

transported through MDDS is analyzed by a CDS tool.

34 352-365 Replace lines 352-365 with the following text:

“FDA does not intend to enforce compliance with applicable regulatory

requirements for PDS that enable the patient or non-health care professional

caregiver to independently review the basis for the recommendation so that

it is not the intent that such patient or non-health care professional rely

primarily on any of such recommendations to make a decision regarding the

patient.”

PDS is defined earlier in the document (section II) so

there is no need to include lines 351-361 in Section V.

The latter portion of the sentence uses existing text from

lines 362-365.

35 371 We recommend providing additional examples for the “rationale or support

for the recommendation” for a patient or non-healthcare professional for a

PDS.

Examples would be helpful to clarify the type of rationale

that patients would be able to understand.

36 375-377 We recommend providing additional examples of the “kinds of

explanations” that a health care professional may understand versus a

patient’s understanding due to educational and experience differences.

It would be helpful to understand FDA’s thinking on

what patients should be able to understand.

37 380-393 We recommend including the following example:

Software that provides information or general instructions to patients or non-

healthcare professional caregivers that are not specific to any drug, biologic,

or medical device labeling, such as pre- and post- surgical care preparation

and instructions.

This type of information for patients meets the criteria

proposed by FDA as being under enforcement discretion.

38 381-385 We recommend revising the text to read: Medication reminders and information should be

AdvaMed Comments


11


Software that provides information to a patient about the use of a

prescription drug that is consistent with the FDA-required labeling or the

patient’s prescription, such as reminding the patient how or when to take a

prescribed drug. Such software does not recommend changes in dose or drug

discontinuation that healthcare providers do not oversee (unless drug

labeling includes such recommendations).

available to patients who are taking medication in

accordance with their prescription, which often represents

the standard of care. This limitation could interfere with

a physician’s ability to prescribe medication in a way that

is most beneficial to the patients and the specifics of their

disease state, and could increase patient risk.

39 402 We recommend including additional examples of PDS that would be subject

to FDA oversight.

The CDS Draft Guidance contains only one PDS

example. Additional examples would be helpful to

further understand the boundary between the PDS that

FDA intends to regulate and those they do not.