Maintaining the Consistency of Electronic Health Record’s

Medication List

Juha Puustjärvi

and Leena Puustjärvi

Department of Computer Science, University of Helsinki, P.O. Box 68, Helsinki, Finland

The Pharmacy of Kaivopuisto, Neitsytpolku 10, Helsinki, Finland

Keywords: Electronic Health Record, HL7 RIM, CCD Standard, Medication List.

Abstract: An electronic health record (EHR) is a systematic collection of health information about an individual

patient. It includes a variety of types of observations entered over time by health care professionals,

recording observations and administrations of drugs and therapies, orders for the administration of drugs

and therapies, and test results. A well known problem is the consistency of EHR’s medication list: often

some of the prescribed drugs are missing, or some information is no more valid, e.g., some prescribed drugs

may be replaced by new drugs, or the dosage may be changed. In this paper we have focused on this

problem. We have restricted on EHRs and on prescriptions that are applications of the HL7 Reference

Information Model (RIM). Further, we have used the Refined Message Information Model (RMIM) to

specify the components that are extracted from prescriptions and transmitted into EHR. We have also

specified the criteria for medication list’s consistency, and the way it can be maintained. In addition, we

have studied the ways the RIM can be used in linking patient’s prescriptions among themselves such that

the name of the link indicates its semantics. By viewing patient’s prescriptions as a linked data structure we

can improve the effectiveness of prescriptions’ retrieval as well as provide expressive queries on patient’s

health documentation.

1 INTRODUCTION

An electronic health record (EHR) describes the

systematic documentation of a single patient's

medical history (Hartley and Jones, 2005). The main

goal of an EHR is to provide a complete and

accurate summary of the health and medical history

of a patient (NEHTA, 2006). It includes a variety of

types of observations entered over time by health

care professionals, recording observations and

administrations of drugs (Angst et al., 2008).

A well known problem is that EHRs’ medication

history is often out of date in the sense that some of

the prescribed drugs are missing, or some

information is no more valid, e.g., some prescribed

drugs may be replaced by new drugs, or the dosage

may be changed (Puustjärvi and Puustjärvi, 2011).

So, there is a risk for physician’s wrong diagnosis or

treatment decision.

In this paper we have focused on this problem.

We have studied how relevant medication data can

be extracted from prescriptions and transmitted to

the EHR such that the sender and receiver can

unambiguously interpret the semantics of the

exchanged messages.

It is not necessary to store the whole prescription

into an EHR as it is just a summary of the health and

medical history of a patient. For example, we have

omitted the context information of a prescription

such as who created it, when, where and for what

purpose. Yet the physician can retrieve such

information by following the link from the EHR to

the original prescription that is stored in a

prescription holding store. Anyway, storing the

information of prescribed drugs and dosages into

EHRs is of prime importance. Then a physician may

present data centric queries such as the average

blood pressure and/or cholesterol level during the

time periods the patient was using Emconcor (a drug

for blood pressure).

There are many standards, such as HL7 CDA

(HL7, 2004), EN 13606 (prEN13606, 2006) and

openEHR (openEHR, 2013) developed to digitally

represent clinical data. Nowadays EHR systems

increasingly use CDA’s CCD standard (CCD, 2009)

although it original purpose was to deliver clinical

330

Puustjärvi J. and Puustjärvi L..

Maintaining the Consistency of Electronic Health Record’s Medication List.

DOI: 10.5220/0005199203300335

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2015), pages 330-335

ISBN: 978-989-758-068-0

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

summaries between healthcare organizations

(Benson, 2010).

With respect to the standards, we have restricted

on EHRs and on prescriptions that are applications

of the HL7 Reference Information Model (RIM),

i.e., they are based on the same terminology.

Further, we restricted on EHRs based on the CCD

standard as it is nowadays increasingly used for

storing medical summaries.

In order to achieve semantic interoperability

between the prescription holding store and the EHR

system we have to specify the semantics of the

exchanged message. In specifying the data elements

that are extracted from prescriptions and transmitted

to EHR we constrained the conceptual model of the

prescription, i.e., we constrained the Refined

Message Information Model (RMIM) of the

prescription.

Defining messages by RMIMs is a central idea of

the HL7 V3 approach (HL7, 2007). Each RMIM

diagram is derived from the RIM by limiting its

optionality in the sense that the designer can take

only the needed classes and attributes. Such

constrained specifications are called profiles. Hence,

EHRs based on CCD-standard, prescriptions as well

as the messages transmitted to EHR have profiles.

We have also studied the ways the RIM provides

for linking EHRs to prescriptions as well as linking

prescriptions among themselves such that the name

of the link (e.g., replaces) indicates the meaning of

the link. By viewing patient’s prescriptions as a

linked data structure we can improve the

effectiveness of prescriptions’ retrieval as well as

provide expressive queries on patient’s health

documentation.

The rest of the paper is organized as follows. In

Section 2, we first give a scenario of an electronic

prescription process, and then we give our

interpretations of the prescription concept. In

Section 3, we describe the prescription process from

communication architecture point of view, i.e., we

present the systems that are involved in prescription

process. In Section 4, we first give an overview of

the RIM, and then we illustrate how it is constrained

in modelling prescriptions as well as the messages

transmitted to the EHR.

In Section 5, we first present the structure of the

CCD documents, and then we describe how its

medication list can be linked into prescriptions

according to the modelling primitives of the RIM.

We also present our introduced notions of

medication list’s consistency and the ways it can be

maintained. In addition, we discuss the suitability of

our ideas for maintaining the consistency of personal

health records. Finally, Section 6 concludes the

paper by shortly discussing our future research.

2 PRESCRIPTION

Unfortunately there is no commonly used exact

interpretation of prescription concept. For example,

if the dosage of a prescription is changed or the

prescription is renewed whether we have modified

the existing prescription or whether we have

produced a new one?

We have adopted the interpretation that once the

prescription is stored in a prescription holding store

it cannot be changed. Yet, a prescription may be

invalidated and replaced by a new prescription.

Hence prescriptions may have mutual dependencies

which give rise for maintaining appropriate data

structures among patient’s prescriptions.

Our argument for not allowing prescriptions to

be changed is to avoid confusions. For example, if a

prescription is changed, then two physicians nay

have different views of the same prescription. In

addition, we only allow a prescription to be replaced

ones. However, the length of the replacement chain

is not restricted. The only requirement is that the

chain may not be cyclic as it indicates an error.

If a replaced prescription is retrieved, then the

whole replacement chain is presented for the user.

This ensures that the user can make the distinction

between valid and out date information in

prescriptions.

We have also made the distinction between

active and passive prescriptions: A prescription is

active, if all its prescribed drugs are not yet

dispensed or if the course of the drugs is not

finished; otherwise a prescription is passive.

Our argument is that passive prescriptions should

not be deleted from patient’s EHR. Otherwise,

queries such as “Give me the average blood pressure

during the time the patient was using drug A and

drug B” would require that both drugs are included

in active prescriptions.

3 THE ARCHITECTURE OF THE

SERVICE ORIENTED EPW

We now describe the architecture that can be used

for providing the services described in Section 2.

The architecture is based on the service oriented

computing paradigm (Singh and Huhns, 2005).

Basically, services are a means for building

MaintainingtheConsistencyofElectronicHealthRecord'sMedicationList

331

distributed applications more efficiently than with

previous software approaches. The main idea behind

services is that they are used for multiple purposes.

Services are also used by putting them together or

composing them. Therefore every aspect of services

is designed to help them to be composed.

In the health care sector service oriented

computing provides flexible methods for connecting

electronic prescription system to other relevant

health care systems (Puustjärvi and Puustjärvi,

2012). For example, electronic prescription writer

can interact through a Web service with the health

care system that supports patient records. There may

also be components that are used by different

healthcare systems. For example, medical database

may provide services for medical information

systems as well as for electronic prescription system.

The communication is based on Web services

and SOAP-protocol (SOAP, 2012). Originally they

provided a way for executing business transactions

in the Internet. Technically Web services are self-

describing modular applications that can be

published, located and invoked across the Web.

Once a service is deployed, other applications can

invoke the deployed service. In general, a Web

service can be anything from a simple request to

complicated business or eHealth processes.

The components of the electronic prescription

system are presented in Figure 1. Each component

communicates through a Web service interface (WS-

interface). Further, each message is presented as an

XML-document, which is carried by the SOAP

protocol.

Although in this architecture EPW extracts

relevant data from prescription and transmits it to

the EHR system, we can also easily modify the

architecture such that the prescription holding store

carries out this function, i.e., transmits the extracted

data into the EHR. This functionality may also be

EPW

Expert

database

system

Medical

database

system

Prescription

holding store

Prescription

pricing

authority

Health care

system

WS-interface WS-interface

WS-interface WS-interface WS-interface

EHR

system

WS-interface

Figure 1: The Communication Architecture of the EPW.

EPW specific, i.e., depending on the EPW either it

or the prescription holding store transmits the

extracted data into the EHR. The analysis presented

in forthcoming sections is valid for all these

architectural choices.

4 MODELLING PRESCRIPTIONS

AND EXCHANGED MESSAGES

BY RMIMS

4.1 Reference Information Model Rim

The Reference Information Model RIM is the

cornerstone of the HL7 Version 3 development

process (Boone, 2011). It is the root of all

information models and structures developed as part

of the V3 development process.

The RIM is based on two key ideas (Benson,

2010). The first idea is based on the consideration

that most healthcare documentation is concerned

with “happenings” and things (human or other) that

participate in these happenings in various ways.

The second idea is the observation that the same

people or things can perform different roles when

participating in different types of happening, e.g., a

person may be a care provider such a physician or

the subject of care such as patient.

As a result of these ideas the RIM is based on a

simple backbone structure, involving three main

classes, Act, Role, and Entity, linked together using

three association classes Act-Relationship,

Participation, and Role-Relationship (Figure 2).

Figure 2: The RIM backbone structure.

The classes in the RIM have structured attributes

which specify what each RIM class means when

used in a message (exchanged document). The idea

behind structured attributes is to reduce the original

RIM from over 100 classes to a simple backbone of

six main classes.

Each happening, such as prescribing medication

or any CDA document is an Act, and it may have

any number of Participations, which are Roles,

played by Entities. An ACT may also be related to

other Acts via Act Relationships, i.e., it links Acts

together. Further, every ActRelationship has a

HEALTHINF2015-InternationalConferenceonHealthInformatics

332

source and target to which it points, and each Act

may have any number of AcRelationships. Its

typeCode, which is a structural attribute, describes

the type of association between Acts. These are

Composition (COMP), Documents (DOC), Fulfils

(FLFS), Refers (REF), and Replaces (REP).

The typeCodes REF and REP play a central role

in our solution: We use typeCode REF in linking the

medication list of an EHR to prescriptions, and

typeCode REP in linking prescriptions among

themselves.

4.2 Refined Message Information

Model RMIM

The RIM is not a model of healthcare, nor is it a

model of any message, although it is used in

messages. The structures of messages are defined by

constrained information models. The most

commonly used constrained information model is

the Refined Message Information Model (RMIM).

Each RMIM is a diagram that specifies the structure

of an exchanged message.

Each RMIM diagram is derived from the RIM by

limiting its optionality by omission and cloning

(Benson, 2010). Omission means that the RIM

classes or attributes can be left out. Note that all

classes and attributed that are not structural

attributes in the RIM are optional, and so the

designer can take only the needed classes and

attributes. Cloning means that the same RIM class

can be used many times in different ways in a

profile. For example, Patient and Employee are

specializations of Role, and so they may both appear

in the same diagram.

The multiplicities of associations and attributes

in the diagram are constrained in terms of

repeatability and optionality. Further, code binding

is used for specifying the allowable values of the

used attributes.

To illustrate the relationships of the RIM and

RMIM consider the RMIM diagram of Figure 3.

Note that HL7 uses its own representation of

UML in RMIM diagrams: each class has its own

color and shape to represent the stereotypes of these

classes, and they only connect in certain ways.

The entry point of this diagram (Prescription) is

SubstanceAdministration, which is a specialization

of the RIM class Act. Replaces is a specializations

of the association class ActRelationship. Patient and

Employee are specializations (subclasses) of the

RIM class Role. Person and Organization are

specializations of the RIM class Entity. Subject and

Performer are specializations of the association class

SubstanceAdministration

Subject Performer

Patient

Employee

Person

Organization

ManufacturedProduct

Consumable

1..1patientPerson

1..1employeeOrganization

1..*manufacturedProduct

Prescription

LabeledDrug

1..*manufacturedDrug

Replaces

0..*vitalSignsEvent

SubstanceAdministration

Figure 3: The RMIM of a simplified prescription.

Participation.

The diagram (drugsInPrescription) in Figure 4

specifies the RMIM for the message that the

prescription holding store (or EPW) transmits to the

EHR system. It is specified by constraining the

RMIM of the prescription by omission. In particular

the context information is left out from the

prescription.

SubstanceAdministration

ManufacturedProduct

Consumable

1..*manufacturedProduct

DrugsInPrescription

LabeledDrug

1..*manufacturedDrug

Replaces

0..*vitalSignsEvent

SubstanceAdministration

Figure 4: The RMIM of the message transmitted to EHR.

The XML-schemas of the exchanged messages are

derived from the RMIM such that the class and

attribute names of the diagram are the names of the

elements of the XML-schemas. So, the RMIM

diagram gives the semantics for the tags (elements)

of the exchanged messages.

MaintainingtheConsistencyofElectronicHealthRecord'sMedicationList

333

5 CONTINUITY OF CARE

DOCUMENT

5.1 CDA and CCD Standards

The HL7 Clinical Document Architecture (CDA) is

an XML-based markup standard intended to specify

the encoding, structure and semantics of clinical

documents for exchange (Boone, 2011). It is based

on the HL7 RIM, meaning that we can interpret the

semantics of its tags of the XML-documents by the

RIM.

Each CDA document has one primary purpose

(which is the reason for the generation of the

document), such as patient admission, transfer, or

inpatient discharge. The CCD specification is a

constraint on the HL7 CDA standard. The CCD

standard has been endorsed by HIMSS (Healthcare

Information and Management Systems Society

Though) (HIMSS, 2013) and HITSP (Healthcare

Information Technology Standards Panel) (HITSP,

2013) as the recommend standard for exchange of

electronic exchange of components of health

information.

Although the original purpose of the CCD

documents was to deliver clinical summaries

between healthcare organizations, nowadays it

increasingly used for other types of messages: it is

considered as set of templates because all its parts

are optional, and it is practical to mix and match the

sections that are needed (Benson, 2010). Hence,

there is a RMIM behind each CCD document.

5.2 The Structure of a CDA Document

A CCD document, as well as any CDA document, is

comprised of the Header and the Body (Benson,

2010). A simplified Level 3 CCD document

including the Header and the Medications section is

presented in Figure 5. The simple element REF in

the complex element Medication provides the link to

the original prescription. Note that there is only one

Medication element in the Medications element, and

so there is only one link (REF-element) in the

document.

<PatientName>Tim Jones></PatientName>

</Patient>

<REF>Prescription-123</REF>

<MedicationID>Medication.567</MedicationID>

2012-03-01TO12:00

</ExactDateTime>

</DateTime>

<Actor>

<ActorID>Pharmacy of Kaivopuisto</ActorID>

<ActorRole>Pharmacy</ActorRole>

</Actor>

</Source>

<Text>One tablet three times a day</Text>

</Description>

<ProductName>Voltaren</ProductName>

<BrandName>Diclofenac</BrandName>

</Product>

<Unit>milligram</Unit>

</Strenght>

</Quantity>

</Medication>

</Medications>

</SimplifiedCCDfile>

Figure 5: A simplified example of a CCD document.

5.3 The Consistency of CCD’s

Medication List

We say that CCD document’s medication list

(Medications element) is well-formed, if each

Medication elements includes a link (i.e., REF-

element) to a prescription. It is exhaustive, if

patient’s all prescriptions are linked into the EHR.

Further if, the medication list is well-formed and

exhaustive, we say that it is consistent.

Whether the medication list is well formed can

be easily checked from patient’s EHR. Instead

whether it is exhaustive requires also accessing

patient’s prescriptions from prescription holding

store. However, assuming that the prescription

holding store follows the practise of linking its

prescriptions into EHRs, then there is no need for

such a checking.

6 CONCLUSIONS

As a patient may live in many places and use many

healthcare specialities, patient’s clinical documents

are often stored in several systems and locations.

However, patient’s all relevant documents should be

easily accessible for the physicians treating the

patient. Hence the EHRs, which provide a complete

HEALTHINF2015-InternationalConferenceonHealthInformatics

334

and accurate health and medical history of a patient

is of prime importance.

EHR systems usually organize clinical

documents into hierarchical structures that simplify

the search of documents, e.g., grouping together the

documents by episode, clinical specialty or time

period. Further, each clinical document is stored as a

stand-alone artefact, meaning that each document is

complete and whole in itself, including context

information such as who created it, when and where

and for what purposes. Without such contextual

information in some cases it may be a risk to

interpret some values of the data included on a

document.

On the other hand, considering each document

only as a complete and a whole in itself also has its

drawback. The problem here is that the efficient

usage of patients’ health documentation often is data

centric, meaning that data should be extracted from

various documents and then integrated according to

specific criteria. For example, a physician may be

interested to know the average blood pressure and/or

cholesterol level during the time periods the patient

was using a drug for blood pressure. Hence the

medical summaries such as the CCD documents are

of prime importance. However, maintaining the

consistency of the CCD documents is not an easy

task as it requires the interoperation of several

systems.

The key point in our presented solution for

achieving the consistency of CCD documents’

medication list is the semantic interoperability

between the prescription holding store and the EHR

system. Yet medication list is just a component of an

EHR. Ensuring the consistency of the other

components of the EHR is equally important. This

suggests that the semantic interoperability of the

EHR system and other systems that produce clinical

documents for the EHR is also of prime importance.

In our future research we will focus on this topic.

REFERENCES

Agarwal R, Angst C.M., 2006. Technology-enabled

transformations in U.S. health care: early findings on

personal health records and individual use, In Galletta

G, Zhang P, (Eds.), Human-Computer Interaction and

Management Information Systems: Applications (Vol.

5). Armonk, NY: M.E. Sharpe, Inc., pp. 357-378.

Angst, C.M., Agarwal, R, Downing, J., 2008. An

empirical examination of the importance of defining

the PHR for research and for practice, Proceedings of

the 41st Annual Hawaii International Conference on

System Sciences.

Benson, T., 2010. Principles of Health Interoperability

HL7 and SNOMED. Springer.

Boone, K., 2011. The CDA Book. Springer.

CCD, 2009. What Is the HL7 Continuity of Care

Document? Available at:

http://www.neotool.com/blog/2007/02/15/what-is-hl7-

continuity-of-care-document/

CCR, 2011. Continuity of Care Record (CCR) Standard.

Available at: http://www.ccrstandard.com/

Hartley, C., Jones, E., 2005. EHR Implementation. AMA

Press.

HIMSS, 2013. Healthcare Information and Management

Systems Society, Available at: http://himss.org/

HITSP, 2013. Healthcare Information Technology

Standards Panel, Available at: http://hitsp.org/

HL7, 2004. EHR System Functional Model and Standard

Draft Standard for Trial Use (DSTU).

HL7, 2007. What is the HL7 Continuity of Care

Document? Available at:

http://www.neotool.com/blog/2007/02/15/what-is-hl7-

continuity-of-care-document/

NEHTA. 2006. Review of shared electronic health record

standards. Version 1.0. National e- Health Transition

Authority, Available at:

http://www.nehta.gov.au/component/option,com_docman/

task,cat_view/gid,130/Itemid,139/

prEN13606, 2006.Health informatics – Electronic

healthcare record communication – Parts 1-5.

Committee European Normalisation, CEN/TC 251

Health Informatics Technical Committee. Available

at: http://www.centc251.org/

Puustjärvi, J. and Puustjärvi, L., Personal Health Book: A

Novel Tool for Patient Centered Healthcare. In the

Proc of the International Conference on Health

Informatics (HEALTHINF 2011). Pages 386-393.

2011.

Puustjärvi, J. and Puustjärvi, L.,. Moving from Remote

Patient Monitors to Cloud-Based Personal Health

Information Systems: a Way to Practicing Patient-

Centered Chronic Care Model. . In the Proc of the

International Conference on Health Informatics

(HEALTHINF 2012). Pages 37-45. 2012.

openEHR Foundation. Available at: http:

//www.openehr.org.

Singh, M., Huhns, M., Service Oriented Computing:

Semantics Proceses Agents. John Wiley & Sons, 2005.

SOAP, 2012. Simple Object Access Protocol. Available

at: http://www.w3.org/TR/SOAP/

MaintainingtheConsistencyofElectronicHealthRecord'sMedicationList

335