Modular Health Kiosk based on Web Technologies

João Silva, Pedro Brandão and Rui Prior

Instituto de Telecomunicações, Faculdade de Ciências da Universidade do Porto, Portugal

Keywords:

Health Kiosk, Personal Health Devices, Data Collection, Autonomous Measurements, Health Monitoring.

Abstract:

We describe a modular and easily reconﬁgurable Health Kiosk based on common, off-the-shelf Personal

Health Devices and a computer with a touchscreen interface. The Kiosk is implemented in standard web tech-

nologies (JavaScript, HTML and CSS) on top of the Electron platform. It is intended to be used autonomously

by the patients. It is highly modular, can easily be adapted and reconﬁgured by health professionals with little

to no computer expertise, using a graphical interface, to adapt to different groups of patients and use cases.

We document our ﬁndings, identifying problems faced throughout the development and solutions to those

problems.

1 INTRODUCTION

With the increase of the population at a worldwide

level, the expenses associated with health care are

proportionally increasing. Despite that fact there are

still some gaps that need to be fulﬁlled since the re-

sources are mainly allocated in central areas that most

of the time are not easily accessible to all the pop-

ulation. Moreover, due to that centralization of re-

sources, the ratio of patients for each health profes-

sional is expected to increase, making it more difﬁ-

cult for them to proper assess all patients that use a

medical facility.

There is a clear demand for alternatives to visit-

ing a medical facility, due to the expenses associated

with it, not only ﬁnancial but also in terms of time.

Due to the high demand and a low offer in terms of

medical professionals available, there is a chance that

when visiting a medical facility a patient may not be

evaluated by a professional. This situation can lead to

a delay in ﬁnding abnormal biometric values, causing

a later treatment start.

Health has always been a ﬁeld with a high-level of

acceptance of innovation, and using technology with

the intent of improving patients health is something

that has been evolving over the time. This evolution

allowed for the development of medical devices ac-

cessible not only to hospitals but also for personal use

at home. (Suggs, 2006) There was an evolution from

different types of devices that facilitated the access to

health information. The phone acted as a way to solve

simple questions for the patients, which, when the In-

ternet access was globalized, was made easier through

forums or e-mails.

A shortage of these types of devices or technolo-

gies in rural areas is visible and due to that fact, it

should be a main goal of our society to try to reduce

the discrepancy between these areas and others more

developed. In rural areas where the offer in terms of

medical services is low, the impact of a system that

can make evaluation of the patients without taking

time from the medical professionals can be extremely

relevant. (Das and Padhy, 2014)

Creating a system such as the health kiosk would

allow the patients, without the requirement of allo-

cating human resources in these areas, hospitals or

other possible locations, to obtain information on

their health, ultimately saving time and resources to

the user, and in the case of the hospital both to the pa-

tient and to the health professional that has access to

the information without having to collect it.

Possible applications of this system are hospitals

or health centers, but it is not limited to those as the

system is being developed in order to adapt to the

needs of the situation. This is accomplished by having

a conﬁguration that allows for modiﬁcations. With the

right conﬁguration it can be deployed in rural areas,

based on the needs of those areas, or elderly commu-

nities in which its inhabitants require constant medi-

cal attention.

In this work, the possibilities of improving an ex-

isting health kiosk are analyzed, what modiﬁcations

were made, what beneﬁts those modiﬁcations bring

to the table, as well as the difﬁculties faced on the

Silva J., BrandÃ

co P. and Prior R.

Modular Health Kiosk based on Web Technologies.

DOI: 10.5220/0006297705170525

development and milestones that are to be reached in

order to have a fully functional system, capable of be-

ing deployed in different areas.

2 RELATED WORK

Using computers or other internet capable devices has

always been of great help in health related develop-

ments, not only with respect to machines used, the

type of devices available in hospitals but also in the

way the general population has access to health infor-

mation.

The evolution of technology made possible the

adaptation of several of those developments to health

areas, such as the phone, video, clariﬁcation of doubts

via e-mail, medical websites, and the creation and us-

age of electronic health records. (Verma et al., 2008)

With the increase in the variety and offer of medi-

cal devices, it rose the idea of grouping a set of these

devices associated with an application in order to cre-

ate a system capable of taking measurements of its

users to provide some feedback on their vital signs,

which otherwise would not be possible if its users

lacked the resources to acquire these devices or to

make visits to health centers. Currently the health

kiosk is a system capable of collecting data from a

blood pressure monitor, a weighing scale and a pulse

oximeter. Nonetheless, it is not limited solely to these

devices as new ones can easily be added to the system.

The idea of a system capable of collecting bio-

metric data from its users and show them the re-

sults is not new, as it can be seen in public locations,

where most of the time static, ofﬂine systems with

a small set of instructions provide the user valuable

information. In parallel some other types of kiosks

can be seen in some locations such as the informa-

tion kiosks that serve the purpose of disseminating in-

formation throughout the population (Nicholas et al.,

2003; Leeman-Castillo et al., 2010), they can be in-

ternet connected with the intent of remotely changing

the available information.

A more approximated system to our proposal is

the Multi-User Health Kiosk developed in a joint ef-

fort of the University of Pittsburgh and Carnegie Mel-

lon University. (Courtney et al., 2013) Their ﬁndings

provided helpful information on how to tackle the de-

velopment of a health kiosk. Creating a modular ar-

chitecture, to change in accordance to what is needed

or providing helpful, step by step, instructions on how

to use the devices, is information that, despite being

simple, has a major impact on the usability of the sys-

tem.

Since our aim with this system is to deploy it at

communities, public locations or medical facilities, a

multi-user approach must be made instead of creat-

ing a simple collection tool for a single user to use at

home. This has to take into account that the system

will be used by different users, with different charac-

teristics and different health needs.

A speciﬁc application case of this type of system

are elderly communities, as the need for attention on

their vital signs is higher due to the increased fragility

of human health over time. This type of deployment

has proven to be very positive with a high-level of

acceptance from its users. (Demiris et al., 2013)

The system is being developed making use

of commercially available Personal Health Devices

(PHDs). With the increased availability of these types

of devices, the price is more accessible, reducing the

total cost of assembling a system with these require-

ments. Some of the devices that are already working

with this system, and possible new devices, communi-

cate under a standardized form, which allows adding

new devices in a simpler way since the communica-

tion module handles all the devices.

The ISO/IEEE 11073 Personal Health Data (PHD)

Standards allow for the intended interoperability be-

tween some of the different devices that make up the

system. This standard appeared as a merge of differ-

ent standards such as ISO TC215, CEN TC251, IEEE

1073. (Nam et al., 2011) The Continua Health Al-

liance has a major impact both in the standard as well

as in the health care industry, trying to standardize

health devices in an orderly process, and also to make

it easier for developers to work around with these de-

vices.

Not having this standardization in some devices is

a problem since it means that an individual approach

must be made in order to interact with the devices. A

way to establish the communication has to be created,

as well as an interpretation of the messages sent by

the devices, and if needed to the devices.

The objective of reducing consultation times, and

keeping a more detailed patient’s history is achieved

by having access to these records. This implies that

the health kiosk in the future must be able to add

data to the patient’s Electronic Health Record (EHR)

this would improve the view the health professional

has on the patient’s history since the number of mea-

surements taken outside a medical facility should be

higher than inside one. Despite its beneﬁts, it is not

an easy task to converge the user’s medical data of a

user and make it available at all medical facilities that

the user could visit. (Kalra, 2006) For now, a local

database serves the purpose of giving the patients the

possibility of saving and evaluating their history.

It is now possible, when using the health kiosk to

make use of a smart card reader, this option makes

it possible to extract data from the Portuguese Citi-

zenship card. This function helps not only to avoid

human error when inserting personal data, but also

as a way of reducing usage time of the application.

Further testing needs to be made in order to establish

the true value of this feature. The data available for

collection is public data that is visible in the physi-

cal card, no private data is accessible without a Per-

sonal Identiﬁcation Number (PIN) that only the user

has knowledge of, besides text data it is also possible

to extract the picture of the user.

With the objective of being used in an autonomous

way by the patients, the usability of the health kiosk is

a concern. The current version of this system is an im-

provement to an existing version, which was assessed

in respect of the usability of the application. The dif-

ferences between the two versions will be address in

the next section. (Soares et al., 2016) Little changes

were made relative to the execution ﬂow of the appli-

cation in order to take advantage of the information

that was collected regarding the usability. This eval-

uation of the application was based on observer-ﬁlled

questionnaires alongside the option of keeping track

of user clicks on the screen in order to evaluate the

number and position of clicks per screen to see the

changes to be made in the presented content.

3 OVERVIEW OF THE SYSTEM

An example of a health kiosk physical deployment is

visible in Figure 1, which has three devices associated

with it, a blood pressure monitor, a pulse oximeter and

a weighing scale that is not visible in the ﬁgure. The

interaction from the user is made through the use of

the touchscreen, if the user chooses to, it can insert

the citizenship card onto the smart card reader. After

the exams are ﬁnished, the results are printed in the

printer that is also visible in the ﬁgure.

Figure 1: Physical health kiosk.

Relative to the system architecture a representa-

tion is visible in Figure 2. The system has two possi-

ble types of devices, Continua Alliance Certiﬁed and

Non Certiﬁed Devices, at the moment all the devices

communicate via Bluetooth. Nonetheless, the devel-

opment of a way to communicate with the devices

takes one of two possible approaches, either the de-

vice is Continua Alliance certiﬁed and communicates

with an Antidote IEEE 11073 PHD interface, or it

is not certiﬁed and an individual approach must be

made in order to communicate with that speciﬁc de-

vice. The process of creating a way of communicat-

ing with a non-certiﬁed device can be applied to other

devices, creating a skeleton that is the base for the

development. Consequently, reducing the time of de-

velopment.

In the future we intend to have a connection to a

central EHR system, in order to make the patient’s

data available in different health kiosks, as well as to

health professionals. By sharing data along all differ-

ent locations that the users visit the impact the col-

lected information has is higher.

Figure 2: Overview of the System.

4 IMPLEMENTATION

The current development of the health kiosk has been

based on a previous existing version that, despite al-

ready having a functional ﬂow, did not have the tools

for a proper continuous development. With that came

the idea of developing a version of the health kiosk

that used web technologies. The previous version

was developed using JavaFX, where some challenges

were found before the transition into the use of web

technologies. This transition came as an alternative

that could replace the existing version and at the same

time take advantage of features that are available with

the usage of this type of technologies, such as Web

Real Time Communication (WebRTC).

The application was developed on top of Electron,

a framework for building cross-platform applications

based on JavaScript, HTML and CSS. The Electron

framework was selected because it makes it possible

to communicate with the operating system directly us-

ing Node.js, while providing all the advantages of us-

ing web technologies (including the vast amount of

JavaScript libraries for building web applications).

The previous version was already assessed in

terms of usability (Soares et al., 2016). With that in

mind, the development of the new interface was made

trying to keep the same ﬂow of interaction.

Some changes had to be made, either because of

the advantages of using web technologies, or because

the creation of new modules such as the smart card

reader implied new screens that the user has to inter-

act with. In the following subsections the adaptations

made to the system will be addressed.

Regarding the usage of the application, there are

several possible cases of use due to the modularity of

the application. Figure 3 represents a full usage of

the application, this includes language selection, au-

thentication selection, performing exams and an end

summary. Figure 4 represents a smaller application

case, where no user data is collected, just the exams to

be performed and a summary with respect to the col-

lected data. These variations allow for different ﬁeld

applications since what is intended is to adapt the ap-

plication to the users and/or scenario and not the other

way around.

The ﬂows visible in the ﬁgures goes through sev-

eral steps, these steps being optional in some cases.

By conﬁguring the system to follow the ﬂow visible

in Figure 3 it gives the users the possibility of tak-

ing full advantage of all the features. Starting with

the language selection, the user is presented ﬂags rep-

resenting all available languages. After selecting the

language, all texts and voice instructions to be pre-

sented to the user are in the selected language. The

user is presented now with the authentication method

selection, if the user chooses to use the citizenship

card all the necessary personal data is collected au-

tomatically. If not the user is presented with several

screens in order to insert the data by himself. After

having all the data, the user is presented with a screen

showing all exams that are to be performed. Subse-

quently the user iterates over each exam, following a

set of instructions, either by image or video, and eval-

uating the collected information on an intermediary

results page. In the end a table is shown presenting the

ﬁnal results, and it is also visible in the screen a QR

Code containing all the information of that table that

is inserted as a calendar entry, all this is printed out to

give out to the user. After that, the system restarts and

is ready for a new user.

http://electron.atom.io/

Figure 3: Example of the ﬂow of execution.

What is intended with this system is not only to

have the ability to collect data, process it and present

the results, but to give the option to the responsible

person to adapt the health kiosk in order to fulﬁll the

needs of its users. There are different use cases to the

health kiosk, some differences are related to the type

of data that is intended to be collected, other to the

necessity or not to collect user personal data, for that

the health kiosk must be modular and easily adaptable

to the circumstances.

Figure 4: Example of a simpler ﬂow of execution.

4.1 User Interface

The usage of this system can be divided upon three

different stages, collecting personal data from the

user, collecting data from the devices, presenting re-

sults to the user.

When the patient starts the process of using the

health kiosk, it has the choice of either inserting a cit-

izenship card, and the application itself collects rele-

vant data from the card, or the user can himself insert

its personal data, such as the national health identiﬁ-

cation number, gender, height and age.

After having all the user data collected, the next

step is to go through all the deﬁned exams, after each

exam the user is presented with the results and a

chronological chart with all the measurements taken

with that device associated with the user. The col-

lected measurements are displayed in a bar, colored

green on what are considered default values for that

measurement with a gradient to red as it increases

the distance to those values. The intermediary re-

sults screen are visible in Figure 5, which represents

what it looked like in the older version of the health

kiosk, and Figure 6 represents the newer version of

that screen.

The proposed changes included an usage of

chronological graph, with the x axis being a time se-

ries, which means that the points take into considera-

tion the distance between the presented dates; center-

ing the next button and using a green color instead of

blue.

Figure 5: Blood Pressure Results on the previous version.

Figure 6: Blood Pressure Results on the new version.

In the ﬁnal screen a table is presented with all col-

lected data, as well as a QR Code that upon reading

by a smartphone inserts in the default calendar app an

entry with all the collected data.

A page is also printed containing the user personal

data, the collected data and the QR Code. It also con-

tains a logo on the top that can be conﬁgured to ﬁt the

needs of the situation.

The idea of using a QR Code to share data serves

not only the purpose of saving the data in the users

smartphones, but can also be used in the future as a

way of transmitting data to a health kiosk smartphone

application that if developed can act as a place where

the user can evaluate at any moment their vital signs

registry and even add other measurements that were

not made in the health kiosk.

The printing of the results, as well as the genera-

tion of a QR Code are optional functions that can be

disabled by the person responsible for the conﬁgura-

tion. This goes along with the idea of creating a sys-

tem that is highly conﬁgurable and capable of dealing

with the needs of its users.

4.2 Application Modularity

From the beginning one of principles of the develop-

ment of this health kiosk was the idea of modularity.

By creating a system that is based on this idea, adding

or removing elements, changing their order or using

the system with different conﬁgurations is a goal eas-

ier to achieve.

With that in mind, one of the main focus when

developing this application is the possible conﬁgura-

tions that the application should have. The use cases

can increase by creating a modular application. As

such, a conﬁguration ﬁle was created, in which all

the possible options of the system are inserted. The

conﬁguration ﬁle allows for the deﬁnition of which

screens to show, which exams are to be performed and

in which order to show them.

When having the possibility of choosing which

screens to be used, or which exams to perform, the

system is easily adapted to different use cases, from a

situation where no user data is needed such as a spe-

ciﬁc event where only a speciﬁc parameter is being

evaluated in a population to detect anomalies, to cases

where the system is deployed in a local place where

all the population can access it, and a record speciﬁc

to each user has more meaning.

A approach was made, when the system was being

developed, to try and simplify the process of adding

new exams or devices. A skeleton, based on web

components, is created for adding new exams to the

application, and if the device is certiﬁed, it can easily

be added to the system, needing only speciﬁc codes

for the parameters being read from the device.

Figure 7 represents an exam component, this com-

ponent can be reused in different cases, the compo-

Figure 7: Representation of an Exam Component.

nent itself contains two different components, the card

set that is shown to the user with the instructions,

and the results component that is shown after the user

has passed through all the instruction cards. This ap-

proach was made throughout all the application in or-

der to facilitate adding new screens or elements to ex-

isting ones.

4.3 Internationalization

Although at the moment the smart card component

collects only data from Portuguese Citizenship cards,

and the national health identiﬁcation number asked

is also the Portuguese one, this will not always be

the case, and the wide range of possible users of the

health kiosk must be taken into consideration. With

that in mind, we implemented in the system the pos-

sibility of using different languages, making use of an

internationalization framework

Having each text component associated with an id,

and for each language a set of ids with the respec-

tive text values, the process of making the application

available in new different languages was made easy.

As for adding a new language the development pro-

cess passes only through creating a ﬁle with all the id

and values pairs and the system is capable of dealing

with that information.

Although the previous version of the health kiosk

already had voice instructions, these were recorded

See http://i18next.com/.

by a person. This has some limitations in terms of

development. This initial approach made possible a

ﬁrst development and evaluation on how sound in-

structions can help the user take the available exams.

However, it has several problems associated with it,

for perfect instructions no noise in the sound would

be preferable and this is not possible to achieve with

low cost recording devices. Another fact to take into

account is that even small changes to the audio in-

structions imply that a new recording session has to

be made.

To tackle these issues, we added digital voice in-

structions to the application. These voice instructions

are generated making use of the text-to-speech tech-

nology and saved into ﬁles to ensure that the produced

speech is the same across all systems. The process of

creating these instructions is the same as for the text

instructions, a set of values associated with an Id have

to be created, and then all these values are read and

a ﬁle for each available language is generated. Since

the voice’s used are the available ones on the operative

system, and new ones can be added, it is easily possi-

ble to add voice instructions in different languages.

4.4 Hardware

Currently the prototype of the health kiosk is de-

ployed in an all-in-one PC with a 22” touchscreen.

This prototype is capable of collecting from any pos-

sible combination of a blood pressure monitor, a

weighing scale, and a pulse oximeter. This system

has connected to it a printer in order to handout the

results to its users and a smart card reader to extract

data from the citizenship card.

The current supported and tested devices in the

system are two Continua Alliance Certiﬁed devices,

a blood pressure monitor (AND A&D Medical UA-

767 Plus BT-Ci) and a weighing scale (AND A&D

Medical UC-351PBT-Ci), and a non-certiﬁed device,

a pulse oximeter (Nonin 3230), this device commu-

nicates via Bluetooth Low Energy (BLE). Although

Nonin has a Continua Alliance compliant device we

used this one to develop and test the integration of non

Continua devices. Moreover, we also experimented

with the differences for a BLE device.

4.4.1 Device Communication

During the development of the new version, we cre-

ated modules to communicate with the devices. By

using Electron to develop the application, Node.js can

be used in order to access the operating system di-

rectly, which would not be possible if a browser ap-

plication were to be developed.

Using a Node.js module (node-dbus), made it

possible to develop a new module capable of commu-

nicating with the existing Continua Alliance certiﬁed

devices, and to easily add new devices as long as in-

formation about the devices is previously given to the

developers in order to properly extract relevant infor-

mation produced by the device.

Continua Alliance certiﬁed devices, generate data

in eXtensible Markup Language (XML) format, hav-

ing the relevant medical data associated with a spe-

ciﬁc Id for the parameter, it also provides information

relative to the date of the measurement. It also con-

tains parameters that can hold information about the

physical device.

Since the objective of the application is to adapt to

the users and not the other way around a decision had

to be made in order to support non certiﬁed devices

since there is a possibility of these types of devices

being cheaper for some possible use cases. This deci-

sion goes along with the idea of creating an adaptive

system that is not closed in terms of compatible de-

vices.

For the case of the Nonin Oximeter 3230, as it

is not a Continua Alliance certiﬁed device a different

approach had to be made. Since this device commu-

nicates via BLE it was decided that taking advantage

of a Node.js modules (Noble) was an appropriate way

to develop the means to communicate with these types

of devices. For that a module was created that takes

the MAC Address of a device, starts scanning until

the device is found, after connecting to the device it

has to activate the characteristic of the device respon-

sible for sending data via Bluetooth, when that is done

a stream of continuous data is received by the appli-

cation, being decided that upon a number of repeti-

tions that value was to be considered and the stream

stopped.

The development of these new modules will allow

a simpler development in the future since the base of

the communication is already implemented and what

is required is to adapt it to the new devices is an eval-

uation of the device in order to proper assess what

messages it sends, how it sends them and what is the

best way to extract information from them.

4.5 Usability

Being an application that evolved from an existing

one, and since the previous version had an usability

evaluation, what was made when developing this ap-

plication was to follow the ﬂow of interaction pro-

vided in that application. The usability of the pre-

vious version was studied in different scenarios, at

the university open days (by 195 users), at a health

day in one of the university schools (46 users), during

a week at a local city hall (127 users) and for thir-

teen days in thirteen different villages in Brazil (465

users). This covered different age groups, and usage

information was retrieved not only from the applica-

tion but also from the evaluation on how people used

the system. The evaluation used observer-ﬁlled ques-

tionnaires and user click tracking. The evaluation did

not use the standard user questionnaires as we per-

ceived them as either too long or less appropriate than

a researcher observing the usage. More details can be

seen in (Soares et al., 2016).

At the moment the usability of the current system

has not been tested by a large population. The tools

for assessing time spent on each screen and where the

user has clicked throughout the usage are developed

and will soon be tested. This will allow us to evaluate

if the interface is easily usable, if the user has the abil-

ity to use the application from start to ﬁnish without

any assistance, or if so which screens are taking more

time from the ﬂow of interaction.

The collection of time spent on each screen can

help us determine if the instructions on the screen are

easy to understand, and for instance, if having the

ability to use a citizenship card is quicker and more

adopted than introducing the data manually.

By also collecting the coordinates of the clicks and

group all clicks made in a single screen presenting

them on top of a screen representation it is possible to

determinate if the screen is usable, and if it is being

used in the most correct way. If a large group of peo-

ple click somewhere in the screen that is not intended

to be clicked then something is not right about that

screen and must be evaluated.

More consideration has to be made in order to

proper evaluate the usability by using these methods,

such as the elimination of outliers that could affect the

visualization of the problems on the screen. A small

amount of users could make excessive clicks in wrong

places or spent too much time in certain screens and

with that alert for a non existing problem.

The usability of a previous version of the health

kiosk has been tested (Soares et al., 2016) with the

same idea of representing clicks on a screen represen-

tation, which is visible on Figure 8.

Figure 8: Weight measurement result screen usage pattern.

In Figure 8 it is possible to evaluate that users try

to interact with the color gradient before clicking on

the button to show the new screen. This type of infor-

mation allow us to consider what steps to take to make

the application more ﬂuid, with quicker and better re-

sponses from the users.

4.6 Conﬁguration Tool

Both on the previous version as well as in the new

version there was a unique point in the system that

was responsible for the conﬁguration of the system.

The conﬁguration ﬁle is currently responsible to

allow for the deﬁnition of which screens to be shown

or wich personal data to collect, if features such as QR

Code, printing, voice instructions should be used or

not in the application among other different options.

For easier conﬁguration, all possible conﬁgurable

values must be in this ﬁle. At this moment it is under

development a tool that will allow for non-technical

users to conﬁgure the health kiosk. A preview of the

application interface is visible in Figure 9, this appli-

cation will be divided in several blocks of conﬁgu-

ration grouped by what is being conﬁgured, such as

available languages, what type of authentication is to

be used, what exams are to be performed. The de-

velopment of this tool is not only important to make

the health kiosk conﬁgurable without technical help

but also to evaluate what truly is conﬁgurable in this

system.

Figure 9: Current status of the Conﬁguration Tool.

5 CONCLUSIONS

A system such as the health kiosk could have a major

impact in different possible scenarios, such as rural

areas lacking medical resources or health centers with

higher attendance than the one they can process. De-

ploying this system in these locations, makes it pos-

sible for the population to, by themselves, measure

their vital signs.

The current prototype makes use of a simple

weighing scale, a portable blood pressure monitor and

pulse oximeter, an evaluation of possible changes to

this setup is undergoing, with the idea in mind of hav-

ing devices simpler to use and that possibly collect

more data. One example is going from a normal blood

pressure monitor that the user has to set up and adjust,

to one where the user simple introduces the arm in the

ﬁxed device and waits for the results. Also, weighing

scales capable of evaluating body fat are also an al-

ternative to the current existing ones. One point that

has to be considered is relative to the powering of the

devices, presently all the devices are battery powered,

which is not feasible in large scale.

At it was already referred, the conﬁguration of

the health kiosk is made by editing an existing con-

ﬁguration ﬁle with the desired values, but a Graphi-

cal User Interface (GUI) is being integrated into the

health kiosk system soon that will allow for anyone

responsible for the health kiosk to edit the conﬁgura-

tion without knowledge of the technical details.

It is also being developed under a master’s the-

sis project a module that will allow the establishment

of a video conference, using WebRTC, in which the

patient can get help on how to use the device or ask

for a medical opinion on the collected data. Due to

the possibilities of WebRTC, the health professional

is not only able to establish a video conference, but it

is also able to have access to data from the applica-

tion, and to send data to the application. This creates

the possibility of having remote instructions that can

change the status of the application.

ACKNOWLEDGEMENTS

This article is a result of the project NanoS-

TIMA Macro-to-Nano Human Sensing: Towards In-

tegrated Multimodal Health Monitoring and Ana-

lytics, NORTE-01-0145-FEDER-000016, supported

by Norte Portugal Regional Operational Programme

(NORTE 2020), through Portugal 2020 and the Euro-

pean Regional Development Fund.

REFERENCES

Courtney, K. et al. (2013). Designing the community multi-

user health kiosk. Enabling Health and Healthcare

Through ICT: Available, Tailored and Closer, 183:79.

Das, R. and Padhy, H. M. (2014). Health monitoring kiosk:

An effective system for rural health management. In-

ternational Journal of Innovations in Engineering Re-

search and Technology, IJIERT, 1(2).

Demiris, G., Thompson, H., Boquet, J., Le, T., Chaudhuri,

S., and Chung, J. (2013). Older adults’ acceptance of

a community-based telehealth wellness system. Infor-

matics for Health and Social Care, 38(1):27–36.

Kalra, D. (2006). Electronic health record standards. IMIA

Yearbook of Medical Informatic, pages 136–144.

Leeman-Castillo, B., Beaty, B., Raghunath, S., Steiner, J.,

and Bull, S. (2010). LUCHAR: Using computer tech-

nology to battle heart disease among latinos. Ameri-

can Journal of Public Health, 100(2):272–275.

Nam, J.-C., Seo, W.-K., Bae, J.-S., and Cho, Y.-Z. (2011).

Design and development of a u-Health system based

on the ISO/IEEE 11073 PHD standards. In The 17th

Asia Paciﬁc Conference on Communications, pages

789–793. IEEE.

Nicholas, D., Huntington, P., and Williams, P. (2003). Three

years of digital consumer health information: A lon-

gitudinal study of the touch screen health kiosk. Inf.

Process. Manage., 39(3):479–502.

Soares, E., Oliveira, C., Maia, J., Almeida, R., Coimbra,

M., Brandão, P., and Prior, R. (2016). Modular health

kiosk for health self-assessment. In Computers and

Communication (ISCC), 2016 IEEE Symposium on,

pages 278–280. IEEE.

Suggs, L. S. (2006). A 10-year retrospective of research in

new technologies for health communication. Journal

of health communication, 11(1):61–74.

Verma, A., Dhand, H., and Shaha, A. (2008). Healthcare

kiosk next generation accessible healthcare solution.

In e-health Networking, Applications and Services,

2008. HealthCom 2008. 10th International Confer-

ence on, pages 194–199. IEEE.