more intuitive way. Also the specificity of medical in-
formation should be adapted to the health literacy of
each patient, health literacy which changes in time.
4.2 PHR to VHCR
The main obstacle is the fact that for clinical infor-
mation to be imported into VHCR it needs to be ap-
proved via signing by a healthcare professional, in
this case the general practitioner. The general prac-
titioner has objective but also subjective reasons to
refuse to do so:
• Not reimbursed to do it. Doctors can view spend-
ing time in filtering information from the PHR to
VHCR as a waste of their time since it is an ac-
tivity for which they are not financed. One way
to encourage doctors to guide their patient in us-
ing IT-enabled, patient empowering tools is to re-
imburse “e-Visits“ (Tang et al., 2006), namely
the virtual encounter between the doctor and the
patient. Moreover, even without reimbursement,
the previous virtual encounter with the healthcare
provider can make the actual encounter more pro-
ductive and more focused, using the provider‘s
time more effectively and lowering the commu-
nication barrier.
Also in the case of pediatric doctors with young
children registered in their care, the PHR can
prove very helpful as it frees them from contin-
uous domestic visits or visits of the parents with
their children to the cabinet, by being able to mon-
itor remotely the children evolution and to raise
the responsibility with the parents.
• Not willing to take responsibility for unchecked
data. Once a fact from the PHR is integrated into
VHCR via his signature, the doctor becomes re-
sponsible for that entry.
While some of these obstacles can be overcome by
changing legislation (e.g. reimbursing eVisits) we be-
lieve that technology can also play a part in assisting
the GP, by partially automizing the filtering process
and using notifications.
5 IMPLEMENTATION
VHCR is implemented using a service oriented archi-
tecture(Serbanati and Vasilateanu, 2008). The POS
uses a wrapper that transforms the output from the
EHR application to a HL7 compliant message that
is sent to the intelligent broker which forwards it to
VHCR component. The broker is also responsible for
sending notifications to the interested parties.
In the present prototype we add to the POS a fil-
tration subsystem based on an automatic, rule based,
system that analyzes the coherency of data (double
submits, submits with no body, etc) which commu-
nicates directly with the PHR. The PHR chosen for
this proof-of-concept was Google Health (McBride,
2008), which implements a partial subset of Continu-
ity of Care Record (CCR)(Ferranti et al., 2006).
The information inspected for validation is repre-
sented by the Problems element and Medication ele-
ment. The PHR used does not allow an asynchronous
retrieval of medical information introduced therefore
a synchronous retrieval of data must be implemented;
the data is retrieved by a worker thread created and
started on the start of the application. The POSDi-
gester is responsible for retrieving data for all pa-
tients marked as registered at the logged in physician,
afterwards for all new information it generates no-
tifications which are processed by the filtration sys-
tem. The flow of the validation process from PHR to
VHCR is presented in fig 1. The system receives noti-
fications when in PHR either a new medicine is added
or a new symptom is added and these two types of
notifications are processed differently:
• If the notification is a symptom and its syntax is
correct, it is displayed as an alert to the physi-
cian in charge; the physician can either classify
it medically irrelevant and the flow stops, or it can
be classified medically relevant and an encounter
event is created (ADT) and sent to the VHCR.
The encounter can belater appendedto an existing
medical episode, or it can generate a new medical
episode on its own.
• If the notification is a new medicine its counter
indications are checked; if there are no known in-
teractions between the medicine and other drugs
or conditions than it is disregarded. If the previ-
ous condition is not fulfilled then a check is made
to see if the new drug has interactions with an ex-
isting patient condition and if this is so then an
encounter(ADT) should be created automatically
and an alert displayed; if the medication has in-
teractions with other drugs , therefore this infor-
mation should be taken into account for further
prescriptions, the information is appended to the
VHCR and the physician is alerted.
To include data from VHCR to PHR, PHR must
register as a client to the notifications dispatched by
the VHCR. To make a customized selections of what
types of events should be included in PHR, we have
devised a proxy service between the PHR and VHCR.
In effect the proxy registers to VHCR notifications
and it forwards them selectively to PHR. The proxy
also acts as a translator, transforming HL7 messages
INTEGRATING CLINICAL INFORMATION FROM A PERSONAL HEALTH RECORD INTO THE VIRTUAL
HEALTHCARE RECORD
523