FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 1

FDA Webinar- Design Considerations and Premarket Submission Recommendations for 

Interoperable Medical Devices Final Guidance

Moderator: Irene Aihie

October 26, 2017

1:00 pm ET

Operator: Welcome and thank you for standing by. All participants will be in listen-only 

mode until the question-and-answer session. At that time you may ask a 

question by pressing Star followed by the number 1 to ask a question.

Today’s conference is being recorded. If you have any objections you may 

disconnect at this time. I’d now like to turn the conference over to Irene Aihie. 

You may begin.

Irene Aihie: Hello and welcome to today’s FDA webinar. I am Irene Aihie, of CDRH’s 

Office of Communication and Education. On September 6, 2017 the FDA 

issued the final guidance document, Design Considerations and Pre-market 

Submission Recommendations for Interoperable Medical Devices. The 

guidance outlines the Agency’s recommendations for developing safe and 

effective devices that exchange and use patient information electronically.

Today, Heather Agler, Senior Science Health Advisor in the office of the 

Center Director here in CDRH, will present an overview of the final guidance. 

Following the presentation, we will open the line for your questions related to 

information provided during the presentation. Additionally, there are other 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 2

Center subject matter experts here with us today to assist with the Q&A 

portion of our webinar. 

 

Now, I give you Heather...

(Heather): Thank you. So during this Webinar we are going to do an overview of the 

guidance which will include key definitions, an introduction, background and 

scope, the design considerations for interoperable medical devices and also 

the pre-market commission content. And then that will be followed by a 

question and answer session.

So just so we’re on the same page I’d like to go over the key definitions that 

are found within the guidance document and the way that we have defined 

certain terms. Interoperable medical devices we have defined them as those 

that have the ability to change and use information through an electronic 

interface with another medical or non-medical product, system or device.

Interoperable medical devices can be involved in simple, unique directional 

transmission of data to another device or product. Or in more complex 

interactions such as exerting command and control over one or more medical 

devices. Interoperable medical devices can also be part of a complex system 

containing multiple medical devices.

The other key term that we use within the guidance document is electronic 

interface. And we define this as the medium by which systems interact and/or 

communicate with each other thereby allowing the exchange of information 

between systems. It (brings) both a type of connection and when we say type 

of connection we mean like whether it’s a USB port or wireless connection, 

whatever that may be. 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 3

And then also the information content. And it is the medium by which a 

medical device exchanges and uses information with other equipment or other 

medical devices. 

So the purpose of the guidance is to promote the availability of safe and 

effective interoperable medical devices and to provide considerations to you 

in the development and design of these interoperable medical devices. Also to 

clarify the contents that you would submit in a pre-market submission to 

support an interoperable medical device.

And then finally to provide recommendations for what can be found in the 

labeling. FDA has been involved in medical device interoperability for many 

years. Here is just a recap of some of the highlights. In 2004 we hosted the 

second meeting of the medical device plug-and-play interoperability project. 

Also in 2010 there was a medical device interoperability workshop. In 2012 

we co-hosted a summit on medical device interoperability with (Amy).

And then in 2013 we had a special recognition of the set of standards that 

supported both medical device interoperability and also cyber security. Then 

in 2015 we also had a workshop on promoting semantic interoperability of 

laboratory data. And then of course what we’re here talking about today we 

published the draft guidance document in 2016 and now have published the 

final guidance.

So next to talk about the benefits of interoperable medical devices: really with

the increase in new technologies that we see, there is this sort of desire to 

connect medical devices with one another and to share that data that is 

available. And with the advent of wide adoption of electronic health records 

it’s also sort of driven that desire to use medical device data for different 

applications.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 4

Interoperable medical devices have the potential to foster new, innovative 

health care solutions at a lower cost. And also to foster information sharing 

between devices and systems and across manufacturers.

The use - information from medical devices can be used in many ways 

including displaying and storing, simply displaying and storing the 

information, interpreting or analyzing the information or automatically acting 

on or controlling another product, such as a close-loop system may be looking 

at the different vital signs from a patient and may use some sort of automatic 

control to adjust patient treatment.

And systems that include interoperable medical devices may be composed of 

existing devices, products or technologies acting together to achieve a 

function different from the individual medical devices. In our guidance 

document we have a section on considerations for medical device 

manufacturers. 

So these are things to consider when designing devices. We suggest designing 

systems with interoperability as an objective. So think about this upfront when 

you’re thinking about your device; conducting appropriate verification, 

validation and risk management activity. And specifying the relevant 

functional performance and interface characteristics in a user available 

manner such as labeling.

So the scope of the guidance the guidance itself provides manufacturers with 

the design considerations when developing interoperable medical devices. 

Recommendations regarding information should include in a pre-market 

submission and recommendations for what to include in device labeling.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 5

This document focuses on the information content exchange over the 

connection. And it does not focus on aspects of the physical compatibility. So 

although we are concerned about the physical connection, we do feel it’s 

important to specify whether it is a USB port, a wireless connection; we are 

more focused on what is actually the information content exchange, the 

format, the context, the type of information that is being actually exchanged 

over that connection.

This document is not intended to provide guidance on whether or not a 

specific product or modification to a product requires a pre-market 

submission. And we intend for this document to compliment other FDA 

guidances. The pre-market discussion within the guidance applies to the 

follow pre-market submissions; 510(k)s, de novo requests, PMAs, product 

development protocols, humanitarian device exceptions and biologic license 

applications.

So the following considerations should be appropriately tailored to the 

selected interface technology and the intended use environment for the 

medical device. So when you have an interface on your device you should be 

thinking about what is the purpose of that electronic interface. What could it 

be used for, you know, is it just meant for the manufacturer to have access for 

updates or is it meant to connect to other systems, other medical devices.

Who are the anticipated users of the medical device? These could be – it could 

be used by home healthcare workers or integrators within a hospital or 

clinicians. So think about who might be your users of the device or the 

interface on the device. 

Also think about risk management. When you have an interface on the device 

what types of risk does that introduce to the device itself? And how might 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 6

those risks be mitigated? And verification and validation, you know, in what 

ways would you need to verify and validate the interface on the device. What 

labeling considerations should you have?

So what would you want to put in the labeling so that people could use the 

interface properly in the way in which it was intended. And then also the use 

of consensus standards. You know, obviously if we are connecting medical 

devices and we want them to be able to exchange information, use that – there 

are some standardization involved with that data. 

You’re one step closer to being able to use that data in the proper way. And 

having sort of the same, you know, and defining the different exchange 

parameters in the same way. So we highly suggest the use of consensus 

standards where it is applicable.

So getting into the purpose of electronic interface so device manufacturers 

should consider the purpose for each of the electronic interfaces found on the 

device. Manufacturers should consider the level of interoperability needed to 

achieve the purpose of the interface. You know, is it purely just semantic 

interoperability? Is there context? Is there other things that need to be known 

in order to be able to use the data in the way in which it is intended.

As well as what information is necessary to describe the interface. Design 

considerations may be different for different types of electronic interfaces. So 

elements that should be considered include but are not limited to the 

following. The types of devices it is meant to connect to. So, you know, are 

you meant to connect to very specific devices, are you meant to connect to a 

broad change of devices or are you merely providing an interface so that 

anybody can download information off that particular device.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 7

So what are those types of connections; the type of data exchange taking 

place, what standards may be used, the need for time synchronization? If there 

are going to be several devices connected within a network and you need to 

know sort of what artifacts are happening at what time you would want those 

particular devices possibly to have time synchronization so that you can 

follow the sequence of events.

The method of data transmission and necessary timeliness and reliability of 

information; that this is information that you’re going to use to make real time 

patient decisions; the method of data transmission. Any limitations or contra 

indications associated with use of the electronic interface. The clinical 

context, anticipated use of the interface and the functional and performance 

requirements of the device.

In addition to how the interface would be used you also should think about 

who are the anticipated users. So you should – manufacturers should 

determine the anticipated uses for each of the electronic interfaces and 

determining the anticipated users will help in appropriately applying risk 

management strategies for activities such as developing appropriate 

instructions for use and setting limitations for the use of the device; including 

contra indication, warnings and precautions. 

It should consider the different users when designing the device and 

developing the instructions. So instructions may vary a lot depending on who 

it is that may be using the device. So users, operators and clinicians need to 

know the clinical uses and potential risks relevant to the use environment and 

the clinical task at hand.

Equipment maintenance personnel and hospital/clinical engineers need to 

know what actions to take to verify correct configuration and operation. They 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 8

need to ensure that the system is performing as specified. IT professionals 

need to understand the performance needs and security requirements of the 

devices connected to the networks they maintain and operate. Systems 

integrators may need to know the capabilities of the component so that they 

can perform adequate risk management and validation.

And finally patients may need to know specific instructions on how to use 

their device in a home environment. In addition to the expected users 

manufacturers should also consider any malicious users or attackers in the 

design of the device. These considerations may influence whether the 

manufacturer places certain limitations on the users of the device or 

limitations on how the device may be used.

Developing different instructions for different users may help mitigate the 

risks.

And so also risk management – you should consider both intended and 

unintended access through (the) interface. In balance how to allow intended 

access by implementing security features to restrict unintended access to the 

medical devices and consider reasonably foreseeable uses and misuses of the 

electronic interface.

And develop an ongoing process for identifying hazards, estimating and 

evaluating associated risks, controlling these risks and monitoring the 

effectiveness of the controls over the life cycle of the device.

So these considerations really as I said should be thinking about the entire life 

cycle. And when you see additional risks post-market they really should be 

feeding back into the design of the device and see if there are any mitigations 

need to be made.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 9

So we mentioned security. I would like to say that we don’t get into depth 

about cyber security within this guidance document. We have guidance 

documents available on cyber security both pre-market and post-market. We 

do have a Webpage that is pictured here where you can go to and get 

information and other resources on cyber security.

But we wanted to, you know, mention that we understand that it is a balance 

that while we want to share data and have interoperable medical devices, that 

we also understand the need to have appropriate security to balance that as 

well.

So we also focus on the potential hazards, safety concerns and security issues 

introduced when including an electronic interface. For example in part of the 

evaluation in design process, manufacturers should consider the following; 

whether implementation and use of the interface degrades the basic safety or 

risk controls of the device; whether implementation and use of the interface 

degrades the essential performance of the device and whether appropriate 

security features are included in the design.

And finally whether the device has the ability to handle data that is corrupted 

or outside the appropriate parameters. So while we want our devices to be able 

to talk to one another when you’re talking about medical devices that being 

part of a network or talking with other medical devices and we want the 

information to be understandable, we also really need to consider the safety 

features with medical devices. Because the last thing we want is for an issue 

to come up that could adversely affect patients.

An interoperable system should maintain basic safety and essential 

performance during normal and (fault) conditions. A manufacturer should 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 10

design an interoperable medical device that can appropriately mitigate risks 

associated with possible error scenarios such as failures and malfunctions 

caused by direct or indirect connection of - in intended devices; failure or 

malfunctions caused by invalid command; failure or malfunctions caused by 

receiving and processing erroneous data or command. And failures or 

malfunctions caused by not adhering to the nonfunctional requirements of the 

communications specification.

So again we want to make sure that manufacturers have thought about ways to 

mitigate these types of failures such that it may not adversely affect the 

patient.

So the verification and validation considerations really depend on the level of 

risk associated with the device itself; the purpose of the interface on the 

device, the anticipated use of the device and the target system and the 

intended use of the device.

So testing should demonstrate that the interactions on the electronic interface 

perform as intended and comply with the intended specifications. And for 

devices meant to be used with a limited number of specific devices, 

appropriate testing to demonstrate safe operation with those specific devices 

would make sense. For devices meant to work with many devices it may be 

more appropriate to test the device against the interface specification and with 

a representative device for verification.

For devices meant to be part of a larger, interoperable system the 

manufacturer should conduct testing to reasonably ensure that the medical 

device will continue to safely and effectively fulfill its intended use when it is 

assembled, installed and maintained according to its instructions. 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 11

So appropriate testing may include testing to assure that the device continues 

to operate safely when data is received in a manner outside the bound of the 

parameters specified; establish and specify failsafe states for critical functions 

such as delivering energy or real-time monitoring; verifying only authorized 

users that are allowed to exchange information with the interoperable medical 

device; validating the user interface and determining if the users are capable 

of correctly using the interface; assuring that reasonably foreseeable 

interactions only cause correct operation of other network systems and 

nothing else; and testing that simulates real-world use of the device.

The labeling should contain the functional interface and performance 

requirements of the electronic interfaces that may be used to connect medical 

devices with other electronic equipment. Labeling may include materials 

within the packaging of the device, the instructions for use or device-specific 

information posted on the manufacturers Website. 

There may be different directions for different users and further 

recommendations can be found and later on in the guidance document that I 

will go over for the pre-market submission. So we’ll talk more in-depth about 

labeling.

And then also manufacturers should really consider the use of consensus

standards when they are available. We really encourage the use of consensus 

standards to support medical device interoperability. The standards that 

support interoperability are often for manufacturers and also other 

stakeholders such as health care delivery organizations, system integrators, 

system designers, installation technology professionals who work in 

healthcare settings.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 12

So these – there can be many types of standards that can help support 

interoperability. And as I said previously we did do an initial recognition of 

many standards that support interoperability and cyber security. We have 

continued to review different standards that support interoperability and have 

recognized others as well.

If ever there is a standard that you would like us to consider recognizing we 

ask that you go to the link below and suggest the recognition of that standard. 

And you can always go to our database to see if the standard that you’re 

interested in using is recognized by the FDA.

Within – I’m just going to (ahead) – within our standards that we have 

recognized they really are many times design standards. And while 

recognition – what we have recognition to encourage the use of standards, it is 

very possible that it makes more sense for a manufacturer to use another 

design for how they maybe define elements of their interface. And we just ask 

that it is clearly explained to us and we’ll get into that more in the pre-market 

submission part of the prog.

So contents of the pre-market submissions, so we’re not talking about – we’re 

not going to talk about what which particular devices or how you would 

decide whether or not you need a pre-market submission. But for those 

devices that do need a pre-market submission for medical devices intended to 

exchange and use information with or from other products, technologies or 

systems FDA recommends sponsors provide basic information similar to what 

would be normally provided to support other functions or features on the 

medical device.

So really what we’re saying here is that normally if you would have an 

electronic interface that had a particular function we would recommend these 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 13

same criteria would be looked at. So what we’re doing here in this guidance is 

we’re really trying to clarify that for devices who are meant to use these 

interfaces and to allow the device to be an interoperable medical device.

So I also want to note that there may be FDA guidances or special controls 

applicable to the device. Also some device-specific standards may contain 

interface specification recommendations as well. 

So in the first part in that your normally submitted device description that you 

would have in your pre-market submission a sponsor should discuss each 

externally facing electronic interface. If the interface is only meant to be used 

by the manufacturer this should be clearly stated. And if the interface is meant 

to be used with only specific devices, then those devices should be clearly 

specified as well.

And we also ask you to note that the level (of) detail provided in the device 

description may depend upon the intended interoperable scenarios in which 

the manufacturer expects the interoperable medical device to be used. So 

clearly if it’s only meant to be used by a manufacturer not – you probably 

don’t need to include as much information describing the interface as to which 

– as compared to an interface that is meant to let’s say connect to an infusion 

or some other medical device.

The description of the electronic interface may include some or all of the 

following elements based upon the claims of data exchange and use made for 

the medical device. The purpose of the interface and the role that the device 

plays within an interoperable system if the interface is meant to transmit, 

receive or exchange information but standards were used, requirements for 

timeliness and integrity of the information such as a sample rate or 

transmission rate; communication format rate and transmission method.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 14

Are there any limitations or things that the user shouldn’t do? Are there any 

contra indications for cautions and warnings? What are the functional 

performance requirements? And the application programming interface if the 

device is software that can be used by other software or medical device or 

system.

Now for the risk analysis manufacturers should consider the risks that are 

associated with interoperability. The reasonably foreseeable misuse and the 

reasonably foreseeable combination of events that could result in a hazardous 

situation. The risk control measures may not be necessary for risks that are 

broadly acceptable. And there may be additional hazardous situations that 

arise when more than one medical device is connected within a system.

And the manufacturer should specify which mitigations are implemented and 

which ones are necessary for safe use and may require implementation by 

other parties such as the party responsible for setting up or installing.

We recommend including an analysis of the interface or interfaces on the 

device, the intended connections and any effects that the connections may 

have on the device performance. The submitted analysis should include 

normal elements in a risk analysis and address the risk control measures for 

reducing unacceptable risk to acceptable levels, (stop) tolerant behavior, 

boundary conditions and failsafe behavior.

Any risks potentially arising from security vulnerabilities that may be 

involved with the presence of an electronic interface. And risks arising from 

normal use as well as reasonably foreseeable misuse.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 15

For the verification and validation of the electronic interfaces a sponsor 

should include results of verification and validation testing for the electronic 

interfaces; the nature and extent of the validation depends upon the risks 

associated with the device; the purpose of the interface, the anticipated use of 

the device and the interoperable system and the intended use of the device.

For devices only meant to be used with a limited number of specific devices 

documentation demonstrating appropriate testing with those specific devices 

may be appropriate. For devices meant to connect with a class of devices or to 

be used in any device or computer system documentation demonstrating 

appropriate testing with a representative of the class of devices or within the 

context of the system may be more appropriate.

Documentation which demonstrates the following performance testing should 

be included in the submission; verification that the device interface meets its 

design specification; validation that the device interface performs as intended; 

determination and verification of the information that should be provided to a 

user to connect to the interface and to allow the user to ensure that the 

connection has been made correctly. And verification that the device will 

perform safely and within specifications when used under normal conditions 

and as normal conditions that are reasonably likely to occur.

So the degree of documentation for verification and validation can vary based 

upon the risks. If the purpose of the interface along with the intended 

scenarios for use of the interface do not add significant risks to the operation 

of the medical device then test summaries may be sufficient. For example if 

you have an infusion pump that is intended to receive patient data from 

several devices such as a pulse oximeter, ventilator, blood pressure monitor 

and that it’s going to use this data to change infusion pump settings, complete 

test reports most likely should be provided to the FDA in the plan submission.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 16

If a non-invasive blood pressure monitor has an interface intended to allow 

historical data to be downloaded to a computer then a summary of the testing 

performed on the interface may be sufficient. Information regarding the 

electronic interface on the device should be included in the labels so that the 

device can be used safely and effectively for its intended use.

So we really want these labels to contain the appropriate amount of 

information so that somebody can connect and use the information as it was 

designed. So information as I said should enable users to connect to the device 

in a specified manner and should give proper instructions on how to use the 

connection of the device in the ways again in which it was designed.

This should include any limitations of the connections to discourage any 

misuse of the device. It also should contain any precautions, warnings, contra 

indications. Validations of labeling regarding the use of electronic interface 

should consider human factors as well.

So just going to walk through a couple scenarios and talk about what we 

would – what we are thinking about should be in the labeling for these 

different scenarios. 

So in Scenario 1 the device is meant to interact with only a few specific 

devices. In this case the labeling should explicitly state that the medical device 

is meant to connect with those specific devices listed and include the version. 

And then it should not be used with other medical devices or non-medical 

device technology.

In the second scenario if the interface is only meant to be used by the 

manufacturer’s technicians for software updates or diagnostics it should be 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 17

explicitly stated in the labeling that the use of electronic interface is reserved 

for representatives of the manufacturers. 

In Scenario 3 the device is not meant to be interoperable. So the labeling 

should state that the electronic interface found on the device is not meant for 

connecting to other medical devices or non-medical device technology.

And then finally in Scenario 4 if the electronic interface is meant to interact 

with other medical devices the guidance selects a series of items to consider 

placing in your labeling. So consider certain information is needed for 

someone to properly connect to your device through the electronic interface

and use the information as described.

Consider what information is appropriate based on the risk associated with the 

device, the purpose of the interface, the anticipated use of the device and the 

interoperable system and the intended use of the device. Consider the use of 

standards for the electronic interface. The FDA recommends the following 

information be included in the device labeling as appropriate based upon the 

purpose of the medical device interface.

And I would like to emphasize when we talk about device labeling this 

doesn’t have to be labeling on the box. This can be instructions for use. It can 

be information found on the internet. And so it’s important for manufacturers 

to figure out the most appropriate way to convey the information to the users.

So we recommend that the following be included; the purpose of the interface 

including any devices, device types, interface standards specification of 

software with which it is meant to connect; who are the anticipated users of 

the interface; whether the connection is meant to control the operation of 

another device. 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 18

Specifications for each of the interfaces – this could be the specifications 

could include – could be a logical way forms prototype, accuracy, frequency 

of response as well as the necessary performance and functional requirements 

from a device related to the sending or receiving of data. 

A list of the data attributes being exchanged, the summary of the testing 

performed on the interfaces to verify interoperability claims and any activity 

suggested for a user to verify safe operations. And the case where testing was 

performed an interface specification and verified with representative device 

the manufacturer should specify the representative’s device used.

Any relevant standards used and certifications received; any methods used for 

time synchronization; a description of any fault tolerance behavior; boundary 

condition testing or failsafe for critical functions that will allow the user to 

understand how to use the interface correctly; any known limitations, contra 

indications, precautions and warnings; any recommended connections; 

recommended settings or configurations for the electronic interface. And 

instructions for specific users such as IT personnel on how to connect or 

install and disconnect or uninstall the device.

So I wanted to also direct your attention as we’ve gone through the 

information in the guidance document that we do have a Website on medical 

device interoperability. It is underneath – it’s within the digital health part of 

our Webpage. And it contains a lot of information and resources that you can 

go to as well as of course links to the guidance document.

And if you have any questions regarding interoperability or any digital health 

related questions we do have a digital health email address at the bottom of 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 19

this slide. And I will say that the group itself is very good at getting back to 

people on their questions and it can be a great resource.

So at this time we’d like to open it up to questions.

Operator: Thank you. To ask a question please press Star followed by the number 1. 

Please unmute your phone and clearly state your name and company to 

present your question. If your question has been answered, please press Star, 2

to withdraw your request.

One moment please for the first question.

(Heather): So one of the things while we’re waiting for the first question that I was –

when we went over the comments on the draft guidance document one of the 

things that we found is that we tried to provide clearer language throughout 

the guidance document. We found that sometimes there, you know, the 

wording that we had used maybe was misinterpreted.

One of the things that often is – that people have questions on as well was the 

purpose of the interface. And we were very careful to avoid the use of the 

intended use of the interface because we wanted to avoid having it confused 

with the intended use of the medical device as defined when you are 

submitting an application for medical device.

And so while the purpose of the interface may be included in the intended use 

because one of the main functions of a medical device most likely and 

electronic interface on a device would not be part of the intended use.

We’ll take our first question.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 20

((Crosstalk))

Operator: First question from (Aflan Schmitt) from GetGo Research. Your line is open.

(Aflan Schmitt): Hi. Thank you for having this presentation. When I think of electronic 

interfaces I think like most people I think of wired interface. But not too long 

ago we had a lot of data moving around by SneakerNet by USB6 and the like.

Would you also be thinking of that as an electronic interface? Or should we 

think of just the wired connections.

(Heather); No we are thinking of the other connections as well. Any place where it’s an 

interface where you could exchange and use information. I mean we certainly 

know that there are many different technologies out there. So not just the 

wired connections.

(Aflan Schmitt): Good. Thank you for that clarification.

(Heather): We’ll take our next question.

Operator: (Robert Evell) from Cenify your line is open.

(Robert Evell): Hi, thank you for the presentation. I had a question – you had an early slide 

about time synchronicity. So are you talking about like between a Smart 

Phone like the clock on our Smart Phone like if there’s an app on that that’s 

controlling a medical device. And then if there is a clock on the medical 

device itself?

(Heather): Yes. So anything that may be connected. I mean we’ve heard and heard in the 

past where people have done studies and looked around an OR and looked at 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 21

the time on different devices and found that they can be quite dramatically 

different. 

And if you had software let’s say that’s recording events from different 

medical devices in a situation like that or an EHR that’s collecting information 

from different devices and if you have the reporting of times that are very 

different you can understand how that information would be difficult to 

interpret after a surgery or whatever it might be.

(Robert Evell): Right. Thank you for (unintelligible).

Operator: Next question from (Amir Shaw) from Teva. Your line is open.

(Amir Shaw): When specifying (unintelligible) and to.

(Heather): I’m sorry the person asking the question dropped off.

Operator: (Amir), your line is open sir. We have you cutting out. Can you present your 

question again please?

(Amir Shaw): (Unintelligible) have to have (unintelligible).

Operator: Once again we do apologize we’re not able to get the question at this time. 

We’ll move on to the next question. Or once again we are showing no 

questions. But as a reminder please press Start, “1” to ask your question. One 

moment please.

We do have questions coming through, one moment please.

Next question is from (Jacob Brown) at Springborn. Your line is open.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 22

Woman 1: Hi. I have a question about the – first of all thank you again for the 

presentations today. It’s been extremely helpful. I have a question about the 

submission, the 510(k) submission. Would you expect to see a special section 

describing how interoperability has been managed or would you anticipate 

that it be the various elements be incorporated into the rest of the submission 

content?

(Heather): I don’t think that it would need to be its own section. It could certainly be 

incorporated. We currently know that a lot – what goes into interoperability. 

There is related software as some of the information may be very much 

obviously related to cyber security. So I would incorporate it most likely in 

where you’re talking about your software section and your cyber security; 

wherever would make the most sense.

Woman 1: Thank you.

Operator: And the next question from Tom Johnson from Medtronic. Your line is open.

Tom Johnson: Yes my question is I see a lot of (unintelligible) the (unintelligible) and the 

21st Century hears that. Could you help me understand – I just see a lot of 

(unintelligible). And then...

(Heather): No, yes. Yes we can certainly understand that. Certainly if you have a very 

just simple transferring of data out of your device as you know within the 21st 

Century Cures Act that would not be considered part of the medical device. 

And we would not be reviewing that necessarily in terms of the detail that’s 

seen within the guidance document.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 23

But so we certainly understand that. There are of course more complex 

connections among devices that are sort of beyond that sort of what we, you 

know, we’re calling MDDS or what’s talked about in the 21st Century Cures 

Act, where you could be taking information and analyzing it and then 

interpreting it. And then actually changing the settings on the device based 

upon that information.

And so when it you get especially into those more complicated connections 

that’s where the information here would, you know, definitely be applied.

Tom Johnson: Thank you.

John Murray: This is John Murray. I’d like to add to what (Heather) was saying that we will 

not be regulating medical device data source systems. We don’t get to the 

(league) devices. But when you connect your device to any other type of 

connection whether it’s a power connection or communication connection, 

whatever, we do have some concern or some issue related to the impact.

And the expectation here is that if you intend to hook it up to something that 

you’ve at least thought of what the risk considerations are. So that’s important 

to us. If you hook it up to an established specification there’s probably 

minimal risk there. But if you have a special connection it’s the same kind of 

impact analysis or thinking that goes along with using power out of a wall or 

(battery) or things like that.

So we will be thinking about the impact of connectivity even though we won’t 

directly regulate or review medical device data systems.

(Heather): And I – this is (Heather) again. I would like to add too – that’s also why the 

front of the guidance document was sort of written the way it was. So we 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 24

recognize there are many things out there that we don’t regulate to a premarket submission whether or not we regulate them all when we’re talking 

about some of the things covered in the 21st Century Cures Act. 

So we really wanted to put down our thinking out there for people in terms of 

what are sort of, you know, good considerations for you to be thinking about 

when (connecting) with medical devices or having connecting a medical 

device with other systems.

Operator: The next question is from (Sonya Phillips). Your line is open.

(Sonya Phillips): Hi. Our defibrillators continue to interoperative device.

(Heather): I’m sorry did you ask if defibrillators were considered a priority device, is that 

what I heard?

(Sonya Phillips): No, interoperative device. Our defibrillator on the discussed specification that 

we’re talking about?

Linda Ricci: So this is Linda Ricci. Any device that has an external communicating aspect 

to it could be considered to have aspects of interoperability. But we’re really 

relying on you as the manufacturer to define what that interoperability means 

for your specific device. I mean if you’re looking at an automated external 

defibrillator that has some ability to communicate off of the device for a 

specific reason, then there’ll be aspects of this guidance that would apply to 

that.

(Sonya Phillips): Okay, thank you.

Operator: Next question from Larry Liu of Verb Surgical. Your line is open.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 25

Woman 2: Hi this question is on behalf of Verb Surgical. So we were wondering around 

interoperability of medical devices. When you (assess) the risks associated 

with interoperability we are aware of the risks in our device or maybe the 

connection of our device to another. But how do we assess the risks associated 

with the other device that we have no idea some of the risks that are 

associated with that other device that we are connecting to.

Is there any FDA guidance on how to address that? Thank you.

(Heather): Yes so we certainly understand that that’s a concern. What we hope is that 

you can define the specifications are – what are the requirements of your 

interface when somebody else is connecting with them. And that you have 

taken the sort of appropriate precautions to mitigate risks for devices that you 

foresee connecting with them.

And hopefully through defining the types of devices and that through those 

requirements would sort of have some control over that. But we certainly 

understand that if somebody else is connecting to your device that there are 

some things that really should be controlled on their side or considered on 

their side in terms of the risk associated.

Yes so and that’s why we used the language that we had that you really should 

be considering the risks with normal use and any foreseeable misuse with the 

device as well. But obviously unforeseen uses – those are things that we 

would not be expecting you to control because we certainly understand that.

John Murray: Yes, this is John Murray. There was a lot of questions about this in the draft 

document, the question of scope of risk management. And I think (Heather) is 

correct, (Heather) is right on mark here. You don’t own the risk management 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 26

of the entire universe. But you do need to identify those risks that you know 

about or have had experience with. 

And there’s also a part of the presentation I saw that you may provide 

instructions for use to control some risk that you may anticipate outside of 

your control but that you want the user to take care of. So you have different 

risk methods here that you can employ to solve that problem.

Woman 2: Thank you so much.

Operator: Next question is from (Corinne) from (Boticel). Your line is open.

Man 1: Hello. My question here is like, you know, we are the manufacturer for the 

(fritz) used only for (flip) and we believe that, you know, our software work 

well the third party medical device. So my question here is how – what 

(unintelligible) like, you know, we are only the third application and (the) test 

software which is known that we are getting (new) at. 

But we believe that our software, the (unintelligible) software is (completely 

below) interoperable work with a third party medical device.

(Heather): Sorry I caught a lot of what you’re saying, but not all of it. Were you asking 

about – so you’re talking about it – your device is software only? And that...

Man 1: It’s (current) device so it’s just applications or it’s the software.

(Heather): Yes.

Man 1: And this (unintelligible) you asked whether the (unintelligible) risk. But our 

software worked interoperable with a third party medical device.
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 27

(Heather): Okay. So it works – it’s interoperable with a third party medical device. And 

what was the question about that?

Man 1: So what factor as a manufacturer of the (search) software we need to consider. 

What factor we need to consider to (see) interoperable?

(Heather): What do you need to consider. So I – obviously it sounds like you’ve been 

working with a particular device but you would need to consider what are the 

risk of operating with that particular third party device. What type of 

verification and validation test show that you do interact well with that device. 

Also are there any security issues or other things, risks to mitigate, that you’ve 

taken into account.

So I do think...

Man 1: Okay.

(Heather): ...yes, the things that we’ve gone over in this guidance would apply to that.

Man 1: Okay, okay.

Operator: We are showing no further questions. We’ll turn it back to our host, Irene 

Aihie.

Irene Aihie: Thank you. This is Irene Aihie. We appreciate your participation and 

thoughtful questions. Today’s presentation and transcript will be made 

available on the CDRH (unintelligible) Webpage at 

www.fda.gov/training/cdrhlearn by Friday, November 3. If you have 
FDA

Moderator: Irene Aihie

10-26-2017/1:00 pm ET

Page 28

additional questions about today’s presentation please use the contact 

information provided at the end of the slide presentation. 

As always we appreciate your feedback. (At the conclusion) of today’s 

Webinar please complete a short, (unintelligible) and question survey about 

your FDA CDRH Webinar experience. The survey can be found at 

www.fda.gov/cdrhwebinar immediately following the conclusion of today’s 

live Webinar.

Again thank you for participating. And this concludes today’s Webinar.

Operator: Thank you for attending the conference. This does conclude the call. You may 

disconnect at this time.

END