Accessible Mobile Application to Support Self Testing
for Anticoagulated Patients using a Personal Health Record
Appliying Good Practices
Adrián Casado-Rivas, Lourdes Moreno López,
Paloma Martínez Fernández
and Javier García Guzmán
1
Universidad Carlos III de Madrid, Avda. de la Universidad 30, 28911, Leganés, Madrid
Keywords: Personal Health Record, Accessibility, Anticoagulated Patients, Self Testing, Mobile Application,
Requirements Engineering, Good Practices.
Abstract: Full adoption of Information Technologies in the healthcare domain is a reality. New paradigms as mobile
computing can support a big amount of healthcare needs. The aim of this research work is to present the
application of good practices in the design of healthcare information technology following a
methodological approach for apps in mobile environments involving fictitious users based on knowledge of
real users in the app design. Real users’ needs have been extracted from empirical researches, guidelines
and standards, favoring an outstanding role to users. In order to illustrate the approach and provide a
resource to designers, a case study showing how to obtain an accessible design is introduced. The mobile
app considered supports a Personal Health Record and self testing for anticoagulated patients who are often
elderly. The access characteristics of the elderly and their possible disabilities are essential aspects to keep
in mind in the design of a mobile user interface. To address users’ needs on the healthcare mobile
applications it has been concluded that the requirement elicitation must take into account functional
requirements concerning aspects that characterize a disease, and accessibility requirements related to
special needs of patients suffering a disease.
1 INTRODUCTION
New laws, global competition, technological
advances, and evolving societal values toward
disability require the integration of universal and
accessible design principles into the general practice
of the design community (Erlandson, 2010).
Governments support the adoption of Information
Technology (IT) on their national health systems
and especially Electronic Health Records (EHRs)
(Blumenthal, 2009). The purpose of EHRs is to
retrieve all the health information of a patient
distributed in a national health system and in health
providers´ records, giving access to this information
to doctors and patients. One way to accomplish the
goals of health care IT adoption is to give the
patients/health care consumers more control over
their health care and wellness by enabling them to
own and manage a Personal Health Record (PHR)
(Harrison, 2010). PHR is supposed to be used by all
citizens, so systems that support PHRs have to be
accessible by the population
There are many areas in which medicine and
health are being influenced by the impact of apps
and mobile technology, from patient education and
communications, to biometrics and EHRs (Moore,
2012).
When using a PHR, the ideal situation allows
individuals to interact with their health care
providers in real-time to review, update and
customize their own personal health maintenance
and health improvement plans (Harrison, 2010). A
set of patients that need periodical interaction with
their physicians are anticoagulated people. They
receive oral anticoagulants as medical treatment.
Oral anticoagulants are commonly used in the
elderly (van Walraven et al., 2007). The rate of
venous thromboembolism in the general population
is approximately 2.5% (Viale, 2005) and it is
estimated that nearly 60% of patients diagnosed
with venous thrombosis are aged ≥ 70 years
(Bauersachs, 2012).
351
Casado-Rivas A., Moreno López L., Martínez Fernández P. and García Guzmán J..
Accessible Mobile Application to Support Self Testing for Anticoagulated Patients using a Personal Health Record - Appliying Good Practices.
DOI: 10.5220/0004805703510357
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2014), pages 351-357
ISBN: 978-989-758-010-9
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
The drug dose they have to take has to be
regularly adjusted to avoid the appearance of
problems. Patients can adjust their daily oral
anticoagulant dose using self testing techniques.
This issue has motivated the domain of the proposal,
which is presented in this work.
In this paper is proposed the design of an
accessible app to support a PHR for anticoagulated
patients trained for self testing.
Moreover, it is essential to keep in mind the user
in the development process of the application, and
furthermore to take into account the functional
requirements elicitation, to consider accessibility
requirements and special needs of the target
application, in this case, the elderly. As it is a
reasonably well documented fact that software
requirements definition has a big impact on final
product quality,, app’s functional and accessibility
requirements have been collected to achieve a
proper app design.
In conclusion, we present a case study where is
proposed an approach of applying good practices in
the analysis and design of an app for the medical
domain, which can be extended to others. App’s
functional requirements have been extracted from
medical literature, where is described patients’
required care and illness treatment. To obtain app’s
accessibility requirements, it has been studied
standards to first detect target users’ accessibility
needs.
User target of the app is elderly because they are
who usually suffer embolism or thrombosis such as
has been indicated, of which prevents oral
anticoagulants. Elderly people pay more attention to
technology when they consider that it is useful for
them (Sayago et al, 2011) Also, to increase the
technology acceptance is very important to build
and implement an accessible app design because
some disabilities are inherent to age like cognitive
or visual impairment (Hanson, 2009).
2 RELATED WORK
The PHR adoption for self control of personal health
status and the use of IT and mobile devices to
develop health applications are two topics that are
currently working. The literature review carried out
in (Dorr et al., 2007), stands that was found that
many of the reviewed systems to support care for
chronic illness were successfully implemented.
Apps developed for healthcare domain try to
solve different challenges. Some of them are the
monitoring of a patient daily life and provide
assistance in emergency situations as in
(Kozlovszky et al, 2011). The work of (Ogawa et
al., 2012) introduces a mobile application in which
doctor can look up patient’s health information. The
data contains information about a patient’s
medications and medical examinations. The app is
not a PHR, it is a Medical Health Record
nevertheless, the concept of implementing a medical
history can be adopted on PHRs. In (Puustjärvi &
Puustjärvi, 2012) authors become aware of new
healthcare models in which co-operation between
patient’s healthcare team is required.
The success of any software system depends on
how well it fits the needs of its users and its
environment. Requirements Elicitation (RE) is the
process by which the requirements are determined.
Related work of RE in the domain of mobile app for
health have been found in (Widya et al., 2009).
Their work is framed in a UCD approach, in which
highlight the need for UCD development and argue
for an early user involvement (Samaras & Horst,
2005).
Following this approach, in the present work has
been taken into account special needs and
requirements of the users’ accessibility before
design. Previous work on addressing accessibility to
PHRs has been done. In (Basdekis, Sakkalis, &
Stephanidis, 2012), authors present a set of
guidelines to implement successfully an ePHR.
Their motivation to provide the guidelines is that
although web based PHRs systems are plenty of
functionalities and are user friendly, they do not
fully implement accessibility standards.
3 ANTICOAGULATED
PATIENTS
A patient can be considered as anticoagulated when
he/she takes medicine to avoid suffering a
thrombosis or an embolism. A person should start an
anticoagulation treatment when he/she is inside a
group composed of people who have known risk
factors that potentially can cause a thrombosis or an
embolism.
The most popular medicine is oral anticoagulant.
Anticoagulated patients have to remember two
important facts: oral anticoagulant dose has to be
adjusted periodically by a cardiologist and they have
to take the dose each day at the same time. A
cardiologist has to done the adjustment of the dose
measuring the prothrombin time. It is the time that
HEALTHINF2014-InternationalConferenceonHealthInformatics
352
takes a patient with the coagulation altered to
coagulate as compared to the time that it takes to a
patient with non altered coagulation. The standard
measure unit for prothrombin time is International
Normalized Ratio (INR). The test to measure
prothrombin time is called PT/INR test. When the
dose is not well adjusted, it can cause a
haemorrhage or the appearance of clots.
A large group of studies demonstrated that self
testing is an effective technique to improve oral
anticoagulant treatments and the quality of life of
anticoagulated patients (Heneghan et al., 2012). Self
testing is when patients measure by themselves their
prothrombin time. A customized algorithm for each
patient helps to adjust the dose. Anticoagulated
patients have to maintain tight control on taking
their medication and adjusting the dose.
4 PERSONAL HEALTH
RECORDS
A Personal Health Record (PHR) service allows a
patient to create, manage, and control his or her
personal health data in one place through the web,
which has made the storage, retrieval, and sharing of
the medical information more efficient (Li et al,
2013). Traditionally, people have not has access to
their health information, so a PHR system is focused
on collaboration between doctors and patients and
they allow patients to manage and monitor their
health record.
What it is expected to record on a PHR varies
according to user needs and what data can provide
doctors and health organisms. The collaborative
disease tracking has the potential to lower
communication barriers between patients and
caregivers (Tang et al, 2006).
PHR’s have support of governments and
institutions. The IEEE-USA Medical Technology
Policy Committee developed in 2012 a position
statement to the widespread adoption of PHR’s.
This statement aims to fit together PHR systems and
assistive technologies. Also, instructions about
facilitate PHR adoption by implementing the system
on mobile devices and tablets are given.
The architecture of a system that implements a
PHR has been described in the literature as done in
(Tang et al., 2006) and in (Daglish & Archer, 2009).
There exist three predominant architectures: tethered
PHRs, standalone PHRs and Integrated PHRs. The
architecture chosen in this work has been the
integrated as it contains the push model: patients are
going to be the data providers and it is expected a
two side communication with physicians.
5 APP ANALYSIS
This section includes requirements gathering, not
only functional type, but also user requirements
such as requirements of accessibility and special
needs. All knowledge has been obtained through
field research and analysis of standards. This
information in a case of real application should be
complemented by the opinions of stakeholders like
patients and medical practitioners.
5.1 Functional Requirements
To support self testing for anticoagulated patients
and recording of their personal INR results, user
requirements for the app are presented on Table 1.
They are closely related to aspects that characterize
anticoagulation treatments.
Table 1: App’s functional requirements.
Functional Requirements
ID Description
FR-01
The app shall show the user the dose that he/she has
to take.
FR-02
The app shall show the user the time when he/she
has to take the next dose.
FR-03
The app shall show the user the current date on the
same screen where it shows the dose.
FR-04 The app shall show the user the last INR test results.
FR-05
The app shall show the user if the dose has been
validated by his or her cardiologist.
FR-06
The app shall allow the user to update the current
INR test results.
FR-07
The app shall allow the user to send to his or her
cardiologist the current INR test results.
FR-08
The app should allow the user to edit the current
INR test results if them has not been sent to his or
her cardiologist.
FR-09
The app shall receive notifications from the user
cardiologist that contain the updated dose.
FR-10
The app shall update the dose that shows to the user
and mark it as valid when the cardiologist notifies to
the app his agreement.
FR-11
The app shall allow the user to save the dose to take
and the INR test result of each day.
FR-12
The app shall allow the user to look up previous
amount of dose taken together with the
corresponding INR test result.
FR-13
The app should allow the user to share by email his
or her record of previous amount of dose taken
together with the corresponding INR test results.
FR-14 The app should allow the user to set dose reminders.
FR-15
The app should alert the user at the time set for
reminders.
AccessibleMobileApplicationtoSupportSelfTestingforAnticoagulatedPatientsusingaPersonalHealthRecord-
AppliyingGoodPractices
353
5.2 Accessibility and User Needs
Requirements following Standards
Accessibility requirements elicitation has been
divided in two steps. In the first one, both ISO IEC
TR 29138-1 and ISO IEC TR 29138-3 standards
have been checked in order to check for
accessibility aspects to include on the app. In the
second one, accessibility suggestions extracted from
first step have been translated to accessibility
requirements.
5.2.1 Accessibility User Needs
The ISO/IEC TR 29138 is a set of standards that
collects needs for disabled people when using
information technologies. It is divided in three parts,
but only two of them have been used in this work.
The ISO/IEC TR 29138-1 identifies user needs
according to both kind of disabilities and the typical
interactions with information technologies. The
motivation for describing each user need is to get
closer to the problems that people with disabilities
have when they interact with the technology
These technical reports include disabilities as
blindness, visual impairment, deafness, hearing
impairment, deaf blindness, physical impairment,
cognitive and language and learning impairment.
Additionally, when needs match to all the
disabilities listed above, “any kind of disability”
category is used. As indicated, older people are the
target of the app, therefore keeping them in mind
their needs are discussed in this section. Older
people’s user needs respond mainly to cognitive
impairment, as can be read on (Hanson, 2009), and
also important ones were found on visual
impairment and hearing impairment categories.
The ISO IEC TR 29138-3 groups all the user
needs identified on ISO IEC TR 29138-1 by kind of
user interactions. This research has consisted on
first, understanding motivation for each user need to
properly extract those related with app’s target users
and second, on mapping extracted users’ needs with
accessibility requirements. In this case, thirty four
elderly needs have been extracted, taking into
account the app context and the app functionality.
5.2.2 Resources for Mobile Accessibility
Guidelines
Each mobile platform support different user needs.
The major mobile platforms are iOS and Android.
With regard to accessibility documentation, the
following works have been found: Apple
Accessibility Programing Guide for iOS, Apple
iPhone User Guide and Android Developer
Accessibility API Guide. It can be learnt that iOS
operating system supports accessibility since its
prior versions by including on itself a group of
accessibility features, while accessibility features on
Android operating system are mainly provided by
third party. So, the chosen platform has been iOS as
it provides high maturity level accessibility features
on version 6.0, useful for the development of the
app. Table 2 shows the accessibility requirements
obtained, which have been elicited from the
extracted elderly needs.
Accessibility features included on iOS can be
directly adjusted by users accessing the settings
menu. Features that implement some of the
accessibility requirements obtained are: zoom and
large text, accomplishes AR-02, mono audio,
accomplishes AR-05, and LED Flash for Alerts,
accomplishes AR-08.
There are other facilities that are implemented on
iOS environment. One of them is the device control
volume. Users can adjust sound volume with device
volume buttons or inside settings menu. Another is
the app design that can be made taking into account
the Apple iOS Human Interface Guidelines (Apple,
2013). In this guideline, it is explained how to use
iOS technology and UI iOS app elements to
improve user experience. By taking in consideration
this guidance, AR-15 accessibility requirement
could be successfully implemented. For
requirements not supported by iOS platform, it is
suggested to include a preferences view on the app
where the users can adjust required values. Finally,
the app shall provide mechanisms to preserve
information privacy stored on the PHR.
6 APP DESIGN
Guided by guidelines and results obtained from
empirical researches, the next step is to design a
prototype based on requirements previously
collected. Stakeholders must evaluate the prototype
iteratively. To design the app appropriately, it is
necessary to consider look and feel empirical
guidelines taken from (Rello et al., 2012).
Next, app’s user interface mockups for the
prototype are included. A mockup is a middle to
high fidelity, design representation.
Figure 1 shows the state of the app when a
patient uses it the first time in the day. When
opened, the app loads “Today” tab, which mainly
HEALTHINF2014-InternationalConferenceonHealthInformatics
354
Table 2: App's accessibility requirements.
Accessibility Requirements
ID Description
User Need
Traceability*
AR-01 The app shall allow the user to change the information’s color attending to his or her
preferences. By default, text’s color in foreground shall contrast with the background color.
1-5, 1-11
AR-02 The text contained in the app shall be readable. If available, it is suggested to use platform’s
accessibility facilities as zoom or augmented text.
1-6, 5-5
AR-03 The app shall allow the user to suit the sound volume attending to his or her preferences. By
default, sound volume is the one configured on user’s device.
2-3
AR-04 The app shall implement different vibrations patterns for each alternatively vibration. 2-5
AR-05 Sound provided for notifications and alerts shall be monaural except if platform’s
accessibility facilities allow combining stereo channels.
2-6
AR-06 Logos and other decorative elements shall not adopt the controls’ aspect. 3-2
AR-07 Controls and information areas shall visually contrast between them adopting if necessary the
platform’s design guidelines.
3-4, 4-6
AR-08 The app shall allow the user to activate visual indicators when a notification or alert occurs.
If available, it is suggested to use platform’s standard LED flash alerts.
4-5
AR-09 Sound provided for notifications and alerts shall have enough audio quality and shall be free
of pith shifts.
4-7, 5-8, 5-9
AR-10 The return of an action shall be predictable according to the instructions contained on the
control used to activate the action and shall happen at the same location where the control is.
5-10, 5-12, 12-12
AR-11 The app shall not require using simultaneous gestures to activate controls. 6-6
AR-12 The controls that activate similar or same actions across the app shall be activated in a similar
way and located in a similar place
6-2
AR-13 The app shall alert the user when an error occurs and provide him or her clear guidance about
what to do to solve it.
9-1, 9-2
AR-14 The app shall provide mechanisms to protect user information and maintain its security. 10-2, 10-3
AR-15 The app navigation and the use of controls shall be designed using platform patterns and
human interfaces guidelines.
12-12, 13-6, 13-8
AR-16 To perform and action, the app shall not request for more than three steps. 13-8, 13-9, 13-11
AR-17 The text contained in the app shall be easy to understand and all the icons inside controls
must represent correctly their purpose.
13-2, 13-8, 14-1
AR-18 The app shall provide a help screen where the user can learn how to use the app. 13-10, 16-5
AR-19 The accessibility preferences implemented in the app shall be change when the user needs
them.
16-2
AR-20 The accessibility features shall not be blocked unless the user deactivates them. 16-10
AR-21 The updates of the app shall respect the accessibility features implemented on previous
versions unless are not useful for the users.
16-1
* Elderly user needs extracted from ISO IEC TR 29138-1 and ISO IEC TR 29138-3 standards
supports patient’s self testing. As in the current day
patient does not have made self testing and thus his
or her cardiologist is unable to validate the dose, the
app mark the dose as not validated. The app shows
information about
next take time. It is required to anticoagulated
patients taking only the necessary amount of dose
and always to take it at the same time of day. When
patient taps on “Insert today INR result”, apps
navigate to “Today INR result” view showed on
Figure 2. In that view, the app asks for today INR
result. When inserted, patient has the option of only
save the INR result on his/her PHR and send it later
to his or her cardiologist, or both save and send the
INR result. When result has not been sent to the
cardiologist, patient can edit the introduced result.
Alerts can indicate the successful or the failure of
patient’s action.
Back to the first view, supposing that the result,
together with the dose of the previous day, was
successfully sent to the cardiologist, when the
patient is back, he/she has to wait for cardiologist
dose validation. The user receives the cardiologist
dose validation by a push notification. It includes
the dose that the patient has to take that day and the
INR test result sent for patient confidence in the
dose recommended. When the app handles the
notification, it validates that data on the first tab.
Tapping on the top left bottom, patients can access
to edit the reminders The top right “Gear” button is
on both tabs to provide patients always access to set
his/her preferences. In the “Preferences” view
AccessibleMobileApplicationtoSupportSelfTestingforAnticoagulatedPatientsusingaPersonalHealthRecord-
AppliyingGoodPractices
355
Figure 1: Dose not validated. Figure 2: Today INR result. Figure 3: Preferences view. Figure 4: INR PHR.
(Figure 3) they are able to customize text and
background colour and font size from defaults.
Second tab Figure 4) provides patients access to
their previous personal INR test results. Data is the
one stored by the patient day by day. In this tab
patient can look up by seeking on the calendar
his/her personal INR test result and the validated
dose for a day, included the current one if the dose
has been validated. When the user taps the up left
“Share” button, the data can be sent by email default
to patient’s cardiologist. If the user allows
physicians to include his or her PHR on their MHR,
the app sends the whole database and attaches a
PDF file to allow a fast review.
7 CONCLUSIONS, LIMITATIONS
AND FUTURE WORK
Many researches have been focused on supporting
conceptual and technologically PHRs. Also new
challenges in healthcare domain have been
addressing with PHRs.
With an appropriate tracking, anticoagulated
patients are able to lead a normal live. To avoid
problems arising of a defective dose adjustment, self
testing is positioning as a feasible and powerful
solution. Mobile technologies can provide an
efficient support to self testing. Additionally, with
mobile technologies it is possible to implement
mobile PHRs that allow both patients and doctors to
look up everywhere at every time patients’ health
data.
All these facts have allowed us to highlight the
importance of involving real users. We have to
remark that the limitation of the proposal is that in
the current state of the research, we do not have
feedback from real users. Knowledge about
anticoagulated patients and their needs, related to
their illness and to accessibility, has been captured
from field research, as high impact publications and
standards.
In the future works, we are going to situate users
as key stakeholders in the development process
following User Centered Design methodology,
integrating previous approaches such as “Customer
Driven Innovation”, “Outcome Driven Innovation”,
“Voice to Consumer”, “Open Innovation” or the
approximations related with the innovation based on
social networks (prosumers).
At the mobile app evaluation phase, the
technological effectiveness of the solution will be
considered. This is the ability of a solution to be
effective, efficient and to solve the real problems of
the target population within a real environment. This
analysis will be done attending to the following
factors: emotional focus, ergonomics (including
cognitive, functional and organizational ergonomics,
universal design and familiarity), citizen innovation,
sustainability (social, economical and
environmental), security management, ethics and
neuro-usability (evaluation of real perceptions).
All these factors are considered (when
appropriate) in the different development phases
(from prototype evaluation to market), especially in
the design and evaluation stages.
Summarizing, the purpose of the research is to
underline the significance of well gathering
HEALTHINF2014-InternationalConferenceonHealthInformatics
356
requirements in order to they really reflect users’
needs. We have work on illustrating with a test case
a good practice to define requirements, taking users
into account, to get a suitable design. To validate the
design is necessary that real users test it.
ACKNOWLEDGEMENTS
This research work is supported by the Research Network
MAVIR (S2009/TIC-1542), MULTIMEDICA project
(TIN2010-20644-C03-01) and Living Labs Methods,
Techniques and Tools project (UC3M/2009/00421/001).
REFERENCES
Apple (2013). iOS Human Interface Guidelines. Retrieved
from https://developer.apple.com/library/ios/
documentation/userexperience/conceptual/mobilehig/.
Basdekis, I., Sakkalis, V., & Stephanidis, C. (2012).
Towards an Accessible Personal Health Record.
MobiHealth 2011 (Vol. 83, pp. 61–68). Berlin,
Heidelberg: Springer Berlin Heidelberg.
Bauersachs, R. M. (2012). Use of anticoagulants in elderly
patients. Thrombosis research, 129(2), 107–15.
Blumenthal, D. (2009). Stimulating the Adoption of
Health Information Technology. The New England
Journal of Medicine, (360), 1477–1479.
Daglish, D., & Archer, N. (2009). Electronic Personal
Health Record Systems: A Brief Review of Privacy,
Security, and Architectural Issues. 2009 World
Congress on Privacy, Security, Trust and the
Management of e-Business, 110–120.
Dorr, D., Bonner, L. M., Cohen, A. N., Shoai, R. S.,
Perrin, R., Chaney, E., & Young, A. S. (2007).
Informatics Systems to Promote Improved Care for
Chronic. Journal of the American Medical Informatics
Association, 14, 156–163.
Erlandson, R. F. (2010). Universal and Accessible Design
for Products, Services, and Processes (Google eBook)
(Vol. 8).
Hanson, V. L. (2009). Age and Web Access : The Next
Generation. In W4A ’09 Proceedings of the 2009
International Cross-Disciplinary Conference on Web
Accessibililty (W4A) (Vol. 44, pp. 7–15). Madrid:
ACM.
Harrison, W. B. (2010). Your Personal Health Record -
It’s Your Responsibility. IEEE-USA Today’s Engineer
Online. Retrieved from http://
www.todaysengineer.org/2010/Apr/PHRs.asp.
Heneghan, C., Ward, A., Perera, R., Bankhead, C., Fuller,
A., Stevens, R., Zittermann, A. (2012). Self-
Monitoring of Oral Anticoagulation: Systematic
Review and Meta-Analysis of Individual Patient Data.
Lancet, 379(9813), 322–34.
Kozlovszky, M., Sicz-mesziár, J., Ferenczi, J., & Márton,
J. (2011). Combined Health Monitoring and
Emergency Management through Android Based
Mobile Device. MobiHealth 2011 (pp. 268–274). Kos
Island, Greece: Springer Berlin Heidelberg.
Li, M., Yu, S., Zheng, Y., & Member, S. (2013). Scalable
and Secure Sharing of Personal Health Records in
Cloud Computing Using Attribute-Based Encryption.
IEEE Transactions on Parallel and Distributed
Systems, 24(1), 131–143.
Moore, J. (2012). The benefits of mobile apps for patients
and providers. British Journal of Healthcare
Management, 18(9), 465–468.
Ogawa, K., Matsumoto, K., Hashimoto, M., Hamai, T.,
Shibuya, A., & Kondo, Y. (2012). Mobile Timeline -
Mobile Charting System that Provides a Graphical
Summary of a Patient’s Medical Record. In
HEALTHINF 2012 (pp. 23–29). Vilamoura, Algarve,
Portugal.
Puustjärvi, J., & Puustjärvi, L. (2012). Moving from
Remote Patient Monitors to Cloud-Based Personal
Health Information Systems. In HEALTHINF 2012
(pp. 37–45).
Rello, L., Kanvinde, G., & Baeza-Yates, R. (2012). A
Mobile Application for Displaying More Accessible
eBooks for People with Dyslexia. Procedia Computer
Science, 14, 226–233.
Samaras, G. M., & Horst, R. L. (2005). A systems
engineering perspective on the human-centered design
of health information systems. Journal of Biomedical
Informatics, 38(1), 61–74.
Sayago, S., Sloan, D., & Blat, J. (2011). Everyday use of
computer-mediated communication tools and its
evolution over time: An ethnographical study with
older people. Interacting with Computers, 23(5), 543–
554.
Tang, P. C., Ash, J. S., Bates, D. W., Overhage, J. M., &
Sands, D. Z. (2006). Personal Health Records:
Definitions, Benefits, and Strategies for Overcoming
Barriers to Adoption. Journal of the American
Medical Informatics Association, 13(2), 121–127. s.
Van Walraven, C., Austin, P. C., Oake, N., Wells, P.,
Mamdani, M., & Forster, A. J. (2007). The effect of
hospitalization on oral anticoagulation control: a
population-based study. Thrombosis research, 119(6),
705–14.
Viale, P. H. (2005). Abnormal clotting in cancer: an
overview of pathophysiology and etiology. Seminars
in oncology nursing, 21(4 Suppl 1), 12–20.
Widya, I., Bults, R. G. A., van Beijnum, B. J. F., Sandsjö,
L., Schaake, L., Huis in’t Veld, M. H. A., … Hermens,
H. J. (2009). Requirements Elicitation in a
Telemedicine Pain-treatment Trial. In 17th IEEE
International Requirements Engineering Conference.
Atlanta: IEE.
AccessibleMobileApplicationtoSupportSelfTestingforAnticoagulatedPatientsusingaPersonalHealthRecord-
AppliyingGoodPractices
357
