versioned healthcare events. Versioning is
accomplished through recording every data change
in special data structures (Contributions).
All the interaction with data is achieved through
the use of Archetypes and Templates. An archetype
is a component that allows standardization by
mapping each medical event into pre-agreed
individual fields of information (Entries) forming a
Composition. A Template serves both as a
messaging standardization structure and is closely
related to screen forms. It aggregates one or usually
more archetypes.
An archetype can be used to manage data
referring, for example, to a blood pressure
monitoring event, that are mapped into various
information fields (date, systolic, diastolic,
respective values, etc), forming a Composition, e.g.
“blood pressure measurement”. A Template can be
an aggregate of information, e.g. “discharge
summary” that manages the information relative to
various healthcare events, each one of them created
through a particular archetype.
Archetypes are meant to be created by other
parties, namely in close collaboration with medical
experts, and Templates are mostly to be developed
by local implementations. Archetypes are also the
structures that allow the use of terminologies.
OpenEHR’s main focus is on components
instead of documents and its main specification is
the openEHR EHR Reference Model, namely its
EHR Information Model described by Beale et al
(2008). An openEHR system is composed of an
EHR Repository, an Archetype Repository,
Terminology, and Demographic or identity
information. A high-level openEHR EHR structure
consists of Contributions, EHR_id, EHR_Access,
EHR_Status, Directory, and Compositions.
3 A PORTABLE PHR openEHR-
Compliant
The basic paradigm of the Portable PHR (p.PHR) is
simplicity in order to attract users to the world of
PHRs. The best way to start is by allowing
individuals to scan their current paper records,
mostly CDTs and to provide a simple means to
store, organize and manage that information that will
be kept in a USB flash pen for total portability. The
proposed model also accommodates a workflow
similar to the paper-based but in which CDTs are
handed to the patient in electronic format both by e-
mail and in physical presence.
In another work (Santos et al, 2010), we
proposed a p.PHR, implemented on a USB flash
pen, based on secure virtual containers with
characteristics briefly summarized below. In this
paper we present the necessary steps to make it
compatible with the openEHR specifications.
One of the key concepts of the previously
proposed PHR model is the existence of five
different conceptual data types implemented through
individual document classification or by placing the
documents in different data storage areas or virtual
containers: a) Confidential Data (extremely
sensitive); b) Normal Data (disclosed to health
professionals); c)Transfer Data (recently entered the
PHR); d) Prescription Data; e) Emergency Data.
This model allows patient mobility, provides an
emergency data repository, and can be used, by a
patient with just basic computer skills, as a passive
information repository to be carried between
healthcare facilities, thus mimicking the existing
social habit with paper-based records.
In order to achieve this, the p.PHR’s structure
needs to be secure and to allow for different data
storage areas depending on the degree of
confidentiality the patient deems the particular data
items that make up his PHR. The information
contained in the p.PHR is controlled, managed, and
made available to third parties by the patient and
only under his explicit consent.
In order to allow the patient to both manage the
PHI contained in the p.PHR and to make it available
to other actors in a scalable manner, various
operating modes are available upon patient’s option.
These operating modes are shown in figure 1.
Upon receiving the p.PHR in the respective
device, the patient authenticates himself for account
provisioning. The device is supplied with a master-
password that will be used for the initial setup of
p.PHR native applications and for the creation of a
working-password (password). When the patient
accesses the p.PHR an operating mode is selected.
Each actor in healthcare delivery has different
information access needs, therefore with different
access privileges to each data type. Figure 1 shows
these data types in usage context.
Although an EHR is conceptually different from
a PHR, the openEHR specification can be deployed
for data structure. In terms of data, the EHR
openEHR-compliant’s structure can be deployed
with the added feature of the secure virtual
containers (containing the classified compositions)
reflected at the openEHR directory level.
In terms of the overall system the EHR
repository
will be reduced to just one PHR and the
HEALTHINF 2011 - International Conference on Health Informatics
354