Research and Engineering Roadmap for Development and Deployment

of Smart Medical Devices

Jan Sliwa and Emmanuel Benoist

RISIS, Bern University of Applied Sciences - TI, Quellgasse 21, CH-2501 Biel, Switzerland

Keywords:

Smart Medical Devices, Interoperability, Translational Medicine, Evidence Based Medicine, Cyber-Physical

Systems, Research Roadmap.

Abstract:

The actual clinical use of smart wireless, software-based, mobile medical devices does not meet the recently

raised expectations. First, current low level of interoperability calls for setting and enforcing open standards

from the device level to the national/global collaboration structure. Second, heterogeneous and frequently

changing devices, operating in various natural, technical and human environments, do not match the classical

approval model. In addition to a time-limited set of clinical trials, they need a system of continuous quality

monitoring. Third, ad-hoc deployment, without dedicated staff with well deﬁned, novel skill sets is not scal-

able. A proper organizational structure is necessary. In this paper we present a modular software structure

and a framework of a system supporting both the direct health care and the continuous quality evaluation. We

expose the location of interfaces crucial for assuring multivendor interoperability. We then deﬁne a roadmap

giving structure to the necessary development effort. The structure we propose should permit to coordinate

the actions of independent teams tackling the immense number of multifaceted and interrelated tasks.

1 INTRODUCTION

In spite of brilliant visions of the wireless future of

the medicine

the actual adoption of smart medical

devices into the clinical practice lags far behind ex-

pectations. In this paper we discuss the obstacles im-

peding this adoption and propose ways to overcome

them. We focus our attention on the chosen basic sce-

nario: patients with wearable and implantable med-

ical devices, connected via an aggregator (typically

a smartphone) into a larger infrastructure. We dis-

cuss the challenges to the development of a versatile

ecosystem of interoperable devices and support sys-

tems and to their deployment in the actual clinical

practice:

• Interoperability at all levels

• Conﬁguration and deployment to the patients

• Servicing the deployed systems

• Ongoing quality control

Then we propose an organizational framework

that provides a viable reference structure that enables

to decompose the overall problem into manageable

tasks. The solution is not only technical but to a

http://www.ted.com/talks/eric topol the wireless future

of medicine, accessed May 7, 2014

great extent organizational and requires a coopera-

tion of many partners, willing to open they systems or

to share their data. Their interests are legitimate and

their concerns have to be treated with respect. There-

fore we discuss the driving forces that should motivate

them to enter into such collaboration.

On the basis of this framework we set a research

and development roadmap that identiﬁes main prob-

lem areas to be solved. The deﬁnitions of inter-

faces and data structures deserve a particular atten-

tion, since they are decisive for the current and future

interoperability and ﬂexibility. If well designed, they

will permit a development of solution elements by in-

dependent teams that eventually will match into an

encompassing superstructure.

In the conclusion we invite fellow researchers to

discuss the proposed roadmap and to collaborate in

using it as a scaffold for the actual project plan.

2 RELATED WORK

Mobile medical devices are currently an important re-

search area. We present here only a selection of pa-

pers relevant for our subject. A good starting point

221

Sliwa J. and Benoist E..

Research and Engineering Roadmap for Development and Deployment of Smart Medical Devices.

DOI: 10.5220/0005291002210232

In Proceedings of the International Conference on Biomedical Electronics and Devices (SmartMedDev-2015), pages 221-232

ISBN: 978-989-758-071-0

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

is the roadmap

of the Healthcare Information and

Management Systems Society. A broad picture of

future possibilities is given in (Kumar et al., 2013a)

and (Alemdar and Ersoy, 2010). The paper (Bergs-

land et al., 2014) presents various barriers faced by

medical innovation - related to economy, mentality

differences, healthcare organization, inadequate regu-

latory process, intellectual property and ethical issues.

A deeper analysis in the context of Ambient Assisted

Living (AAL) is presented in (Memon et al., 2014).

This paper discusses important issues like interoper-

ability and gives a sobering overview of actually im-

plemented systems.

The problem of technology evaluation is ad-

dressed in (Kumar et al., 2013b), (Tomlinson et al.,

2013) and (Mohr et al., 2013). A novel approach is

crowdtesting (Speidel and Sridharan, 2014). One of

the main topics of this paper, medical registries, is

treated in the paper (Amit et al., 2014) that presents

the Israeli implantable cardioverter-deﬁbrillators reg-

istry, and (Wolpert et al., 2011) that exposes the ne-

cessity of a cardiac registry and the barriers that hin-

der their implementation. An approach to protect the

data privacy in a registry

, based on a physical sep-

aration of personal and medical data is presented in

(Sliwa and Benoist, 2012).

At the side of the integration of the patient’s sen-

sors with a smartphone, we witness two major ini-

tiatives: Apple’s Health app

and Samsung’s wear-

able sensor device Simband

with corresponding soft-

ware on the smartphone. They should deﬁne ulti-

mate (competing) personal health monitoring plat-

forms. As for now, it was impossible for us to verify

the claims regarding their validity as open systems.

In any case, they position themselves in the consumer

market segment.

Various approaches to create integration frame-

works for system operation and device comparison

are proposed in (Wagner et al., 2013), (Pawar et al.,

2012), (Seeger et al., 2013), (Viswanathan et al.,

2012) and (Franke et al., 2013). Open mHealth Ar-

chitecture, similar to our goal, is proposed in (Estrin

and Sim, 2010).

The European project “Renewing Health” (RE-

gioNs of Europe WorkINg toGether for HEALTH)

http://www.himss.org/mobilehealthit/roadmap, access-

ed May 7, 2014

http://memdoc.org/, accessed May 7, 2014

http://www.apple.com/ios/whats-new/health/, access-

ed Oct. 20, 2014

http://www.samsung.com/us/globalinnovation/innova

tion areas/,accessed Oct. 20, 2014

http://www.renewinghealth.eu/en/, accessed Oct.20,

2014

has delivered several pilot projects related to the man-

agement of chronic diseases with telemedicine. In

particular, the Telemonitoring for Chronic Heart Fail-

ure project in the Veneto Region

shows an organi-

zational structure including explicitly various human

participants.

3 REFERENCE SETTING

In this paper we concentrate on systems of im-

plantable and wearable devices, connected via a Body

Area Network to a data aggregator, currently typically

a smartphone (Fig. 1). This set is to be considered as

a virtual multi-element device, performing a common

task in a coordinated way.

Figure 1: Basic conﬁguration.

They have a speciﬁc medical purpose, like mon-

itoring of vital health signals in a chronic disease,

possibly expanded with direct life saving functions.

The latter may be performed by the device itself, like

a pacemaker, deﬁbrillator or an implantable insulin

pump, or may involve alarming qualiﬁed medical per-

sonnel. Therefore they do not work in isolation, but

rather are integrated into a well deﬁned infrastructure.

They are selected and prescribed by medical special-

ists as an integral part of a therapy. In the face of the

severity of the medical condition treated, of the im-

portance of the provided function and of the degree of

risk in case of a malfunction, they are subject to the

regulatory oversight of the relevant authority.

We deliberately leave aside the thriving ﬁeld

of consumer devices used for ﬁtness, promoting a

healthy lifestyle and preventive health monitoring.

Those devices do not have to meet stringent require-

ments and are not in the focus of the approval authori-

ties. In this ﬁeld the market forces and the consumer’s

satisfaction will play the decisive role.

http://www.renewinghealth.eu/documents/28946/9c9db

1d1-8ace-4b07-bc08-8a7a68f55d05, accessed Oct.20,2014

BIODEVICES2015-InternationalConferenceonBiomedicalElectronicsandDevices

222

4 CHALLENGES

4.1 Interoperability

Technically, one of the major problems is interoper-

ability. It is necessary if we want to ﬂexibly conﬁg-

ure the systems, selecting the best elements for ev-

ery function from any producer. It has an economic

background, as many producers prefer to protect their

ecosystems with proprietary, undisclosed data for-

mats and protocols. In consequence, the hospital and

the patient may be forced not to include necessary de-

vices that are not supported by a chosen supplier. In

the same way, if we want our devices to communicate

directly with the hospital Electronic Health record

(EHR) system, the EHR system chosen will limit us

to only certain suppliers. Such connection exist or can

be developed on demand

, the effort is however sub-

stantial and provides only a 1:1 communication path.

This does not scale into an vendor independent, open

solution.

Figure 2: Complex event.

We also may want the devices to operate in a co-

ordinated way. An important case is the detection of

complex events (Fig. 2). In this ﬁgure the device de-

vice D1 detects a peak of the measured value (point

event), D2 assesses a prolonged waveform as an ab-

normal state, and the parameter measured by D3 ex-

ceeds the limit value. The combination of those mea-

surements establishes a medical condition (e.g. an

emergency) with a much better precision then each

of them alone, reducing in that way signiﬁcantly the

frequency of false alarms. In the case of cardiac mon-

itoring, D1 could be an accelerometer, D2 - an ECG

monitor and D3 - pulse meter.

From the position of the system designer the ne-

cessity of an open, interoperable system is evident.

If the best sensors of the classes D1, D2 and D3 are

available from different producers, we want to be able

http://nanthealth.com/, accessed May 7, 2014

http://www.isirona.com/, accessed May 7, 2014

to connect them into a closely coupled system - with

one communication device executing the event detec-

tion algorihm and with well synchronized clocks.

As far as possible, existing standards have to be

respected. They currently form a multicolor patch-

work of partly overlapping initiatives backed by vari-

ous organizations (St Cyr, 2013). The list of ECG for-

mats alone is overwhelming (Bond et al., 2011). Over

the time, the technology and market forces will deter-

mine the optimal solutions, whereas open standards

will still coexist with proprietary standards enforced

by major players. In the area of data exchange with

medical devices, the predominant standard on the se-

mantic level is HL7

. At the lower level the major

standards are ISO/IEEE 11073

(Yao and Warren,

2005), (Trigo et al., 2014) and ASTM F2671

. It is

to be examined which competing standards will even-

tually predominate and to what extent they are appli-

cable to low power micro/nano sensors.

4.2 Conﬁguring and Distributing the

Devices

Distributing smart medical devices to the patients is a

complex task. It is difﬁcult from the medical point of

view, especially when the device has to be implanted

(Kramme, 2007), (Lemke et al., 2013). Conﬁguring

a device like a deﬁbrillator requires a special blend

of medical and technical knowledge. This knowledge

is today available in good hospitals. However, if the

composite device has to be conﬁgured from individual

sensors into a working Body Area Network together

with an application on a commercial smartphone, we

enter a new domain. In order to set a wireless net-

work, a good network supporter is necessary. Just

trying to assign the tasks of installation and support

to the clinical staff is unfeasible (Wagner et al., 2013).

On the other hand, working with frail and elderly pa-

tients is not a common skill among the network sup-

porters.

4.3 Support

Similarly, establishing a support service is not triv-

ial. We have to remember that not only the patients’

calls have to be handled. The data coming from the

devices may also indicate problems that are not vis-

ible to the patients but require an intervention. For

example, missing or wrong values (outliers) suggest a

http://http://www.hl7.org/, accessed Oct.15,2014

http://www.continuaalliance.org/accessed Oct.15,

2014

http://www.astm.org/Standards/F2761, accessed

Oct.15, 2014

ResearchandEngineeringRoadmapforDevelopmentandDeploymentofSmartMedicalDevices

223

Figure 3: Medical device and its environment.

wrong ﬁxation of the device, empty battery or a sim-

ilar cause. In this case the medical personnel has to

contact the patient, and depending of the severity of

the disease it may be urgent. With a limited number

of patients, normal personnel is sufﬁcient, but above

a certain limit a special organizational unit is neces-

sary, especially that such cases will require not only

medical knowledge but also profound technical skills.

4.4 Quality Control

4.4.1 Smart Medical Devices as Complex

Cyber-physical Systems

A device does not work on its own, but is a part of

an environment that has to be included in the quality

assessment (Fig. 3). It consists of humans, nature and

other technical systems.

The patients are biologically different and may re-

spond differently to the same therapy. In general, the

device may be adequate for their medical condition or

not. If they have to perform some operations them-

selves (attach the device, input settings, read and in-

terpret the messages), the result will depend on their

motoric and cognitive skills.

Among other participating humans we have sev-

eral groups of helpers, whose services will be of value

if they master the necessary novel mixture of ap-

proaches and skills that are currently provided by var-

ious isolated communities (Fig. 4).

As the software based, networked medical devices

communicate electronically with the external world,

they are susceptible to attacks from hackers. They

store and transmit valuable patient data which are in-

teresting to various sorts of data thieves. Aside from

the electronic attacks, the devices can be physically

stolen or destroyed.

The forces of nature play an important destruc-

tive role - the devices break, they corrode inside the

body, ﬁxations loosen, sensors get dirty and nozzles

get clogged. Flesh, bones and cloth attenuate the sig-

Figure 4: Merging approaches and skills.

nal propagation in the Body Area Networks. Land-

scape and buildings obstruct the phone signal.

Networked devices depend on other technical sys-

tems. They need electrical power, phone signal and

Internet connection, possibly also GPS positioning.

We cannot take their existence for granted. On the

other hand, nearby systems may introduce noise and

jam the useful signal. Other wireless systems may use

the same bandwidth and compete for channel capac-

ity.

4.4.2 Formal Approval and Reimbursement

The approval process of medical devices is relatively

new, compared with the process for the drugs (Yin,

2012). In every market the respective regulatory

agency deﬁnes precise rules of approval for the med-

ical devices (Abdel-Aleem, 2009). They are divided

in several classes, depending on the possible risk to

the patient. Usually only for the high risk (Life-

Saving and Life-Sustaining) devices the results of a

well-controlled clinical investigation have to be pro-

vided. FDA has recently issued the guidance re-

garding the mobile medical applications

that de-

ﬁnes which apps are the focus of regulatory over-

sight, which may meet the deﬁnition of medical de-

vice but are exempt from enforcement and which are

not considered medical devices. Similarly, the Euro-

pean Commission is working on the update of its reg-

ulatory framework

. A good analysis from technical

and legal poin of view can be found in (Sorenson and

Drummond, 2014). As the process is highly dynamic,

we will not comment it here in detail.

In the design phase a risk analysis has to be per-

formed. The main standard used in this context are

ISO 14971:2007 (Application of risk management to

medical devices) and IEC 80001-1:2010 (Applica-

http://www.fda.gov/downloads/MedicalDevices/Device

RegulationandGuidance/GuidanceDocuments/UCM263366

.pdf, accessed Mar. 26, 2014

http://ec.europa.eu/health/medical-devices/regulatory-

framework/, accessed Oct. 10, 2014

BIODEVICES2015-InternationalConferenceonBiomedicalElectronicsandDevices

224

tion of risk management for IT-networks incorporat-

ing medical devices). The paper (Alemzadeh et al.,

2013) provides an in-depth analysis of this process.

A complex example of its application for hemodial-

ysis devices is shown in (Lodi et al., 2010). The re-

sults depend however on the actual assiduity of the

people who perform the assessment, on their techni-

cal knowledge and capacity to imagine rare and novel

risks.

The most trusted method is a randomized control

trial. A double-blind experiment with medical de-

vices is difﬁcult to implement (Potapov et al., 2011),

(Lipton et al., 2010) and (Castro et al., 2010) as it

is not easy to construct such a fake device that it is

not noticed by the patient. The paper (Zannad et al.,

2014) presents an extensive analysis of the challenges

facing the trials using the example of cardiovascular

medical devices. The approval process is however far

from perfect (Teow and Siegel, 2013) and risky de-

vices may reach the market (Hauser, 2012).

Another important factor is the reimbursement of

the therapies by insurances or government authorities.

There is a large market for consumer devices that are

useful in prevention, e.g. supporting a healthy life

style. The professional devices are however more ex-

pensive and their large scale use is only possible if

they are reimbursed. Therefore the respective payers

require a proof of their medical efﬁcacy as well as of

economic efﬁciency (what therapy improvement for

what price). The new devices not only induce costs

- extensive use of medical devices may increase the

possibilities of ambulant treatment and hence have a

positive inﬂuence on the general costs of the system.

4.4.3 Continuous Monitoring

For many reasons a one-time clinical study is not suf-

ﬁcient for a thorough evaluation of smart medical de-

vices. The devices operate in a variable, undeﬁned

environment consisting of natural and technical con-

ditions, as well humans that use and support them. A

patient can be allergic to the used material, another

can misunderstand the instructions. During travel

phone signal can be missing or bad roaming contract

may inhibit the data transfer.

All detected problems may lead to an update of the

device - its mechanical part (e.g. ﬁxing) or software.

The operating procedures may be changed or the per-

sonnel and the patients may be better instructed. In

all such cases the compound (device + environment)

is not the same, what formally invalidates the previous

tests.

Assessing the quality of updated software is a hard

statistical problem. Let us assume that the basic med-

ical algorithm is correct, but due to bugs the software

Figure 5: Software versioning.

crashes from time to time (Fig. 5). As said before,

a device with a changed software is not the same de-

vice. We have however already collected a valuable

set of data, and resetting the measurements would

be wasteful. Only some well known negative effects

were caused by the bug, the rest is unchanged.

Another factor is time. The device may wear out

with time. The quality of unchanged software, e.g.

without security patches, deteriorates with time

We want to know the long term effects of the ther-

apy but the necessity of a long clinical trial collides

with the pace of technical progress. Especially if we

require - correctly - that during all conditions remain

exactly the same, the result will be of no value. More-

over, we need to notice any change in the infrastruc-

ture, the deployment of new features (software and/or

hardware) to be able to statistically assess the effect

of the changes.

We therefore advocate to collect data during the

operation of the devices for continuous surveillance

of installed devices in order to detect hidden ﬂaws,

rare defects and results of material wearout and other

forms of degradation. On one hand, we will obtain

problem notiﬁcations regarding speciﬁc patients that

require contacting them, i.e. knowing their identities.

On the other hand, we will have general results con-

cerning the efﬁcacy of therapy methods and quality

of device classes and models. This information (with

identities removed) will be analyzed by good statisti-

cians and forwarded to the producers and to the ap-

proval authorities.

Those issues are well understood by the med-

ical community. (Sedrakyan et al., 2013) present

the rationale for an international registry of cardio-

vascular devices, (Kesselheim et al., 2014) even ar-

gue for compulsory postmarket research. Several

organizations and initiatives are active in this ﬁeld.

In the USA we can name the Institute of Medicine

http://www.wired.com/2014/01/theres-no-good-way-

to-patch-the-internet-of-

things-and-thats-a-huge-problem/, accessed Oct. 20, 2014

ResearchandEngineeringRoadmapforDevelopmentandDeploymentofSmartMedicalDevices

225

(IOM), Patient-Centered Outcomes Research Insti-

tute (PCORI), FDA’s Sentinel Initiative, Medical De-

vice Epidemiology Network Initiative (MDEpiNet)

or MedWatch, The FDA Safety Information and Ad-

verse Event Reporting Program. Even if their num-

ber suggests overlapping competences, it shows also

a growing importance of the issue.

5 ORGANIZATIONAL

FRAMEWORK

5.1 Basic Scenario

Having discussed the challenges we face, we pass

now to the presentation of the outline of a solution we

propose in this paper. The proposed organizational

units cover the tasks described before. The informa-

tion ﬂow ensures a smooth functioning of the system

and permits to all participants to produce and receive

necessary data.

We consider here a health support system regard-

ing a single medical problem, or a group of related

problems, e.g. cardiovascular diseases. It can be sub-

divided in following parts (Fig. 6):

• Patient’s System: the set of devices delivered to

the patient, the local network and installed software

• Infrastructure System: hospitals and other sup-

porting entities, communicating with the patients via

Wide Area Network

◦ Direct Health Support

◦ Quality Control and Evaluation

Figure 6: Subsystems: patient (PS) and infrastructure (IS);

actors and data ﬂows.

It has to provide following functionality:

• deployment and support

◦ conﬁguring and delivering to patients

◦ network operation (connection with devices)

◦ contacting patients

• notifying producers, distributing updates

• quality assurance and effectiveness evaluation

◦ monitoring technical state

◦ detecting failures

◦ measuring medical effectiveness

• extracting medical knowledge for better therapies

5.2 Actors and Roles

The partners that cooperate in the structure outlined

above are: • Patients

• Hospitals

• Technical support

◦ Conﬁgurators

◦ Operators

◦ Call centers

• Producers

• Approval authorities

• Research institutes

We will further discuss the motivation of the part-

ners driving them towards the cooperation outlined

here.

5.2.1 Patients

The patients are the ones that should proﬁt from the

novel therapies. Their feedback will be very useful

in ﬁnding and eventually ﬁxing the problems not de-

tected in the laboratory setting. In cases when the sup-

porters see surprising data or detect data losses, the

help of the patients will permit to connect the IT prob-

lems to the events from real life and to identify their

actual causes. Moreover, sharing anonymous data for

research will enable a better understanding of the pro-

cess, provide evidence based medical knowledge and

help to evaluate and improve the deployed devices.

5.2.2 Hospitals

Every patient is related to a hospital, handling his/her

case. We will use the term “home hospital”. This

hospital keeps the patient’s record - on paper or in

electronic form.

5.2.3 Technical Support

In order to assure the operation of the system, a

number of functions has to be performed (Fig. 7).

These functions require special technical equipment

and a novel set of skills that may exceed the current

capacities of a typical hospital. They may be de-

livered by one or several organizations, depending

on the necessary skills and equipment, and whether

a direct contact to the patients and hospitals is needed.

BIODEVICES2015-InternationalConferenceonBiomedicalElectronicsandDevices

226

Figure 7: Technical support - subunits.

Conﬁgurators A conﬁgurator is a unit that con-

ﬁgures the complete set of devices received by a pa-

tient. It cares that all hardware components can effec-

tively communicate and that all software packages run

on the data aggregator used by the patient. This ag-

gregator may be a device (e.g. a smartphone) owned

by the patient or a special device preconﬁgured for

this task. The conﬁgurator performs also the ﬁnal de-

livery to the patient and gives him/her the necessary

instruction. Having a supply of physical devices, the

conﬁgurator will be contacted if a service or replace-

ment is needed. The conﬁgurator acts on behalf of

the hospital and provides the necessary technical ex-

pertise, missing at the hospital. As the conﬁgurators

interact with patients, they need to maintain local of-

ﬁces. In case of implantable devices, the operation is

performed at the hospital, this however seems not to

require the presence of the conﬁgurator. Actual con-

nection into a functioning Body Area Network (BAN)

will rather be done later, after the scar is healed. This

geographical distribution permits various forms of or-

ganization - as separate, local companies or connected

in one enterprise.

Operators An operator is a unit that supports the

continuous function of the system of distributed med-

ical devices. We think here mostly of assuring the

network connection between the patients’ aggregator

devices and the hospital and other data destinations.

The operator has to perform all transformations on

data received from the patients and distribute them

according to the predeﬁned scheme. The operator has

to know all communications partners. It also has to

know the types and versions of all devices (sensors,

actuators) used in the system and their producers in

order to generate the status and malfunction notiﬁca-

tions. Likewise, the information about the actual con-

ﬁguration of the device sets delivered to the patients

is necessary for speciﬁc service functions, e.q. status

inquiries or software updates.

Call Centers The ﬁrst function of a call center

is receiving remarks, complaints and service requests

from the patients. Equally important are contacts with

the patient initiated by the service providers (Fig. 8).

The device set delivered to the patient may automat-

ically inform about a problem of which the patient is

not aware. Sensor values systematically out of range

suggest a wrong position or weak contact with the

body. This again can be caused by dirt, humidity or a

loosened ﬁxation. Signal from a device will be miss-

ing if its battery is drained or if the device was un-

comfortable and has been removed. It also could be

broken, lost or stolen. The effective cause is unknown

to the service providers. Therefore the patient has to

be personally contacted, otherwise his/her system will

not be working. The patient can correct the installa-

tion of the devices, but if the problem is caused by a

property of the installed devices, like weight, size or

noise, it rather gives a valuable input to the producers

who should improve the design.

Figure 8: Call center - active contact.

Evidently, if the contact has to be efﬁcient, the pa-

tient has to be available and be in the position to con-

centrate on the problem. Therefore a second call at

another time of the day may be needed, or a follow-

up call if the problem persists or reappears after a cer-

tain time. We see that the tasks of a call center are

very similar to a Customer Relationship Management

(CRM) System. A 24 hours / 7 days operation is rec-

ommended. In addition to the technical and medi-

cal fundamentals, the personnel needs local language

skills and the ability to interact with ill, elderly, un-

certain or angry people.

Producers

The individual devices (sensors, actuators) have

various producers. Typically, they will provide their

own means for reading the status and data recorded

in the devices or for updating the software. In our

case, it is important that the patient’s set of devices is

treated as a system. The operator should know about

the deployed software versions, in our design it is also

the main distributor of the information. This does not

ResearchandEngineeringRoadmapforDevelopmentandDeploymentofSmartMedicalDevices

227

exclude sending data directly to the producer who has

own established programs for data analysis and qual-

ity control. It is also possible that in the initial phase

the procedures deployed in the system proposed here

are not equally mature. It is understandable that the

producer is interested in keeping its trade secrets and

in treating the faults in its products discreetly. On

the other hand, we promote here openness, and this

ﬁnally serves all. It is to be decided if the produc-

ers should have a direct commercial relationship with

the end users (and consequently know them) or not.

We endorse the solution where they are isolated from

them by the interface of the conﬁgurators and opera-

tors of our system.

They should be informed about the performance

of the devices, mechanical, electrical and networking

issues. The software update process has to be deﬁned:

in what cases the producer is obliged to deliver an up-

date (e.g. software crash, new security leak) and what

are the test and approval procedures.

Approval Authorities

The proposed system should be integrated in the

postmarked surveillance program of the approval au-

thorities. It can generate automatic warnings about

the malfunction of the devices. One goal is ensuring

the patients’ safety. Therefore emergency cases that

put their health in danger have to be reported imme-

diately. Another goal is to evaluate the effectiveness

of the methods and the quality of speciﬁc devices. In

the proposed system, long term progress reports can

be generated. They should not be treated as the sole

basis for decisions, they can however be useful in pro-

viding sound quantitative foundation. If the therapies

are refunded, their cost-effectiveness should also be

evaluated. The exact contents and frequency of re-

ports are subject to an individual agreement. In the

case of internationally marketed products, many au-

thorities may be involved.

Research Institute

The main task of the research institute is to sup-

port the registry. The goal of the registry has been

presented in the section 4.4.3. The researchers have

to deﬁne the logical structure of registry items that is

a reasonable compromise between diverging require-

ments: heterogeneity, variability and stable structure

for comparison and research. The actual implemen-

tation and hosting may be provided by a partner with

stronger IT skills. The researchers use this data col-

lection to answer questions leading to better medical

and economical decisions. They publish scientiﬁc pa-

pers and produce reports for cooperating medical so-

cieties, government ofﬁces or for general public.

The researchers have to bring skills in relevant

medical ﬁelds and in statistics. The environment is

very far from a clean randomized trial. The patients

represent a known, but neither predeﬁned nor bal-

anced assortment of age, gender, life-style and other

properties. The devices are applied as decided by the

hospital, their elements are replaced, software is ﬁxed

and updated. This makes producing truthful statistics

extremely challenging.

5.3 Driving Forces

The proposed scheme is based on the cooperation of

many partners. It will never function in real life if

they are not sufﬁciently motivated to participate.

The patients want to receive the best treatment

possible and the hospitals want to provide it. Both

of them want to have freedom of choice of therapy

and devices and to avoid a vendor lock. With the reg-

istry, we propose a secondary use of patients’ data,

not aimed directly to support their own health. Ul-

timately the goal of collecting those data is to serve

them better in optimizing the therapy and eliminating

device faults. This approach corresponds to the trend

towards the predictive, personalized, preventive, par-

ticipative (P4) medicine (Hood, 2013).

Strong, established device producers often prefer

to protect their market share with proprietary stan-

dards. This is a winning strategy only for dominant

players, as for the less strong ones it would limit the

possible options to own products, what may reduce

their chances for new customers. For small, innova-

tive producers, participating in open standards is the

only way to reach the market.

The producers may be reluctant to participate in

the quality monitoring scheme, as it discloses the de-

fects of their devices. On the other hand, not hiding

the issues makes the impression of playing a fair game

and should eventually increase the trust of the patients

towards such producers.

In many countries there is a growing pressure

from the side of the ofﬁcial bodies, like approval au-

thorities to cooperate in the evaluation of medical

effectiveness and ﬁnancial efﬁciency. This pressure

may be a decisive argument for participation.

The framework proposed here intends to provide

solution for several basic cases, each of them having

slightly different participants with different interests

and motivations. The following diagrams show those

participants and the respective information ﬂows for

the considered cases:

• Health support (Fig. 9)

• Quality assurance (Fig. 10)

• Medical research (Fig. 11)

BIODEVICES2015-InternationalConferenceonBiomedicalElectronicsandDevices

228

Figure 9: Data ﬂow for health support.

Figure 10: Data ﬂow for quality assurance.

6 DEVELOPMENT ROADMAP

In the preceding sections we have presented the issues

hindering the widespread adoption of smart medical

devices and shown an organizational structure that

should facilitate this adoption. Now we want to out-

line a roadmap that sets the overall structure of a so-

lution permitting to construct ﬂexible healthcare sys-

tems based on smart medical devices. We aim at open

systems where all producers can concentrate on their

core capacities and deliver elements of best quality

that can be selected by the conﬁgurators without be-

ing locked by vendors’ proprietary, undisclosed stan-

dards. Our goal will be achieved if these ideas will

help to focus the future development or serve as a

basis for discussion. The terminology used in the

following text relates to the proposed organizational

structure, as shown in Fig. 6 and Fig. 7.

• Building Composite Devices

– Combining personal device clusters into com-

posed multi-element devices

– Selecting / expanding current interoperability

standards

– Creating a generic structure for smartphone ap-

plications for sensor/actuator networks

A modular smartphone application should be able

to integrate various devices from different vendors.

The devices have common features on various levels.

They send or receive several data types: events, sin-

gle values, waveforms. They can send data sponta-

neously (asynchronously or in a time raster) or when

requested. The semantics can be categorized into

a limited (but extensible) number of classes: blood

pressure, oxygen saturation, electrocardiogram. On

all those levels modular software structure has to be

Figure 11: Data ﬂow for medical research.

deﬁned. It is also to be analyzed to what extent the

emerging de facto standards (e.g. from Apple and

Samsung) are really applicable, ﬂexible and extensi-

ble in the open environment.

• Integrating devices in the healthcare system

– Deﬁning data extracts for various recipients

– Implementing data transformations and split-

ting data ﬂow

– Solving related security and privacy issues

Data sent from the composite medical device to

the network operator module consist of a sequence of

items: events and measurements. The operator soft-

ware distributes them to the registered recipients (hos-

pital, producer, quality control, approval authority or

other). The recipients may register for certain types of

items related to various sources (patients). Depend-

ing on the recipient, the forwarded items may be pro-

cessed, e.g. anonymized. A recipient may also submit

an algorithm for processing the sequence of items to

detect interesting events. In such a case the sequence

would be processed locally at the operator on behalf

of the recipient that would be informed only if a de-

ﬁned event occurs. For security and privacy protec-

tion, the data ﬂow has to be veriﬁed and approved by

qualiﬁed (human) administrators. If basic access limi-

tations for a recipient are deﬁned, he/she can also sub-

mit an algorithm that will be automatically attached to

the system if those limitations are respected. Such a

modular structure will permit to construct the opera-

tor software with no knowledge about the underlying

semantics.

• Monitoring quality

– Deﬁning a ﬂexible and expandable ontology

permitting to compare heterogeneous, evolving

devices

ResearchandEngineeringRoadmapforDevelopmentandDeploymentofSmartMedicalDevices

229

– Establishing a vendor-independent infrastruc-

ture for continuous assessment of devices qual-

ity and therapy methods effectiveness

The devices we want to integrate into our scheme

are heterogeneous, they come from various vendors

and their hardware and software may be frequently

updated. They show however certain similarities. For

example, implantable devices face similar problems:

short battery life, erosion by body ﬂuids, mechani-

cal/chemical/electrical harm to the body, etc. Wire-

less nodes can lose data packets, their signal can be

attenuated by body tissue or clothing. They can also

be subject to malicious human actions like eavesdrop-

ping or impersonation. We see that a device, because

of its properties may belong to many classes. The goal

of the design of the registry is to capture these simi-

larities and to generate standardized data structures in

the database that will permit to make some founded

statements about the (absolute and relative) quality of

the devices and the efﬁcacy of the therapy methods.

• Organization

– Organizing device conﬁguration and distribu-

tion

– Establishing efﬁcient data exchange between

deployed devices and healthcare institutions

– Setting an organization for handling special

cases initiated by patient or by hospital

– Solving international approval issues

– Ensuring a correct reimbursement for speciﬁc

medical cases

The tasks described above are necessary if we

want to pass from a technically possible solution to

a solution that is actually applied. Only if we succeed

here, the patients will effectively beneﬁt from our ef-

forts. As the experience shows, overcoming organi-

zational hurdles and convincing potential partners to

enter into a cooperation may be more difﬁcult than

providing the technology. However, a working tech-

nical solution is a condition for

• Statistics

Until now we have discussed the methods to en-

sure the data ﬂow for the system operation and quality

assurance. The next step is to process the collected

data in order to obtain meaningful insights, helping

to choose the best devices and to evaluate the medi-

cal efﬁcacy of the therapies, also with respect to the

costs. The setting is far from a clean clinical trial. The

composition of the patients’ cohort is statistically bal-

anced. The condition tested is not a simple yes or no

- during a treatment the device can be replaced wit a

new model, some elements can be updated, software

bugs can be ﬁxed. Also the result is not reducible to

a single parameter. The algorithm of an insulin pump

may be correct, but the software may crash from time

to time. After a patch, this problem is solved. On

the other hand, the composition of the substance used

may be not optimal for some patients. The device may

be rejected by some patients as too obtrusive. The tip

of an implanted sensor may break. How to determine

which parts of the result are conserved when system

elements are modiﬁed? All this is an immense chal-

lenge to the statisticians.

7 CONCLUSION AND FUTURE

WORK

In this paper we have presented the technical and or-

ganizational obstacles that curb the widespread adop-

tion of mobile medical systems. We have then pro-

posed a modular framework of a solution. In the fol-

lowing we have outlined a roadmap that will permit to

channel the activities of the developers ant other part-

ners into a well coordinated effort. It deﬁnes the main

tasks and pinpoints the elements critical for the inter-

operability. In our opinion, it can be used as a draft of

an actual project plan. The list of tasks is long, there-

fore they have to be executed by many teams over a

longer period of time. We intend to be a part of it.

Achieving interoperability of smart medical de-

vices and reliable functioning of systems built upon

them is a tremendous challenge. However, without

engaging in this endeavor we will remain at the stage

of isolated solutions and the promising technologies

will not meet our justiﬁed expectations.

REFERENCES

Abdel-Aleem, S. (2009). Design, execution, and manage-

ment of medical device clinical trials. John Wiley &

Sons.

Alemdar, H. and Ersoy, C. (2010). Wireless sensor net-

works for healthcare: A survey. Computer Networks,

54(15):2688–2710.

Alemzadeh, H., Iyer, R. K., Kalbarczyk, Z., and Raman, J.

(2013). Analysis of safety-critical computer failures in

medical devices. Security & Privacy, IEEE, 11(4):14–

26.

Amit, G., Suleiman, M., Konstantino, Y., Luria, D.,

Kazatsker, M., Chetboun, I., Haim, M., Gavrielov-

Yusim, N., Goldenberg, I., Glikson, M., et al.

(2014). Sex differences in implantable cardioverter-

deﬁbrillator implantation indications and outcomes:

BIODEVICES2015-InternationalConferenceonBiomedicalElectronicsandDevices

230

lessons from the Nationwide Israeli-ICD Registry. Eu-

ropace, page euu015.

Bergsland, J., Elle, O. J., and Fosse, E. (2014). Barriers

to medical device innovation. Medical devices (Auck-

land, NZ), 7:205.

Bond, R. R., Finlay, D. D., Nugent, C. D., and Moore, G.

(2011). A review of ecg storage formats. International

journal of medical informatics, 80(10):681–697.

Castro, M., Rubin, A. S., Laviolette, M., Fiterman, J., Lima,

M. D. A., Shah, P. L., Fiss, E., Olivenstein, R., Thom-

son, N. C., Niven, R. M., et al. (2010). Effectiveness

and safety of bronchial thermoplasty in the treatment

of severe asthma: a multicenter, randomized, double-

blind, sham-controlled clinical trial. American journal

of respiratory and critical care medicine, 181(2):116.

Estrin, D. and Sim, I. (2010). Open mHealth architec-

ture: an engine for health care innovation. Sci-

ence(Washington), 330(6005):759–760.

Franke, M., Seidl, C., and Schlegel, T. (2013). A seamless

integration, semantic middleware for cyber-physical

systems. In Networking, Sensing and Control (IC-

NSC), 2013 10th IEEE International Conference on,

pages 627–632. IEEE.

Hauser, R. G. (2012). Here we go againanother failure

of postmarketing device surveillance. New England

Journal of Medicine, 366(10):873–875.

Hood, L. (2013). Systems Biology and P4 Medicine: Past,

Present, and Future. Rambam Maimonides medical

journal, 4(2).

Kesselheim, A. S., Rajan, P. V., et al. (2014). Regulat-

ing incremental innovation in medical devices. BMJ,

349:g5303.

Kramme, R. (2007). Medizintechnik: Verfahren, Sys-

teme, Informationsverarbeitung; mit 170 Tabellen.

Springer.

Kumar, S., Nilsen, W., Pavel, M., and Srivastava, M.

(2013a). Mobile health: Revolutionizing health-

care through trans-disciplinary research. Computer,

46(1):28–35.

Kumar, S., Nilsen, W. J., Abernethy, A., Atienza, A.,

Patrick, K., Pavel, M., Riley, W. T., Shar, A., Spring,

B., Spruijt-Metz, D., et al. (2013b). Mobile health

technology evaluation: the mhealth evidence work-

shop. American journal of preventive medicine,

45(2):228–236.

Lemke, B., Fr

ohlig, G., Jung, J., Carlsson, J., and Koglek,

W. (2013). Herzschrittmacher-und Deﬁbrillator-

Therapie: Indikation-Programmierung-Nachsorge.

Georg Thieme Verlag.

Lipton, R. B., Dodick, D. W., Silberstein, S. D., Saper, J. R.,

Aurora, S. K., Pearlman, S. H., Fischell, R. E., Rup-

pel, P. L., and Goadsby, P. J. (2010). Single-pulse

transcranial magnetic stimulation for acute treatment

of migraine with aura: a randomised, double-blind,

parallel-group, sham-controlled trial. The Lancet Neu-

rology, 9(4):373–380.

Lodi, C. A., Vasta, A., Hegbrant, M. A., Bosch, J. P.,

Paolini, F., Garzotto, F., and Ronco, C. (2010). Mul-

tidisciplinary evaluation for severity of hazards ap-

plied to hemodialysis devices: an original risk analy-

sis method. Clinical Journal of the American Society

of Nephrology, pages CJN–01740210.

Memon, M., Wagner, S. R., Pedersen, C. F., Beevi, F.

H. A., and Hansen, F. O. (2014). Ambient assisted liv-

ing healthcare frameworks, platforms, standards, and

quality attributes. Sensors, 14(3):4312–4341.

Mohr, D. C., Cheung, K., Schueller, S. M., Hen-

dricks Brown, C., and Duan, N. (2013). Continuous

evaluation of evolving behavioral intervention tech-

nologies. American journal of preventive medicine,

45(4):517–523.

Pawar, P., Jones, V., Van Beijnum, B.-J. F., and Hermens,

H. (2012). A framework for the comparison of mobile

patient monitoring systems. Journal of biomedical in-

formatics, 45(3):544–556.

Potapov, E., Meyer, D., Swaminathan, M., Ramsay, M.,

El Banayosy, A., Diehl, C., Veynovich, B., Gregoric,

I. D., Kukucka, M., Gromann, T. W., et al. (2011).

Inhaled nitric oxide after left ventricular assist de-

vice implantation: a prospective, randomized, double-

blind, multicenter, placebo-controlled trial. The Jour-

nal of Heart and Lung Transplantation, 30(8):870–

878.

Sedrakyan, A., Marinac-Dabic, D., and Holmes, D. R.

(2013). The international registry infrastructure for

cardiovascular device evaluation and surveillance.

JAMA, 310(3):257–259.

Seeger, C., Laerhoven, K. V., Sauer, J., and Buchmann, A.

(2013). A Publish/Subscribe Middleware for Body

and Ambient Sensor Networks that Mediates between

Sensors and Applications. In Healthcare Informat-

ics (ICHI), 2013 IEEE International Conference on,

pages 199–208. IEEE.

Sliwa, J. and Benoist, E. (2012). A web architecture based

on physical data separation supporting privacy protec-

tion in medical research. International Journal of Re-

liable and Quality E-Healthcare, 1(4).

Sorenson, C. and Drummond, M. (2014). Improving medi-

cal device regulation: The united states and europe in

perspective. Milbank Quarterly, 92(1):114–150.

Speidel, D. and Sridharan, M. (2014). Quality Assurance

in the Age of Mobile Healthcare. The Journal of

mHealth, 1(2):42–46.

St Cyr, T. J. (2013). An overview of healthcare standards. In

Southeastcon, 2013 Proceedings of IEEE, pages 1–5.

IEEE.

Teow, N. and Siegel, S. (2013). Fda regulation of medi-

cal devices and medical device reporting. Pharmaceut

Reg Affairs, 2(110):2.

Tomlinson, M., Rotheram-Borus, M. J., Swartz, L., and

Tsai, A. C. (2013). Scaling up mHealth: where is the

evidence? PLoS medicine, 10(2):e1001382.

Trigo, J. D., Kohl, C., Eguzkiza, A., Mart

ınez-Espronceda,

M., Alesanco, A., Serrano, L., Garc

ıa, J., and Knaup,

ResearchandEngineeringRoadmapforDevelopmentandDeploymentofSmartMedicalDevices

231

P. (2014). On the seamless, harmonized use of

iso/ieee11073 and openehr. Biomedical and Health

Informatics, IEEE Journal of, 18(3):872–884.

Viswanathan, H., Chen, B., and Pompili, D. (2012). Re-

search challenges in computation, communication,

and context awareness for ubiquitous healthcare.

Communications Magazine, IEEE, 50(5):92–99.

Wagner, S., Hansen, F. O., Pedersen, C. F., Memon, M.,

Aysha, F., Mathissen, M., Nielsen, C., and Wesby,

O. (2013). Carestore platform for seamless deploy-

ment of ambient assisted living applications and de-

vices. In Proceedings of the 7th International Con-

ference on Pervasive Computing Technologies for

Healthcare, pages 240–243. ICST (Institute for Com-

puter Sciences, Social-Informatics and Telecommuni-

cations Engineering).

Wolpert, C., Lubinski, A., Bissinger, A., Merkely, B., Pri-

ori, S., and Brugada, J. (2011). Barriers to imple-

mentation of evidence-based electrical therapies and

the need for outcome research: role of European reg-

istries. Europace, 13(suppl 2):ii18–ii20.

Yao, J. and Warren, S. (2005). Applying the ISO/IEEE

11073 standards to wearable home health monitoring

systems. Journal of clinical monitoring and comput-

ing, 19(6):427–436.

Yin, G. (2012). Clinical Trial Design: Bayesian and Fre-

quentist Adaptive Methods, volume 876. John Wiley

& Sons.

Zannad, F., Stough, W. G., Pi

na, I. L., Mehran, R., Abra-

ham, W. T., Anker, S. D., De Ferrari, G. M., Farb,

A., Geller, N. L., Kieval, R. S., et al. (2014). Current

challenges for clinical trials of cardiovascular medical

devices. International journal of cardiology.

BIODEVICES2015-InternationalConferenceonBiomedicalElectronicsandDevices

232