Clinical Decision Support Rules in an Archetype-BasedHealth Record System

Combining Archetype Query Language (AQL) and Semantic Web RuleLanguage (SWRL)

Herman Viklund & Hanna Karlsson

LiTH-IMT/MI30-A-EX--09/477--SE

Linköping 2009

Clinical Decision Support Rules in an Archetype-BasedHealth Record System

Combining Archetype Query Language (AQL) and Semantic Web RuleLanguage (SWRL)

Examensarbete utfört i medicinsk informatikvid Tekniska högskolan i Linköping

av

Herman Viklund & Hanna Karlsson

LiTH-IMT/MI30-A-EX--09/477--SE

Handledare: Erik SundvallInstitutionen för medicinsk teknik, Linköpings universitet

Mikael NyströmInstitutionen för medicinsk teknik, Linköpings universitet

Examinator: Håkan PeterssonInstitutionen för medicinsk teknik, Linköpings universitet

Linköping, 20 februari , 2009

AbstractBy using archetypes, it is possible to define how data are stored in the EHR,which facilitates querying for data.

The objective of this thesis is to investigate the possibility of connecting a deci-sion support system to archetype-based medical records by using the ArchetypeQuery Language (AQL) and the Semantic Web Rule Language (SWRL).

The result shows that, since SWRL is a logic language rather than a program-ming language, built-ins are necessary to allow SWRL rules to function as pro-gramming rules. Built-ins are SWRL modules that can be written in e.g. Java,which allows complex functions to be created.

The conclusion is that built-ins can be used to connect archetypes and SWRLrules by querying the archetype path with AQL. There are however several ruledesign factors to consider when using SWRL e.g. data location problems.

SammanfattningGenom att använda arketyper så kan man definiera hur data lagras i den elek-troniska journalen, vilket underlättar åtkomst av data.

Syftet med examensarbetet är att undersöka möjligheten att koppla ett beslut-stödssystem till arketypbaserade journaler med hjälp av Archetype Query Lan-guage (AQL) och Semantic Web Rule Language (SWRL).

Resultatet visar på att built-ins behövs, eftersom SWRL är ett språk för logikoch inte ett programmeringsspråk. Dessa gör att SWRL-regler kan fungera somprogrammeringsregler. Built-ins är SWRL-moduler som kan skrivas i t.ex. Javavilket ger möjlighet att skapa komplexa funktioner.

Slutsatsen är att built-ins kan fungera som en länk mellan arketyper och SWRLgenom en förfrågan i arketypsökvägen med hjälp av AQL. Det finns dock fleraregeldesignfaktorer att beakta vid användandet av SWRL t.ex. datalokaliser-ingsproblem.

Acknowledgments

Thanks to Magne Rekdal for help with interpretation of decision rules to pro-gramming rules.

We would also like to thank Erik Sundvall, Mikael Nyström and Håkan Pe-tersson for the support during the work process.

For allowing us to access their database, we would like to thank Ocean Infor-matics.

Contents

1 Introduction 11.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 52.1 Diabetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 What is diabetes? . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Guidelines to support health care . . . . . . . . . . . . . . . 6

2.2 Decision Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Historical background and introduction to Clinical Deci-

sion Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Arden Syntax: a rule language for decision support . . . . . 9

2.3 Electronic Health Records . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1 What is an ontology? . . . . . . . . . . . . . . . . . . . . . . . 142.4.2 The Semantic Web Rule Language - a language for ontol-

ogy rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.3 Terminology in health care . . . . . . . . . . . . . . . . . . . 17

2.5 openEHR archetypes . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.1 The openEHR foundation . . . . . . . . . . . . . . . . . . . . 192.5.2 Structured information in the EHR . . . . . . . . . . . . . . 192.5.3 Paths in archetypes . . . . . . . . . . . . . . . . . . . . . . . . 212.5.4 Archetype Query Language - a query language for archetypes 22

3 Method 253.1 Decision rule implementation . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Selection of decision rules . . . . . . . . . . . . . . . . . . . . 253.1.2 Design of decision rules . . . . . . . . . . . . . . . . . . . . . 26

3.2 SWRL rule implementation . . . . . . . . . . . . . . . . . . . . . . . 273.2.1 Design of SWRL rules . . . . . . . . . . . . . . . . . . . . . . 27

Contents

3.2.2 Data retrieval from EHRs . . . . . . . . . . . . . . . . . . . . 273.2.3 Transfer of data between AQL and SWRL . . . . . . . . . . 28

4 Results 31

5 Discussion 355.1 Aspects on Arden Syntax and SWRL . . . . . . . . . . . . . . . . . . 35

5.1.1 Result presentation . . . . . . . . . . . . . . . . . . . . . . . . 355.1.2 Data retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.3 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 SWRL rule design factors . . . . . . . . . . . . . . . . . . . . . . . . 385.2.1 The missing data problem . . . . . . . . . . . . . . . . . . . . 385.2.2 Creating OWL individuals . . . . . . . . . . . . . . . . . . . 39

5.3 Demands on the Archetype Query Language . . . . . . . . . . . . . 395.3.1 Operators for improved functionality . . . . . . . . . . . . . 405.3.2 Functions for the future . . . . . . . . . . . . . . . . . . . . . 42

5.4 Using SNOMED CT in SWRL rules . . . . . . . . . . . . . . . . . . 435.5 Efficiently using located data . . . . . . . . . . . . . . . . . . . . . . 43

5.5.1 Data filtering in the SWRL rule or in the AQL query? . . . 445.5.2 Data dictionary - separating medical rules and data-mining

rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.7 Further development . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Conclusion 49

Bibliography 51

A XML responses 55

Glossary

Archetype "a computable expression of a domain content model in the formof structured constraint statements, based on a reference (information)model" [1]

Decision rule in this thesis is refered to as a collection of procedural rules fordecision support based on guidelines and observations

Guideline provides evidence-based advice and support for clinicians to im-prove health care [2]

Ontology defines the underlying rules for creating a model of a domain [3]

openEHR develops open specifications and open-source software for electronichealth records [4]

Semantic web "provides a common framework that allows data to be sharedand reused across application, enterprise, and community boundaries" [5]

SNOMED CT a terminology system for clinical use [6]

Template "a directly locally usable definition which composes archetypes into alarger structures" [1]

Terminology "a set of terms representing the system of concepts of a particularsubject field" [7]

Xpath "XML Path Language is a language for addressing parts of an XML doc-ument" [8]

Abbreviations

ADL Archetype Definition Language

AQL Archetype Query Language

CDS Clinical Decision Support

CDSS Clinical Decision Support System

DD Data Dictionary

EHR Electronic Health Record

HL7 Health Level 7

MLM Medical Logic Module

OWL Web Ontology Language

RIM Reference Information Model

SWRL Semantic Web Rule Language

XML eXtensible Markup Language

Chapter 1

Introduction

This report discusses how to connect Electronic Health Records (EHRs) with adecision support system. The data structure in the EHR is defined by archetypes.With the Archetype Query Language (AQL), information is extracted from theEHR. The decision rules are written in the Semantic Web Rule Language (SWRL).

1.1 Context

That there are advantages with electronic health records compared to paper-based dittos is probably a general consensus. A computerized record is easier toshare and to keep updated [9]. Transfer to another location is faster than havingto send paper-based versions by mail. A computer does not, however, have thesame capabilities as a human to interpret information. Whereas a human caneasily interpret and extract information from a medical record in a narrativeformat, the computer needs structured data to be efficient and make use of thatinformation [10].

To share information between institutions, it does not suffice with just structure[7]. Although structure is a key component for computer processing of the data,the structure is of little use if the information is to be passed along to anotherlocation that has an incompatible structure. As many other fields are globalized,so is the medical and sharing information becomes a larger demand as timepasses.

Sharing EHRs is important to avoid medical errors [11]. If a record is unavail-able to the physician, he must rely on the information described by the visitingpatient: current medications, previous surgeries, allergies, etc. According to a

1

2 Introduction

national study from 2008 made by the Swedish Board of Health and Welfare [12],more than 100 000 people are injured every year in Sweden due to the health careand medical errors. Several injuries are caused by mistakes as well as wrong ormissing information, especially in diagnosis and medical treatments [12].

A prerequisite to share information is consensus between the related parts thatthe information shared has the same meaning at both locations [7]. Anotherfactor is how information is stored. For this purpose archetypes [1] has beendeveloped by the openEHR foundation [4]. Archetypes are used to define thedata structure the EHR [1]. With archetypes, the electronic health record reachesa structure that is understandable to a computer and makes it possible to queryfor data. Archetypes can be structured with templates to customize data entryat a local level, yet maintaining the general model that allows transfer betweeninstitutions [1]. The information can be shared even though the same templatesare not used, as long as the archetypes are. Archetypes in this report will refer toarchetypes specified by openEHR. There are, however, several other standardsfor exchanging medical records, for example Health Level 7 (HL7).

Having the correct information about a patient is one factor in avoiding medicalerrors. Another is having correct information regarding what to do. To addressthis issue, clinical decision support (CDS) has evolved [13]. A clinical decisionsupport system (CDSS) can aid the clinician in a variety of ways. The systemmay alert for abnormal lab values, incorrect drug dosages or send a warning ifa prescribed drug conflicts with one already in use [13].

Linking the decision support system to the EHR enables various decision sup-port actions, such as alerts and suggestions, to be triggered by data entry in thehealth record. However, the efficiency of the integration is often low [14]. In thisreport, the possibility of connecting EHRs in an archetyped format with decisionrules in the Semantic Web Rule Language (SWRL) with the use of the ArchetypeQuery Language (AQL), will be investigated.

1.2 Objective

The objective of this thesis is to investigate the possibility of connecting archetype-based EHRs with a decision support system using Archetype Query Language(AQL) and Semantic Web Rule Language (SWRL).

1.3 Problem description 3

1.3 Problem description

Knowledge about the data location in the EHR is necessary to be able to usethe data in a decision support system. Using archetypes and templates whenwriting data into the patient record is one way to approach the problem.

A decision support system can be a number of rules based on guidelines andcare plans. A rule could serve as a reminder for the care practitioner e.g. aremainder that the time passed since the last visit is too long according to thecare plan. It could also be used to found a summary over a patient before a visitor extract information to form statistics. The purpose of these rules is to assistthe physician in decisions to make the work more efficient by providing usefulinformation.

1.4 Method

In our case the decision support system consists of a number of rules, createdto illustrate the syntax and expressiveness in SWRL. The rules are chosen withregard to clinical practice [15] as well as to an engineer’s point of view. Therules combined with a study of the literature covering the related areas, namelydecision support, ontologies and EHRs, served as the foundation on which webased our conclusions and results of the thesis.

The Arden Syntax is studied to draw parallels to known problems such as howto extract data (the curly braces problem). It was also an inspiration for decisionrule design.

1.5 Delimitations

This thesis is theoretical rather than an implementation of a functioning system.

• No focus is on the aspect of security in transferring data between the EHRand SWRL nor on authorization for accessing data.

• Arden Syntax is theoretically studied, no actual implementation of rules inArden Syntax is done.

• A graphical user interface is not implemented.

Chapter 2

Background

2.1 Diabetes

The purpose of this section is to give some understanding of the rules chosen inchapter 3.

2.1.1 What is diabetes?

Diabetes mellitus is one of the most common diseases in the Western World [16].In the United States, it is the fourth cause of death by disease, mainly because ofcomplications in heart and blood vessels which leads to cardiovascular diseases[17].

Due to the increasing number of people having a sedentary life style combinedwith bad eating habits and obesity, type 2 diabetes has changed from previouslybeing a disease for elderly to now appear in children and teenagers [17]. Todaythere are approximately 350 000 people living with diabetes mellitus in Sweden,which is nearly 4 % of the population [16]. In the United States the numberis much higher and about 10 % of the population have the diagnose diabetesmellitus today [16].

Diabetes mellitus is a disorder when the body constantly has an elevated bloodglucose level. It is caused by a shortage or an absence of insulin, a hormone pro-duced by the pancreas which aids the transport of glucose into body cells [17].There are several different types of diabetes mellitus where the most commonones are type 1 and type 2. Another type is gestational diabetes which occursonly in pregnant women [18].

5

6 Background

In type 1 diabetes, the pancreas no longer produces insulin and it is usually de-veloped early in children and young people. The person’s own immune systemcauses a destruction of the pancreatic beta cells which leads to the lack of insulin[17]. The disease is partly hereditary and is not possible to prevent [17].

In type 2 diabetes, the pancreas still produces insulin but the target cells have losttheir sensitivity to insulin and therefore the pancreas cannot produce enough[17]. Type 2 diabetes has high heredity and there are several environmentalfactors which increase the probability for a break out. It is most common inolder people and obesity increases the risk to develop diabetes. Obesity alsomakes the disorder develop earlier than usual. Factors like smoking and stressare also significant in estimating the risk of diabetes [18]. Type 2 diabetes is themost common type of diabetes and corresponds to more than 90 % of all casesof diabetes [17].

2.1.2 Guidelines to support health care

To make sure all patients get an equivalent treatment and care, guidelines andsupport for the health staff are important [2]. The work to develop and updatethese guidelines is done continuously. According to the Dagmar agreement,which is an agreement between the state and the councils in Sweden, the dif-ferent local and regional care plans should be based on these guidelines [19].Diabetes was in 1996, the first area where national guidelines were settled [19].

According to the Dagmar agreement [2] the patient should be able to take partin the care, there should be a dialog between the health care provider and carereceiver. The patient should be allowed an active influence over his or her owntreatment plan.

The care plans for diabetes contain information on how to diagnose diabetes,treatment, risk factors and follow-up. They should work as a "manual" for thecare staff and be a support through the care.

2.1 Diabetes 7

Examples from the care plan

Example 1:

HbA1c Measure how much of the glucose in the blood that at-tach to the red blood cells. It shows an average of glucoselevel value during 6-8 weeks. It is measured in percent-age unlike the blood sugar which is measured in mmol/l.A high value of HbA1c and complications are stronglyconnected. Should be monitored at the regular checkupsat the care center.

National goal <6,5 %Acceptable 6,6-7,5%Unsatisfactory >7,5 %

The goal has to be individualized.

This is an example from the care plan for diabetes mellitus in Stockholm County[20] showing how to interpret the value of HbA1c.

Example 2:

This is an example of how a plasma glucose measurement is used to diagnosediabetes.

FASTING PLASMA GLUCOSE

capillary or venous

No symptoms

4.0 - 6.0 6.1 - 6.9 ≥7.0

Normal

Impaired

fasting

glychaemia

(IFG)

≥7.0

4.0 - 8.8 8.9 - 12.1

No action Fasting plasma

glucose x2

No symptoms

≥12.2

Fasting plasma

glucose x2

Diabetes

≥7.0 ≥7.0

Symptoms

≥12.2

Type 1 Type 2 Other

RANDOM PLASMA GLUCOSE

capillary

Figure 2.1. Example from the diabetes care plan, Västmanland County [18]. The flowchart shows how to diagnose diabetes through a plasma glucose measurement. Whenthe patient has a fasting plasma glucose value higher than 7.0 mmol/l at two occasions,the diagnose diabetes is establish [18]. Depending on whether the patient has symptomsor not the random plasma glucose measurement has different paths in the flow chart.

8 Background

2.2 Decision Support

2.2.1 Historical background and introduction to Clinical Deci-sion Support

Computer-based clinical decision support has been in use for almost half a cen-tury [13]. Its uses vary from performing small simple tasks e.g. verifying thata registered value in an electronic health record is within reasonable ranges tomore complex systems like allowing the Decision Support System (DSS) to makediagnoses based on the information from an examination [13]. Some of the earli-est systems were INTERNIST-I and MYCIN, both created in the mid 1970’s withthe intention to aid clinicians in diagnosing different diseases [21].

The successfulness of a Clinical Decision Support System (CDSS) depends ona number of factors. For example, a medical center in the United States hadto cancel a CDSS because the clinicians were so frustrated over its slowness[13]. However, not only technical obstacles and difficulties require solutions.According to a study by Sittig et al. [22] the major factors for acceptance of aCDSS were not excessive amounts of alerts and false positives but in fact patientcharacteristics and environmental factors. The clinicians were more likely to usethe decision support if the patient was elderly and less when lagging behindschedule [22].

Rule-based expert systems often use logic such as IF-THEN statements to reacha conclusion. To do this, the system can either be forward chaining or backwardchaining [23]. In MYCIN, the backward chaining method was used [24]. Back-ward chaining, also called goal-driven, starts with the goal and works its wayback in the knowledge chain. The forward chaining, or data driven, methodstarts with the known facts to reach the goal. Simply, one could say that a back-ward chaining system asks whether it should do the THEN part by checking theIF part.

Example: If y then xIn backward chaining this logic sentence would be interpreted as:Should I do x? Yes, if y is true. Whereas in forward chaining it wouldbe:Is y true? OK, then I do x.

The efficiency of the two different approaches weighs to the advantage of thebackward chaining. With the forward chaining method, every rule that con-cludes true will trigger more rules, many of which may lead to nowhere [23].Nevertheless, the choice of method depends largely on the kind of implemen-tation. In a system for patient monitoring, the forward chaining method mightbe a better choice as the CDSS evaluates the incoming data as it arrives. An

2.2 Decision Support 9

example of a rule language that uses forward chaining is the Arden Syntax [25].

2.2.2 Arden Syntax: a rule language for decision support

Created in the early 1990’s, the developers of Arden Syntax aimed to developa standard for sharing medical information [26]. The effort succeeded in 1992when the language became a standard under the American Society for Testingand Materials (ASTM) [26]. During the years that followed Arden Syntax becamefairly popular and in 1994, after having been a standard for two years, at leasteight institutions used it for their needs [26].

With its growing popularity, the standards developing organization Health Level7 (HL7) became interested and adopted the standard in 1998. Hope arose thatthis would solve the problem with data access in the Arden Syntax, the so calledcurly braces problem, by linking the data mapping in Arden Syntax with thearchitecture in the HL7 Reference Information Model (HL7 RIM) [27]. As waslater found out, this proved to be difficult. The RIM adopted an object-orientatedapproach that matched poorly with the simple data model in the Arden Syntax[28].

Medical Logic Modules

In Arden Syntax, the decision rules are written in separate modules called Med-ical Logic Modules (MLM). The MLM describes the purpose of the rule, whichdata will be used and how this data will be used [25]. This is done by dividingthe MLM into three categories; maintenance, library and knowledge. Each categorythen contains different slots [25].

The knowledge category contains the actual decision rule. In this category thereare five compulsory slots – type, data, evoke, logic and action – and two optionalslots – urgency and priority.

In the type slot is defined which other slots the knowledge category will include.The only option here is data-driven [25]. Other options are not possible but theslot exist to allow possible other slot configurations in the future [26].

The data slot is the slot where the variables that will be used in the logic slotare mapped to the data necessary to evaluate the decision rule [25]. As patientdata are stored differently in different EHRs the developers of the Arden Syntaxchose not to define how information is retrieved in the MLM [29]. It is insteadleft to the local institution to make site specific queries within two curly braces({}) in the data slot with the READ statement [30].

10 Background

The evoke slot defines the condition under which the MLM will trigger, for ex-ample storage of a laboratory test [25]. The actual rule is described in the logicslot. The rule is built-up by IF-THEN statements and return either true or false.If the logic slot returns true the action slot will trigger [25]. Evoking other MLMs,returning results to a calling MLM or sending a message are typical actions thatcan be performed in the action slot [25]. Messages are sent with the WRITEstatement. As is the case with READ statement in the data slot, the destinationfor the message is specific to the current institution and specified within twocurly braces.

As mentioned earlier, the knowledge category is the main category for the exe-cution of the rule but the remaining two are important as well. The maintenancecategory includes information about the MLM, such as the author of the MLM,the date that it was created, at which institution it was made, etc. These slotscould be of interest but are not actually related to the decision support [25]. Thelast category is the library category. The slots in this section state the purposeof the MLM, lists keywords, a short explanation of the MLM and include anoptional slot for citations [25].

2.2 Decision Support 11

Example of an MLM:

maintenance:title: Check BMI level;;filename: bmi;;version: 1.00;;institution: Department of Biomedical Engineering, LinköpingsUniversitet, Sweden;;author: Herman Viklund and Hanna Karlsson;;specialist: ;;date: 2008-12-18;;validation: testing;;

library:purpose: Check whether BMI exceeds value for over-weight/obesity.;;explanation: When the BMI value is stored, the MLM is in-voked. The MLM gives an alert if the value is above thresholdlevel.;;keywords: BMI;;citations: ;;

knowledge:type: data-driven;;data:

bmi := READ LAST {SELECT magnitudeFROM result WHERE value = ’BMI’};bmi_storage := event {storage of bmi};threshold := 25;

evoke: bmi_storage;;logic:

if bmi > threshold thenif bmi > (threshold+5) then

label := "obese";else

label := "overweight";conclude true;

endif;action:

write: "Patient is " || label;;urgency: ;;

end:

This example shows a Medical Logic Module. The maintenance category in-cludes information about the author and file name, etc. The library categorydefines the purpose of the MLM and explains how the decision rule works. In

12 Background

the knowledge category the BMI value from the patient’s health record is re-trieved and stored in a variable. If that variable exceeds a threshold value, amessage is stored in another variable. At the end of the rule, depending on ifthe value was above the threshold or not, a message is printed.

Data access in the MLM

As the database model in which the information in the electronic health recordis stored differs between institutions, there is no standard for how to queryinformation from the database of the EHR in the Arden Syntax [30]. The methodfor data retrieval in the Arden Syntax is written by the author of the MLM withintwo curly braces ({}) specifically for the IT-structure of the institution. The resultof the query is stored in a variable that can be used later to evaluate the rule.

Avoiding having to write the whole query syntax within the curly braces in thedata slot, a data dictionary (DD) can be used [30]. The data dictionary definesthe query paths and terms for the specific variable. By using a data dictionarythe clinical part of the rules is separated from the technical part. The author ofthe MLM need only to decide which data he wants to use, not how to retrieve it[30].

To access the data, the author of the medical rule types the DD code of thespecific item he or she wants to use in the rule within the curly braces in thedata slot. For example, if the author needs the systolic blood pressure, he wouldwrite

systolic_blood_pressure = READ LAST {"S_BP"}

where systolic_blood_pressure would be the variable name to use later in thelogic slot and S_BP the data dictionary code. The DD code is linked to a querysyntax in a meta database and maintained by a database administrator [30].

2.3 Electronic Health Records

The purpose and structure of Electronic Health Records

A patient record contains information about the health of the patient, previousdiseases and the reason for the visits. It is often complemented with other typeof data e.g. X-rays or laboratory tests, but the major part of the informationis textual information and could therefore be transformed to a computer-basedpatient record [9].

2.3 Electronic Health Records 13

The main purpose of patient records is to aid and improve the health care, buttoday many other purposes have arisen which puts higher demands on the struc-ture and the content of a patient record.

According to van Bemmel and Musen [9] a patient record has to support

• Patient care - for information and to be used in decision making

• Legal issues - to trace medical actions in the care

• Research - it has to be possible to track diseases, see changes and develop-ment, compare symptoms and patients

• Education - to have medical records in education

• Management - support planning and management

which contributes to the need for a computer-based patient record.

Today the medical knowledge is enormous which makes it hard to grasp withoutthe aid from a computer. The development has made the health care furtherspecialized and several physicians now have a part in the care of the patient [9].To use just one medical record for a patient causes many problems in the transferof the record and has resulted in that every specialized clinician keeps his or herown record over the patient. To form a complete picture of the medical historyof the patient, information needs to be gathered from different physicians andoften also from different places [9]. With a paper-based record this becomes evenmore complicated since a paper-based medical record can only be at one placeat a time. Moreover, handwritings can be impossible to interpret and differentclinicians can have different terminologies and abbreviations not understood byothers. One of the greatest advantages when using electronic health records isthe increasing accessibility, not just in one hospital but through the whole careprocess [10]. It also contributes to a greater understanding and could have anactive part in the care through a decision support system or as the foundationfor reminders and warning [9].

The structure of the medical record varies, there are e.g. time-oriented, source-oriented and problem-oriented records. In a time-oriented record every event is orga-nized in a chronological order [9]. A source-oriented record is structured accordingto the origin of the information and a problem-oriented record uses the SOAP struc-ture i.e. Subjective, Objective, Assessment and Plan, for every medical problemthe patient has [9]. Usually an EHR has a mixture of all these structures [9].

When writing information in an EHR, data could be written in free text formas well as in coded form, or in a combination of both [10]. Coded data makesit easier for a computer to analyze and retrieve information. Coding is alsonecessary when using a decision support systems [31]. On the other hand, in

14 Background

a free text form a clinician could usually be more nuanced in their descriptions[9].

Standardization is used to form rules that facilitates working with the samethings or processes by different people [7]. A standardized EHR could aid wheninformation about the patient is located in different systems who needs to coop-erate to form a complete picture of the patient [7]. Standardized terminologiesmake sure that the interpretation of a concept is the same among different physi-cians [7].

Health care consists of several facilities that work more or less independent ofeach other and to make it possible to share data and information among them,some common form of standardization is necessary [7]. During his or her life-time, a patient visits numerous different general practitioners and other spe-cialists with limited communication between them which could make the careineffective and incomplete [7]. Preferably, information about the patient or anelectronic health record should follow the patient through the care to create acomplete medical history at every single occasion for care [10].

2.4 Ontologies

2.4.1 What is an ontology?

In computer science, the word ontology differs slightly from the philosophicalmeaning, which according to Encyclopaedia Brittanica [32], is the the study ofbeing. There is no general definition, but one that has been widely accepted isby Thomas Gruber [3]:

an explicit specification of a conceptualization.

In other words, ontologies in computer science defines the underlying rules forcreating a model of a domain. As for the philosophical ontology, these rules canbe used to define the existing concepts and relations between objects.

The basic building blocks in an ontology are classes, individuals (or instances),relationships and properties [3]. An ontology can be viewed as a hierarchicaltree where the individuals are the leaf nodes, representing single objects. Anindividual is part of a class and inherits the properties of the class. The classmay itself also be part of another class. If a class is a subclass to another class,the individual of the subclass will inherit all the properties of the superclass aswell. An illustration of this can be seen in figure 2.2.

2.4 Ontologies 15

CLASS_1

Property_1Property_2

SUBCLASS_1

Property_3Property_4Property_5

SUBCLASS_2

Property_6

INDIVIDUAL_1Property_1Property_2Property_3Property_4Property_5

INDIVIDUAL_2Property_1Property_2Property_6

is_ais_a

instance_ofinstance_of

INDIVIDUAL_3Property_1Property_2Property_6

instance_of

Figure 2.2. Ontology classes and individuals. The figure depicts how individuals in-herits properties from classes. An individual has the properties from its class as well asits superclass(es). In this figure, the individual individual_2 has the properties from sub-class_2 and those inherited from class_1. A class may contain several individuals, whichis illustrated by individual_2 and individual_3 under subclass_2

2.4.2 The Semantic Web Rule Language - a language for ontol-ogy rules

There are a number of different languages to represent ontologies in variousenvironments and applications. One of them is the Web Ontology Language(OWL) [33]. OWL is a language recommended by the World Wide Web Con-sortium (W3C) to represent and model ontologies on the web [33]. The ratio-nale behind OWL is to have an ontology language that can be used to presenthuman-readable information as well as allowing computerized processing of theinformation represented [33].

Based on OWL, the Semantic Web Rule Language (SWRL) [34] is a language forcreating rules in an ontology. The rules can be used to classify or define relationsbetween objects. SWRL is a logic language and as such, its intended use is toinfer knowledge based on logic. One field of application is diagnosis of diseasesbased on symptoms. If certain symptoms are present, the SWRL rule will inferthe knowledge that the patient suffers from that disease. One area of applicationis electrocardiogram (ECG) diagnosis as depicted in figure 2.3 from an exampleby van Bemmel and Musen [35].

16 Background

LogicalVariable Logical Expression E1 All RR intervals are regularE2 All QRS complexes are identicalE3 QRS durations are longer than 120 msecE4 The heart rate is higher than 100 beats/minE5 P waves are presentE6 The heart rate is lower than 40 beats / minE7 Negative P in II and positive P in aVRE8 No. of P waves / No. of QRS complexes < 1.1E9 No. of P waves / No. of QRS complexes > 1.1E10 PR intervals regularE11 PR interval > 200 msE12 P waves present in leads other than II and aVR

Table 1

Rule E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E12 Diagnostic expressions 1 T T T T F d d d d d d d Ventricular tachycardia2 T T T F d T d d d d d d Idioventricular rhythm3 T T F d F d d d d d d F Nodal rhythm4 T T F d T d T d d d d d Nodal rhythm5 T T F d T d F T d d d d First-degree AV block6 T T F d T d F T d F d d Wandering pacemaker or Wenckebach or AV dissociation7 T T F d T d F F T d d d Second-degree AV block8 T T F d T d F F F d d d Third-degree AV block9 T T d d T F F T F T F d Sinus rhythm

Table 2

Figure 2.3. Table 1 is a table with logic expressions connected to variables. These expres-sions are then evaluated in table 2. A logic expression can be either true (T), false (F) ordon’t care (d). An example (rule 1): If E1-E4 are true and E5 is false, the diagnosis isVentricular tachycardia. In this rule, the expressions E5-E12 may be either true or false, thediagnosis will be the same nonetheless. The example is taken from Handbook of MedicalInformatics [35]

A SWRL rule is divided in two parts, the first part, the antecedent is made up by anumber of functions, called atoms, that return true if certain factors are satisfied.If all the atoms in the antecedent are positive, the atoms in the second part, theconsequent, will be inferred. The antecedent and the consequent are separated byan arrow. The following example illustrates this.

hasParent(?person1,?person2) ∧ hasBrother(?person2,?person3) →hasUncle(?person1,?person3)

For every person, that has a parent with a brother, that brother is inferred to bethe uncle of the first person.

2.4 Ontologies 17

SWRL rules cannot be negated. Consequently, the inverse of the previous ex-ample is not possible i.e. inferring that a person does not have an uncle if theparent has no brother. Illustrated in this example by the negation sign in frontof hasBrother.

hasParent(?person1,?person2) ∧¬ hasBrother(?person2,?person3) →hasNoUncle(?person1,?person3)

Several built-ins are included in SWRL. They can be used for more advancedreasoning. A built-in atom can be seen as a Boolean function, which one mayprovide with an input to get an output. The predefined built-ins that comewith SWRL are functions to perform comparisons, calculations of mathematicalformulas, string manipulations, time & date, etc. [34].

To facilitate modeling of ontologies in OWL, the Stanford Center for BiomedicalInformatics Research has developed an editor for ontologies called Protégé [36].The editor can be used to visualize, modify and create the different elements inthe ontology (classes, individuals, properties, etc.).

Protégé also comes with plug-ins, called tabs among which one is called SWRLTab[37]. SWRLTab allows creating and execution of rules in Protégé and comes witha library of additional built-ins. These built-ins include among other things,more advances mathematical expressions and XML-querying functions. One ofthe more powerful features in the SWRLTab environment is the SWRL Built-inBridge [38], which allows built-ins to be created from scratch in Java.

2.4.3 Terminology in health care

Coding and classifying information in an EHR is one way of using the computerto more than just a storage place for data. There are several advantages of havingcoded data and some of them are listed by van Bemmel and Musen [39]:

• It is possible to connect coded data to a decision support system

• To form statistics and to use data for research is easier when there is struc-ture in a document

• Coded data could assist a planning system in a hospital

By having a common terminology a better understanding and a more completepicture of the patient could be achieved in the care process [39].

There are several different classification systems for example International Clas-sification of Diseases (ICD) and SNOMED CT. ICD is organized in hierarchies

18 Background

with a three-digit code and a possibility of adding a fourth digit for an extralevel of detail [39]. SNOMED CT has no hierarchical codes but codes who aregenerated by combining concepts, more described in the following section.

Example of the structure of ICD-10 [40]

J00-J99 Diseases of the respiratory systemJ00-J006 Acute upper respiratory infections

J00 Acute nasopharyngitis (common cold)J01 Acute sinusitis

J01.0 Acute maxillary sinusitis..

SNOMED CT

Systematized Nomenclature of Medicine Clinical Terms or SNOMED CT is aterminology system originating in a fusion between SNOMED Reference Ter-minology, created by the College of American Pathologists, and Clinical TermsVersion 3 from the National Health Service of the United Kingdom [41].

The terminology consists of concept, descriptions and relationships, defined inthe SNOMED CT glossary, that both the clinician and the software applicationcan use to code, retrieve and analyze data [41]. There are approximately 311000 active concepts and they are all organized according to, e.g. clinical find-ing/disorder, procedure, body structure, organism, etc [6]. Each concept has adescription and a concept code which is a unique number without any hierar-chical meaning [41]. A concept often has several different synonyms attachedwhich are also searchable and refer to the concept [6], as illustrated in example2. All together and in combination with the 1 360 000 different relationshipsbetween concepts, SNOMED CT founds an enormous system [6].

SNOMED CT glossary [41]:

• A concept is something that have a clinical meaning and it is defined by itsrelationship between other concept. It has a fully specified name which areunique for each concept and a preferred term.

• A description is used to describe concepts.

• A relationship could be of four types: defining, qualifying, historical oradditional. Every active concept has at least one relationship IS_A whichis of the type defining.

2.5 openEHR archetypes 19

Example 1. Example of relationship from SNOMED CT user guide [41]:

Open fracture of foot (disorder) IS_A Fracture of foot (disorder) IS_A Injury of foot(disorder) IS_A Disorder of foot (disorder)

Example 2. Example of synonyms from SNOMED CT user guide [41]:

Fully Specified Name: Myocardial infarction (disorder) are:

• Synonym: Cardiac infarction

• Synonym: Heart attack

• Synonym: Infarction of heart

2.5 openEHR archetypes

2.5.1 The openEHR foundation

The openEHR foundation is a nonprofit organization whose aim is to aid in thedevelopment towards a computerized medical record that follows the patientduring his or her lifetime [4]. The openEHR foundation provides open specifi-cations and open-source software to be used in medical systems. openEHR usesarchetypes to define the structure of the EHR [31].

2.5.2 Structured information in the EHR

openEHR is based on the so called two-level modeling, meaning that there is astable reference information model which is implemented in the software, levelone. Level two constitutes of archetypes and templates where domain conceptsand definitions are stored. Archetypes and templates can later be connected todifferent terminologies [42].

Due to the separation of the information model, domain content and terminolo-gies, updating and maintaining a solid system is simplified. This is becausechanges that are made or new concepts that are added in one level, do not affectthe whole system [42, 43]. The separation also makes it possible for technicaldevelopment in the reference model by IT developers and domain development,like archetypes and templates, by domain experts. Another quality is that thereference model only needs to be constructed once and be reused later even ifconcepts, terminologies or archetypes change [42].

20 Background

The reference model has different functions for storing, querying, caching andgeneric logic while archetypes have the actual control of the modification andthe querying of the data [42].

Archetypes

Beale and Heard [1] define archetypes as:

a computable expression of a domain content model in the form ofstructured statements, based on a reference (information) model.

Archetypes are used to gather and structure information and data in a clinicaldocumentation system [31]. To do this, the archetype constrains the referencemodel to form a model of a domain concept [42]. Archetypes are separatedfrom the actual data and act as the building blocks that creates the foundationof templates [31].

The purpose of archetypes is to make it possible for clinicians to model domainconcepts and to form a foundation for querying data [1]. The domain knowl-edge from a clinician is required to develop and design the archetypes but sincearchetypes are reusable and flexible the work of implementing an archetype onlyneeds to be done once [42].

Archetypes are usually represented in the Archetype Definition Language (ADL)which is a language created to express archetypes [42].

Figure 2.4 shows a blood pressure archetype tree. It consists of different conceptse.g. systolic and diastolic blood pressure, cuff size, instrument, position, etc.A template can later constrain the archetype, for example by deciding whichconcepts to include and which to exclude.

Templates

Templates are used for construction and validation of data by forming a tree ofone or several archetypes [1]. They are to be used at runtime [42]. Templatesform compositions by putting archetypes together and usually correspond to,e.g. notes or reports [42]. They also create default data structure and ensure thatthe data in the EHR follow the constraints made by the archetypes [42].

To constrain archetypes to form a customized structure, templates can be used.Some design factors in forming a template are available archetypes or the adoptedterminology [42]. Templates are mostly used at a local level while archetypes canbe developed and used at a national or international level [42].

2.5 openEHR archetypes 21

Figure 2.4. An example of the structure of a blood pressure archetype from Ocean Infor-matics [44]. The blood pressure archetype specifies the information that can be stored inthe EHR, for example position, cuff size, instrument, location of measurement, etc.

2.5.3 Paths in archetypes

To locate data in an archetype, there is a path mechanism in the architecturewhich makes it possible to pinpoint all nodes in the archetype with the supportof an archetype-based Xpath compatible path [42].

There are different ways to define a path and the general pattern consists of anattribute name with an intervening slash character [42]. In most archetypes thereare lists and sets which requires more than just an attribute name to distinguisha specific node. To overcome this problem, a predicate expression can be addedto the attribute name and the usual way of doing this is by an archetype codeenclosed by square brackets ([]) [42]. The typical structure of an archetype codeis e.g. [at0003].

Example 1. The simplest form with only an attribute name:

attribute_name_1/attribute_name_2/.../attribute_name_n

Example 2. A path with archetype codes as predicate expressions [42]:

/data/events[at0006]/data/items[at0004]/value/magnitude

The path in example 2 locates the magnitude of the systolic blood pressure inthe following observation archetype, figure 2.5.

22 Background

OBSERVATION[at0000] matches { -- blood pressure measurementdata matches {

HISTORY matches {events {1..*} matches {

EVENT[at0006] {0..1} matches {-- any eventname matches {DV_TEXT matches {...}}data matches {

ITEM_LIST[at0003] matches {-- systemic arterial BPcount matches {2..*}items matches {

ELEMENT[at0004] matches {-- systolic BPname matches {DV_TEXT matches {...}}value matches {magnitude matches {...}}

} ELEMENT[at0005] matches {-- diastolic BP

name matches {DV_TEXT matches {...}}value matches {magnitude matches {...}}

}}

}}

}}

}

Figure 2.5. An observation archetype from openEHR Architecture overview [42] withone blood pressure measurement, expressed in ADL. In the figure the structure of thearchetype is illustrated with the archetype codes.

It is also possible to use name attributes in the path to form a unique path to avalue [42].

Example 3. A path with a name attribute [42]:

/data/events[at0006, ’sitting’]/data/items[at0004]/value/magnitude

The path above locates the magnitude of the systolic blood pressure taken in asitting position in the following observation archetype, figure 2.6. If the pathis written according to example 2, both the systolic values would be returnedbecause they match the path in this archetype [42]. To extract just one value thepath has to be complemented with the name value ’sitting’ or ’standing’.

2.5.4 Archetype Query Language - a query language for archetypes

Archetype Query Language (AQL) was earlier named EHR Query Language(EQL), which is a declarative query language created by Ocean Informatics tobe used in EHR systems [45]. The structure is much like Structured QueryLanguage (SQL) with clauses like SELECT, FROM, WHERE, etc. As in SQL,

2.5 openEHR archetypes 23

< -- OBSERVATION - blood pressure measurementarchetype_node_id = <[openEHR-EHR-OBSERVATION.blood_pressure.v1]>name = <value = <“BP measurement”>>data = < -- HISTORY

archetype_node_id = <[at0001]>origin = <2005-12-03T09:22:00>events = < -- List <EVENT>

[1] = < -- EVENTarchetype_node_id = <[at0006]>name = <value = <“sitting”>>time = <2005-12-03T09:22:00>data = < -- ITEM_LIST

archetype_node_id = <[at0003]>items = < -- List<ELEMENT>

[1] = <name = <value = <“systolic”>>archetype_node_id = <[at0004]>value = <magnitude = <120.0> ...>

>[2] = <....

name = <value = <“diastolic”>>archetype_node_id = <[at0005]>value = <magnitude = <80.0> ...>

>>

>>[2] = < -- EVENT

archetype_node_id = <[at0006]>name = <value = <“standing”>>time = <2005-12-03T09:27:00>data = < -- ITEM_LIST

archetype_node_id = <[at0003]>items = < -- List<ELEMENT>

[1] = <name = <value = <“systolic”>>archetype_node_id = <[at0004]>value = <magnitude = <105.0> ...>

>[2] = <

name = <value = <“diastolic”>>archetype_node_id = <[at0005]>value = <magnitude = <70.0> ...>

>>

>>

>

Figure 2.6. An observation archetype from openEHR Architecture overview [42] withtwo blood pressure measurements in different positions, expressed in ADL. In this fig-ure there are multiple measurements with the same archetype code and to get just onemeasurement, a name value has to be specified.

24 Background

SELECT is used to specify what information to retrieve, for example elementsor values [46]. To find data, openEHR’s node syntax is used to describe thepath in the archetype. In the FROM clause, the area of the search is definedand information about which archetype to be used is specified in CONTAINS.The WHERE statement is used to put constraints on the query with aid from thenode syntax and arithmetic functions [46].

An example of a query in AQL:

SELECT o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/valueFROM EHR eCONTAINS OBSERVATION oWHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude<=140

The query selects the systolic blood pressure from a certain EHR if the magni-tude is below or equal to 140.

Chapter 3

Method

This chapter describes the methods for selecting and designing the rules, bothdecision rules and SWRL rules. The methods used to retrieve data from the EHRdatabase are also described.

3.1 Decision rule implementation

3.1.1 Selection of decision rules

The decision rules were selected based on the guidelines for diabetes by Stock-holm County [20] and from a decision support system for diabetes already inuse by Magne Rekdal [15]. In selecting the decision rules, the aim was to haverules that where either interesting for testing purposes (rules that depended onthe results of other rules) or rules of medical interest.

The following rule is an example of a rule to set the goal for HbA1c for a patient.It is a simple rule of IF-ELSE statements.

Example of a decision rule by Rekdal [15]:

if age≥80HbA1c goal = 9

else if age > 70HbA1c goal = 7.5

elseHbA1c goal = 7.0

25

26 Method

It was also desirable to find solutions to problems where missing data was anissue. For example, how the decision rules would have to be implemented tomake a distinction between missing data and data that did not match the rule.The following example is one way of solving the problem of missing data. Thistype of control, to check whether a value is below zero to conclude that the valueis missing, requires a default value below zero.

Example of how Rekdal deals with the problem of missing data [15]:

if blood pressure<0value is missing

In SWRL however, the monotonicity makes it hard to solve the problem this way.As modification of values are not allowed, a preset value will remain a propertyeven though new values are added.

3.1.2 Design of decision rules

What mainly determined the design of the rules was the open world assump-tion in OWL. Under open world assumption, it is not possible to conclude theopposite of a statement.

statement: the hat is red.question: is the hat blue?answer: unknown.

Even if the hat is known to be red, it cannot be assumed that it is not also blue.The possibility exists that it is of both colors. To conclude that the hat is notblue, it must be specifically assigned as not blue. To conclude the hat to be redand only red, every other color must be assigned as false. In SWRL, this meansthat a rule cannot have an ELSE statement, only IF is possible.

Another main design factor was the execution order of the rules. The SWRLrules in Protégé are all executed at the same time, which requires customizedbuilt-ins to create solutions for rules that depend on results of other rules.

3.2 SWRL rule implementation 27

3.2 SWRL rule implementation

3.2.1 Design of SWRL rules

Depending on the purpose of the rules, their results were presented in differentways. For the blood pressure rules, a text message was printed to the commandwindow of Protégé. The message simply stated the conditions under which therule had triggered.

Patient: Age 85, Systolic BP: 150, Diastolic BP: 90Patient is older than 80 years old and the blood pressure is below 170/100

The example above shows the result of a rule that checks whether a patient isover a certain age, 80, and has a blood pressure that is below 170/100. Theinformation in the text message is a repetition of the trigger conditions for therule.

To make a working decision rule, some SWRL rules have to depend on theresults of other rules and for this, values and results were stored. An exampleof this is the rule that calculates the body mass index (BMI). To be able to usethe BMI value as a condition for other rules, this value was stored in the patientcharacteristics as a property of the current individual in the ontology. A Booleandata property was set to either true or false if the BMI exceeded a predefinedreference value for overweight. If the BMI were below the reference value, falsewould be stored, and consequently true would be stored if it exceeded. Due tothe open world assumption in OWL, this approach was necessary. In a closedworld assumption, it would have been sufficient to store just true and let otherrules conclude false if there were no true value.

3.2.2 Data retrieval from EHRs

The patient data used was retrieved from a database provided by Ocean In-formatics. To access the data, the Simple Object Access Protocol (SOAP) wasused. This was done through EHRBankTool [47], a small flash application cre-ated specifically for communication with the Ocean Informatics database.

The AQL queries were written either manually or with the query builder inTemplate Designer, a program to create templates [48]. In Template Designer,it is possible to generate queries by expanding the archetype tree until the de-sired node could be selected. Conditions to the queries, such as the WHEREstatement, had to be manually written and added to the query syntax.

28 Method

Example of an AQL query:

SELECTo/.../valueFROM EHR[uid=’@id’]CONTAINS OBSERVATIONo[openEHR-EHR-OBSERVATION.blood_pressure.v1]

The query consists of three parts; SELECT, FROM and CONTAINS. The firststatement, SELECT, defines that which should be presented. In the case of theexample query, the systolic blood pressure value is desired and thus the path tothat archetype node is the argument of the SELECT statement.

Having decided which data to present, it must then be specified from where.This is done with the FROM statement. In the example the query will get thesystolic value for the patient with the patient id ’@id’.

The last statement is CONTAINS. This statement defines the archetype that hasbeen used to store the information.

The result from an AQL query in the EHR database is presented as XML code.For the query example above, the result (stripped down to the essentials) wouldlook like this:

<RetreiveResultsResult>. . .

<magnitude>130</magnitude><units>mm[Hg]</units><precision>0</precision>. . .

</RetreiveResultsResult>

3.2.3 Transfer of data between AQL and SWRL

The EHRBankTool presented the result from the AQL queries as XML code. Asthe objective for this thesis did not include building an actual system, the transferof the information into the OWL ontology was done manually. However, thepossibility of using the SWRLTab XML Built-in Library, provided by Protégé toquery XML documents, existed.

The SWRLTab XML Built-in creates classes and individuals from XML docu-ments. Each XML element in the XML file is transformed to an individual inthe ontology and the attributes become data properties. The advantage with this

3.2 SWRL rule implementation 29

built-in is that it structures every element in the same way as they are structuredin the XML file. With knowledge of the structure in the XML document that istransformed, it becomes a fairly easy task to retrieve the desired value.

It is possible to select a single value as well as multiple values from archetypeddata. The resulting XML file will have different elements depending on thequery syntax. If the query is designed to get the systolic value, instead of allvalues from the blood pressure archetype, the XML response will not have theelement systolic. It would still be possible to extract the magnitude value by

hasName(?element,magnitude) ∧ hasValue(?value,magnitude)→ sqwrl:select(?value)

However, if the same rule is applied in a case where all values are selected, itwould render two results - both the systolic value and the diastolic value. Thedifferent XML responses can be seen in appendix A.

One feature of the SWRLTab XML built-in library is that it creates a large amountof information as every XML element is transformed into an OWL individual.The structure of the XML file is conserved by the object properties the built-increates. The object property links the individuals to each other by parenthood.However, as every element is an individual under the class XMLElement, muchof the visibility for human interpretation is lost.

Chapter 4

Results

This chapter presents some examples of rules implemented in SWRL e.g. how touse the SWRLTab XML built-in in rules and different examples with individualsand properties in SWRL. The examples illustrate rules for different purposes.

Examples of rules in SWRL

Rule 1: A SWRL rule to get the blood pressure from archetyped EHR content:

The first rule extracts the blood pressure values from an AQL response by usingSWRLTab XML built-in. To find the desired values, the rule compares attributenames with predefined names. The first three rows locate the element with theattribute value DV_QUANTITY. For every element that satisfies this, the rulechecks if the sub element has the name magnitude. When all statements are true,the content of that element is selected. The XML code used in the rule can beseen in appendix A.

swrlxml:hasAttributes(?element,?attribute) ∧swrlxml:hasValue(?attribute,?value) ∧swrlb:endsWith(?value,"DV_QUANTITY") ∧swrlxml:hasSubElements(?element,?sub) ∧swrlxml:hasName(?sub,"magnitude") ∧swrlxml:hasContent(?sub,?content)→ sqwrl:select(?content)

31

32 Results

Rule 2: A SWRL rule to print a message when certain conditions are satisfied:

Rule number two is based on the following decision rule:

if age≥80if sbp<170 and dbp<100

print: the patient is over 80 years old and the blood pressure is below170/100

For the rule to trigger, some patient characteristics must first be stored in theontology. This information is stored as properties to individuals in the Patientclass. Figure 4.1 shows an individual with properties in SWRL. A blood pressuremeasurement is stored as an individual in the Blood pressure examination class andhas properties like systolic blood pressure, diastolic blood pressure, comments,etc. It also contains an object property linking the examination to a patient.

Figure 4.1. An individual in SWRL with different properties. These properties are date,systolic and diastolic value, a comment field and a link to the patient. Every new exam-ination is stored as an individual and the values cannot be modified. The individual ispart of an Examination class.

33

The first five rows extract data from the patient and the examination. The ageis extracted from the patient characteristics individual and the systolic and di-astolic blood pressures are extracted from the examination individual. Thesevalues are then compared to reference values and a message will be printed ifthey satisfy the conditions.

hasPatienID(?patient, "327138991") ∧hasAge(?patient,?age) ∧examinationReference(?patient,?examination) ∧hasSBP(?examination,?systolic) ∧hasDBP(?examination,?diastolic) ∧swrlb:greaterThan(?age,80) ∧swrlb:lessThan(?systolic,170) ∧swrlb:lessThan(?diastolic,100)→ dd:print("Patient is older than 80 years old and the blood pressure is below170/100")

Rule 3: A SWRL rule to calculate the BMI from the length and height andstore the result:

Rule number three also uses stored values. The rule calculates the BMI andstores the result in a property hasBMI to the individual in the class Patient. Thisrule uses the mathematic built-in eval from Protége SWRLTab to calculate theBMI. The built-in can be used to calculate mathematic expressions. Withoutthis built-in every arithmetic operation has to be a single atom e.g. swrlb:add,swrlb:divide etc.

Patient(?pat) ∧hasWeight(?pat,?weight) ∧hasHeight(?pat,?height) ∧swrlm:eval(?bmi,"weight/(height*height)",?weight,?height)→ hasBMI(?pat,?bmi)

Rule 4: A SWRL rule to check whether a patient is obese based on a previouslystored BMI value and sets a Boolean property:

Rule number four checks if a BMI value is stored. If there is a value the rulechecks whether the value is greater than 30 and if so, a Boolean property isObeseis set to true to the individual in the class Patient.

Patient(?pat) ∧hasBMI(?pat,?bmi) ∧swrlb:greaterThan(30,?bmi)→ isObese(?pat,true)

34 Results

Rule 5: A SWRL rule to check whether a patient is obese based on a previouslystored BMI value and classifies that patient as obese:

Rule number five is the same decision rule as rule number four except that thepatient is classified as an individual in the class ObesePatient instead of having aBoolean property, if the conditions are fulfilled.

Patient(?pat) ∧hasBMI(?pat,?bmi) ∧swrlb:greaterThan(30,?bmi)→ ObesePatient(?pat)

Chapter 5

Discussion

5.1 Aspects on Arden Syntax and SWRL

This section presents different aspects on rules, for example how a result ispresented, how to retrieve the data necessary for the logic evaluations in therule, etc. It is shown for SWRL as well as for Arden Syntax.

5.1.1 Result presentation

In Arden Syntax, the action slot in the MLM defines the action to be performedshould the logic slot conclude true. The WRITE command can be used to sendmessages to destinations defined within curly braces at the local institution.

A SWRL rule will perform the action specified in the consequent of the rule.Rules in SWRL are mainly used to infer properties, e.g. relationships or assign-ing values. Within the ontology, a text message can be written as a value in adata property of an individual. Alerts as text messages cannot be sent outsidethe ontology without customized built-ins.

35

36 Discussion

Example of an alert message in SWRL and in Arden Syntax:

SWRL:hasSBP(?pat,?sbp) ∧ swrlb:greaterThan(?sbp,150)→hasNote(?pat,"Patient has high blood pressure")

Arden Syntax:logic:

if sbp>150conclude true;

action:write "Patient has high blood pressure"

5.1.2 Data retrieval

The data aggregation for the logic in the Arden Syntax is not specified in thestandard. The path to the requested data is defined within curly braces.

The SWRL rules get their data from the individuals in the ontology. To getexternal data, it must first be imported to the ontology. With the SWRLTab XMLBuilt-in, it is possible for SWRL rules to query XML documents.

With a data dictionary, the query path can be linked to a code. In Arden Syntax,this facilitates sharing of MLMs as the MLM in itself does not have to be alteredwhen arriving at the institution - only the path in the data dictionary. It is alsopossible to create a data dictionary in SWRL by a customized built-in to retrievedata outside the ontology e.g. directly from the EHR with the Archetype QueryLanguage. This is further discussed in section 5.5.2.

5.1.3 Usability

In a SWRL rule, every atom in the antecedent needs to be positive for the ruleto infer the consequent. If one of the atoms returns a false value, the rule willterminate. This fact, plus the one that it is not possible to negate atoms makes itdifficult to compose rules that create an alert for missing values. One solution tothis problem is customized built-ins that return true if a value cannot be found.It does, however, require the rule to be split into a set of rules for each condition,as illustrated in Example of an IF-ELSE solution in SWRL on the following page.

The problem with missing data in Arden Syntax is more easily solved. Failureto retrieve a value will result in a NULL value for the variable. In the logic slot,an IF statement can then be used to produce a message that the value is missing.

5.1 Aspects on Arden Syntax and SWRL 37

Example of a solution to missing data in Arden Syntax:

data:sys_bp:=read last {S_BP};

logic:if sys_bp is NULL

message := "Systolic blood pressure is missing";conclude true;

Because the consequent of the SWRL rule will only execute if all the atoms ofthe antecedent are true, writing IFs in SWRL is inconvenient. Each alternativein the IF statement must be a separate rule.

Example of an IF-ELSE solution in SWRL:

if a<10if b<20

do action1else

do action2else

if b<20do action3

elsedo action4

end

In SWRL, four different rules would have to be composed.

swrlb:lessthan(?a,10) ∧ swrlb:lessthan(?b,20)→ action1swrlb:lessthan(?a,10) ∧ swrlb:greaterThanOrEqual(?b,20)→ action2swrlb:greaterThanOrEqual(?a,10) ∧ swrlb:lessthan(?b,20)→ action3swrlb:greaterThanOrEqual(?a,10) ∧ swrlb:greaterThanOrEqual(?b,20)→ action4

Furthermore, there is no way to make an ELSE statement in SWRL. An ELSEmust be an IF due to the open world assumption.

38 Discussion

5.2 SWRL rule design factors

5.2.1 The missing data problem

The problem with missing data is an important issue. One way of solving theproblem is constructing a built-in for data retrieval that would return informa-tion on whether the data existed or not. A major obstacle of doing this type ofcontrol in SWRL is the open world assumption. If the question is: does data ex-ist in the medical record? And the answer is yes, it is possible to conclude trueabout the statement. On the other hand if the answer is no, it is not possible toconclude false. Two rules have to be made, one that asks if data exist and onethat asks if data does not exist to conclude whether data exist. To be able to dothis, the answer must exist within the ontology.

If no value is returned when querying an archetyped path, it might be possiblethat there is another archetyped path where the requested information is lo-cated. Another possibility is that data could be calculated from other data. Oneexample is: if the body mass index value queried from the archetype for BMIis missing, it could be calculated by using the paths for the height and weightarchetypes.

One solution to this problem is constructing a built-in that serves as a prioritylist. The list would include information that the built-in can use to query anotherarchetyped path if the requested data could not be found using the first path.For example, if a value entered according to the BMI archetype is missing thena path from the archetype for weight could be used for queries, etc.

Another problem is the possibility that weight and height values are more re-cently stored than the existing BMI value. If the date is an important issue, anew BMI value should be calculated from these values. A comparison betweenthe dates has to be made before the decision which data to use. This howeverrequires nested queries and is discussed in 5.3.2.

Both these problems could possibly be avoided by calculating the BMI valueevery time a value for weight and height is stored. To have the most recentvalues, a value depending on another value should be stored at the same time.For example, if a BMI value is stored but not a weight and a height value analert message should be presented to the clinician.

Another possible scenario is that the query is too specific resulting in a seeminglymissing value. By querying for a blood pressure value taken in a sitting positioninstead of a more general query, it is possible that no value is returned. Onesolution to this is a priority order. For example if a blood pressure value ina sitting position does not exist then query for blood pressure in a standingposition and so on until a value is found. It is also possible to completely remove

5.3 Demands on the Archetype Query Language 39

the condition on the query.

5.2.2 Creating OWL individuals

The SWRL rules reason and base their information on the individuals in theOWL ontology. The individuals contain properties with values as well as rela-tions to other individuals. Consequently, the layout and design of the individu-als are of great importance in the making of efficient rules.

Considering that the EHR extracts are archetype-based, one approach is to createindividuals that correspond to archetypes. An archetype would be matched byOWL individuals that have the same properties as the archetype. The archetypeindividuals would then be structured in classes, depending on the informationmodel e.g. the EHR Information Model by openEHR [49].

This method requires connections between the different individuals to concludeinformation about specific patients. An individual with patient characteristicswould be linked to an observation by some kind of ID. Some of the rules createdduring this master thesis used a version of this to some extent. An individualcontaining the necessary patient characteristics for the current rule were linkedby the ID to another individual containing information from an observation ofthe blood pressure, see figure 5.1.

For reference values, individuals are also used. This approach allows changesof threshold values in multiple rules by adjusting the reference value in thereference value individual.

As SWRL is used to reason with logic, a possibility of having classes for symp-toms or diseases is possible. A person that fulfills certain requirements for adisease would be classified as an individual of the class with the name of thedisease. One possible use for this is diagnosis. If a patient has certain symp-toms characteristic for a disease, he would be classified as having that disease.Another example is illustrated in the rule number 5 in chapter 4.

An alternative to this is to have individuals with just a value and references.The AQL query is performed in a built-in and the retrieved value is stored in anindividual. A reference box in the individual would be used to connect it to apatient and/or other query results. This is illustrated in figure 5.2.

5.3 Demands on the Archetype Query Language

To write a query manually, knowledge of the archetype structure and the nodesyntax is necessary. With the aid of the query builder in Template Designer

40 Discussion

Query EHR

hasPatientID(?patient, "327138991") ΛhasAge(?patient, ?age) ΛexaminationReference(?patient, ?examination) ΛhasSBP(?examination, ?systolic) ΛhasDBP(?examination, ?diastolic) Λswrlb:greaterThan(?age, 80) Λ swrlb:lessThan(?systolic, 170) Λswrlb:lessThan(?diastolic, 100) —› dd:print("Patient is older than 80 y.o. and the blood pressure is below 170/100")

Patient is older than 80 y.o. and the blood pressure is below 170/100

Patient

327138991

hasPatientID:

examinationReference:

examination148

hasAge:

80

BP examination

SBP:

DBP:

140

90

Patient1

examination148

OWL DATAEHR

Store patient information in the ontology

Get the required data from the patient.

Get the required data from theexamination that is linked to the patient.

Calculate.

Execute rule

Perform action

}

}}}

Date:

2008-12-11

...

...

...

...

Figure 5.1. Flow chart describing the execution and evaluation of a rule checking if apatient has a certain blood pressure and a certain age. The patient individual has areference to the examination. One patient could have multiple examination references,one for each examination. After querying the EHR, patient information and examinationdata are stored in OWL. The rule uses this data to calculate and perform an action. TheSWRL rule in this example is the same as rule number 2 in the results chapter.

implemented by Ocean Informatics, a certain amount of the query (includingthe node syntax) could be generated. However, it could not be used to generateany conditions on the query, i.e. use the clause WHERE. To make specific queriesfor single values, the node syntax had to be manually added.

5.3.1 Operators for improved functionality

Rule creation can be facilitated by naming the response from a query e.g. if thereturned value always has the same name it is easier for the rule to find therequested data. In AQL, the keyword AS is for naming responses from a query,the same manner as in SQL [46]. The possibility of using the AS function toname the XML elements could simplify the use of SWRLTab XML Built-in forthe conversion of an XML document to OWL classes.

5.3 Demands on the Archetype Query Language 41

id:

blood_pressure

Parent:

id:

blood_pressure

ref1

value:

Blood pressure

value:

systolic

id:

ref2

value:

magnitude

id:

ref3

value:

130

ref2

Child:

Parent:

ref1

Child:

Parent:

ref2

Child:

Parent:

...

Child:

ref3

value:

Parent:

blood_pressure

id:

ref4

Child:

position

ref5

value:

Parent:

ref4

id:

ref5

Child:

sitting

ref1ref4

Figure 5.2. Modular examination representation. Each value in a stored blood pressureis stored in an individual with references to the parent and the child. In this figure theref2 individual with the value magnitude has the parent ref1, systolic, and the child ref3that specifies the value 130. The blood pressure also has a reference to the position, ref4,with the child ref5 stating that the blood pressure was taken in a sitting position.

To write as efficient queries as possible, different kinds of functions are needed inAQL. The proposed function CURRENT-DATE [46], that returns the current datein a string format, is one of them. This function could be used in situations whena rule depends on the time passed since the last examination. In a combinationwith the keyword ORDER BY, this could be a helpful tool to form statistics onintervals between several different measurements.

Other required operators are the MIN and MAX functions for locating the mini-mum or the maximum value of an expression. One possible application for thesefunctions is finding the latest examination in an archetype-based patient record,e.g. by MAX(date). This procedure, however, requires that the date is stored ina format where such an operator will render a meaningful result. A function toretrieve the most recent value would be practical. In Arden Syntax, the READLAST statement does this.

42 Discussion

MATCHES is another proposed operator to be used in combination with WHERE[46]. MATCHES is intended to be used in many different situations such as tocheck if a name matches another name, a value matches another value or if aname or a value matches one of different names or values in a list. It could alsodiscover whether a value is within an interval [46]. MATCHES could also beused when searching for a SNOMED CT concept code.

Example of how to use MATCHES with a terminology

SELECT .. FROM ..WHERE defining_codeMATCHESterminology: SNOMED CT Concept code = 50043002

5.3.2 Functions for the future

Nested queries are practical when a condition needs to be based on anothercondition. It is possible to do such operations in SWRL but requires multipleexecution sequences. To use an input argument in an AQL query from anotherSWRL rule, the first rule must be executed before the other. An example of thiswould be one rule to query for the maximum date and one rule that uses thesame maximum date to set the condition on the next query.

If SWRL is used instead of nested AQL queries, much more data from the EHRmust be extracted to allow SWRL to reason with it. If SWRL performs the nestedquery and multiple archetypes are involved, the amount of data extracted getseven greater. For efficient filtering and to minimize the amount of undesireddata, the possibility of writing a nested query in AQL is convenient.

Pseudo code for a nested query: SELECT blood pressure FROM ...WHERE date = (SELECT MAX(date) FROM ...)

The query selects the most recent blood pressure by first querying for the latestdate and then use that value as a condition.

The possibility in SQL to join tables might also be useful in AQL to represent theresponse in a way that makes it easy to form connected individuals based on thejoined tables. By connecting archetyped data to each other before they are en-tered to SWRL, much time and complicated operations might be avoided. How-ever, this area needs more research before any recommendation can be given.

5.4 Using SNOMED CT in SWRL rules 43

Example how a response from a joined AQL query could look like in a tabularform:

date height weight BMI2008-12-19 170 65 NULL2008-06-10 NULL NULL 242006-04-03 NULL 74 NULL

Pseudo code for the query: SELECT date, height value, weight valueand BMI value FROM EHR e CONTAINS archetype "height" JOIN with"weight" JOIN with "BMI" ORDER BY date descending order

The example shows combined information entered using different archetypes. Itcan discover missing data as well as be used to locate data in several archetypepaths. If a join were created it would be easier to find the most recent datawithout searching in different archetype paths.

5.4 Using SNOMED CT in SWRL rules

Extracting the SNOMED CT concept code in combination with a name or a valuefrom the EHR could be used to later form statistics or be used for searching formore information about the concept.

By importing the terminology to OWL, it is possible for SWRL rules to useSNOMED CT for reasoning. The structure of SNOMED CT, with its concepts andrelationships, can be matched with the class structure of OWL. For example, therelationship IS_A in SNOMED CT can be represented by parents and children inthe OWL ontology. With SNOMED CT in an OWL format, it can be connectedto SWRL rules and thereby used in combination with decision support rules foradditional knowledge.

5.5 Efficiently using located data

When creating an efficient decision support system, a number of factors areimportant for the system to be able to adapt to changes. Such changes couldbe that an archetype changes, rendering the archetype paths obsolete or thatnew medical discoveries are presented. It is therefore worth considering wheredata filtering should occur and if medical rules and data-mining rules should beseparated.

44 Discussion

Where in the process the filtering of the data should be performed has no givenanswer and is depending on application and importance of performance. It isnot always certain that the optimal solution is to filter close to the source whenusing SWRL and AQL.

By separating the medical rule and the data-mining rule, the medical rule authordoes not need any knowledge of how to find data in the database. Furthermore,when the paths to the data change the data-mining rule can be modified withouttampering with the medical part.

5.5.1 Data filtering in the SWRL rule or in the AQL query?

Filtering the data can be done either in the SWRL rule or in the AQL query.Both methods have their advantages and disadvantages. This is illustrated inthe examples below. The first example sets as much restriction as possible inthe AQL query to get just one exact answer and use the rule for presentation ofthe data. The second example uses a very general query and all arithmetic andlogical functions are made in the SWRL rule.

Consider the two AQL queries and their corresponding SWRL rule:

Example 1:

AQL

SELECT ../valueFROM EHR eWHERE ../value/magnitude<140

SWRL

getResult(?result)→ print(’The magnitude is below 140’)

Example 2:

AQL

SELECT ../valueFROM EHR e

SWRL

getResult(?result) ∧ swrlb:lessThan(?result,140)→ print(’The magnitude is below 140’)

5.5 Efficiently using located data 45

An advantage with the first example is that only the information needed for therule is extracted from the medical record. In a simple rule that prints informa-tion on whether the magnitude was below 140, there is no need for redundantinformation e.g. the position or the cuff size. The main disadvantage is that ifno value is returned from the query it is impossible to know whether a valuedid not exist, or if the value was above 140. This could be avoided by using thequery in the second example. If no value is returned from the query it is prob-ably known that no value existed. The disadvantage with this type of filteringis that more information than needed has to processed. The actual value is notimportant in this example, only the knowledge that it is below 140.

5.5.2 Data dictionary - separating medical rules and data-miningrules

As already mentioned, only the medical part of the AQL response is necessaryfor the author of the medical rule. He or she has no need for the meta data thatcomes with every AQL response. The technical rules would create individualswith properties such as name, magnitude, unit from the AQL response that themedical rule could then use. In SWRL, the author of the medical rules wouldthen write

hasName(?data,Systolic) ∧ hasMagnitude(?data,?magnitude)→ sqwrl:select(?magnitude)

to get the value for the systolic blood pressure and would not have to botherabout how the information is stored in the archetype-based patient record.

With the SWRLBuilt In Bridge, it is possible to create a data dictionary to getthe data needed for the evaluation of the rules. The built-in would read directlyfrom the AQL response and extract the desired value depending on the inputthat it is given. This solution is similar to that proposed by Bo Johansson [30] forthe Arden Syntax and figure 5.3 shows this in SWRL.

An example of such a built-in would be

dd:s_bp(?sbp,?patiendID)

where dd:s_bp is the name of the built-in. The systolic blood pressure is returnedin the variable ?sbp for the input ?patientID, which would be the ID of the patient.

The built-ins, depending on how they are authored, can have an arbitrary num-ber of input and output arguments. It is possible to specify e.g. position or timewhen such information is desired, or be left omitted if they are not. In the fol-lowing example, the position is requested as well as the systolic blood pressurevalue. Note that the same built-in is used as in the previous example but with

46 Discussion

dd:s_bp(?sbp, “327138991”) Λdd:d_bp(?dbp, “327138991”) Λdd:age(?age, ”327138991”) Λswrlb:lessThan(?sbp, 170.0) Λswrlb:lessThan(?dbp, 100.0) ΛageLimit(old, ?ref_age) Λswrlb:greaterThan(?age, ?ref_age)—› dd:print("Patient is older than 80 y.o. and the blood pressure is below 170/100")

Patient is older than 80 y.o. and the blood pressure is below 170/100

s_bp

AgeGroup

ageLimit:

80

old

OWL DATA

EHR

Query EHR

}

}

. . . s_bp(patientID) { Get age from EHR using SOAP; Set as �rst argument; }. . .

Data dictonary(built-ins)

. . . s_bp(patientID) { Get systolic blood value from EHR using SOAP; Set as �rst argument; }. . .

age

SWRL Rule

Figure 5.3. A data dictionary approach for a SWRL rule. The first three rows in the SWRLrule use the data dictionary. Each built-in takes the patient ID as an input argument andrequests the specific data from the EHR. The EHR extracts are then calculated in SWRL. Ifthe rule is true, a message will be printed to the location specified in the data dictionaryfor the print command.

an additional argument.

dd:s_bp(?sbp,?patiendID,?position)

5.6 Limitations

Limitations for this thesis are mostly due to limited time.

• The selection of rules from the guidelines was limited, but the ones chosenillustrate the general pattern and represent a large number of rules.

• No built-ins in SWRL were created.

• As no graphical user interface was implemented, the results of the rulescan only be seen as a flag of true or false in SWRL or as data written in apredefined place. This implies that the results of this thesis are a theoreticalrather than a practical foundation for a future system.

5.7 Further development 47

5.7 Further development

• Built-ins to connect the AQL response to SWRL.

• Built-ins for AQL queries with input arguments from the SWRL rule

• Evaluate the possibility of translating Arden Syntax MLMs to SWRL rules.This would allow decision rules to be composed in a language specificallydeveloped for clinicians.

• Investigate the possibility of using different rule languages than SWRL.

Chapter 6

Conclusion

As a language for logic, the main application field for SWRL is to infer knowl-edge based on facts by conjunction of IF statements. In decision support, this canbe useful to draw conclusions about diagnoses or give a warning when certainfactors are satisfied. However, as all SWRL atoms in the antecedent need to betrue, making IF-ELSE statements require one rule for each statement.

The open world assumption in OWL limits the possibility of making false as-sumptions since it is not possible to conclude the opposite of a statement. How-ever, in this application, the open world assumption made it difficult to knowif a rule had not triggered because it did not satisfy the conditions or because aneeded value was missing. If knowledge is requested whether data exists or not,a built-in could be constructed that would return true if the value was missingin the EHR. Another impact that the open world assumption in OWL has on theSWRL rule design is that ELSE statements are not possible, only IFs.

Another factor when designing rules with OWL and SWRL is the monotonicityin SWRL. As the SWRL rule cannot alter an existing value, only add to a list,multiple values are created when a value is changed. Even though it was not anissue in our application, it is worth considering when designing rules in SWRL.

Since SWRL is not a language for programming, some kind of mechanism tocompose complex functions is required. With, for example, SWRL Built-inBridge, it is possible to create built-ins in Java. Although this is a powerfulfeature, it requires knowledge of Java programming. Therefore, the rule shouldbe written in a language more comprehensible for a clinician and then parsed toJava.

Archetypes and AQL could be used to extract the information needed for thedecision rule from the EHR. A built-in with the query path for an archetype

49

50 Conclusion

returning the desired value from the EHR to the SWRL rule is one way of con-necting the decision rule with the data-mining rule. These together have thepotential to form a decision support system.

Bibliography

[1] Archetype definition and principles, revision 1.0 (openEHR release1.0.1). http://www.openehr.org/releases/1.0.1/architecture/am/archetype_principles.pdf, Mars 2007. [verified 2009-01-28].

[2] Sveriges Kommuner och Landsting Socialdepartementet. Dagmaröveren-skommelse 2008, December 2007.

[3] T.R. Gruber. Towards principles for the design of ontologies used for knowl-edge sharing. Indernational Journal Human-Computer Studies, 43:907–928,1993.

[4] openEHR. The openEHR foundation. http://www.openehr.org/about/foundation.html, 2007. [verified 2009-01-28].

[5] W3C. W3C Semantic Web activity. http://www.w3.org/2001/sw/. [verified2009-02-10].

[6] International Health Terminology Standards Development Organisation.SNOMED-CT. http://www.ihtsdo.org/, December 2007.

[7] E.H. Shortliffe and J.J. Cimino, editors. Biomedical Informatics, chapter 6.Springer, 2006.

[8] W3C. XML Path Language. http://www.w3.org/TR/xpath. [verified 2009-02-10].

[9] J.H. van Bemmel and M.A. Musen, editors. Handbook of medical informatics,chapter 7. Springer, 1997.

[10] E.H. Shortliffe and J.J. Cimino, editors. Biomedical Informatics, chapter 9.Springer, 2006.

[11] H.P. Lehman, P.A. Abbot, N.K. Roderer, A. Rothschild, S. Mandell, J.A.Ferrer, R.E. Miller, and M.J. Ball, editors. Aspects of electronic health recordsystems, chapter 4. Springer, 2006.

51

52 Bibliography

[12] Socialstyrelsen. Vårdskador inom somatisk slutenvård, 2008. Article no2008-109-16.

[13] R.A. Greenes, editor. Clinical decision support, chapter 1. Academic Press,2007.

[14] J. G. Carbonell and J. Siekmann. Lecture Notes in Computer Science, pages89–93. Springer Berlin / Heidelberg, 2005.

[15] Personal correspondence with Magne Rekdal, MD.

[16] Karolinska Universitetssjukhuset. Varför ökar diabetes? http://www.karolinska.se/sv/sys/Press-nyheter-tema/Artiklar/Artiklar-om-folksjukdomar/Diabetes/Varfor-okar-diabetes/, 2001.[verified 2009-01-28].

[17] G.J. Tortora and B.H Derrickson. Principles of Anatomy and Physiology. JohnWiley & Sons, 2006.

[18] Diabetesrådet Landstinget Västmanland. Vårdprogram för diabetes melli-tus, 3rd edition, September 2004.

[19] Socialstyrelsen. Nationella riktlinjer för vård och behandling vid diabetes -för hälso- och sjukvårdspersonal, September 1999. Article no 1999-0-61.

[20] N. Adner, E. Moberg, E. Forbes, and J. Tovi. Vårdprogram: Diabetes typ2. http://www.viss.nu/CONTENT/ENDOKRIN/Diabetes/Vardprogram.htm,February 1997. [verified 2009-01-28].

[21] Open Clinical. Decision support systems. http://www.openclinical.org/dss.html, July 2006. [verified 2009-01-28].

[22] D.F. Sittig, M.A. Krall, R.H. Dykstra, A. Russell, and H.L. Chin. A surveyof factors affecting clinician acceptance of clinical decision support. BMCMedical Informatics and Decision Making, 6(6), 2006.

[23] R.A. Greenes, editor. Clinical decision support, chapter 2. Academic Press,2007.

[24] B.G. Buchanan and E.H. Shortliffe. Rule-based expert systems: The MYCINexperiments of the Stanford Heuristic Programming Project. Addison-WesleyPublishing Company, 1984.

[25] Health Level 7. Arden Syntax for Medical Logic Systems v2.1. HL7, 1999.

[26] G. Hripcsak. Rationale for the Arden Syntax. Computers and BiomedicalResearch, 27(6), 1994.

Bibliography 53

[27] R.A. Jenders, W. Sujansky, C.A. Broverman, and M. Chadwick. Towardsimproved knowledge sharing: assessment of the HL7 Reference Informa-tion Model to support medical logic module queries. Proc AMIA Annu FallSymp, pages 308–312, 1997.

[28] R.A. Jenders, R. Corman, and B. Dasgupta. Making the standard morestandard: A data and query model for knowledge representation in theArden Syntax. AMIA Annu Symp Proc., pages 323–327, 2003.

[29] Open Clinical. Arden Syntax. http://www.openclinical.org/gmm_ardensyntax.html, March 2005. [verified 2009-01-28].

[30] B. Johansson, N. Shahsavar, H. Åhlfeldt, and O. Wigertz. Database andknowledge base integration - A data mapping method for Arden Syntaxknowledge modules. Methods of Information in Medicine, 35:302–308, 1996.

[31] R.A. Greenes, editor. Clinical decision support, chapter 15. Academic Press,2007.

[32] Encyclopaedia Britannica Online. Ontology. http://www.britannica.com/EBchecked/topic/429409/ontology, 2009. [verified 2009-02-09].

[33] D. McGuinness and F. van Harmelen. OWL Web Ontology Languageoverview. http://www.w3.org/TR/owl-features/, February 2004. [veri-fied 2009-01-28].

[34] I. Horrocks, P.F. Patel-Schnider, H. Boley, S. Tabet, B. Grosof, and M. Dean.SWRL: A semantic web rule language combining OWL and ruleML. http://www.w3.org/Submission/SWRL/, May 2004. [verified 2009-01-28].

[35] J.H. van Bemmel and M.A. Musen, editors. Handbook of medical informatics,chapter 15. Springer, 1997.

[36] Stanford Center for Biomedical Informatics Research. The protégé ontologyeditor, version 3.4 beta. http://protege.stanford.edu/. [verified 2009-01-28].

[37] M. O’Connor. SWRLTab. http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTab, November 2008. [verified 2009-01-28].

[38] SWRL Built-in Bridge. http://protege.cim3.net/cgi-bin/wiki.pl?SWRLBuiltInBridge, February 2008. [verified 2009-01-28].

[39] J.H. van Bemmel and M.A. Musen, editors. Handbook of medical informatics,chapter 6. Springer, 1997.

[40] World Health Organization. International Statistical Classification of Dis-eases and Related Health Problems, 10th Revision. Version for 2007, 2007.[verified 2009-02-09].

54 Bibliography

[41] International Health Terminology Standards Development Organisation.SNOMED Clinical Terms users guide, July 2008.

[42] Architecture overview, revision 1.1 (openEHR release 1.0.1). http://www.openehr.org/releases/1.0.1/architecture/overview.pdf, April 2007.[verified 2009-01-28].

[43] T. Beale. Archetypes constraint-based domain models for future proof infor-mation systems. Eleventh OOPSLA Workshop on Behavioral Semantics, pages16–32, November 2002.

[44] Ocean Informatics. Mindmap: openehr-ehr-observation.blood_pressure.v1.http://archetypes.com.au/archetypefinder/mindmaps/mindmap.html?openEHR-EHR-OBSERVATION.blood\_pressure.v1.mm. [verified 2009-01-28].

[45] M. Chunlan, H. Frankel, T. Beale, and S. Heard. EHR query language (EQL)- A query language for archetype-based health records. MEDINFO, pages397–401, 2007.

[46] M. Chunlan, H. Frankel, and T. Beale. Archetype Query Language(AQL) (Ocean) (openEHR specifications). http://www.openehr.org/wiki/display/spec/Archetype+Query+Language+(AQL)+(Ocean), November2008. [verified 2009-01-28].

[47] E. Sundvall. EHRBankTool. http://www.imt.liu.se/~erisu/2008/ehrbank/. [verified 2009-02-10].

[48] Ocean Informatics. Template designer, version 2.1. https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer.[verified 2009-01-28].

[49] EHR Information Model, revision 5.1.0 (openEHR release 1.0.1). http://www.openehr.org/releases/1.0.1/architecture/rm/ehr_im.pdf, April2007. [verified 2009-01-28].

Appendix A

XML responses

The XML response from an AQL query for all values stored with the bloodpressure archetype.

<RetreiveResultsResult><anyType archetype_node_id="openEHR-EHR-OBSERVATION.blood_pressure.v1"xsi:type="q1:OBSERVATION" xmlns:q1="openEHR/v1/Content"><name><value>Blood Pressure</value>

</name><language><code_string>en</code_string><terminology_id><value>openehr</value>

</terminology_id></language><encoding><code_string>utf-8</code_string><terminology_id><value>IANA</value>

</terminology_id></encoding><subject xmlns:q2="openEHR/v1/BaseTypes" xsi:type="q2:PARTY_SELF" /><protocol archetype_node_id="at0011" xsi:type="q3:ITEM_LIST"xmlns:q3="openEHR/v1/Structure"><name><value>list structure</value></name><items archetype_node_id="at0014">

55

56 XML responses

<name><value>Location of measurement</value>

</name><value xmlns:q4="openEHR/v1/BaseTypes"xsi:type="q4:DV_CODED_TEXT"><value>Right arm</value><defining_code><code_string>at0025</code_string><terminology_id><value>local</value>

</terminology_id></defining_code>

</value></items>

</protocol><data archetype_node_id="at0001"><name><value>data</value>

</name><events xmlns:q5="openEHR/v1/Structure" archetype_node_id="at0006"xsi:type="q5:POINT_EVENT"><name><value>any event</value>

</name><time><value>2006-12-05T13:51:54</value>

</time><data archetype_node_id="at0003" xsi:type="q5:ITEM_LIST"><name><value>blood pressure</value>

</name><items archetype_node_id="at0004"><name><value>systolic</value>

</name><value xmlns:q6="openEHR/v1/BaseTypes" xsi:type="q6:DV_QUANTITY"><magnitude>130</magnitude><units>mm[Hg]</units><precision>0</precision>

</value></items><items archetype_node_id="at0005"><name><value>diastolic</value>

57

</name><value xmlns:q7="openEHR/v1/BaseTypes" xsi:type="q7:DV_QUANTITY"><magnitude>99</magnitude><units>mm[Hg]</units><precision>0</precision>

</value></items>

</data></events>

</data></anyType>

</RetreiveResultsResult>

The XML response from an AQL query for the systolic pressure value storedwith the blood pressure archetype.

<RetreiveResultsResult><anyType xsi:type="ArrayOfAnyType"><anyType xsi:type="q1:DV_QUANTITY" xmlns:q1="openEHR/v1/BaseTypes"><magnitude>130</magnitude><units>mm[Hg]</units><precision>0</precision>

</anyType></anyType>

</RetreiveResultsResult>