AUTOMATING THE IMPORTATION OF MEDICATION DATA

INTO PERSONAL HEALTH RECORDS

Juha Puustjärvi

Helsinki University of Technology, Innopoli 2, Tekniikantie 14, Espoo, Finland

Leena Puustjärvi

The Pharmacy of Kaivopuisto, Neitsytpolku 10, Helsinki, Finland

Keywords: Medication data, e-Prescription, Personal health record, Business process management, XML, RDF.

Abstract: A personal health record (PHR) provides a summary of the health and medical history of a consumer. It

includes data gathered from different sources such as from health care providers, pharmacies, insures, the

consumer, and third parties such as gyms. Importing data into PHRs is problematic as different data sources

use different representation formats. In addition, automating the importation is problematic as many of the

sources are built based on proprietary solutions, and thereby are not able to interoperate with PHR systems.

In this paper, we described how the importation of e-prescriptions into PHRs can be automated. In our

solution e-prescriptions are produced by an electronic prescription writer (EPW) which functionality is

specified by BPMN notation and then translated into executable WS-BPEL code. The EPW sends CCR-

formatted data of e-prescriptions into PHR system, which first transforms (if needed) the data into the

format of the used PHR system, and then stores them into PHRs. In particular, we consider how a PHR

system can transform a CCR-formatted data into RDF/XML format. The gain of such transformation is that

we can implement the PHR system as an application of a knowledge base system, and thereby we can

capture the wide expression power of knowledge base system’s query interface into the PHR system.

1 INTRODUCTION

E-prescription is the electronic transmission of

prescriptions of pharmaceutical products from

legally professionally qualified healthcare

practitioners to registered pharmacies (Batenburg

and Van den Broek, 2008). The information in an e-

prescription includes for example, prescribed

products, dosage, amount, frequency and the details

of the prescriber.

The problems related to prescribing medication

are discussed in many practitioner reports and public

national plans, e.g., in (Hyppönen et al., 2005;

Puustjärvi and Puustjärvi, 2006; Dwivedi et al, 2007;

Batenburg and Broek, 2008; Ghani et al., 2008).

These plans share several similar motivations and

reasons for the implementation of electronic

prescription systems (EPSs). These include:

reduction of medication errors, speeding up the

prescription ordering process, better statistical data

for research purposes, and financial savings.

Physicians usually produce e-prescriptions by

exploiting specific electronic prescription writers

(EPWs), which also assist in storing e-prescriptions

into prescription holding stores. As a result of recent

interest in personal health records (PHRs) a relevant

challenge is to extend EPWs in a way that they are

also able to store e-prescriptions into PHRs.

A PHR is a record of a consumer that includes

data gathered from different sources such as from

health care providers, pharmacies, insures, the

consumer, and third parties such as gyms (Agarwal

et al., 2006; Kaelber et al, 2008). It typically

includes information about medications, allergies,

vaccinations, illnesses, laboratory and other test

results, and surgeries and other procedures (Lewis et

al., 2005; Tuil et al, 2006).

An ideal PHR provides a complete and accurate

summary of the health and medical history of a

consumer (Angst et al., 2008). It is accessible to the

consumer and to those authorized by the consumer.

It is not the same as electronic health record (EHR)

135

Puustjärvi J. and Puustjärvi L. (2010).

AUTOMATING THE IMPORTATION OF MEDICATION DATA INTO PERSONAL HEALTH RECORDS.

In Proceedings of the Third International Conference on Health Informatics, pages 135-141

DOI: 10.5220/0002335801350141

 SciTePress

(EHR, 2009), which is designed for use by health

care providers (Raisingha and Young, 2008).

PHRs can be classified according to the platform

by which they are delivered. In internet-based PHRs

health information is stored at a remote server, and

so the information can be shared with health care

providers. They also have the capacity to import data

from other information sources such as a hospital

laboratory and physician office. However, importing

data to PHRs from other sources requires the

standardization of PHR-formats.

Various standardization efforts on PHRs have

been done. In particular, the use of the Continuity of

Care Record (CCR standard) of ASTM and HL7’s

(Dolin et al., 2001) Continuity of Care Document

(CCD standard) has been proposed. From

technology point of view CCR (CCR, 2009) and

CCD-standards (CCD, 2009) represent two different

XML schemas designed to store patient clinical

summaries. However, both schemas are identical in

their scope in the sense that they contain the same

data elements.

It is widely anticipated that in the near future

PHRs have the potential to dramatically change

healthcare. However, our argument is that a critical

aspect of current PHRs’ use is their consistency. In

particular the recall (the fraction of the relevant

documents, which have been stored in PHRs) is

crucial: making healthcare decision on inadequate

data may be a strong risk.

It is evident that the recall of PHRs is highly

dependent on the way the data is imported to PHRs.

Our argument is that in order to ensure that a PHR

includes an accurate medical history of the patient

the importation of source data into PHRs should be

done automatically. Re-entering data into PHRs

would cause additional manual operations, and the

importation of all the relevant data cannot be

ensured.

In this paper, we describe our work on automatic

importation of e-prescriptions’ data into PHRs. We

will illustrate the extension of WS-BPEL based

EPW in a way that it can automatically send

prescriptions’ data into relevant PHRs. The format

of the data follows the CCR standard. However, we

do not assume that all PHR-systems are based on

CCR standard since the format can be transformed

by a stylesheet engine into PHR system’s used

format. As an example, we present how a CCR-file

can be transformed into RDF/XML-format (RDF,

2004). The gain of using RDF/XML-format is that

we can store the data in a knowledge base which

provides powerful querying facilities on PHRs. This

in turn increases the efficient and reliable use of the

PHRs.

The rest of the paper is organized as follows.

First, in Section 2, we give an overview of an

electronic prescription process in which prescription

writer application interacts with other health care

applications. Then we illustrate how BPMN can be

used in modelling the coordination of electronic

prescription processes. In Section 3 we present the

service oriented architecture where EPW takes

place. In Section 4 we consider the representation

formats of the delivered medicinal and give an

example of transforming a CCR-file into RDF. The

gains of using RDF-formatted PHRs are analyzed in

Section 5. Finally Section 6 concludes the paper by

discussing the weaknesses and advantages of our

developed solutions.

2 e-PRESCRIPTION PROCESS

2.1 Constructing e-Prescriptions

In our used model, in prescribing medication the

physician uses an EPW. The prescribing process

goes as follows: First the physician request from the

patient whether the patient have a PHR, and whether

the data of the new prescription should be stored in

patient’s PHR. In the case positive attitude the

physician delivers that information to EPW. If the

EPW do not have information about patient’s PHR

then such information is requested from the patient

and then delivered to the EPW.

In prescribing the actual medication the EPW

used by the physician may interact with many other

health care systems in constructing the prescription.

For example, the EPW may query previous

prescriptions of the patient from the prescription

holding store and from patients PHR (in the case of

authorized by the patient). The EPW may also query

patient’s records from other health care systems.

Once the physician has constructed the

prescription the EPW sends the prescription to the

medical expert system which checks (in the case of

multi drug treatment) whether the prescribed drugs

have mutual negative effects, and whether they have

negative effects with other ongoing medical

treatment of the patient. Then the EPW sends the

prescription to a medical database system, which

checks whether the dose is appropriate. The medical

database may also provide drug-specific patient

education in multiple languages. It may include

information about proper usage of the drug,

warnings and precautions, and it can be printed to

HEALTHINF 2010 - International Conference on Health Informatics

136

the patient. Then the EPW sends the prescription to

a pricing system, which checks whether some of the

drugs can be changed to a cheaper drug.

Once the checks and possible changes have been

done the physician signs the prescription

electronically. Then the prescription is encrypted

and sent to an electronic prescription holding store.

The patient is usually allowed to take the

prescription from any pharmacy in the country. At

the pharmacy the patient gives the prescription to the

pharmacist. The pharmacist will then request the

electronic prescription from the electronic

prescription holding store. After this the pharmacist

will dispense the drugs to the patient and generates

an electronic dispensation note. Finally they

electronically sign the dispensation note and send it

back to the electronic prescription holding store.

Hence the dispensation of the e-prescription is also

stored in the prescription holding store.

2.2 Modelling e-Prescription Processes

Now we illustrate how the coordination of the

interoperability required by electronic prescription

systems can be automated by utilizing XML-based

languages. In particular we show how the Business

Process Modeling Notation (BPMN) (BPMN, 2005)

and Web Services Business Process Execution

Language (WS-BPEL) (WS-BPEL, 2007) can be

used for automating the coordination of electronic

prescription processes.

The reason for using BPMN is that the BPMN

notation is readily understandable for the employees

of the health care sector. It is also readily

understandable for the business analyst that create

the drafts of health care processes as well as for the

technical developers responsible for implementing

the technology that will perform those processes. In

addition, a notable gain of BPMN specification is

that it can be used for generating executable WS-

BPEL code.

BPMN provides a graphical notation for

specifying business processes in a Business Process

Diagram (BPD), based on a flowcharting technique

very similar to activity diagrams from Unified

Modeling Language (UML).

In BPD there are tree Flow Objects: Event,

Activity and Gateway: An Event is represented by a

circle and it represents something that happens

during the business process, and usually has a cause

or impact. An Activity is represented by a rounded

corner rectangle and it is a generic term for a work

that is performed in companies. A Gateway is

represented by a diamond shape, and it is used for

controlling the divergence and convergence of

sequence flow. In BPD a Sequence Flow is

represented by a solid line with a solid arrowhead.

In Figure 1 we have presented how the process

of producing electronic prescription (described in

Section 2.1) can be represented by a BPD.

Construct apre scription

Check negative effectsSe nd toe xpert database system

Yes

Che c k thedose

Che c k thepr ice s

Se nd tomedical datab as e sys tem

Yes

Sign th e  pr escription

Se nd the prescription to p re s cription ho ldin gstore

Chec k thePHRSe nd thepre scr iption to PHRsyste m

Yes

Figure 1: A prescription process presented by a BPD.

3 EXECUTING

e-PRESCRIPTION PROCESS

Web Services Business Process Execution Language

(WS-BPEL) is an XML based programming

language to describe high level business processes

(WS-BPEL, 2007). A 'business process' is a term

used to describe the interaction between two

businesses or two elements in some business. An

example of this might be an EPW system requesting

from the expert database system whether two drugs

have negative mutual effects. WS-BPEL allows this

interaction to be described easily and thoroughly

such that the expert database system can provide a

Web Service and the EPW can use it.

In terms of WS-BPEL, the term 'Web Service'

means something with which one can interact (Singh

and Huhns, 2005). For example, in our prescribed e-

prescription process there are web services that are

interacted to get information whether there are

substitutable drugs having lower prices.

The interactions of web services are described

from architectural point of view in Figure 2.

AUTOMATING THE IMPORTATION OF MEDICATION DATA INTO PERSONAL HEALTH RECORDS

137

Electronic Prescription Writer

(WS-BPEL engine)

Expert

database

system

Medical

database

system

Prescription

holding store

Prescription

pricing

authority

PHR

system

WS-interface WS-interfaceWS-interface WS-interface WS-interface

WS-interface

Physician

Internet / SOAP-messages

Figure 2: The interoperation of the EPW.

The EPW (WS-BPEL engine) loads WS-BPEL

specifications and then runs the prescription process.

A nice feature of WS-BPEL engines is that they

itself are also web services. Hence the physician

interacts with the web service interface of the EPW.

The EPW communicates with other systems by

using the SOAP protocol (SOAP, 2009), which was

originally intended to provide networked computers

with remote-procedure call services written in XML.

It has since become a simple protocol for

exchanging XML-messages over the Web.

A SOAP-message is comprised of a SOAP

header, SOAP envelope and SOAP body (Singh and

Huhns, 2005). In particular, the SOAP body contains

the application-specific message that the backend

application will understand. As illustrated in Figure

3, we incorporate our used CCR-formatted

medicinal documents in the SOAP body.

HTTP Header

SOAP Envelope

SO AP Header

Headers

SOAP Body

CCR-formatted PHR-element

Figure 3: A CCR-formatted PHR-element in a SOAP-

message.

4 REPRESENTATION FORMATS

4.1 Transforming PHR-formats

In order that the medicinal information systems are

able to handle the XML-elements of the SOAP-

messages they have to use the DOM-parser and the

Stylesheet engine. The DOM parser (Daconta et al.,

2003) transforms input text (i.e., CCR-elements) into

a tree, which is suitable for the Stylesheet engine to

process.

The term DOM (Document Object Model)

(Daconta et al., 2003) refers to a language-neutral

data model and application programming interface

(API) for programmatic access and manipulation of

XML-coded data. Generally, parsing (also called

syntactic analysis) is the process of analyzing a

sequence of tokens to determine its grammatical

structure with respect to a given formal grammar.

As illustrated in Figure 4, the Stylesheet engine

takes the CCR-formatted XML-document from the

DOM-parser, loads it into a DOM source tree, and

picks out the needed information in transforming the

XML-document with the instructions given in the

local (PHR-specific) stylesheet.

Stylesheet engine

P H R in a lo c a l fo rm a t

Local Stylesheet

CCR-form atted

PHR in a tree

fo rm

PHR in CCR-format

DOM -parser

PHR system

W eb service

SOAP-m essage in XM L

Figure 4: Transforming the representation format of a

CCR file.

4.2 Transforming a CCR-file into RDF

The CCR standard is an ANSI-accredited health

information technology standard, which is published

in 2006. Though it is proposed for PHRs its original

purpose is to enable the creation, storing and

exchange (between computer systems) of digital

summaries of individuals’ administrative and

clinical health information.

A CCR-file is comprised of seventeen sections. It

is not intended to capture individuals’ all past

medical history but instead to summarize

information that will be most useful in individual’s

medical encounter with a new or unfamiliar

provider.

The sections of the CCR standard include for

example patient demographics, insurance

information, immunizations, allergies, diagnoses,

HEALTHINF 2010 - International Conference on Health Informatics

138

procedures and medication list. Each section

contains elements that can represent free text or

structured XML-coded text. The content of each

CCR file is captured from various sources such as

from hospital information system, a clinical

laboratory, from a pharmacy or from the patient him

or herself. In order to know who or what

organization is the source of each element in a CCR

file each data element is time and source stamped.

A simplified example of a CCR file is presented

in Figure 5. It represents a CCR file that has a

medication list (element Medications) which is

comprised of one medication (element Medication)

that is source stamped by the Pharmacy of

Kaivopuisto.

<Patient><ActorID>Person.12345></ActorID></Patient>

Medication567

</CCRDataObjectID>

2009-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>

</ContinityOfCareRecord>

Figure 5: An element of a CCR file.

In order to illustrate the transformation of CCR

files into RDF, the CCR file of Figure 5 is presented

in RDF/XML format in Figure 6.

<rdf:RDF

xmlns : rdf=

”http://www.w3.org/1999/02/22-rdf-syntax-ns#”

xmlns : xsd=”http://www.w3.org/2001/XMLSchema#”

xmlns : po=http://www.lut.fi/ontologies/p-ontology#>

<rdf:Description rdf:about=”120962-K3”>

<rdf:type rdf:resource=“&po;Patient”/>

<po : PatientName>Lisa Smith</po : PatientName>

</rdf : Description>

<rdf:Description rdf:about=” MO-5481”>

<rdf:type rdf:resource=“&po;Medication”/>

<po : Contains>Voltaren</po : Contains>

<po : StrenghtValue rdf:datatype=

”&xsd;integer”>30</po : StrenghtValue>

</rdf : Description>

<rdf:Description rdf:about=” 211708-8”>

<rdf:type rdf:resource=“&po;Source/>

<po : ActorRole>Pharmacy</po : ActorRole>

</rdf : Description>

<rdf:Description rdf:about=” Voltaren”>

<rdf:type rdf:resource=“&po;ProductName”/>

<po : BrandName>Diclofenac</po : Contains>

</rdf : Description>

</rdf:RDF>

Figure 6: A PHR in RDF/XML format.

5 THE GAINS OF USING RDF IN

PERSONAL HEALTH RECORD

We have investigated the use cases of PHRs. It is

turned out that patients are not only interested about

single documents such as the content of the previous

prescription but most of the searches or queries

require computing over many documents. For

example, a patient may be interested to know the

average blood pressure and/or blood sugar

concentration (glucose level) during the time periods

he or she was using Diovan (a drug for blood

pressure), or the patient may be interested to know

the cholesterol values when he or she was on a diet.

Unfortunately the computation required by such

data centric queries is not supported by the query

languages (e.g., XPath (XPath, 2008) and XQuery

(Xquery, 2008) that are designed to address XML-

documents. The problem here is that the CCR- (as

well as the CCD-based) PHRs are XML-documents

that can only be accessed by the query languages

developed for XML-documents.

This is the reason why we have developed PHRs,

which content is structured according to an

ontology, and which thereby allow a wide variety of

data centric searches and queries. In particular, we

have used OWL (Web Ontology Language) (OWL,

2006) in designing the PHR-ontology. The instances

AUTOMATING THE IMPORTATION OF MEDICATION DATA INTO PERSONAL HEALTH RECORDS

139

of the ontology are presented in RDF. Hence, for

example the RDF-formatted PHR element of Figure

6 can be stored in an ontology based PHR system.

Fundamentally, the purpose of the PHR-ontology

is to describe the concepts of the domain in which

PHRs take place. Hence, a PHR-ontology describes

the concepts (as well as their relationships) such as

demographics, insurance information,

immunizations, allergies, diagnoses, procedures and

medication.

In developing the PHR-ontology we have

exploited the XML-schema of the CCR file. In

transforming the XML schema to OWL-ontology we

have used on the whole the following rules:

• Complex elements are transformed to

OWL classes.

• Simple elements are transformed to

OWL data properties.

• Element-attribute relationships are

transformed to OWL data properties.

• The relationships between complex

elements are transformed to class-to-

class relationships (object properties).

To illustrate this kind of transformation, a simple

PHR-ontology is presented in Figure 7. In this

graphical representation ellipses represent classes,

and rectangles represent data and object properties.

Patient

Me di c ati on

Product

ProductN am e BrandN am eStrenghtU nit

Source

ActorIDActorRole

PatientId

PatientN am e

Uses

Contains

StrenghtValue

O rig in at es

Medi c ati onId

Figure 7: A simple PHR-ontology in a graphical form.

6 CONCLUSIONS

It is obvious that in the near future PHRs have the

potential to dramatically change healthcare. They

will enable consumer to become more involved and

engaged in their care, and allow other authorized

stakeholders to access information about consumer

that has not been previously been available or

difficult to access electronically. The change that

can be caused by the deployment of PHR systems

could have a significant impact on the efficiency of

administrative and clinical process within healthcare

sector, and thus will give rise for considerable cost

savings.

However, the extensive exploitation of PHRs

requires that (i) PHRs are exhaustive in the sense

that they contain all the relevant documents, and that

(ii) PHR systems support appropriate use cases such

as data centric queries.

Our argument is that the exhaustive medicinal

history can be captured in PHRs only if we can

automate the importation of relevant documents into

PHRs. As we have presented, one way of doing that

with respect to e-prescriptions is to extend the EPWs

by exporting the prescriptions into PHRs. Further, in

order to support appropriate use cases, we can

implement the PHR system as an application of a

knowledge base or a database system.

The importation of e-prescriptions into PHRs is

rather straightforward if the EPW exploits service

oriented architecture. In particular, if the EPW is

based WS-BPEL then the required modifications can

be done by just inserting appropriate operations in

the WS-BPEL code.

In order to support a wide variety of queries on

PHRs we have analyzed PHRs, which data is

structured according to an PHR ontology. Importing

data from XML-based data sources (e.g., HL7 CDA

compliant systems) to such PHR system requires

that the XML documents are first transformed by a

style sheet engine to RDF/XML format and then

inserted to the PHR.

We will emphasize that using a PHR should not

be an end in itself: if the PHR captures information

that is imported at random, then the use of the PHR

in healthcare may be a risk. Developing and

maintaining a reliable and exhaustive PHR requires

considerable efforts in developing health care

systems interoperability.

The deployment of a reliable PHR system is also

an investment. The investment includes a variety of

costs including software, hardware and training

costs. Introducing and training the staff on new

technology is a notable investment, and hence many

organizations like to cut on this cost as much as

possible. However, the incorrect usage and

implementation of a new technology, due to lack of

proper training, might turn out to be a risk of

healthcare.

HEALTHINF 2010 - International Conference on Health Informatics

140

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.

Batenburg, R., Van den Broek, E., 2008. Pharmacy

information systems: the experience and user

satisfaction within a chain of Dutch pharmacies,

International Journal of Electronic Healthcare. Vol. 4,

No.2 pp.119-131.

BPMN, 2005. Business Process Modeling Notation

(BPMN), Available at: http://www.bpmn.org/

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, 2009. Continuity of Care Record (CCR) Standard.

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

Daconta, M., Obrst, L., Smith, K. (2003) The semantic

web. Indianapolis: John Wiley & Sons.

Dolin, R. H., Alschuler; L., Beerb, C., Biron, P. V.,

Boyer, S- L, Essin, D., Kimber, E., Lincoln, T., and

Mattison, J-E., 2001. The HL7 Clinical Document

Architecture. J. Am Med Inform Assoc (6). pp 552-

569.

Dwivedi, A., Bali, R.K., Wickramasinghe, N., Naguib,

R., 2007. How workflow management systems enable

the achievement of value driven healthcare delivery.

International Journal of Electronic Healthcare, Vol. 3,

No.3 pp.382-393.

EHR, 2009, Electronic Health Record, Available at:

http://en.wikipedia.org/wiki/Electronic_health_record.

Ghani, M., Bali, R.K., Naguib, R., Marshall, I.M.,

Wickramasinghe, N.S., 2008. Electronic health

records approaches and challenges: a comparison

between Malaysia and four East Asian countries,

International Journal of Electronic Healthcare,Vol. 4,

No.1 pp.78-104-77.

Kaelber, D. Jha, A. Johnston, D. Middleton, B.and Bates,

D., 2008. A Research Agenda for Personal Health

Records (PHRs), J. Am. Med. Inform. Assoc.,

November 1,15(6). pp. 729 - 736.

Lewis, D, Eysenbach. G., Kukafka, R., Stavri P.Z., and

Jimison, H., 2005. Consumer health informatics:

informing consumers and improving health care. New

York: Springer.

Hyppönen, H., Salmivalli, L., Suomi, R.,2005. Organizing

for a National Infrastructure: The Case of the Finnish

Electronic Prescription. In Proc. of the 38th Hawaii

International Conference on System Sciences.

OWL, 2006. Web OntologyLanguage.

http://www.w3.org/TR/owl-ref/

Puustjärvi, J., Puustjärvi, L. ,2006. The challenges of

electronic prescription systems based on semantic web

technologies. In Proc. of the 1st European Conference

on eHealth, pp. 251-261.

Raisinghani. M.S. and Young, E., 2008. Personal health

records: key adoption issues and implications for

management, International Journal of Electronic

Healthcare. Vol. 4, No.1 pp.67-77.

RDF, 2004, Resource Description Framework (RDF).

Available at: http://www.w3.org/RDF/

Singh, M. and Huhns, M. (2005) Service Oriented

Computing: Semantics Proceses Agents. John Wiley &

Sons.

SOAP, 2009. SOAP. Available at:

http://en.wikipedia.org/wiki/SOAP.

Tuil, W. S., Hoopen, A. J., Braat, D. D. M., Vries Robbe,

P.F., and Kremer J. A. M., 2006. Patient-centred care:

using online personal medical records in IVF practice,

Hum. Reprod., November 1, 21(11). pp. 2955 - 2959.

WS-BPEL, 2007. Web Services Business Process

Execution Language (WS-BPEL) Available at:

http://docs.oasis-open.org/wsbpel/2.0/varprop.

XPath, 2008. XML Path Language (XPath). Available at:

http://www.w3.org/TR/xpath.

Xquery, 2008. XQuery 1.0: An XML Query Language.

Available at: http://www.w3.org/TR/xquery/.

AUTOMATING THE IMPORTATION OF MEDICATION DATA INTO PERSONAL HEALTH RECORDS

141