Trying to Fill the Gap between Persons and Health Records
The MedIcona InterPersonal Health Record
Federico Cabitza and Iade Gesso
Dipartimento di Informatica (DISCo), Universit
`
a degli Studi di Milano-Bicocca, Viale Sarca 336, 20126 Milano, Italy
Keywords:
Electronic Health Record, Personal Health Record, General Practice.
Abstract:
In this paper, we discuss the concept of InterPersonal Heath Record and its role in the most recent models
of health service delivery: such a health record should integrate health-related information with communi-
cation and collaboration capabilities that could allow both patients and caregivers co-produce information
and knowledge toward prevention and illness treatment and management. We then present MedIcona, a full-
fledged demonstrator of the IPHR notion developed as free, open-source installation profile of Drupal 7. Its
functionalities are aimed at enabling higher levels of user tailoring, content sharing and annotation among
patients and their caregivers.
1 MOTIVATIONS AND
BACKGROUND
Of all the eHealth applications that in the last 25
years have collected greater hope (and sometimes
even hype), the one that has so far fallen shorter of
its promises (Pagliari et al., 2007; Westin et al., 2008)
is probably the Personal Health Record (Majeed et al.,
2009; Singleton et al., 2009; Greenhalgh et al., 2008;
Karsh et al., 2010), that is the “Web-based appli-
cations through which individuals can access, man-
age and share their health information” (Tang et al.,
2006). This is probably due to many socio-technical
factors that would be out to scope to review here ex-
tensively (see, e.g., (Heeks et al., 1999; Tang et al.,
2006; Greenhalgh et al., 2010)).
Yet, if the success of a technology is to be evalu-
ated also in terms of the adoption rate it has reached
where it received sufficient budget and country-wide
endorsement, the failure of the PHR is blatant so far.
A recent online survey performed by the IDC Health
Insights in the US in 2011 found that only the 7% of
respondents have ever used a PHR; and slightly less
than half of these respondents, i.e., the overall 3%,
were currently using one to manage their health (Dun-
brack, 2011). Another study of 2008 reported that
70% of respondents were not aware of an important
nation wide PHR initiative in UK (Greenhalgh et al.,
2008). In Germany and Austria, a user study found
similar levels of general low familiarity with the re-
lated concept of EHR, as the 68,3% ignored its exis-
tence and meaning (Hoerbst et al., 2010). A similar
study conducted in 2013 in Italy (Cabitza et al., 2014)
reported that only 4 out of 10 respondents claimed to
know what a PHR is, despite the fact they were from
a great metropolitan area where a Region-wide PHR
had existed since the mid-2000s; moreover, whilst
for the same Region the National Bureau of Statis-
tics reports that 70 out of 100 used the Internet reg-
ularly
1
, the aforementioned study showed that only 2
out of 100 used to manage their health documents on
line. The same official report shows that while health-
related activities are the least performed by Internet
users, 81% communicate by exchanging emails, and
51% engage in social interactions with friends and
acquaintances in some social media (e.g., Facebook,
Twitter, Forums). This grim picture has been re-
cently enriched by the notorious closures or de-facto
dismissals of the UK National HealthSpace (Green-
halgh et al., 2010) and Google Health worldwide. No-
tably, when the creator of the latter system, Adam
Bosworth, was questioned on the reasons why Google
Health failed, he simply replied: “it’s not social!”
2
.
On the other hand, it has been also recently reported
that 1 out of 7 GPs already uses Social Media to inter-
act with their patients and that 1 out of 3 practitioners
would like to use emails to that same aim more often
in the next future (Cabitza, 2012).
These reports seem all to convene on the same
conclusion that “there is a gap between today’s PHRs
1
http://www.istat.it/it/archivio/78166
2
http://goo.gl/D8ifl
222
Cabitza F. and Gesso I..
Trying to Fill the Gap between Persons and Health Records - The MedIcona InterPersonal Health Record.
DOI: 10.5220/0004747402220229
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2014), pages 222-229
ISBN: 978-989-758-010-9
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
and what patients [...] need from this electronic tool
for managing their health” (Kahn et al., 2009). That
notwithstanding, still a lot of research has to be done
to frame and fill this gap, starting from the recogni-
tion that the record ought to be considered a compo-
nent of a complex socio-technical network, that is a
communication hub, rather than a mere container of
data (Greenhalgh et al., 2010).
Our contribution in this direction is the concept of
InterPersonal Health Record (IPHR), and the MedI-
cona system, which is the first instance of this class
of applications and its proof-of-concept that can be
freely used (and evaluated) by the interested stake-
holders. We define an InterPersonal Health Record
as a Web-based application where a citizen can store,
manage, search, retrieve and visualize personal health
data and documents (like her reports, results and cer-
tificates) that is specifically endowed with function-
alities aimed at enabling a richer collaboration and
communication between her and her (possibly many)
caregivers; this is accomplished by allowing users
to situate health data in a rich context of interper-
sonal interactions and, most notably by supporting co-
production. In MedIcona we reach the first aim by
allowing data and at least some of the related social
interactions to coexist in the same tasks (e.g., reading
some exam results and asking a doctor for clarifica-
tions), and some of the representations of these inter-
actions (e.g., their written record) to be tightly linked
to the record’s data (Day and Gu, 2012). On the other
hand, we allow co-production of meaning (Boyle and
Harris, 2009) by enabling a tighter communication
between the patient and her networks of caregivers
and acquaintances so that they can meet in a so called
“common information space” (Bannon and Bødker,
1997), that is a place where people collaborate around
a central archive of information whose meaning is not
simply “given” from one party, or “preexisting” the
meeting itself, but it is rather co-constructed in virtue
of a shared agreement as to the interpretation and to
the pragmatic consequences that are discussed in such
space.
In this paper we present a research activity that
was aimed at realizing such a concept with open-
source and off-the-shelf software as a way to address
the research question whether such a communication
hub, with its capabilities and the related challenges, is
technically feasible and concretely usable.
2 MAKING THE IPHR REAL
In (Cabitza et al., 2013), we made the point that an
InterPersonal Health Record must be built on top of
the standard capabilities of an electronic record, like
secure access, orderly storing, fast retrieval, and then
add to these latter ones functionalities aimed at sup-
porting collaboration and communication in a seam-
less manner, so as to transform the record also into a
meeting point, as argued above.
As proof of this concept, we designed and devel-
oped the MedIcona system, which is to our knowl-
edge the first example of Web application that inte-
grates content and communication to make a record
of the former become a means for interpersonal re-
lation and interaction, in short an IPHR. To this aim,
we intended communication in a fourfold form, that is
in terms of: i) content sharing, in either a 1-to-1 or 1-
to-many fashion, also through the notion of “homoge-
nous group of users” (i.e., a circle); ii) content annota-
tion, in terms of either nested threads of side notes, or
semantic tags; iii) discussions, which are either topic-
related, like in regular Forums, or content-related, i.e.,
by making each record’s resource become the “topic”
of a discussion thread; and iv) conversations, that un-
fold in either an asynchronous or synchronous mode,
i.e., like mails and instant messages, respectively.
More precisely, the current implementation of the
MedIcona IPHR allows its users to:
1. define customized data templates and instantiate
them as forms and charts of the record where to
fill in data pertaining their health;
2. upload and tag any external document, to make it
a resource of the record and allow for fast index-
ing and customized retrieval;
3. search and retrieve the record’s resources on the
basis of keyword- and string-based queries, and
get access to contents through two visual time-
lines that reference all the occurrences of dates
that the system finds in the whole record’s con-
tent;
4. invite anyone with a valid email address to the
record as guest, and share with such a guest any
individual resource of the record, at various levels
of granularity, and for either a limited amount of
time or until invite revocation;
5. start a message exchange with guests about any
topic in a Forum-like manner, or about any
record’s resource, in terms of threads attached to
the resource itself;
6. collect all messages exchanged with specific users
or user categories in one single resource of the
record, and send new messages from within the
system;
7. undertake instant messaging with guests and care-
givers that are logged in the MedIcona system;
TryingtoFilltheGapbetweenPersonsandHealthRecords-TheMedIconaInterPersonalHealthRecord
223
8. get access to the most recent information pub-
lished on the Web regarding the content of spe-
cific resources; for patients the system collects re-
sources from certified news sites or patient asso-
ciations portals; for doctors it lists the most re-
cent papers that have been retrieved from medical
databases (like PubMed) on the basis of keywords
extracted from the content of the records
3
;
9. visualize bar charts or time series on the basis of
the data contained in the record (e.g., drug intakes,
weight trends).
10. annotate any textual passage, as well as picture,
image and diagram contained in the record, and
start thread-like discussions on any content and
annotations as well.
Before going into the details of this specific IPHR
implementation, we need to share a convenient way
to represent what an IPHR really is, so that the func-
tionalities mentioned above can look more as a co-
herent set of factors that enact the twofold (con-
tent/communication) nature of the application, than a
heterogeneous list of state-of-the-art features.
3 REPRESENTING THE IPHR
Although the definition of IPHR follows from that
of PHR in a quite straigtforward way, since the for-
mer can be seen as a sort of socially augmented PHR,
taking seriously the interpersonal element requires to
change the way in which such an application could be
offered to their potential users so that they can actu-
ally meet with others in the record, and make it a com-
munication hub also. Very simply put then, MedIcona
is an electronic record containing resources that can
be shared; to represent shared resources these can be
represented as nodes of graphs where ownership and
visibility are represented as arcs between resources
and user nodes (i.e., empty and filled circles in Fig-
ure 1, respectively). This metaphor can help us pre-
senting the business models that we invision as con-
sistent with the idea of IPHR. In this paper we outline
three scenarios of adoption:
Scenario 1: First the Doctor, then her Patients
In this scenario MedIcona is given to single
practitioners and selected specialists, e.g., for the
initiative of either a Regional Health Authority
or a pharmaceutical company. These could be
partly driven by promotional motives, but also
by the potential lying in the anonymous mining
3
This service is provided by the Diogene system that
NewGo developed also according to our domain analysis.
http://www.new-go.it/?q=node/35
and profiling of the practitioners’ patients. The
specialist adopts MedIcona as her Electronic
Medical Record, i.e., an application by which to
manage the medical records of all her patients; to
this aim, she partly uses the predefined content
types, and partly extends them by building the
charts, templates and forms that she needs in her
profession (more on this ability in Section 4.1).
Moreover, the specialist offers MedIcona to
each of her patients to share documents (orders,
prescriptions, certificates) that she produced and
also as a direct communication line with her
office. The doctor’s EMR and the patient PHR
hold resources in common, but they also have
private spaces containing resources that are not
shared. In other words, MedIcona creates a
personal health record for each invited patient
(unless this has got already one), who can use it
as her own Personal Health Record.
Scenario 2: First the Patient, then her Guests
In this scenario MedIcona is autonomously
adopted by a single citizen/patient (the P red
circle at the bottom of Figure 1), who makes it
a highly tailored and flexible Personal Health
Record where to store her medical documents
and other health-related resources (empty circles
in Figure 1). Instead of using emails, the patient
can use MedIcona also to share selected portions
of her record (typically documents, reports and
results) with some of her caregivers (e.g., the D
green circle on the left in Figure 1), whom she
invites through MedIcona itself. These caregivers
can get access to the patient’s record as guests
by logging in MedIcona and, if they like, they
can also use MedIcona to communicate with the
patient, as well as to store private patient-related
data in the same system. Yet, some of these
caregivers could use MedIcona as their EMR: in
this case, MedIcona asks them whether to create
a medical record at her facility for that patient or
not.
Scenario 3: Facilities First, then their Clients
In this scenario MedIcona is adopted by a
multi-specialty center or hospital (the H layer
in Figure 1): on one hand, the center offers
MedIcona to each of its customers, as their free
and confidential Personal Health Record (unless
they have already got one); this facility record
also encompasses several ”private” spaces acting
as multi-user mono-department Electronic Patient
Record, which are used by all the caregivers
(doctors and nurses, D and N blue circles in
Figure 1) of a department of the facility where
the patient has once been admitted. On the other
HEALTHINF2014-InternationalConferenceonHealthInformatics
224
Figure 1: All the 3 IPHR scenarios as a graph.
hand, each doctor of the facility can become
a user of a specific MedIcona record, because
invited by either the patient or by other doctors of
the departments where the patient was admitted;
invited doctors (G yellow circles in Figure 1) can
get into MedIcona, work with shared resources
as well as maintain a private space, which ”lives”
beside the department private space and the
patient private space within the patient record.
Scenario 1 and 2 are symmetrical, while Sce-
nario 3 is more complex only apparently and ex-
ploits the modular nature of an IPHR, which essen-
tially emerges from the intersection of multiple pri-
vate spaces (dotted closed lines in Figure 1) in a num-
ber of 1-to-1 common information spaces (the inter-
sections of these areas in Figure 1). As said above,
each resource is owned by only one user (continuous
segments in Figure 1), i.e., the owner, who can make
it visible also to other users (dotted segments in Fig-
ure 1), possibly to many (more details on the MedI-
cona user profiles are provided in Section 4.3).
The current version of MedIcona already supports
scenarios no. 1 and 2, but small interventions would
make it ready also for the third scenario of adoption.
In short, all these scenarios can coexist and reinforce
each other, so as to increase the odds to spread the use
of such a record among practitioners and patients.
4 CONSTRUCTING THE
MedIcona IPHR
In this section we provide some details on the demon-
strator we built as proof of the IPHR concept, that
we called MedIcona. This application is built on top
of Drupal (v. 7), a free and open-source content man-
agement system that has been chosen for its diffusion,
maturity, modularity and extendability.
Technically speaking, MedIcona is currently a
Drupal distribution, i.e., a specific version of the Dru-
pal core packaged with a set of contributed modules,
libraries and themes, which are pre-configured in a
specific set of default settings. Therefore, the cur-
rent implementation of the MedIcona system is an in-
teresting case of deep tailorization of a widespread
Off-The-Shelf Software to integrate articulated con-
tent management policies with social media function-
alities. To report on this tailorization task, in what fol-
lows we will outline the main implementation choices
that characterize the current version.
4.1 Implementing the Record
Before looking under the MedIcona hood, we provide
a succinct summary of how users see the “record”,
that is of the GUI of this IPHR. As said above, MedI-
cona adopts the record metaphor quite literally. This
means that contents are provided in a folder-like page,
that is divided in binders and sheets; each binder (or
group of sheets) is accessible through a tab and con-
tains either one sheet/resource, or an index, that is a
list of resources; the index can be either itemized in
a specific sheet or presented as a second-level list of
tabs, i.e., a binder. Each resource is displayed in a
single sheet of the record. Currently MedIcona con-
ceives the record as a composite artifact composed of
these groups of sheets: Forms, External Documents,
Images, Conversations, Discussions, Web resources,
and the Timelines. The flexibility of Drupal allows
to organize the content also differently, e.g., under
different tabs, by simply defining new Views. These
allow the system administrator to define sort of cus-
tom high level queries, which can filter contents to be
shown to the users, as well as aggregate and present
contents in different formats and graphical arrange-
ments dynamically.
The flexibility of MedIcona is also evident in the
creation of new content types, i.e., the data structures
where users can fill in new data at need, like forms,
pages and charts, which are usually displayed under
the Forms tab.
4.2 Implementing the Sharing
Resource sharing is the core function by which in-
terpersonal interaction takes place. This is because in
designing MedIcona we tried to avoid the idea that the
record was the aggregation of static documents and
data, and the communication-oriented functionalities
were beside this composite set, as sort of juxtaposed
add-ons. All the contrary, we conceive any piece of
information as a potential trigger for comments and
TryingtoFilltheGapbetweenPersonsandHealthRecords-TheMedIconaInterPersonalHealthRecord
225
Figure 2: The form to set sharing options for a resource
(from the patient’s perspective).
discussions: this implies that any record’s item must
be shared and annotated; on the other hand, we also
conceive any piece of conversation or comments as
highly informative per se: this requires that any of
these items must be searchable and annotable as any
other more structured content of the record.
This approach is reflected by the fact that each re-
source is presented in a page where users find the con-
trol to share it to one or more existing users/guests,
as well as to anyone with a working email address
(see this block in Figure 2). Thus, users can share a
content (e.g., a form or a document), the associated
comments and annotations, an intervention related to
a topic (listed under the Discussions tab) and also a
message sent to other users (listed under the Conver-
sations tab). Users can share resources to either single
users, or to two or more users. To facilitate this lat-
ter case, we also implemented the notion of “circle”,
which (quite similarly to the Google’s notion) repre-
sents a predefined set of users that have been previ-
ously invited to join the “record” (once again, seen as
a meeting place, not just a passive repository of data).
In Figure 2 the sharing box is depicted, by which con-
tents can be shared: either by specifying each user
with the topmost control, or to all the users that are
members of one or more circles.
Implementing resource sharing required to inte-
grate the features of a number of modules. First,
circles exploit the features of the User Relationships
module, which we customized to meet our needs.
Then, resource sharing required us to conceive an
effective management of resource visibility among
users. To this aim, we exploited the features of three
modules that we configured to manage possibly joint
sets of access control policies, i.e., the Taxonomy Ac-
cess Control module, the Content Access module and
the access control sub-module provided by the User
Relationships module. In this way, MedIcona filters
resources by making them available only to specific
users or to those users that pertains to the selected cir-
cles.
4.3 Implementing user Types
This brings us to speak of how MedIcona users can
invite external people to become their record’s mem-
bers, so to say, and how each guest can be categorized.
To make this process straightforward, the owners of
the record (i.e., patients and single doctors, accord-
ing to the Scenario 1 and 2 mentioned in Section 3)
can invite external users when they share a resource
(filling in a new email address). The system catches
the request and prompts the user to specify in which
circle the new guest should be included.
Currently MedIcona adopts a user structure as
shown in Figure 3. According to scenario 1 and 2,
there are two types of record owner: i.e., the practi-
tioner that holds MedIcona as her EMR application;
and the patient, who holds it as her PHR (refer to
Section 3 to distinguish these two cases, which never-
theless can coexist within a single instance of MedI-
cona). Practitioners and patients can invite a third
kind of users, i.e. guests. The Guests role is then
further articulated in terms of homogeneous groups
through the above mentioned concept of circle (pat-
tern areas in Figure 3) so as to allow record owners
to share their contents with a granularity that ranges
from the single user, up to a restricted set of users, i.e.,
one or more circles.
In fact, doctors can invite people also in the “pa-
tients” circle; when one of these accepts, MedIcona
associates this member with the patient role, that is a
special role for which it also creates a specific record
that does not expire and that contains private empty
forms and binders, as well as the resources shared
by the doctor. Doctors can also invite people putting
them in other circles (e.g., the colleagues one in Fig-
ure 3) and selecting specific resources (or sets of
them, up to whole records and sets of records) to be
made visible to those guests. In doing so, MedIcona
associates those people with the (possibly) tempo-
rary role of Guest, whose “record” is populated only
with the resources actually shared in an anonymized
form, in order to allow the practitioner ask for second-
Figure 3: Types of users in MedIcona.
HEALTHINF2014-InternationalConferenceonHealthInformatics
226
opinion consultation or prime an idea exchange with
some specialist.
Patients, in their turn, can invite external guests
too, also in this case by specifying what parts of their
record they want to share (possibly even the whole of
it), for how long and what circle is most suitable to
include the guest. To help patients to share resources
consistently with both their high concern with privacy
and, at the same time, the will for an increasing degree
of participation, MedIcona allows them to distinguish
between relatives (no time limits), acquaintances and
other caregivers (time limited).
We implemented invitations of guest users ex-
ploiting the features of the Invite module and we con-
figured it to work together with the User Relation-
ships module, in order to allow users to automatically
assign their own guests to the desired circles. Circles
are defined by the system administrator, who can add
or delete them at need: for instance, with reference
to Scenario 3 in Section 3, doctors could also see cir-
cles for the colleagues of their same department, for
those of the same hospital, or of different specialties,
and the like. Quite similarly to the content type case
(see above), record owners with special rights (e.g.,
the doctor in the Scenario 1) can define new circles,
through the functions of the User Relationships mod-
ule that are exposed in the “Configuration” section of
the Administration panel.
4.4 Implementing Exchanges
Once record owners, i.e., practitioners and patients,
have shared something with each other and exter-
nal guests, they can annotate and communicate about
those resources. In what follows we focus on Discus-
sions and Conversations.
Discussions are threads of comments. We distin-
guish between content-related discussions and topic-
related discussions. The former ones are kept as close
as possible to the resource that users intend to dis-
cuss about. For instance, a patient could need some
clarification on a prescription (that is a resource that
the doctor has shared with her earlier): to this aim
she adds a comment just below the resource in the
same sheet. Any response is appended to the list of
existing comments for that resource. If the respon-
dent has selected the “reply” command, MedIcona
displays the response indented so as to convey the
idea that that comment explicitly addresses the former
comment. Further comments attached in this way are
progressively nested under the root comment, so that
the idea of related message exchange is conveyed vi-
sually. Nevertheless, users can also attach new com-
ments that are not intended as “replies” to other com-
ments: these will be aligned to the left margin of the
page.
Topic-related discussions are treated differently,
as they are collected under the Discussion tab (see
Section 4.1). In this case, the record owner creates
a new resource, namely a topic, and shares it to any of
her guests as a way to ask for help, pieces of advice or
just an opinion. To this aim, MedIcona creates a sort
of small Forum, where all topics are listed in the Dis-
cussions page and, once the user has entered the sheet
associated with a specific topic, the related responses
are collected under the topic, in a similar manner as
described above.
Conversation is the concept that, in MedIcona,
gathers related threads of messages together accord-
ing to the correspondents involved, rather than to the
“topic” the messages are about (like in the case of dis-
cussions). This is because the record owners would
want to undertake a written exchange with someone
also regardless a specific topic, much alike they would
do when they want to write an SMS, or an email or an
instant message. The point is that they would want
to use an IPHR whenever this message regards their
health, or alternatively, is sent from their family doc-
tor (in case of a patient) or from some of their patients
(in case of practitioners).
Thus under the Conversations tab record owners
can find both a sort of address book, showing the list
of all the people that a record owner has invited so
far (including the practitioner, if she is an invited pa-
tient of hers - see Scenario 1 in Section 3) and, close
to each name, the time of the last message exchanged
with that person. By clicking on a guest’s name, the
related conversation sheet is shown: this is possibly
empty if no conversation has occurred that far with
that person, because only static resources were shared
with her. In this sheet, if the selected person is cur-
rently an active guest of the record, MedIcona gives
the capability to write a message and then share (i.e.,
send) it to that person: in so doing, the system stores
the message in the conversation thread on top of the
previous messages. If the person is online at that time,
the message will be also displayed in a “chat box” that
is placed in the bottom-right corner of each MedIcona
page. Otherwise, the message will be dispatched to
the email address associated with the correspondent.
Also every message sent to online guests through the
“chat box” will be timestamped and reported in the
related conversation sheet, where no real difference is
represented between asynchronous and synchronous
messages.
Thus a conversation sheet encompasses the entire
history of messages exchanged with that person, i.e.,
both instant messages and emails, from the most re-
cent on top, to the oldest at the bottom. Notably, if
the correspondent is either a practitioner (role practi-
TryingtoFilltheGapbetweenPersonsandHealthRecords-TheMedIconaInterPersonalHealthRecord
227
tioner) or a caregiver (role guest in the caregiver cir-
cle) for a patient user, or if she is a patient (role pa-
tient) for a practitioner user (see Scenarios 1 and 2
in Section 3), by default MedIcona also connects to
the mail server of the record owner and downloads
all the messages that it finds exchanged between her
and the correspondent also outside of MedIcona, i.e.,
with a regular email client; in so doing, all the mes-
sages from and to that person can be found in the Con-
versations tab, chronologically ordered, and relatively
close to other health-related resources, in the obvi-
ous assumption that health would be the main talking
point with those professionals. Nevertheless, this fea-
ture can be disabled, if the record owner wants to col-
lect in the record only those messages that she created
and sent with MedIcona.
In order to implement conversations in MedIcona,
we exploited the features of the Drupal Chat module,
and we developed our messaging custom module, i.e.,
the MediMail module.
5 FINAL REMARKS
In this paper we have presented the main aspects of
the concept of InterPersonal Health Record (IPHR),
which we submit as a step forward to improve the in-
clusion of Personal Health Records in the daily life
of citizens and patients. We started from the recog-
nition that PHRs are nowadays still seldom adopted,
if not completely neglected by their potential users,
although many enabling technologies are mature and
widespread by now, like the recent success of social
media and the timeless appeal of electronic mailing
show.
We argued that IPHRs can support recent trends
and proposals in healthcare service delivery, like co-
production, patient empowerment, patient-centered
care, preventive care and self-management, more na-
tively and hence effectively than hybrid solutions that
would keep the health documentation of a person de-
coupled from the social interactions and exchanges
that she would undertake to make sense of it and make
it more situated in her own life.
We are aware that this argument can not be val-
idated in a traditional way, as the diffusion of real
IPHRs in vast communities of patients and care-
givers would require the alignment of many interests
and the involvement of multiple stakeholders. More-
over, evaluating the system in real settings (“in vivo”)
would require to focus on the so called “unintended
consequences” of Health Information Systems (Harri-
son et al., 2007), which could entail serious problems
of information overload, information filtering and in-
terpersonal conflicts.
For this reasons, this contribution is rather aimed
at presenting the research concept of IPHR, and at
supporting it by proposing a first full-fledged imple-
mentation that addresses all the high-level require-
ments, as well as many of the functional ones, that
derive from the IPHR concept, as its feasible and cost-
effective proof-of-concept. Therefore, this work can
be seen more concretely as a work addressing the re-
search question whether the IPHR concept is techni-
cally feasible and capable of providing the complex
functionalities of communication and content sharing
described in the previous sections than proving its so-
cial adoption and usability.
Our contribution to this question is the realization
of MedIcona. This is an open-source, free, Drupal-
based IPHR that integrates a visually and conceptu-
ally rich way to annotate the record’s content and re-
sources (which was just outlined here and presented
in more details in (Cabitza et al., 2013)) with sophis-
ticated yet user-friendly mechanisms to create forms,
upload documents, share health content and support
message exchange about this content.
Due to space limitations, we could focus only
on the basic architecture and on the communication-
oriented features of MedIcona. In so doing, we pro-
vided information useful to replicate this model also
on other similar and equally affordable content man-
agement systems (e.g., Joomla, Wordpress) and, in-
directly, to demonstrate the economic affordability
and technical sustainability of the three scenarios pre-
sented in Section 3. This choice forced us to leave
outside other important features of MedIcona, like the
integration with external Web resources for knowl-
edge dissemination and appropriation, the rich chart
visualization capabilities and the timeline-based ac-
cess to the content (see Section 2), as well as to over-
look the security-oriented aspects of this record, i.e.,
a feature that a health record should obviously exhibit
as a primary concern and core feature. Thus, in regard
to this latter aspect, we hint at the fact that our proto-
type currently guarantees security and confidentiality
through the fine grained configuration of the access
control modules used to implement content sharing
and user permissions. Moreover, contents that are up-
loaded to MedIcona are encrypted during the upload
phase with no direct intervention of the user. This ba-
sic support will be improved in three further ways: by
(i) implementing an intrusion detection system (IDS)
that could be flanked by (ii) a “ban by IP” system,
and (iii) by implementing techniques to avoid SQL-
injections that some Drupal modules already address.
As first contribution in demonstrating the feasi-
bility of the IPHR concept in the context of care
networks and personal health management, we are
HEALTHINF2014-InternationalConferenceonHealthInformatics
228
currently offering the system to anyone interested in
trying and testing its more innovative functionalities
at the Web address http://tinyurl.com/MedIconaBeta.
The full functional evaluation of the system in real
settings will be addressed in further researches that
will be aimed at testing which scenario of those out-
lined in Section 3 is more feasible and promising with
respect to its economic sustainability in the long run.
REFERENCES
Bannon, L. J. and Bødker, S. (1997). Constructing com-
mon information spaces. In ECSCW’97, pages 81–96,
Netherlands. Kluwer Academic Publishers.
Boyle, D. and Harris, M. (2009). The challenge of co-
production. Technical report, NESTA and new eco-
nomics foundation, London, UK.
Cabitza, F. (2012). On the attitudes of GPs toward novel
features of their next EPRs. In Quality of life through
quality of information, volume 180 of Studies in
health technology and informatics, pages 911–916.
Cabitza, F., et al., (2013). ”Worth a thousand fields”. Ar-
guing for a visual turn in computer-supported gen-
eral practice. In eHealth 2013: Proceedings of
the IADIS International Conference on eHealth, 24-
26 July, 2013 Prague, Czech Republic, Computer
Science and Information Systems. IADIS Press, pp.
95102.
Cabitza, F., et al., (2014). User-driven Prioritization of Fea-
tures for a Prospective InterPersonal Health Record:
perceptions from the Italian context. Comput Biol
Med. Forthcoming.
Cahn, E. S. (2000). No more throw-away people: the co-
production imperative. Edgar Cahn, 2000.
Carroll, J. M. (2013). Co-production scenarios for mobile
time banking. In End-User Development, 7897: 137–
152. Springer, Berlin, D.
Coulter, A. and Ellins, J. (2006). Patient-focused interven-
tions: a review of evidence. Technical report, The
Health Foundation, London, UK.
Day, K. and Gu, Y. (2012). Influencing factors for adopting
personal health record (PHR). Stud Health Technol
Inform, 178:39–44.
Dunbrack, L. A. (2011). Vendor assessment: When will
PHR platforms gain consumer acceptance? Vendor
Assessment HI227550, IDC Health Insights, Fram-
ingham, MA, USA.
Fisher, S. (1987). Meeting between experts: An approach
to sharing ideas in medical consultations. Sociology
of Health & Illness, 9(2):211–213.
Greenhalgh, T., et al., (2010). Adoption, non-adoption, and
abandonment of a personal electronic health record:
case study of HealthSpace. BMJ, 341(1):c5814–
c5814.
Greenhalgh, T., et al., (2009). Tensions and paradoxes in
electronic patient record research: a systematic litera-
ture review using the meta-narrative method. The Mil-
bank Quarterly, 87(4):729–788.
Greenhalgh, T., et al., (2008). Patients’ attitudes to the sum-
mary care record and HealthSpace: qualitative study.
BMJ, 336(7656):1290–1295.
Harrison et al., (2007). Unintended Consequences of Infor-
mation Technologies in Health Care - An Interactive
Sociotechnical Analysis. JAMIA 14, 542–549.
Heeks, R., et al., (1999). Why health care information sys-
tems succeed or fail. Technical report, Institute for De-
velopment Policy and Management (IDPM), Manch-
ester, UK.
Hoerbst, A., et al., (2010). Attitudes and behaviors related
to the introduction of electronic health records among
austrian and german citizens. IJMI, 79(2):81–89.
Kahn, J. S., et al., (2009). What it takes: Characteristics
of the ideal personal health record. Health Affairs,
28(2):369–376.
Karsh, B.-T., et al., (2010). Health information technology:
fallacies and sober realities. JAMIA, 17(6):617–623.
Majeed, A., et al., (2009). The impact of eHealth on the
quality and safety of healthcare. In Communications
Infrastructure. Systems and Applications in Europe,
16:204–204. Springer, Berlin, D.
Pagliari, C., et al., (2007). Potential of electronic personal
health records. BMJ, 335(7615):330–333.
Realpe, A. and Wallace, L. M. (2010). What is co-
production? Technical report, The Health Foundation,
Coventry University, Coventry, UK.
Singleton, P., et al., (2009). Critical issues for electronic
health records: Considerations from an expert work-
shop. Technical report, Nuffield Trust, UK.
Tang, P. C., et al., (2006). Personal health records: Defini-
tions, benefits, and strategies for overcoming barriers
to adoption. JAMIA, 13(2):121–126.
Westin, A. F., et al., (2008). Americans overwhelmingly be-
lieve electronic personal health records could improve
their health. Technical report, Markle Foundation.
TryingtoFilltheGapbetweenPersonsandHealthRecords-TheMedIconaInterPersonalHealthRecord
229