Creating Patient Decision Aid Tools

Andrea Corradini, Constantin Alexandru Gheoghiasa and Jesper Nordentoft

KEA Digital, Copenhagen School of Design and Technology, Lygten 37, 2400 Copenhagen NV, Denmark

Keywords: Patient Decision Aid Tools, Shared Decision Making, e-Health, Web Application.

Abstract: This paper reports on the creation of a web application that facilitates the development and implementation

of patient decision aid tools. We propose a software prototype model that allows medical personnel to easily

and rapidly create digital prototypes of patient decision aid tools independently on the medical condition. Our

application can be used as an online framework and is being tested by healthcare professionals.

1 INTRODUCTION

Several medical researchers and practitioners have

been advocating for enabling patients to have a more

active role in making decisions regarding the

treatments to choose to deal with their medical

condition. In order to achieve this, a shared decision

making process needs to be pursued and implemented

(Eason et al, 2012). Cross disciplinary studies have

shown several benefits for patients who are involved

in the decision process during their medical journey

(Lee & Emanuel, 2013). Those patients, once

empowered by providing them with a good

understanding of their condition, the diagnosis, the

possible set of treatments, and the pros and cons of

each of these treatments, can then make more

informed decisions about their treatment choice also

by factoring in personal wishes and life situation. One

of the main challenges in implementing this approach

is the appropriate creation of tools that can help

educating the patient, the healthcare professionals and

the other stakeholders involved in the patient’s

journey.

Patient decision aid tools (Ottawa Framework,

2019) have emerged as clinical frameworks or

guidelines in situations where there are alternative

courses of treatment. They are meant to educate the

patient and help him make a decision. Usually, these

tools are developed by researchers or healthcare

professionals in the form of small leaflets or paper

cards. In recent years, multimedia tools have been

emerging and a new development towards web-based

patient decision aid tools has also caught up

(Syrowatka et al., 2016). Developing patient aid tools

is not an easy process. It requires following a

standardized process that should include a carefully

planned development, available research-based

information, user testing, proper design, field testing

and evaluation (Coulter et al., 2013).

We created a prototype model of a web

application that makes it possible to create generic

decision aid tools. With the term generic, we refer to

a tool that is not tailored to a specific medical

condition but can instead be easily adapted to

accommodate to different conditions with only little

effort.

Our web application is intended to be a ready-to-

use software. It can be used as a sort of online content

management system for the generation of patient

decision aid tools that can be quickly prototyped and

generalized over medical conditions.

2 PATIENT DECISION AIDS

TOOLS

2.1 Related Work

The adoption of software programs by healthcare

professionals has seen an ascending trend in the last

decade. The joint work of software developers and

healthcare professionals has made it possible to create

tools that can help mediate the relation with the

patient, minimize the errors in the care process, help

doctors adhere to medical guidelines, streamline the

process and last but not least, help the patients to have

a better understanding of their illness, the treatment

options and their role in making a decision (Wright et

al., 2009).

Corradini, A., Gheoghiasa, C. and Nordentoft, J.

Creating Patient Decision Aid Tools.

DOI: 10.5220/0008951104070412

In Proceedings of the 13th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2020) - Volume 5: HEALTHINF, pages 407-412

ISBN: 978-989-758-398-8; ISSN: 2184-4305

407

Over the course of the last decade, medical

practitioners have documented better outcomes in

patients who have been actively involved in the

decision making (healio, 2016). The need to involve

patients in the medical decision process has been also

corroborated by scientific studies coming from the

area of medical sciences and socio-psychology (Lee

& Emanuel, 2013). The International Patient

Decision Aid Standards Collaboration has developed

quality criteria for the development of patients'

decision aid tools (Elwyn et al., 2016). The actual

development of such tools is then usually mainly

focused on specific illnesses, such as prostate cancer,

lung cancer, diabetes etc (AHRQ, 2019).

Like with most other areas, we have seen recently

a switch from the paper-based decision aid tools to

computer based ones. The benefits of digital decision

aid tools as compared to the paper based ones have

started to be investigated by both healthcare

professionals and researchers. The importance for

developing a computer-based decision aid tool was

supported by a review conducted by Syrowatka et al

(Syrowatka et al., 2016). The objective of this review

was to identify if computer-based decision aid tools

performed better than commonly used paper-based

decision aid tools. Furthermore, the same study made

a classification of the features that were integrated in

existing computerized decision aid tools. The purpose

of this classification was to identify whether specific

features performed better than others and to figure out

the degree of redundancy of incorporating certain

features in an effort to maximize the quality of the

decision making process. As with many other areas of

our lives, the online environment has the capability of

providing the user with a more interactive experience,

allows for a mix of multimedia components, which in

turns enables the user to have a better understanding

of the subject or theme that is being presented.

Furthermore, a digital decision aid tool can allow the

user to interact with it, thus making the information

presented and experience to be tailored to the specific

characteristics, needs and wants of the user.

As it has also been outlined in other research

studies (Hoffman et al., 2016), online platforms allow

for media rich components to be integrated, making it

possible for patients to benefit from a more

interactive experience that ultimately facilitates the

understanding of the information transmitted and

goes beyond the limitations of the paper-based

approaches. The media rich content can be presented

in terms of instructional videos, inserted in the

material send to the patient over the internet, or in

terms of dynamic graphs and images that can help the

patient better understand his individual case reported

to the average condition or how certain probabilities

related to the treatment would apply in his specific

case. Animations, icons and graphs can be used to

help bring the data from abstract to concrete. In

(Flynn et al., 2015), a computerized decision aid for

thrombolysis in acute stroke was developed. An

assessment on when it is the best time to

communicate to the patient certain medical related

information to ensure a proper reception and

understanding is also discussed.

One of the most prominent frameworks in the area

of decision aid tools development is Ottawa Decision

Support Framework (Ottawa Frameworks, 2019;

Ottawa Decision Aid, 2019). This framework is based

on identifying and resolving the decisional conflict

and is supported by extensive research from

psychology and sociology (Matlock and Spatz, 2014).

It consists of three major components: decisional

needs, decision quality, and decision support. The

potential impediments for adopting patient decision

aids on a large scale by clinicians is also discussed.

The main impediments identified were: poor

development, reluctance on the part of clinicians to

use them, prohibitive workflow, maligned incentives,

or inaccessibility at the time they are needed.

The web application we created facilitates the

development of patient decision aids tools and

incorporates several of the guidelines formulated in

the Ottawa Decision Support Framework. Our

applications is not a decision aid tool per se because

it does not target any specific illness. Our software

application focuses on the creation of web-based

decision aid tools for virtually any medical condition.

It provides a framework for the creation of a layout

where physicians and medical personnel can easily

enter research-based medical information and data to

educate patients and make it possible for them to

make choices when alternative treatments are

possible. With our application it is easy to quickly

prototype and standardize the creation of decision aid

tools. The data entered can be text, video clips, audio

clips, hypertext, and images.

2.2 Minimal Technical Requirements

While designing our application, and after an

empirical analysis of informal discussions with

medical personnel, we decided that it had to display a

set of minimum features. These are:

• web-based: the system must be accessible in a

web browser in order to avoid any additional

software installation

HEALTHINF 2020 - 13th International Conference on Health Informatics

408

• responsive: the user of the system will be able to

access the application from different screen-size

devices

• sharing and collaboration: this feature allows the

medical personnel to collaborate when creating

and defining the content of a given decision aid

tool for a specific condition

• published API for data communications: this

allows for a seamless integration of the

application with other systems used by the

medical organization

• print or export to PDF format: this caters for

patients that prefer a paper version of the tool;

digital features that are not available in paper

format (e.g. video clips) are to be replaced with

other supporting information and material (e.g. an

image of a QR code to scan with a cell phone and

play the video that could not be inserted in the

PDF).

2.3 User Roles

The system is designed with multiple user roles, each

role providing different levels of access and rights.

Specifically, we have the following roles and levels

of access:

• admin: it is the top-level user with access to the

entire technical related functions and user

administration functions; the typical person with

admin role is a developer or one person from the

medical institution

• designer: it is a specialist in creating patient

decision aid tool layouts; s/he designs and creates

new decision aid tools and usually has gone

through some training with the content

management system

• editor: it is person who provides the designer with

the research-based information when a certain

decision aid tool for a certain condition is being

created; s/he is a subject-matter expert but does

not need the technical expertise to create template

layouts

• user: it is the end user of the system, typically the

patient or a patient's relative, with no access to the

system back-end; s/he is only able to view, read,

provide personal input data entered via UI widgets

and print a decision aid tool after this was shared

with her/him in digital form by the medical

personnel.

Usually, the designer and editor are expected to

work in close collaboration when a new decision aid

tool is created. The designer turns the information

provided by the editor in graphical form and style

them according to a few predefined layouts.

3 PROTOTYPING GENERIC

PATIENT DECISION AID

TOOL

3.1 Overall System Architecture

In this section, we present an overview of our system

architecture. We split the architecture into 3 main

components. Being a web application, we naturally

mapped our system onto a three-tier architecture

made up of a front-end, a middle tier, and a backend.

The front-end was created using standard web

technologies such as HTML 5, CSS 3, and a mix of

JavaScript and a set of JavaScript libraries. Figure 1

shows the different tasks allowed (indicated with file

names), the different user roles, and relations between

tasks and user roles.

Figure 1: Overall system architecture: front-end.

The system middle-tier is shown in Figure 2. We

created a model-view-controller architecture based on

PHP and hosted on a free cloud service. We

developed our own model-view-controller

Creating Patient Decision Aid Tools

409

architecture instead of using an existing framework.

Frameworks can prove very efficient in terms of

development time and security. Frameworks that are

used on a large scale have high security

implementations and the pre-built functions can

speed the process of development from hours to

minutes. However, frameworks have also limitations

(Manger et al., 2015). One of the major limitations is

that the developer is constrained to work within its

specifications and limits. In our context, we wanted

to be sure to be browser independent and to not

decrease our application performance due to large

overhead of additional framework code. Moreover, it

can prove difficult to introduce multiple frameworks

in the same project and due to the library limitations,

for the development of our application multiple

frameworks would have been required.

Frontend and middle-tier communicate with each

other through an RESTful API that, while

emphasizing the separation of concerns principle

among component, also acts as the system gateway to

data. With the API it is also possible to integrate our

architecture into other systems that the medical

institution might use.

Figure 2: Overall Architecture: Middle-Tier and Back-End.

Eventually, a MySQL database is used to persist

the data related to the information and meta-data

stored in each patient decision aid tool.

3.2 Creating a Decision Tool

In the section, we report on the process and steps

necessary to the creation of a patient decision aid tool.

The designer is the person in charge of going

though this process. Whenever a new decision aid

needs to be generated, basic information about it is

required for laying out a first simple structure of the

digital document (see Figure 3). This includes for

instance the title to assign to the decision aid tool, a

set of semantic tags, an image, and a variable number

of sections. The title is used on the cover page as well

as to identify the decision aid. The semantic tags are

keywords used to describe the decision aid tool being

build. These tags are used for search and

classification purposes when more aid tools are

available on the system backend. An image is

provided to ensure the visual identity of a decision aid

tool. While collecting system requirements, we were

made clear by the management of the hospital we

started this project on, that it was important to have a

uniquely identifiable message or text on whatever

decision aids implemented both on paper aids and

digital aids. At this stage, the image is typically the

logo of the institution. This is be placed as a footer on

each section/page of the decision aid tool being

created. An additional image can be uploaded to act

as background image throughout the pages of the

final product. Sections are the core components of a

decision aid tool, notably where the subject-matter

information is actually structured. This information

must be provided by subject-matter expert.

Figure 3: Initial steps in creating a new decision aid tool.

Each section has three main components: a title, a

color and the content of the section. At the moment,

we have a set of predefined sections including:

introduction, condition description, treatments, pros

and cons, user preferences, decision, conclusion, and

glossary. More sections can be created, and sections

can be deleted as well.

In the introduction section, text can be added to

introduce who is this tool targeted to or any other

information the expert believes should be conveyed

HEALTHINF 2020 - 13th International Conference on Health Informatics

410

at the very begin of the decision aid tool. The

condition description section provides an overview of

the medical condition. The section ‘treatment’

describes the available treatments along with the pros

and cons for each of them. The section ‘user

preferences’ is essentially supposed to be a short

questionnaire that the patient is asked to filled in.

The questionnaire can contain multi-choice

questions as well as open questions. Right after that

section, a typically one-page section follows where

the patient summarizes his/her decision, based on the

information process until that point. A possible

decision is not to decide any treatment at that point

but rather defer the choice, that is, delay the decision

to a later point in time or avoid the decision

altogether. A conclusion section is used to inform the

patient of the expected next steps. Eventually a

glossary section is used to list and describe all the

technical terms used in the decision aid tool. Sections

are color-coded i,e, are associated with different

colors to allow for a better navigation of the tool by

the intended final user.

One of the most powerful functionalities of the

system is the way through which the content of a

section is created or edited. Once the designer presses

on the content of a section, an HTM editor is enabled.

The editor makes it possible for the user to enter and

edit the content of the section in any way s/he wants.

Figure 4 shows a screenshot of the editor in action,

more precisely in a case where the designer was

attempting at inserting an image into a section. Once

the designer finishes editing the content of a section,

s/he can save it and preview it.

Figure 4: Inserting an image in a section with text.

Figure 5 and Figure 6 show how a new decision

aid tool may look like in print mode (i.e. after

selecting the option to print the digital patient

decision aid tool) and the digital version after some

content has been added, respectively.

Figure 5: Patient decision aid tool as it looks in preview

mode after some data has been entered.

Another functionality of the tool is the

collaboration and sharing mechanism for the tools.

Here is the place where a designer can request access

to a tool if s/he does not have access to this tool yet.

Another functionality under development is the

automatic addition of terms into the glossary. The

rationale here is that, once the designer enter text into

a section, s/he can highlight a (sequence of) term(s)

and provide a description for it. By doing so, the term

will automatically be added in the glossary section

along with the description of its meaning.

Figure 6: The first three pages of a patient decision aid tool

formatted in print mode (preview).

4 CONCLUSION AND OUTLOOK

We developed a web-based application that helps

create generic patient decision aid tools. Our system

was developed based on requirements collected with

healthcare professional working at a Danish hospital.

At the moment, the system exists in its prototype

for it still requires further work and development even

after it has been released to the users for testing.

Primary usability testing with a few beta testers

resulted in positive feedback. The usability of the

Creating Patient Decision Aid Tools

411

system needs be thoroughly tested in the field, as the

purpose of this software is to become a tool that

professionals are willing to use and comfortable with.

The system usability also has to target a set of quality

criteria (Syrowatka et al., 2016; Elwyn et al., 2006)

Specifically, user testing needs to figure out if the tool

we have developed

• provides information in sufficient detail,

• presents data in an unbiased manner,

• includes methods to clarify values and

preferences,

• provides structured guidance for deliberation and

communication,

• presents information in a balanced manner,

• presents up-to-date research-based medical

evidence,

• discloses conflicts of interest,

• uses an appropriate plain language, and

• ensures that the decision is informed and value-

based

The API that we implemented allows for future

integrations of the software into the systems that the

healthcare professionals are already using on a daily

basis. The integration can be done based on both a

push or pull model.

As the next development step, we plan to integrate

the system with Merriam-Webster’s Medical

Dictionary (Merriam-Webster, 2019) and Google

Custom Search (Google, 2019). This integration will

allow the users to be able to access additional

resources in creating decision aid tools and the

patients will be able to find definitions of any terms

in a tool, if in doubt about the meaning.

REFERENCES

Eason, G., Elwyn, G., Frosch, D., Thomson, R., Joseph-

Williams, N., Lloyd, A., … Barry, M., 2012. "Shared

Decision Making: A Model for Clinical Practice",

Journal General Internal Medicine, 27(10):1361–1367.

Lee, E. O., & Emanuel, E. J., 2013. "Shared Decision

Making to Improve Care and Reduce Costs". New

England Journal of Medicine, 368(1):6–8.

Ottawa Hospital Research Institute, 2019. "Ottawa

Decision Support Framework", [Online] https://

decisionaid.ohri.ca/odsf.html (accessed on October

2019).

Syrowatka, A., Krömker, D., Meguerditchian, A. N., &

Tamblyn, R., 2016. "Features of Computer-Based

Decision Aids: Systematic Review, Thematic

Synthesis, and Meta-Analyses". Journal of Medical

Internet Research, 18(1):20.

Coulter, A., Stilwell, D., Kryworuchko, J., Mullen, P. D.,

Ng, C. J., & van der Weijden, T., 2013. "A systematic

development process for patient decision aids". BMC

Medical Informatics and Decision Making, 13(2):2.

Wright, A., Bates, D. W., Middleton, B., Hongsermeier, T.,

Kashyap, V., Thomas, S. M., & Sittig, D. F., 2009.

"Creating and sharing clinical decision support content

with Web 2.0: Issues and examples". Journal of

Biomedical Informatics, 42(2):334–346.

healio.com, "Shared decision making can lead to better,

individualized care,” Jan. 2016. [Online]. http://www

.healio.com/optometry/primary-care-optometry/news/

print/primary-care-optometry-news/%7B45e3e538-3b

8a-4847-b98f-ae5158a7950c %7D/shared-decision-ma

king-can-lead-to-better-individualized-care (accessed

on October 2019).

Elwyn, G., O’Connor, A., Stacey, D., Volk, R., Edwards,

A., Coulter, A., … Whelan, T., 2006. "Developing a

quality criteria framework for patient decision aids:

online international Delphi consensus process". BMJ,

333(7565):417.

AHRQ–Agency for Healthcare Research and Quality,

"Patient Decision Aids - Effective Health Care

Program". 2019. [Online] http://effectivehealthcare.

ahrq.gov/index.cfm/tools-and-resources/patient-

decision-aids/ (accessed on October 2019).

Hoffman, A. S. , Volk, R. J., Saarimaki, A., Stirling, C., Li,

L. C., Härter, M., Kamath, G. R., & Llewellyn-Thomas,

H., 2013. "Delivering patient decision aids on the

Internet: definitions, theories, current evidence, and

emerging research areas,” BMC Medical Informatics

and Decision Making, 13(2):13.

Flynn, D., Nesbitt, D. J., Ford, G. A., McMeekin, P.,

Rodgers, H., Price, C., Kray, C., & Thomson, R. G.,

2015. "Development of a computerised decision aid for

thrombolysis in acute stroke care". BMC Medical

Informatics and Decision Making, vol. 15, pp. 6.

Ottawa Hospital Research Institute, "Conceptual

Frameworks". [Online] https://decisionaid.ohri.ca/

models.html (accessed on October 2019).

Ottawa Hospital Research Institute, "Decision Aid Toolkit

- Patient Decision Aids". [Online]. https://decisionaid.

ohri.ca/resources.html (accessed on October 2018).

Matlock, D. D., & Spatz, E. S., 2014. "Design and Testing

of Tools for Shared Decision Making". 2014.

Circulation: Cardiovascular Quality and Outcomes,

7(3):487–492.

Manger, C., Trejderowski, T., & Paduch, J., 2010.

"Advantages and disadvantages of framework

programming with reference to Yii php framework,

gideon .net framework and other modern frameworks".

Studia Informatica, 31(4A):119–137.

dictionaryapi.com, "Merriam-Webster’s Medical

Dictionary with Audio" [Online]. https://www.

dictionaryapi.com/products/api-medical-dictionary.

htm (accessed on October 2019).

developers.google.com, "Google Custom Search". [Online]

https://developers.google.com/custom-search/

(accessed on October 2019).

HEALTHINF 2020 - 13th International Conference on Health Informatics

412