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-

ﬂedged demonstrator of the IPHR notion developed as free, open-source installation proﬁle 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 sufﬁcient 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

, the aforementioned study showed that only 2

out of 100 used to manage their health documents on

line. The same ofﬁcial 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!”

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

http://www.istat.it/it/archivio/78166

http://goo.gl/D8iﬂ

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

 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 ﬁll 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 ﬁrst instance of this class

of applications and its proof-of-concept that can be

freely used (and evaluated) by the interested stake-

holders. We deﬁne 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-

tiﬁcates) that is speciﬁcally 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 ﬁrst 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 clariﬁca-

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 ﬁrst 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. deﬁne customized data templates and instantiate

them as forms and charts of the record where to

ﬁll 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 ﬁnds 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 speciﬁc 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-

ciﬁc resources; for patients the system collects re-

sources from certiﬁed 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

;

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 speciﬁc 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 deﬁnition 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 ﬁlled 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

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 proﬁling 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 predeﬁned 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, certiﬁcates) that she produced and

also as a direct communication line with her

ofﬁce. 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 ﬂexible 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 conﬁdential 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 speciﬁc 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 proﬁles 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 speciﬁc version of the Dru-

pal core packaged with a set of contributed modules,

libraries and themes, which are pre-conﬁgured in a

speciﬁc 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 speciﬁc 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 ﬂexibility of Drupal allows

to organize the content also differently, e.g., under

different tabs, by simply deﬁning new Views. These

allow the system administrator to deﬁne sort of cus-

tom high level queries, which can ﬁlter contents to be

shown to the users, as well as aggregate and present

contents in different formats and graphical arrange-

ments dynamically.

The ﬂexibility of MedIcona is also evident in the

creation of new content types, i.e., the data structures

where users can ﬁll 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 reﬂected by the fact that each re-

source is presented in a page where users ﬁnd 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 predeﬁned 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 conﬁgured 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 ﬁlters

resources by making them available only to speciﬁc

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

(ﬁlling 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 speciﬁc 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 speciﬁc 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-

ﬁgured 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 deﬁned 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 deﬁne new circles,

through the functions of the User Relationships mod-

ule that are exposed in the “Conﬁguration” 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

clariﬁcation 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 speciﬁc 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 speciﬁc 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 ﬁnd 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 ﬁnds 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 ﬁltering and in-

terpersonal conﬂicts.

For this reasons, this contribution is rather aimed

at presenting the research concept of IPHR, and at

supporting it by proposing a ﬁrst full-ﬂedged 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 conﬁdentiality

through the ﬁne grained conﬁguration 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 ﬂanked by (ii) a “ban by IP” system,

and (iii) by implementing techniques to avoid SQL-

injections that some Drupal modules already address.

As ﬁrst 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 ﬁelds”. 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). Inﬂuencing 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, Nufﬁeld Trust, UK.

Tang, P. C., et al., (2006). Personal health records: Deﬁni-

tions, beneﬁts, 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