Graduate Degree Thesis in Medical Informatics Integration ... · openEHR archetype: ‘A computable...

University of Heidelberg, Heilbronn University and

Karolinska Institutet

Graduate Degree Thesis in Medical Informatics

Integration of Patient Information to Support

Antibiotic Prescribing at a Burn Intensive Care Unit

By Nadim Anani

October 2009

Supervisor: Co-supervisor:

Prof. Sabine Koch, PhD Karolinska Institutet Assoc. Prof. Petra Knaup, PhD University of Heidelberg

Affirmation

I hereby affirm that this graduate thesis is the product of my own independent work.

All content and ideas drawn directly or indirectly from external sources are indicated

as such. The thesis has not been submitted to any other examining body nor has it

been published.

Place, date and signature

Nadim Anani

I would like to thank Prof. Koch a lot for her extensive supervision of my work,

which I feel has also resulted in a positive development of my scientific working and

writing skills. She supported me whenever I needed support in any aspect of my

working, be it scientific advice, hardware resources, contact persons on the clinical

IT side or of other kind.

I would like to thank MD Magnus Falkenhav for his great enthusiasm for the use of

medical informatics in his antibiotic-prescribing work as a physician, and for

providing necessary clinical information and contacts for this thesis.

My thanks also go to the co-supervisor of my work, Assoc. Prof. Knaup, who gave

me valuable advice for conducting this thesis and always answered any questions I

had.

Furthermore, I would like to thank Johanna Forsman, who translated many of her

findings for me from Swedish.

Finally, but not least, I would like to thank everyone who contributed to my work in

this thesis by supporting me mentally, sharing their experiences about their theses,

providing technical and clinical information or any other way, from family and

friends to colleagues, clinicians and IT persons.

Abstract

Background: When physicians go through the complex and vital decision making

process towards prescribing antibiotics to a patient at the burn intensive care unit of

the Karolinska University Hospital, they are faced with difficulties in gathering and

overviewing the patient-related information they need. The difficulties lie in the time

and effort required to log in to the involved computer application programs, as well

as the lack of a summarised view of only that information.

Aims: To tackle the lack of summarised patient-level information for antibiotic

prescribing by designing an integrated data model, implementing it and providing

functions that extract a part of the information from the databases of the application

programs mentioned above. Also to investigate the possibility of implementing

existing openEHR archetypes within the data model, and carry out this

implementation if it is found possible.

Methods: Object-oriented modelling of the integrated data model, Java

implementation of the integrated data model, Java implementation of the extraction

of data from the databases after locating this data in those databases and systematic

analysis of existing openEHR archetypes in the context of antibiotic prescribing with

the help of available electronic tools.

Results: The integrated data model was designed and implemented, and functionality

was provided that extracts a part of the antibiotic prescribing-relevant data from the

databases. Several existing openEHR archetypes were found to be suitable within

decision making on antibiotic prescribing, but 95% of them are not published and

thus expected to change significantly. Knowledge content from these archetypes was

incorporated into the developed data model.

Conclusion: The developed data model as well as currently existing openEHR

archetypes could be suitable to support antibiotic prescribing in intensive care.

However, that has not yet been studied.

Table of Contents

I

Table of Contents

Table of Contents........................................................................................................ I

List of Abbreviations............................................................................................... III

Definitions ................................................................................................................ IV

List of Figures .........................................................................................................VII

List of Tables......................................................................................................... VIII

1 Introduction ........................................................................................................1

1.1 Antibiotic Prescribing at an ICU...........................................................1

1.1.1 Problems.....................................................................................1

1.1.2 Solutions.....................................................................................2

1.2 Decision Support for ICU Antibiotic Prescribing....................................3

1.2.1 Possibilities.................................................................................4

1.2.2 Risks..........................................................................................4

1.2.3 Challenges..................................................................................5

2 Research Topic ...................................................................................................7

2.1 Antibiotic Prescribing at the Karolinska University Hospital Burn ICU....7

2.1.1 Actors.........................................................................................8

2.1.2 Information System Infrastructure.................................................9

2.1.3 Work Processes.........................................................................11

2.1.4 Current Problems.......................................................................14

2.1.5 New Visualisation......................................................................15

2.2 Aims................................................................................................18

2.3 Methods...........................................................................................19

2.4 Delimitations....................................................................................20

3 Existing Database Structures ..........................................................................22

3.1 Involved Data...................................................................................22

3.2 Database Structures...........................................................................22

3.2.1 Basic and Administrative Patient Data.........................................23

3.2.2 Patient History...........................................................................23

3.2.3 Physiology................................................................................24

3.2.4 Chemistry.................................................................................24

3.2.5 Microbiology............................................................................25

Table of Contents

II

3.2.6 Radiology.................................................................................25

3.3 Analysis...........................................................................................26

3.3.1 Conformance with Standards......................................................26

3.3.2 Redundancy..............................................................................26

3.3.3 Transparency.............................................................................28

4 Data Integration Model....................................................................................29

4.1 Review of Existing openEHR Archetypes............................................29

4.1.1 Identification of Existing openEHR Archetypes............................30

4.1.2 Evaluation of Existing openEHR Archetypes................................39

4.2 Modelling........................................................................................41

4.2.1 Modelling Procedure..................................................................41

4.2.2 Use of openEHR Archetypes.......................................................42

4.2.3 UML Diagrams.........................................................................43

5 Implementation.................................................................................................50

6 Discussion..........................................................................................................55

6.1 Usage of openEHR Archetypes..........................................................55

6.2 Software Testing...............................................................................56

6.3 Redundancy Issues............................................................................56

6.4 Unimplemented Parts........................................................................57

7 Conclusion.........................................................................................................58

Literature ..................................................................................................................59

Appendices ................................................................................................................63

List of Abbreviations

III

List of Abbreviations

cf. Definitions (page IV)

API application programming interface

Burn ICU burn intensive care unit

CDS clinical decision support

CDSS computerised decision support system

CPOE computerised physician order entry

CRP carbon-reactive protein

e.g. for example

EHR electronic health record

i.e. that is

ICU intensive care unit

ID identification number

MAAS motor activity assessment scale

PCT procalcitonin

PDMS patient data management system

UML unified modelling language

Definitions

IV

Definitions

API:

A term in computer science that describes a library of services that can be used for

application programming, and all the specifications according to which those

services function.

Burn ICU:

The burn intensive care unit of the Karolinska University Hospital in Stockholm,

Sweden.

CliniSoft:

An ICU patient data management system (PDMS) used during the process of

antibiotic prescribing at the burn ICU.

CPOE:

The electronic instruction entry by physicians to support the treatment process of

a patient.

CRP:

One of the chemical parameters whose value is needed by the ICU physician and

infectious diseases physician at the burn ICU to make a decision on antibiotic

prescribing.

Leukocyte:

A synonym for white blood cell.

Leukocyte count:

See definition of CRP.

Definitions

V

MAAS:

Obtaining the score of the motor activity assessment scale (MAAS) is one of the

methods used to assess the neurological state of a patient during the antibiotic

prescribing process at the burn ICU.

Object-oriented modelling:

A modern software engineering paradigm that relies on making a model of a

world, its objects and the relationships between those objects before going on to

implement this world in a program. In object-oriented modelling, objects are

instances of classes, where the classes describe the applicable states and behaviour

of their objects.

openEHR archetype:

‘A computable expression of a domain content model in the form of structured

constraint statements, based on a reference (information) model. openEHR

archetypes are based on the openEHR reference model. Archetypes are all

expressed in the same formalism. In general, they are defined for wide re-use,

however, they can be specialized to include local particularities. They can

accommodate any number of natural languages and terminologies.’ (from [Beale

and Heard, 2007], p. 8). See also Appendix A.

PCT:


PDMS:

A computer application program that typically supports the tasks in intensive care

units (ICUs).

Sectra:

A radiology information system (RIS) used during the process of antibiotic

prescribing at the burn ICU.

Definitions

VI

TakeCare:

An electronic patient record system used during the process of antibiotic


Thrombocyte count:


UML:

An established modelling language in the context of object-oriented software

development and several other areas.

WWBakt:

A web-based application program comprising microbiological data and

information that is used during the process of antibiotic prescribing at the burn

ICU.

List of Figures

VII

List of Figures

Figure 1. Data transfer amongst application programs and physicians......................11

Figure 2. Working processes during antibiotic prescribing at the burn ICU (by

Johanna Forsman, Medical Informatics student at Karolinska Institutet)..................13

Figure 3. Screenshot 1 of visualisation for antibiotic prescribing at the burn ICU (by






Figure 6. Archetype model meta-architecture (taken from [Beale and Heard, 2007])

....................................................................................................................................31

Figure 7. Relationship of information types to the (clinical) investigation process

(taken from [Beale and Heard, 2008])........................................................................32

Figure 8. How archetypes apply to data (taken from [Beale and Heard, 2008])........33

Figure 9. Mind map of all relevant archetype concepts .............................................35

Figure 10. Mind map of available openEHR archetypes...........................................36

Figure 11. openEHR archetype authoring process (taken from [The openEHR

Clinical Knowledge Manager, 2009]) ........................................................................40

Figure 12. Patient & notes class diagram...................................................................44

Figure 13. Physiology class diagram (1) ....................................................................44

Figure 14. Physiology class diagram (2) ....................................................................45

Figure 15. Chemistry class diagram...........................................................................48

Figure 16. Microbiology class diagram......................................................................49

Figure 17. Radiology class diagram...........................................................................49

Figure 18. Overview of API Documentation .............................................................51

Figure 19. Classes overview within a package...........................................................52

Figure 20. Classes within a package on the left screen side.......................................53

Figure 21. The Use button of the API documentation ...............................................53

Figure 22. The Tree button of the API documentation ..............................................54

Figure 23. The Index button of the API documentation.............................................54

List of Tables

VIII

List of Tables

Table 1. Practices supporting antibiotic prescribing at an ICU (taken from [Kollef,

2001]) ...........................................................................................................................3

Table 2. Grand challenges of clinical decision support (taken from [Sittig et al.,

2008]) ...........................................................................................................................6

Table 3. Allocation Questions-Methods.....................................................................20

Table 4. openEHR archetypes directly matching identified concepts........................37

Table 5. openEHR archetypes related to identified concepts.....................................39

Table 6. Relationships between variables and constants in physiology.....................48

Introduction

1

1 Introduction

1.1 Antibiotic Prescribing at an ICU

More than 50% of patients are prescribed antibiotics at intensive care units (ICUs)

[Bergmans et al., 1997]. As with every decision within patient care delivery, an

antibiotic prescription is desired to improve the state of the patient and serve as an

enrichment for public health. Therefore, optimising the process of antibiotic

prescribing at an ICU can play a significant role in optimising patient care delivery.

This section explores the problems that are attributed to this process and decision,

together with possible solutions.

1.1.1 Problems

An antibiotic prescription can be quite a challenging decision, especially at an ICU.

First of all, an ICU physician has to reach the decision quickly, as the patients are

typically in severe conditions. Quick and accurate judgement is called for, which will

often affect life and death. Time is thus very vital in ICU antibiotic prescribing.

Apart from the time-critical manner of the antibacterial prescribing process, it is a

knowledge-intensive one. A thorough aggregation of large amounts of patient-related

information (certain parts of the admission note, laboratory values, microbiology

results, x-ray information, monitor values and more) is usually required. This also

means that a lot of experience might be needed in order to analyse a patient’s case

before hopefully making the correct choice of antibiotic prescription.

What adds to the difficulty of antimicrobial prescribing are the various effects and

implications it can bring with it for the patient, but also on a health institutional,

Introduction

2

national and global scale. As for the patient, she can show allergic reactions to

certain drugs and dangerous drug-drug interactions can lead to adverse drug events

that range from various illnesses such as eczemae to the patient’s death. On a health

institutional, e.g. departmental scale as well as national and global scale the ever

growing problem of antibiotic resistance to existing drugs makes up a further

worrying association to antibiotic prescriptions. While this resistance to existing

drugs is spreading, the development of new antibacterial agents is very minimal,

making the need for preserving the effectiveness of the antibiotics that are still

working immense [Cars et al., 2008].

1.1.2 Solutions

The whole process of antibiotic prescribing can be seen as divided into different

work processes. Typical examples of these work processes are going through the

patient’s admission note, interpreting laboratory values and evaluating

microbiological results. These work processes form the pivot around which solutions

to the problems (see section 1.1.1 Problems) can be built.

In Table 1 some practices are shown, by which work processes in antimicrobial

prescribing at an ICU can be assisted (from [Kollef, 2001]).

Practice

Provide adequate initial treatment of serious infections (e.g. pneumonia,

bloodstream)

Awareness of predominant causative pathogens

Up to date unit-specific pathogen antibiograms

Drainage of abscesses, empyema cavities, other infected fluid collections

Removal of infected foreign bodies (e.g. central venous catheters)

Monitor serum drug concentrations when appropriate to achieve therapeutic levels

Minimize antibiotic pressures promoting resistance

Avoid prolonged courses of empiric antibiotic therapy

Consider de-escalation of antibiotics based on available microbiologic data and

Introduction

3

clinical course

Use narrow spectrum antibiotics when supported by clinical situation and culture

data

Establish appropriate thresholds for prescribing antibiotics

Develop predetermined criteria for the discontinuation of antimicrobial therapy

Table 1. Practices supporting antibiotic prescribing at an ICU (taken from [Kollef, 2001])

Such practices can be decision-making aids for an ICU physician when prescribing

antibiotics, e.g. ‘Establish appropriate thresholds for prescribing antibiotics’ or

‘Develop predetermined criteria for the discontinuation of antimicrobial therapy’.

Nevertheless, the existence of well established recommended practices still does not

mean that they will be remembered and used. This is where the challenge of

integrating these decision-making aids into the antibacterial prescribing process

arises.

The above mentioned thresholds or criteria could, for instance, be provided to a

physician in the form of a chart on a piece of paper that can be hung on a wall or

carried around, or in a computer file that can be accessed via a hospital’s network

when necessary. However, the more practices the ICU physician needs to think of

fetching the less the chances are that he will. The more decision-making aids are

integrated into the physician’s daily work routine, the better those chances get.

A subject that has been gaining popularity over time in this context is the use of

computerised (clinical) decision support systems (CDSSs). Here, computer

technology is used in varying degrees of complexity to aid decision making in health

care. These will be discussed in more detail in the next section.

1.2 Decision Support for ICU Antibiotic Prescribing

The utilisation of computerised (clinical) decision support systems (CDSSs) in health

care generally is not widely spread, but is expected to continue growing; that can

also be said for the utilisation of CDSSs within prescribing antibiotics more

Introduction

4

specifically [Berner and La Lande, 2007; Musen et al., 2006; Coiera, 2003; van

Bemmel et al., 1997].

The possible functionality of CDSSs in health care ranges from the application of

decision trees to predict medical outcomes, expert systems that aid diagnostic

decisions, making health care professionals aware of relevant guidelines during the

diagnosing process, artificial neural networks to knowledge discovery through data

mining.

CDSSs that can find use in ICU antibiotic prescribing include microbiology result

browsers, alerts about adverse drug events, drug-allergy contraindications as well as

harmful drug-drug interactions, instant communication of laboratory results,

laboratory test interpretations, risk calculators and early identification of patients that

can spread antimicrobial resistance [Sintchenko et al., 2008; Evans et al., 2008; Van

Hoecke et al., 2008].

1.2.1 Possibilities

When studies were conducted regarding the effects of CDSSs for antibacterial

prescribing, they almost always demonstrated positive results. Patient safety was

improved, antibiotic resistance was lowered, deaths were minimised, better therapy

outcomes were reached and costs were lowered [Evans et al., 1998; Thursky et al.,

2006; Evans et al., 2008; Samore et al., 2005; Ammenwerth et al., 2008]. If such

successful CDSSs were to be adopted widely in the antibiotic prescribing process,

patient care may be improved significantly.

1.2.2 Risks

While the proven possibilities of CDSSs within prescribing antibiotics are

encouraging, it must be stated that, often, a preexistent sophisticated information

Introduction

5

system infrastructure1 that supports integrating new features into health care

professionals’ workflow makes it much easier to utilise this potential [Berner and La

Lande, 2007; Evans et al., 1998]. At the same time, the field of CDSSs in health care

is currently not being put into practice on a widespread basis, as has been stated

above. Thus planning and implementing a CDSS for antimicrobial prescribing can

require a lot of time, scarce knowledge and financial resources, without a guarantee

for success.

That leads to the challenges around CDSSs in public health and antibiotic

prescribing.

1.2.3 Challenges

Generally speaking, it may be said that the most challenging aspect of introducing

CDSSs into health care and consequently prescribing antibiotics is of socio-

technical2 nature [Coiera, 2003]. The CDSSs in health care have often been fitted

poorly into clinical practice, i.e. they attempted to solve problems that were not

actually an issue of complaint for health care professionals or required the way

clinicians worked to change.

Additionally, CDSSs are thought to be useful in health care when they guide

inexperienced users in reaching complex decisions, support experienced users in

diagnosing by providing statements that are based on the analysis of a large number

of cases, assist in the diagnostics of nonroutine cases and integrate diagnostic

guidance into electronic patient record systems [van Bemmel et al., 1997].

After an evaluation of the HELP system in Salt Lake City, which also includes a tool

for supporting antibacterial prescriptions, conclusions were reached that decision

1 An information system infrastructure can be seen as ‘the types, number and availability of information processing tools used in a given enterprise’ (from [Haux et al., 2004], p. 30). 2 ‘ “Socio-” refers to the people involved in information processing (e.g., healthcare professionals, administrative staff, computer scientists), whereas “technical” refers to information processing tools (e.g., computers, telephones, patient records).’ (from [Haux et al., 2004], p. 27).

Introduction

6

support needs comprehensive data access, the possibility to process medical language

that is mostly provided in free text, constant evaluation and re-implementation, data

mining to explore helpful trends and well-presented medical reports [Haug et al.,

2003].

In accordance with the mentioned types of challenges, Table 2 shows the ‘grand

challenges’ in CDSSs for clinical practice identified by Sittig et al. Furthermore, the

speed of a CDSS is considered to be a very crucial factor of its success [Bates et al.,

2003].

Challenge

Improve the human-computer interface

Disseminate best practices in CDS design, development and implementation

Summarize patient-level information

Prioritize and filter recommendations to the user

Create an architecture for sharing executable CDS modules and services

Combine recommendations for patients with co-morbidities

Prioritize CDS content development and implementation

Create internet-accessible clinical decision support repositories

Use freetext information to drive clinical decision support

Mine large clinical databases to create new CDS

Table 2. Grand challenges of clinical decision support (taken from [Sittig et al., 2008])

Research Topic

7

2 Research Topic

When looking again at the major challenges that decision support is faced with in

Table 2 above, the challenge of summarising patient-level information is where this

thesis comes in. This work will deal with integrating antibiotic prescribing-relevant

patient information at a burn intensive care unit (burn ICU) from different sources

into a new data model that is merely dedicated to supporting the antibiotic

prescribing process. While designing the new model, it will be investigated how far

currently available openEHR archetypes can be incorporated into it. The thesis will

further implement the new data model in Java, which can then extract its data from

the already existing databases via Java Database Connectivity (JDBC) technology.

The long-term purpose of the work in this thesis is to contribute to a future decision

support system for antibiotic prescribing at this burn ICU, while supporting its

openness towards other information systems.

2.1 Antibiotic Prescribing at the Karolinska University Hospital

Burn ICU

The involved health care unit in this research is the burn intensive care unit (burn

ICU) of the Karolinska University Hospital in Stockholm, Sweden. The Karolinska

University Hospital is one of the largest hospitals in Europe, including 1600 beds,

employing 2400 physicians and receiving 1.5 million patient visits every year [Koch,

2009]. The burn ICU, named BrIVA, has 3 ICU beds and 4 non-ICU beds at its

disposal, as well as 1 ICU physician, 2 plastic surgeons and an infectious diseases

physician who visits the burn ICU every day. The ICU beds belong to the general

ICU called CIVA, which has 10 beds and a staff of 6 ICU physicians in addition to

an infectious diseases physician who visits every day as well. CIVA, in turn, belongs

to ANOPIVA, which is the department of anaesthesiology, operational services and

intensive care [Falkenhav, 2009].

Research Topic

8

In this section the process of antibiotic prescribing at this burn ICU will be described.

The participating actors, information system infrastructure and work processes will

be looked at. Then current problems and approaches to solve them will be discussed.

2.1.1 Actors

There are two actors who participate in the decision making process of antibiotic

prescribing at the Karolinska University Hospital burn ICU. These are the ICU

physician and the infectious diseases physician.

The ICU physician has the following tasks and roles:

• Examine, diagnose and treat the patients at the burn ICU

• Follow the treatment process of the patients at the burn ICU

• Manage a treatment’s documentation

• Communicate with the patients’ relatives

• Prescribe antibiotics to the patients at the burn ICU

• Act as a work leader, anaesthesiologist and scientist

The infectious diseases physician, who can also be referred to as the infectious

diseases consultant, has the following tasks and roles:

• Act as a consultant for the treatment of infectious diseases

• Act as a consultant for the treatment with antibiotics

• Make decisions on whether to prescribe antibiotics, based on the information

that is gathered by or together with the ICU physician

• Have the main responsibility to choose the right antibiotic in an adequate

dosage during an adequate time period

• Control the patients’ conditions

• Observe the microbiological culture results and plan for new tests to be carried

out or already performed tests to be supplemented

• Monitor and analyse the epidemiological situation at the burn ICU and hospital

area

• Take measures that protect against infectious diseases

Research Topic

9

• Act as a scientist, developer and educator in the protection against infectious

diseases

2.1.2 Information System Infrastructure

During the process of antimicrobial prescribing at the burn ICU, the ICU physician

and infectious diseases physician use certain information processing tools. Here, an

overview of the computer application programs which supply the physicians with the

needed medical information to make the prescription decision will be given. Those

application programs are TakeCare, CliniSoft, WWBakt and Sectra.

In the following the types of medical data and information that are retrieved by the

physicians from those application programs will be outlined.

TakeCare is the electronic patient record system. It provides the following data and

information:

• Basic and administrative patient data (ID, name, age, sex, address…)

• Patient’s past medical history

• Admission notes

• Discharge notes

• Radiological images and information via a link to Sectra

• Chemical laboratory measurements and results

• Microbiological laboratory measurements and results

• Pharmacological laboratory measurements and results

• Immunological laboratory measurements and results

• All data and information that is related to a patient’s treatment(s)

CliniSoft is an ICU patient data management system (PDMS) that typically includes

physiological data of the patient. The following data and information are retrieved

from CliniSoft:

• Values from the monitoring devices on a continuous basis, e.g. respiration,

blood pressure and blood gases values

Research Topic

10

• Trend diagrams about different parameters such as temperature and laboratory

values

• Fluid balance and electrolyte metabolism

• Laboratory results

WWBakt is a web-based application program that comprises microbiological data

and information:

• Microbiological culture results

• Antibiotic resistance trends and statistics

• Case histories

• Case-based guidelines and instructions

• Specific guidelines and instructions for infectious diseases

• Graphical and list trends of culture results

Sectra is a program for radiology that contains the according data and information:

• X-ray images

• Descriptions of x-ray images, mostly textual

Figure 1 shows the general data import/export relationships between the illustrated

application programs and the data which the acting physicians (see section 2.1.1

Actors) generally view as well as modify.

Research Topic

11

Figure 1. Data transfer amongst application programs and physicians

2.1.3 Work Processes

This section will describe how the ICU physician and infectious diseases physician

reach a decision on antibiotic prescription at the burn ICU. It will include the

different steps taken, the use of the application programs TakeCare, CliniSoft,

WWBakt and Sectra within those steps and a deeper insight into the exact kinds of

data required.

An ICU physician starts off by a clinical examination of a patient during his round.

He checks organ system for organ system, i.e. neurology, circulation, respiration,

kidney function etc. Next he has a dialogue with his accompanying nurse and/or

colleague. They discuss the patient’s condition, past medical history and the progress

of the intensive care process. Then he logs into the computer, TakeCare and

CliniSoft. He examines different physiological parameters: neurological values,

circulation values (temperature and blood pressure), respiration values, blood gases

which indicate the absorption of oxygen, kidney function, liver function, lactate,

Research Topic

12

fluid balance and coagulation values. After that he looks at physiological parameters

again, but only those that are relevant for infections: blood pressure, pulse, heart

frequency, respiration values, fluid balance and coagulation values. These

physiological datasets are almost identical for every patient.

The ICU physician now uses TakeCare to review the notes of the patient record such

as admission notes, surgical notes, daily notes and past medical history including

past antibiotic treatments. Subsequently he reviews the patient’s chemical laboratory

values like leukocyte count, CRP (C-reactive protein), PCT (procalcitonin) and

thrombocyte count. Next he uses CliniSoft to examine temperature trends in the

patient. Then he views microbiological culture results in TakeCare, which can have

been taken from blood, urine and certain secretions. He also views many different

microbiological files to search for signs of colonisation.

Through TakeCare, the ICU physician then logs into Sectra and reviews radiological

examinations according to the site of the infection. Afterwards he has a dialogue with

the infectious diseases physician about signs of infection and already administered

antibiotics. He discusses the patient’s CRP value, PCT value, leukocyte count value,

temperature, burn character, year of birth, culture results and antibiotic treatment.

Finally, he uses CliniSoft to review a summary of the patient’s stay at the hospital

and earlier treatment, before reaching the antibiotic prescription.

As for the infectious diseases physician, she starts by logging into TakeCare to

review the patient record documentation. She reads admission notes, surgical notes,

daily notes, past medical history and other notes. She then reviews chemical

laboratory results in TakeCare: leukocyte count, CRP, PCT and thrombocyte count.

She also uses TakeCare to go through a summary of the past blood pressure, pulse

and temperature values. Next she views microbiological culture results in TakeCare,

which can have been taken from blood, urine and certain secretions. She also views

many different microbiological files to search for signs of colonisation. After that she

examines the microbiological results and orders during the last day in TakeCare.

Research Topic

13

The next step the infectious diseases physician takes is to check the patient during a

round. She describes the patient’s condition from her point of view to the ICU

physician. Afterwards she logs into Sectra through TakeCare and reviews the

radiological statements as well as images. Now she logs into WWBakt, which only

infectious diseases consultants have the possibility to do. WWBakt provides a

thorough presentation of culture test results and contains the microbiological values

prior to TakeCare in addition to preliminary values which are not available in

TakeCare. Finally she can give her antibiotic prescription recommendation to the

ICU physician.

Figure 2 gives a further illustration of the working processes during antibiotic


Figure 2. Working processes during antibiotic prescribing at the burn ICU (by Johanna Forsman, Medical Informatics student at Karolinska Institutet)

Research Topic

14

2.1.4 Current Problems

The ICU physician and infectious diseases physician working on antibiotic

prescription at the burn ICU need a certain amount of time to log into TakeCare,

CliniSoft, WWBakt and Sectra for getting access to the relevant data. It might take

up to five minutes to have the data displayed. Since time is a very crucial factor at

the burn ICU, this is an issue that may decide on life and death. Additionally, the

physicians typically log into these application programs many times each day and at

different terminals, making log-in time constitute a relatively huge part of their

patient care delivery (see also [Forsman, 2009], p. 13-4, 51).

The second point of consideration related to data access at the burn ICU is the data

access’ complexity, which is associated with the log-in procedure as well. As

‘logging in’ suggests, authentication data, a common example being user names and

passwords, is required to carry it out. When logging into different programs multiple

times daily, authentication can become a process that distracts health care

professionals from their actual goals, in this case adequate antibiotic prescription by

the physicians (see also [Forsman, 2009], p. 27, 51).

After successfully logging into the application programs, the process of analysing

data in the context of antibiotic prescription takes place (see section 2.1.3 Work

Processes). At this point the third data access concern arises, namely an abundance

of data/information. Because several programs are running, that each have a wide

range of tasks to support, a lot of data and information is contained in those

programs, of which only a fraction is needed for antibacterial prescribing. As a

result, a ‘filtering’ of the antibiotic prescribing-relevant data out of all available data

is necessary to proceed. That, in turn, might lead to a further time and effort burden

(see also [Forsman, 2009], p. 14, 27-9, 31, 38).

Another major aspect of the current information system infrastructure which slows

down antibiotic prescribing is that the physicians are dealing with several application

programs at the same time. This makes the physicians need to perform difficult

Research Topic

15

mental aggregations of various scattered data (see also [Forsman, 2009], p. 27-9, 31,

38, 55).

In summary, at the burn ICU

• the log-in time needed to access data related to decision making on

antimicrobial prescription is considerable,

• the log-in procedure needed to access data related to decision making on

antibacterial prescription may irritate physicians,

• physicians are provided with much more data and information than they need

for prescribing antibiotics,

• the mental aggregation of relatively large amounts of data from several sources

is constraining the antibiotic prescribing process.

2.1.5 New Visualisation

In light of those problems and the need for a system that is more dedicated to the

requirements of antibiotic prescribing, another graduate degree thesis in Medical

Informatics has been completed to explore how an antibiotic prescription user

interface should look to accommodate for the needs of the physicians at the burn ICU

when prescribing antibiotics (the work is in [Forsman, 2009]). Figures 3-5 show

sample screenshots of the designed visualisation.

Research Topic

16

Figure 3. Screenshot 1 of visualisation for antibiotic prescribing at the burn ICU (by Johanna Forsman, Medical Informatics student at Karolinska Institutet)

Research Topic

17


Research Topic

18


2.2 Aims

The overall aim of this thesis will be to approach the problems mentioned above (see

section 2.1.4 Current Problems) by summarising relevant patient information

through an integrated data model for antibiotic prescribing. The model should act as

a basis upon which all data needed for the process of antibiotic prescribing at the

burn ICU can be extracted at once. That is, data from TakeCare, CliniSoft, WWBakt

and Sectra needed in a certain work process should be included in the model and

possible to retrieve at once. This can prove to be especially practical given the

visualisation work that has been done in another thesis (see section 2.1.5 New

Visualisation), because in the long run the front-end and back-end work can together

be used as the starting components for a future decision support system for antibiotic

Research Topic

19

prescribing at the burn ICU (see section 1.2 Decision Support for Antibiotic

Prescribing).

The following questions will need to be answered:

• Where exactly is the data needed for antibiotic prescribing located, i.e. in

which databases and where in those databases (it is assumed that TakeCare,

CliniSoft and WWBakt each have one underlying database)? 3

• How is the data structured in its databases?

• What should a data integration model for antibiotic prescribing look like?

• How will the new model be implemented in this work?

Additionally, already conducted research by Medical Informatics student Johanna

Forsman on the use cases (user functions) of a system visualisation for antibiotic

prescribing at the burn ICU will be used to identify appropriate and feasible use

cases to implement on the data access level, within the scope of this work. Based on

the chosen use cases, data integration functions will be designed. One function like

that could possibly be defined in the following way: ‘This function generates a graph

in JPEG format, which, for a given patient, shows the correlation between her

temperature and applied antiinfective agents over the past 24 hours.’ Another

function may have the following definition: ‘This function generates a warning about

drug allergies in the event of a physician prescribing a drug to a patient, who is

allergic to that drug.’

2.3 Methods

In this section methods that will be used in the thesis are allocated to each of the

questions in 2.2 Aims, since the methods attempt at providing the answers to the

questions. The allocation is found in Table 3.

3 Due to time and organisational limitations, the Sectra database will not be investigated in this work. However, radiological data will be included in the integrated data model later (see section 2.4 Delimitations).

Research Topic

20

Question Method(s) Where exactly is the data needed for antibiotic prescribing located, i.e. in which databases and where in those databases (it is assumed that the application programs TakeCare, CliniSoft and WWBakt each have one underlying database)?

Based on information supplied by different IT officials of the Karolinska University Hospital the data will be localised.

How is the data structured in its databases?

The data models of the different databases will be described and analysed.

What should a data integration model for antibiotic prescribing look like?

Object-oriented modelling of the new integrated data structure, keeping in mind compatibility with models of standards (e.g. openEHR Archetypes).

How will the new model be implemented in this work?

The defined model will be implemented and an application programming interface (API) provided using the Java programming language and its associated JDBC technology4.

Table 3. Allocation Questions-Methods

2.4 Delimitations

• The database that stores data for the application program Sectra will not be

accessed and thus radiological images will not be extracted in this work. This

is due to time and organisational matters. However, descriptions of

radiological findings that are imported into the TakeCare patient record

system from Sectra will be extracted via TakeCare.

• The database that stores data for the application program WWBakt will not

be accessed in this work. This is due to time and organisational matters.

4 The Java Database Connectivity (JDBC) technology allows for the access of many kinds of databases from a Java program. For more information on the Java programming language and JDBC please visit http://java.sun.com.

Research Topic

21

However, all data available in the WWBakt database is also transferred to the

TakeCare database and will therefore be extracted from there.

• The software that will be developed in this thesis will not provide for

computerised physician order entry (CPOE), i.e. it only allows the extraction

of already made orders and results (e.g. laboratory values), but not the

placement of orders of any kind.

• The data model to be developed will include all kinds of data that are relevant

to the physicians in making a decision on antibiotic prescribing, even if there

is no access to some data during the time range of this thesis (e.g. the

delimitation relating to extracting radiological images above). Due to this

inclusion of all relevant data in the model, the implementation of the model

can easily be extended to use the new access possibilities.

Existing Database Structures

22

3 Existing Database Structures

This chapter will describe how the data needed within the antibiotic prescribing

process of the Karolinska University Hospital’s burn ICU is stored and structured in

databases. It will go on to analyse these data structures.

3.1 Involved Data

As has been seen in the previous chapter (section 2.1.3 Work Processes) the ICU

physician and infectious diseases physician rely on various data to reach a decision

on an antibacterial prescription. This section will present this data again separately.

The main data can be categorised as follows.

• Basic and administrative patient data (ID, name, age, sex, address…)

• Previous notes about the patient (past medical history, admission notes,

surgical notes, daily notes…)

• Physiological parameters (temperature, blood pressure, blood gases, heart

frequency, electrolyte metabolism…)

• Chemical laboratory parameters (leukocyte count, CRP, thrombocyte count…)

• Microbiological culture findings (bacteria types, antibacterial resistance

patterns…)

• Radiological examinations (x-ray images, descriptions of images)

3.2 Database Structures

All the above data is stored in relational databases (for details on relational

databases, see [Connolly and Begg, 2005; Kroenke, 2002]) behind the application


23

programs TakeCare, CliniSoft and WWBakt5. Hundreds of database tables are

involved in those investigated databases. Here the database structures of the given

data categories will be described.

3.2.1 Basic and Administrative Patient Data

Since TakeCare is the central electronic patient record system within antibiotic

prescribing at the burn ICU (see section 2.1.2 Information System Infrastructure), its

database stores all the necessary basic and administrative patient data, mostly in one

table that has fields corresponding to the characteristics name, age, sex etc. It also

includes links to records from other systems and previous IDs, whether system-

internal or national. Each link to another information system’s application program is

represented by a table, which stores typically relevant data collected from the other

system. Other tables include fields about previous patient IDs, via which the patient’s

data can be retrieved. For example, when the Swedish personal number is not known

during admission at the burn ICU, then another number is given to the patient, which

is not used anymore later on if the Swedish personal number becomes available.

Furthermore, some of the other application programs store basic and administrative

patient data in their databases, similarly in one table.

3.2.2 Patient History

Through TakeCare all available patient history is accessible. There are different

tables that represent, identify and provide links to admission notes, discharge notes,

previous diagnoses and other notes in the TakeCare database. Just like with the basic

and administrative patient data (see section 3.2.1 Basic and Administrative Patient

Data) there are tables storing data gathered from other application programs than

5 As has been noted in chapter 2, the database structures behind Sectra will not be investigated in this work. So the data structures of radiological examinations are unknown here. However, radiological data will be included in the integrated data model later.


24

TakeCare, which are especially important for having as comprehensive a picture as

possible about the patient’s past treatments. Likewise, the tables mentioned in the

context of basic and administrative data that store past patient IDs are very

significant here, because they allow the merging of older and newer history

information about the patient, which can otherwise be overlooked.

The TakeCare database also includes several tables that keep track of past medical

prescriptions, antibiotic prescriptions being a part of these. Past medication types,

prescription reasons, prescribing physicians, dosages, solution compositions, times of

prescriptions and further information are structured in those tables.

3.2.3 Physiology

The CliniSoft data forms the most thorough part of physiological parameters. On a

continuous basis, data from the monitoring devices is fed into the database, typically

as mean values calculated over a time period of two minutes. For each parameter-

value pair (e.g. temperature: 39˚C), a table entry of the same type for all parameters

is made. TakeCare and the other application programs barely store any physiological

data, with the TakeCare database having the possibility to save this data, but it is not

so dedicated to capturing it for a complete picture.

3.2.4 Chemistry

The databases underlying TakeCare as well as CliniSoft save data related to

chemistry laboratory test orders and results. While the CliniSoft database has a

relatively big number of fields referring to a laboratory result that capture a lot of

information about it (including special textual notes), the TakeCare database contains

tables, which have more of a focus on providing diagnoses or evaluational

information that are related to chemical laboratory orders and results.


25

3.2.5 Microbiology

Within this project, the database structures behind WWBakt were not investigated

(see also 2.4 Delimitations). Although WWBakt is very comprehensive in giving

physicians valuable microbiological information towards an antimicrobial

prescription (on the presentation level), on the physical data storage level, TakeCare

has all of the related data, because there are regular messages from WWBakt to

TakeCare containing this data (see Figure 1 in section 2.1.2 Information System

Infrastructure). Therefore, it was sufficient to investigate those structures in the

TakeCare database, to which access had already been granted.

When TakeCare receives the microbiological data from WWBakt, it stores it in

different tables. Some tables represent parts of a culture test request, others the

replies to these. Treatment with antibiotics is handled separately. The tables with

replies contain several fields that characterise the results of a microbiological culture

test, including the reply time and special comments. Fields characterising

antibacterial resistance are a part of the TakeCare tables too.

3.2.6 Radiology

While the investigation of the Sectra database has not taken place in this thesis due to

time limitations, it was possible to gain insight into most of the radiological database

structure through TakeCare as well (see section 3.2.5 Microbiology). The exception

to that were the images, which were not stored in TakeCare.

TakeCare’s tables with radiological data are constructed according to the way they

are received from Sectra. They have a field for the most important radiological

parameter for physicians during the antibiotic prescribing process, which is the

textual descriptions and explanations of x-ray images (more important than the

images themselves). All other significant data around an image such as the date and

time of the x-ray examination, conducting doctor and relevant patient history is kept

in tables as well.


26

3.3 Analysis

How appropriate are the current database structures (described above in section 3.2

Database Structures) for the purpose of supporting the antibiotic prescribing process

to the best possible extent? This question will be answered in this section through an

analysis of the aspects of conformance with standards, redundancy and transparency.

3.3.1 Conformance with Standards

The currently existing data model was, in most of its components, not designed in a

way to conform to existing standards. In the current IT infrastructure used within

antibiotic prescribing at the burn ICU, there has been no implementation of

openEHR specifications [openEHR, 2009]. In Sweden, a conformance to EN13606

and the use of openEHR archetypes has been decided and is planned nationwide [The

openEHR Foundation, 2008]. The openEHR concept is regarded as a promising

approach towards achieving semantic interoperability and easier communication of

patient information amongst and between institutions in health care (chapter 4

includes more details on openEHR).

The HL7 (Health Level Seven) standards [HL7, 2009] have also been gaining more

and more popularity in health care. They are based on exchanging standardised

messages between different systems. Such messages can, for example, contain

clinical admission, discharge and transfer data (the so called ADT messages). In the

current IT infrastructure used within antibacterial prescribing at the burn ICU, there

has been slight implementation of HL7 (see Figure 1 of section 2.1.2 Information

System Infrastructure).

3.3.2 Redundancy

Redundancy in this context refers to the existence of the same piece of data or data

field in more than one part of the databases. Here redundancy would have negative


27

effects due to different reasons. First of all, if data fields that are supposed to capture

the same data are filled in different parts of the databases, this data might be found in

one part for some patient cases, and elsewhere for others. This means that there may

not be a way of certainly knowing where specific data is located. Secondly,

redundancy could lead to an unwanted repetition of information. As a third reason

for not wanting redundancy here the loss of transparency should be mentioned (see

also the next section 3.3.3 Transparency). Different versions of the same data,

depending on differences in the design of the fields, can considerably reduce

transparency.

In the case of the current data model involved in antibiotic prescribing at the burn

ICU, all three risks are present. Because the same chemistry laboratory data is partly

stored in both CliniSoft and TakeCare, locating data can be an issue. An ICU

physician or infectious diseases physician might want to view a CRP value, for

instance, while logged into TakeCare, but not find it before logging into CliniSoft.

The same problem of locating data goes for some physiological data as well.

But the problem of data location is especially significant regarding medication

history, which is a part of the medical history data. All past administered drugs up

until the point in time when the patient arrives at the burn ICU are stored in the

TakeCare database, and not subsequently transferred to the CliniSoft database.

Afterwards the application of those drugs at the burn ICU is only stored in CliniSoft

(usually in addition to further drugs). Finally, a summarised report sheet is sent back

to TakeCare from CliniSoft about the administered drugs at the burn ICU. That

practically means that getting a continuous picture of the timeline of medication

administration is very difficult for the physicians, because they need to check the

medication information ‘back and forth’ between TakeCare and CliniSoft.

When it comes to unwanted repetitions of data entries, they can occur in relation to

physiological data, basic/administrative patient data and patient history data during

antibacterial prescribing at the burn ICU; a physician does not necessarily want to

repeatedly be confronted with the same information. Nevertheless, this problem

constitutes the least significant of negative redundancy consequences, since


28

physicians can learn to ignore repeated information. When this information,

however, is stored and accordingly presented in different ways of different systems,

it becomes more difficult to recognise the repetition. Within antimicrobial

prescribing at the burn ICU, that can happen with physiological and chemical trends.

3.3.3 Transparency

The last mentioned problem of data redundancy within antibiotic prescribing at the

burn ICU is a form of a lack of transparency, i.e. the existing data model does not

provide the shortest/fastest path to access and identify desired data in the context of

antibiotic prescribing, since the purpose of the involved databases when they were

developed was to support the various tasks of their respective application programs.

Instead, it contains undesired data that is not needed for the specific purpose of

antibiotic prescribing. That can also be said for the current model from the point of

view of involved fields. The present model contains a lot of fields, of technical and

clinical nature, that are not needed by the prescribing process, e.g. IDs of TakeCare

database records, fields related to administrative tasks such as managing patients’

appointments and fields documenting other hospital areas than intensive care.

Data Integration Model

29

4 Data Integration Model

The analysis of section 3.3 Analysis shows the need for a dedicated data model for

antibiotic prescribing at the burn ICU, which integrates the relevant data available in

TakeCare, CliniSoft, WWBakt and Sectra. It would be very advantageous for the

new integration model to comply with openEHR archetypes. Additionally,

redundancy of data should be avoided and transparency of data provided to support

the process of antibiotic prescribing.

This chapter will deal with achieving those requirements. To investigate the

possibilities of compliance with openEHR archetypes, a systematic review of the

available archetypes will be carried out to identify the ones that fit into the new data

model for antibiotic prescribing, which will subsequently be developed in this

chapter as well. To reach a transparent, non-redundant model, an object-oriented

solution will be chosen, in which merely the data objects directly involved in the

process of antibiotic prescribing at the burn ICU and the relationships between them

will be considered6.

4.1 Review of Existing openEHR Archetypes

Because openEHR archetypes are in their early development stages, the objective

here will be to review the currently existing openEHR archetypes as to their

suitability in the context of antibiotic prescribing at the burn ICU. To achieve that,

the available openEHR archetypes have to first be identified (4.1.1) and then

evaluated (4.1.2).

6 Transparency here should not in any way suggest a contradiction to the object-oriented concept of encapsulation/information hiding.


30

4.1.1 Identification of Existing openEHR Archetypes

In [Garde et al., 2007] a process is described, by which a dataset can be transformed

into openEHR archetypes. While this process covers transforming a whole dataset

into openEHR archetypes, the aim here is to follow that part of the process which

identifies already existing openEHR archetypes that are relevant for the targeted

domain, since creating new openEHR archetypes would go beyond the scope of this

thesis.

The suggestion of the paper is as follows:

1. Identify all relevant domain-level archetype concepts.

2. Lay out the found archetype concepts in a suitable way, e.g. by a mind map.

3. Check for available reference archetypes that match the identified concepts.

That procedure will be followed here.

1. Identify all relevant domain-level archetype concepts.

The first step deals with extracting high-level (another term for domain-level)

archetype concepts, i.e. concepts that are ‘coherent’ and ‘whole informational’ in a

certain domain, as they are described in [Beale and Heard, 2007]. In other words,

such a concept should be able to stand on its own, and not be dependent on another

concept. Therefore, clinical examples of high-level archetype concepts are blood

pressure but not diastolic blood pressure, admission note but not admission date and

past medical history but not applied dosage of an antibiotic on a given day. If the last

example is considered, a past medical history is a domain-level concept that

clinicians are used to working with on its own, while an applied dosage of an

antibiotic on a given day is just regarded by clinicians as a part of the past medical

history. The same goes for the other examples.

After identifying a domain-level archetype concept it is useful (and requested within

openEHR specifications when editing archetypes) to categorise the concept. But

before going deeper into the categories it is helpful to know how archetypes relate to


31

information and knowledge in the openEHR architecture, which can be seen in

Figure 6.

Figure 6. Archetype model meta-architecture (taken from [Beale and Heard, 2007])

For the purposes of this work it is enough to focus on the aspect in Figure 6 that

archetypes represent knowledge while constraints on archetypes are achieved

through an information model. Constraints can therefore, for example, mean data

instances of a certain computer system or relationships between certain data

elements.

Within openEHR the information types of the different information models (which

are a part of the openEHR reference model) have partly been categorised based on

the problem-solving process that is typical for clinical and medical practice. This

investigative process produces a cycle of information due to its iterative character, as

shown in Figure 7.

The process in Figure 7 shows four information types: observation, opinion,

instruction and action. When a problem is analysed by a clinician (or non-clinician)

observations are made. Then opinions are formed about the observations, after which


32

Figure 7. Relationship of information types to the (clinical) investigation process (taken from [Beale and Heard, 2008])

instructions are given to carry out specific actions. As an example, a physician might

view a high temperature value of a patient (observation), then based on that

observation and other information about the patient case assume that the patient has

an infection (opinion), which makes the physician prescribe medication (instruction)

and subsequently a nurse administers the medication according to the physician’s

instruction (action).

The information types that are derived from the problem-solving process above

correspond to types that are defined in the so called EHR information model (EHR

IM) of openEHR as ENTRY classes. The usable ENTRY classes are

OBSERVATION, EVALUATION, INSTRUCTION and ACTION (and

ADMIN_ENTRY, which is related to administrative tasks in public health).

In addition to ENTRY types, the openEHR reference model includes other types that

are used to express the knowledge in archetypes through constraints on informational

and data level, as can be seen in Figure 8.

The figure shows an important type, the COMPOSITION, which is intended for

classifying composed data, a typical example being notes of all kinds, e.g. admission

notes, discharge notes and past medical history notes.

Now that these features of openEHR have been explored, the focus will go back to

identifying all domain-level archetype concepts that are relevant in antibiotic


33

Figure 8. How archetypes apply to data (taken from [Beale and Heard, 2008])

prescribing at the Karolinska University Hospital burn ICU, including their

categorisation, i.e. stating whether each identified archetype concept is an

OBSERVATION, EVALUATION, COMPOSITION etc.

In this work the identification of all possible relevant archetype concepts was

accomplished by looking at the working processes of the antibiotic prescribing

process at the burn ICU (see section 2.1.3 Work Processes) and extracting all

possible concepts. The categories of archetypes encountered were OBSERVATION,

EVALUATION, INSTRUCTION and COMPOSITION, mostly OBSERVATION.

The identified archetype concepts in antibiotic prescribing at the burn ICU were

found to be as in the following list:

� Clinical ward examination (OBSERVATION)

� Clinical examination note (COMPOSITION)

� Discussion of patient’s condition (EVALUATION)

� Past medical history (COMPOSITION)

� Discussion of treatment progress (EVALUATION)

� Neurological measurements (OBSERVATION)

� Body temperature (OBSERVATION)


34

� Blood pressure (OBSERVATION)

� Respiration (OBSERVATION)

� Blood gases (OBSERVATION)

� Kidney function (OBSERVATION)

� Liver function (OBSERVATION)

� Lactate (OBSERVATION)

� Fluid balance (OBSERVATION)

� Blood coagulation (OBSERVATION)

� Heart frequency (OBSERVATION)

� EHR review (EVALUATION)

� Admission note (COMPOSITION)

� Surgical note (COMPOSITION)

� Chemistry laboratory results (OBSERVATION)

� Leukocyte count (OBSERVATION)

� C-reactive protein value (OBSERVATION)

� Procalcitonin value (OBSERVATION)

� Thrombocyte count (OBSERVATION)

� Creatinine value (OBSERVATION)

� Creatinine clearance (OBSERVATION)

� Cystatin C value (OBSERVATION)

� Microbiology culture finding (OBSERVATION)

� X-ray analysis (EVALUATION)

� X-ray description (COMPOSITION)

� Burn analysis (EVALUATION)

� Infection analysis (EVALUATION)

� Antibiotic prescription (INSTRUCTION)

The last archetype concept in the list, antibiotic prescription, was mentioned for the

sake of completeness regarding the work processes in antibiotic prescribing at the

burn ICU. It is not, however, directly related to the data integration that is meant to

be done in this work, since it rather concerns a physician order entry than a

summarisation of information.


35

2. Lay out the found archetype concepts in a suitable way, e.g. by a mind map.

With all relevant domain-level archetype concepts identified, the next step of the

procedure can be carried out, which is laying out those archetype concepts suitably.

The suggested lay-out method, a mind map, is very common in the context of

presenting openEHR archetypes. Typically, a node is used for each of the categories,

e.g. EVALUATION, and every child node represents one archetype concept of that

category. This was done here, and the resulting mind map in the antibiotic

prescribing setting of the burn ICU can be viewed in Figure 9.

Figure 9. Mind map of all relevant archetype concepts

According to the archetype principles in [Beale and Heard, 2007] archetypes can be

specialised through further archetypes. When specific archetype concepts appeared

to be specialisations of a more general archetype concept in the mind map, then the

specialisation archetype concepts were illustrated as children nodes of the general

archetype concept node. That was the case for ‘Leukocyte Count’, ‘C-reactive

Protein Value’, ‘Procalcitonin Value’, ‘Thrombocyte Count’, ‘Creatinine Value’,

‘Creatinine Clearance’ and ‘Cystatin C Value’, which are specialisations of

‘Chemistry Laboratory Result’.


36

3. Check for available reference archetypes that match the identified concepts.

The ‘openEHR Clinical Knowledge Manager’ tool [The openEHR Clinical

Knowledge Manager, 2009] offers several functions that help in finding openEHR

archetypes that have been developed or are in development. This tool was used here

to search for all existing openEHR archetypes that are in some way related to the

context of antibiotic prescribing, and would thus cover a part of the identified

concepts that are shown in Figure 9 above.

The searching was carried out in July 2009 through viewing all listed archetypes in

the Clinical Knowledge Manager (which were available as a mind map or list),

choosing the ones with names that appear relevant (e.g. ‘Operation Record’) and if

there is uncertainty about what the archetype is about, looking through further details

of that archetype, such as description, purpose or data items. Finally, it was useful to

lay out the found archetypes in a mind map, like in the second step, in order to have a

clear picture of them. Figure 10 shows the mind map.

Figure 10. Mind map of available openEHR archetypes

Like with the identified concepts in steps 1 and 2, the inclusion of the

INSTRUCTION archetypes in Figure 10 serves completeness, and consistency with

those steps.


37

When comparing the found existing openEHR archetypes (in Figure 10) with the

identified archetype concepts (in Figure 9), then a couple of direct matches are

locatable, which Table 4 illustrates.

openEHR Archetype

Name

Identified Concept Name Type

Blood Gas Assessment Blood Gases OBSERVATION

Blood Pressure Blood Pressure OBSERVATION

Body Temperature Body Temperature OBSERVATION

Heart Rate Heart Frequency OBSERVATION

Respirations Respiration OBSERVATION

Encounter Clinical Examination Note COMPOSITION

Table 4. openEHR archetypes directly matching identified concepts

Aside from the direct matches in Table 4, there are several further matches, where an

identified archetype concept in antibiotic prescribing at the burn ICU (in Figure 9) is

a part of or specialisation of a found openEHR archetype (in Figure 10), or vice

versa. For example, the ‘Glasgow Coma Scale’ (Figure 10) is one of the

‘Neurological Measurements’ (Figure 9), a ‘Chemistry Laboratory Result’ (Figure 9)

is a type of ‘Laboratory Test Result’ (Figure 10), a ‘Medication List’ (Figure 10) can

be a part of the ‘Past Medical History’ (Figure 9) and an ‘EHR Review’ (Figure 9)

can include an ‘Evaluation of Risk Condition’ (Figure 10). Table 5 shows these

archetypes that have is-a or consists-of relationships between them.

openEHR

Archetype Name

[1]

Identified Concept

Name

[2]

Type Relationship

Carer Observation Clinical Ward

Examination

OBSERVATION [2] is a [1]

Glasgow Coma

Scale

Neurological

Measurements

OBSERVATION [2] consists of [1]

Laboratory Test

Result

Kidney Function OBSERVATION [2] is a [1]


38

openEHR

Archetype Name

[1]

Identified Concept

Name

[2]

Type Relationship

Laboratory Test

Result

Liver Function OBSERVATION [2] is a [1]

Laboratory Test

Result

Lactate OBSERVATION [2] is a [1]

Laboratory Test

Result

Fluid Balance OBSERVATION [2] is a [1]

Laboratory Test

Result

Blood Coagulation OBSERVATION [2] is a [1]

Laboratory Test

Result

Chemistry

Laboratory Result


Laboratory Test

Result

Microbiology

Culture Finding


Temperature Body Temperature OBSERVATION [2] is a [1]

Evaluation of Risk

Condition

EHR Review EVALUATION [2] consists of [1]

General Statement of

Exclusion or States


Goal Discussion of

Patient’s Condition

EVALUATION [2] consists of [1]

Goal Discussion of

Treatment Progress

EVALUATION [2] consists of [1]

Problem X-ray Analysis EVALUATION [2] consists of [1]

Problem Burn Analysis EVALUATION [2] consists of [1]

Problem

Infection Analysis EVALUATION [2] consists of [1]

Reason for

Encounter

Discussion of

Patient’s Condition

EVALUATION

[2] consists of [1]

Substance Use

Summary



39

openEHR

Archetype Name

[1]

Identified Concept

Name

[2]

Type Relationship

Medication List Past Medical

History

COMPOSITION [2] consists of [1]

Problem List Admission Note COMPOSITION [2] consists of [1]

Medication Order Antibiotic

Prescription

INSTRUCTION [2] is a [1]

Table 5. openEHR archetypes related to identified concepts

4.1.2 Evaluation of Existing openEHR Archetypes

The question whether or not and how far the data model to be developed in this work

can conform to the openEHR archetypes that fit into the picture of antibiotic

prescribing at the burn ICU (they can be found in the first column of Table 4 and

Table 5) is the subject matter of this section. The answer will be based on an

investigation of the maturity of those archetypes, as the development of openEHR

archetypes is in its young stages.

It is good to start with the process that is used to create and edit archetypes, which

can be looked at in Figure 11. To summarise that process: First of all, an idea comes

up to create a certain archetype. Next the archetype is drafted into a rough version.

After that the building of a team to review the archetype takes place, and when the

team members reach a sufficient level of agreement, the archetype is ripe for being

used and thus gets published. Later on newer versions of the archetype can be

produced, making the old versions obsolete. The persons suggesting, drafting and

reviewing archetypes are typically clinicians and health informatics professionals.

The essence of that process for the context of this thesis is that an archetype goes

through three stages until it is usable for describing its domain content as optimally

as possible and therefore ready to be implemented through information models.

Those stages are chronologically:


40

1. Draft

2. Team review

3. Published

Figure 11. openEHR archetype authoring process (taken from [The openEHR Clinical Knowledge Manager, 2009])

During the time when the existing openEHR archetypes above were found, the ones

in the draft stage were ‘Blood Gas Assessment’, ‘Heart Rate’, ‘Encounter’, ‘Carer

Observation’, ‘Glasgow Coma Scale’, ‘Laboratory Test Result’, ‘Temperature’,

‘Evaluation of Risk Condition’, ‘General Statement of Exclusion or States’, ‘Goal’,


41

‘Problem’, ‘Reason for Encounter’, ‘Substance Use Summary’, ‘Medication List’,

‘Problem List’ and ‘Medication Order’.

‘Blood Pressure’ and ‘Respirations’ were in the state of team review. And only

‘Body Temperature’ had been published.

This meant that all available openEHR archetypes that are useful for the process of

antibiotic prescribing were likely to change significantly, except for the archetype

holding the concept of body temperature - 95% were not in the published state.

Therefore, the conclusion was that implementing those openEHR archetypes in this

work would form an effort that is too great compared to its outcome. Nevertheless,

this thesis aimed at bringing its implementation as far as possible towards the

existing openEHR archetypes, in order to facilitate an easier and smoother transition

to openEHR archetypes in the future (see upcoming section 4.2.2 Use of openEHR

Archetypes).

4.2 Modelling

Here the data model holding all important data elements for antibiotic prescribing at

the burn ICU will be designed. Section 4.2.1 will explain how the model is to be

derived; Section 4.2.2 describes how openEHR archetypes will be embedded into the

model, based on the openEHR archetypes found above (in the third step of section

4.1.1 Identification of Existing openEHR archetypes); Section 4.2.3 comprises the

resulting model diagrams according to the unified modelling language (UML), in

addition to explanations about these diagrams.

4.2.1 Modelling Procedure

In Section 3.1 Involved Data six data categories were listed, which represent all data

needed for the process of antibiotic prescribing at the burn ICU and thus all data this


42

thesis aims to integrate for the goal of summarising patient information to

prescribing physicians:

• Basic and administrative patient data

• Previous notes about the patient

• Physiological parameters

• Chemical laboratory parameters

• Microbiological culture findings

• Radiological examinations

In accordance with these six data categories it appears reasonable to design six UML

class diagrams, with each diagram depicting the relationships between the different

objects that are a part of the respective category. The methodology of UML

modelling in [Fowler, 2004] will be used as a basis for constructing the diagrams.

Where necessary, explanations about specific aspects of the diagrams will be

included.

4.2.2 Use of openEHR Archetypes

Table 4 above (in section 4.1.1 Identification of Existing openEHR Archetypes) lists

openEHR archetypes that absolutely matched identified high-level archetype

concepts in the context of antibiotic prescribing at the burn ICU. Those openEHR

archetypes will be used to name and structure the corresponding classes in the

context of object-oriented modelling. Data types will be assumed that are available in

the Java programming language and its class library [Sun Developer Network

(SDN), 2006; Sun Developer Network (SDN), 2008], and will later become clear in

the implementation (chapter 5).

The relationships between other openEHR archetypes and identified concepts in

antibiotic prescribing listed in Table 5 above (equivalently in section 4.1.1

Identification of Existing openEHR Archetypes) will be considered within the

relationships between the different objects in the UML diagrams, and names as well

as attributes of classes will also be based on the participating openEHR archetypes.


43

Again, data types will be assumed that are available in the Java programming

language and its class library [Sun Developer Network (SDN), 2006; Sun Developer

Network (SDN), 2008], and will later become clear in the implementation (chapter

5).

4.2.3 UML Diagrams

The following UML class diagrams represent the data integration model, whose

implementation can be used to extract relevant data during the process of antibiotic


No operations will be included in the modelling, as most operations are get/set

operations that can be deduced from the attributes. All operations can be seen in

detail (as Java methods) in chapter 5.

When the focus in a diagram is merely on the relationship(s) to a certain object (and

the object is explained in more detail in another diagram), then only the name of the

class of that object will be included and thus attributes excluded.

Figure 12 shows the first class diagram. It represents the patient (class Patient

with some representative fields) and notes that are stored about him. Each patient can

have any number of notes associated with him, while each note belongs to one

patient. The class Note is abstract and has the field file to represent the digital file

containing the note. The classes PastMedicalHistory, AdmissionNote,

Encounter, SurgicalNote, XrayDescription, DischargeSummary

and AntibioticTreatmentCourse are specialisations of the class Note. The

classes MedicationList and ProblemList were included since they represent

existing openEHR archetypes; they have no attributes because their openEHR

archetypes have no data elements yet.


44

Figure 12. Patient & notes class diagram

In Figure 13 and Figure 14 the physiology class diagrams are shown. Two diagrams

instead of one were taken for the sake of clarity, since some classes have many

attributes and would be too unclear if made smaller visibly.

Figure 13. Physiology class diagram (1)


45

Figure 14. Physiology class diagram (2)

Both in Figure 13 and Figure 14 most classes involved in the physiological aspect of

antibiotic prescribing (Patient is the only class not directly related to physiology

in the diagrams) are specialisations of the abstract class Measurement, while the

classes GlasgowComaScale and MAAS (stands for motor activity assessment

scale) are associated with the Neurology class.

On the basis of the available openEHR archetypes, the classes

BodyTemperature, BloodPressure, Respirations,

BloodGasAssessment, HeartRate and GlasgowComaScale were given

their names and additional attributes to the inherited ones. The class MAAS was

added after consultation with ICU physician MD Magnus Falkenhav. Table 6

clarifies what the constant attributes (of Java type int) that some of those classes

have mean, i.e. which variable attributes get assigned the values of which constant

attributes.


46

Class Variable Attribute Related Constants

BodyTemperature bodyExposure NAKED, REDUCED_CLOTHING_

BEDDING,

APPROPRIATE_CLOTHING_

BEDDING,

INCREASED_CLOTHING_

BEDDING

BodyTemperature siteOfMeasurement MOUTH, EAR_CANAL, AXILLA,

RECTUM, NASOPHARYNX,

URINARY_BLADDER,

INTRAVASCULAR, SKIN,

VAGINA, OESOPHAGUS,

INGUINAL_SKIN_CREASE

BloodPressure position STANDING, SITTING,

RECLINING, LYING,

LYING_WITH_TILT_TO_LEFT

BloodPressure sleepStatus ALERT_AND_AWAKE,

SLEEPING

BloodPressure cuffSize ADULT_THIGH,

LARGE_ADULT, ADULT,

SMALL_ADULT,

PAEDIATRIC_CHILD,

INFANT, NEONATAL

BloodPressure locationOfMeasure

ment

RIGHT_ARM, LEFT_ARM,

RIGHT_THIGH, LEFT_THIGH,

RIGHT_WRIST, LEFT_WRIST,

RIGHT_ANKLE, LEFT_ANKLE,

FINGER, TOE,

INTRA_ARTERIAL

BloodPressure method AUSCULTATION, PALPATION,

MACHINE, INVASIVE

BloodPressure diastolicEndpoint PHASE_IV, PHASE_V


47

Respirations Rhythm REGULAR, IRREGULAR

Respirations Depth NORMAL, SHALLOW, DEEP,

VARIABLE

Respirations abnormalRespirato

ryPattern

KUSSMAUL_RESPIRATION,

CHEYNE_STOKES_

RESPIRATION, ATAXIC_

RESPIRATION,

APNEUSTIC_RESPIRATION,

CLUSTER_BREATHING,

APNOEA,

PROLONGED_EXPIRATORY_

PHASE

HeartRate rhythm REGULAR,

REGULARLY_IRREGULAR,

IRREGULARLY_IRREGULAR

HeartRate position LYING, SITTING,

RECLINING, STANDING

HeartRate method AUSCULTATION, DEVICE

GlasgowComaSca

Le

bestEyeResponse NO_EYE_OPENING,

EYE_OPENING_IN_

RESPONSE_TO_PAIN,

EYE_OPENING_TO_SPEACH,

EYES_OPENING_

SPONTANEOUSLY

GlasgowComaSca

Le

bestVerbalRespon

se

NONE, INCOMPREHENSIBLE_

SOUNDS,

INAPPROPRIATE_WORDS,

CONFUSED, ORIENTED

GlasgowComaSca

Le

bestMotorResponse NO_MOTOR_REPONSE,

ABNORMAL_EXTENSION_TO_

PAIN,

ABNORMAL_FLEXION_TO_


48

PAIN,

FLEXION_WITHDRAWAL_

FROM_PAIN,

LOCALIZES_TO_PAIN,

OBEYS_COMMANDS

MAAS value UNRESPONSIVE,

RESPONSIVE_ONLY_TO_

NOXIOUS_STIMULI,

RESPONSIVE_TO_TOUCH_

OR_NAME,

CALM_AND_COOPERATIVE,

RESTLESS_AND_

COOPERATIVE, AGITATED,

DANGEROUSLY_AGITATED_

UNCOOPERATIVE

Table 6. Relationships between variables and constants in physiology

Next the chemistry class diagram will be discussed, which can be seen in Figure 15.

It is one of the simplest diagrams, yet includes data that is very important to an ICU

physician and infectious diseases physician in the process of antibiotic prescribing,

namely the results of chemistry laboratory tests. The constants are all related to the

variable type.

Figure 15. Chemistry class diagram

Figure 16 and Figure 17 show the microbiology class diagram and radiology class

diagram respectively. Microbiological results are, amongst other reasons, epecially


49

significant for controlling the worldwide epidemic of antibiotic resistance. Within the

radiological class DiagnosticImage the fields category and

anatomicalSite were chosen on the basis of the openEHR archetype

‘Diagnostic Imaging’, just like the category constants X_RAY, ULTRASOUND,

NUCLEAR_MEDICINE, CT_SCAN and MRI were.

Figure 16. Microbiology class diagram

Figure 17. Radiology class diagram

Implementation

50

5 Implementation

This chapter presents the public application programming interface (API)

documentation of the developed software. Before doing that, the following points

should be mentioned:

• The Java programming language and its class library were used, Java

Standard Edition (SE) 6 [Sun Developer Network (SDN), 2006].

• The Java Database Connectivity (JDBC) [Sun Developer Network (SDN),

2009] technology was used to access the existing databases within antibiotic

prescribing at the burn ICU (see section 2.1.2 Information System

Infrastructure and chapter 3 Existing Database Structures). A Microsoft SQL

Server driver of type 4 and a Sybase driver of type 4 were utilised to connect

to the databases

• The Java packages were organised such that one package represents each of

the UML diagrams above (with physiology regarded as one diagram), in

addition to a package containing the database connection classes

TakeCareConnectionFactory and

CliniSoftConnectionFactory. The packages were named according

to the inverse URL Java convention, with reference to the health informatics

centre (HIC) in the department of learning, informatics, management and

ethics (LIME) at Karolinska Institutet (KI) and the Infobiotika™ project,

under which this thesis has been carried out, as follows (‘dm’ stands for data

model):

� se.ki.lime.hic.infobiotika.dm.pat (patient and notes)

� se.ki.lime.hic.infobiotika.dm.phys (physiology)

� se.ki.lime.hic.infobiotika.dm.chem (chemistry)

� se.ki.lime.hic.infobiotika.dm.micro (microbiology)

� se.ki.lime.hic.infobiotika.dm.rad (radiology)

� se.ki.lime.hic.infobiotika.dm.cons (connections)

• Classes that have been defined but not implemented, such as

SectraConnectionFactory for connecting to the database with

Implementation

51

radiological images, will not be included here (see also section 2.4

Delimitations).

• In each of the packages derived from the UML models, there will be an

additional class providing static Java methods that are specifically tailored

and to be used for extracting data for some of the use cases defined in the

visualisation by Johanna Forsman (see section 2.1.5 New Visualisation and

2.2 Aims). These methods will mainly aim at providing data extraction

functionality for the screen in Figure 3 of section 2.1.5 New Visualisation.

• The API documentation will be presented in the usual and official way that

Java API documentations are laid out.

The enclosed CD ‘Infobiotika DM API 1.0 Documentation’ contains the whole

public API documentation.

The API documentation is comfortably navigable in the form of HTML files. To start

navigating, one possibility is opening the file index.html. That would result in an

overview like in Figure 18.

Figure 18. Overview of API Documentation

Implementation

52

The centre of the overview shows the different packages, which can each be clicked

on to view a package’s classes; the resulting screen is shown in Figure 19 where the

package se.ki.lime.hic.infobiotika.dm.phys had been clicked on. A

further clicking on the classes reveals their documentation.

Figure 19. Classes overview within a package

Alternatively, any of all the classes of all the packages can be viewed through a click

on a certain class on the left side of the screen (in Figure 18 and Figure 19) under

‘All Classes’. However, if a package is selected from the upper left corner, then only

that package’s classes are displayed on the left side of the screen under ‘Classes’,

which Figure 20 shows.

The items on the top of the screen next to Overview – Package, Class, Use, Tree,

Deprecated, Index and Help - provide further navigation power through the API

documentation. The latter, Help, explains aspects of the rest of the items. The button

Use, for example, shows the detailed relationships between a specific package and

other packages. Figure 21 shows the resulting screen for the package

se.ki.lime.hic.infobiotika.dm.pat.

Implementation

53

Figure 20. Classes within a package on the left screen side

Figure 21. The Use button of the API documentation

The Tree button shows inheritance relationships between classes, as Figure 22 shows

for the package se.ki.lime.hic.infobiotika.dm.phys.

Implementation

54

Figure 22. The Tree button of the API documentation

Similarly to an index in a book, the Index button provides an alphabetical list that

includes all objects, with a button representing each letter. A part of the page for the

letter ‘A’ can be viewed in Figure 23.

Figure 23. The Index button of the API documentation

Discussion

55

6 Discussion

6.1 Usage of openEHR Archetypes

The first point to mention here is that there is an ongoing project which is

implementing the openEHR concepts in Java [Chen, 2006; The openEHR

Foundation, 2009]. It includes the implementation of the openEHR informational

model – the openEHR reference model, i.e. the data types specified by openEHR are

being implemented in Java within this project.

The data types used here to consider the existing relevant openEHR archetypes in the

developed data model were partly primitive Java data types and partly classes

belonging to the Java Development Kit 6 (JDK 6) [Sun Developer Network (SDN),

2006; Sun Developer Network (SDN), 2008].

It will therefore be a future aim to implement openEHR archetypes within the

antibiotic prescribing process at the burn ICU through the specific Java classes which

have been designed for openEHR implementation.

Secondly, it will also be a future aim to monitor the development of the identified

relevant existing openEHR archetypes for antibiotic prescribing at the burn ICU (see

section 4.1.1 Identification of Existing openEHR Archetypes) and equally monitor the

emergence of new relevant openEHR archetypes. The monitoring should be done to

find out which archetypes are moving from the ‘draft’ and ‘team-review’ states to the

‘published’ states. When they reach the ‘published’ states, which 95% of the

currently existing relevant openEHR archetypes have not according to section 4.1.2

Evaluation of Existing openEHR Archetypes, then they will be suitable to implement,

especially because they would not change significantly anymore, at least for some

time.

Discussion

56

6.2 Software Testing

The classes PatientData, PhsysiologyData, ChemistryData,

MicrobiologyData and RadiologyData (see the enclosed CD, the usage of

which is explained in chapter 5) provide the main interface of the developed software

with the graphical user interface (GUI) components of the designed visualisation for

antibiotic prescribing at the burn ICU (see section 2.1.5 New Visualisation). These

classes cover certain use cases of the visualisation.

The testing of the classes above was carried out in connection to the graphical user

interface for a certain patient and certain dates in the hospital databases during

preparations for a presentation to demonstrate the program. Those classes had also

been tested beforehand with systematic test data that aimed at using random inputs

and extreme as well as null values; the same systematic tests were also carried out for

the rest of the classes developed here.

However, the tests will need to be carried out more thoroughly with test protocols if

the developed API is to be used clinically, and further tests need to be designed to

test time behaviour, behaviour with large amounts of data to be extracted,

deployment into the hospital environment etc.

6.3 Redundancy Issues

In section 3.3.2 Redundancy the problem was illustrated that there is no continuous

medication record in one single database in the current situation. Also, basic and

administrative patient data, chemistry data and further data are stored in different

hospital databases redundantly.

When the functionality of the classes is extended in the future (by adding further

methods) to extract the concerned data above for some of the remaining use cases,

then it has to be guaranteed that no data is lost. For the medication example, data has

Discussion

57

to be extracted from the TakeCare database during the time the patient was not at the

burn ICU yet and extracted from the CliniSoft database during the time the patient

spent at the burn ICU and finally returned to the user in a coherent format. For the

rest of the data, it has to be found out how the whole picture can be obtained. This

was not possible thus far due to a lack of a sufficient number of complete treatment

cases in the TakeCare test database to which access has been provided.

6.4 Unimplemented Parts

In addition to the methods that still have to be developed to provide further

functionality to classes that already exist, i.e. PatientData,

PhsysiologyData, ChemistryData, MicrobiologyData and

RadiologyData, a class called SectraConnectionFactory has been

defined but not implemented. This class should establish the connection to the Sectra

database, which contains radiological images and data. So far the access has not been

discussed with the responsible IT persons of Sectra.

Conclusion

58

7 Conclusion

The data model developed in this work could prove useful if it would be integrated

into an information system infrastructure used within the decision making process of

antibiotic prescribing at an ICU anywhere, since it only describes data relevant for

this process, and thus facilitates the support of the process. Especially in the design

of clinical computerised decision support systems which are usually focused on a

specific domain, such a model can be a helpful element.

When it comes to extracting antibiotic prescribing-relevant data from the databases

of the application programs used at the Karolinska University Hospital’s burn ICU,

then the application programming interface provided here helps to achieve some of

the required functionality. This means that the rest of the extraction functions still

have to be developed. Also, the available functionality developed here has to

undergo more testing.

A further conclusive statement of this work is that existing openEHR archetypes

could be suitable in the setting of prescribing antibiotics at an ICU from the

perspective of the domain knowledge they capture. However, before they can be

implemented within this setting to achieve goals of the openEHR concept such as

semantic interoperability, it would be advantageous to wait until they are published,

which can be expected to take place in the near future. It can also be useful to create

new openEHR archetypes in order to cover the whole decision making process of

antibiotic prescribing at an ICU. EVALUATION and COMPOSITION archetypes

can be created to describe and document the analysis of burns and infections. When

specialisations of the OBSERVATION archetype ‘Laboratory Test Result’ are

created, they could include kidney function, liver function, lactate, fluid balance,

blood coagulation and microbiological culture test results to support antibiotic

prescribing in intensive care.

Literature

59

Literature

Ammenwerth E, Schnell-Inderst P, Machan C, Siebert U. The effect of electronic

prescribing on medication errors and adverse drug events: a systematic review. J Am

Med Inform Assoc 2008 Sep-Oct;15(5):585-600.

Bates DW, Kuperman GJ, Wang S, Gandhi T, Kittler A, Volk L et al. Ten

commandments for effective clinical decision support: making the practice of

evidence-based medicine a reality. J Am Med Inform Assoc 2003 Nov-

Dec;10(6):523-30.

Beale T, Heard S, editors. Archetype definitions and principles [document online].

The openEHR Foundation; 2007 Mar 14 [cited 2009 Jun 10]. Available from:

http://www.openehr.org/releases/1.0.1/architecture/am/archetype_principles.pdf

Beale T, Heard S, editors. Architecture overview [document online]. The openEHR

Foundation; 2008 Nov 13 [cited 2009 May 15]. Available from:

http://www.openehr.org/releases/1.0.2/architecture/overview.pdf

Bergmans DC, Bonton MJ, Gaillard CA, van Tiel FH, van der Geest S, de Leeuw

PW et al. Indications for antibiotic use in ICU patients: a one-year prospective

surveillance. J Antimicrob Chemother 1997 Apr;39(4):527-35.

Berner ES, La Lande TJ. Overview of clinical decision support systems. In: Berner

ES, editor. Clinical decision support systems: theory and practice. 2nd ed. New

York: Springer; 2007. p. 8-10.

Cars O, Högberg LD, Murray M, Nordberg O, Sivaraman S, Lundborg CS et al.

Meeting the challenge of antibiotic resistance. BMJ 2008 September 27;337:726-8.

Literature

60

Chen R. openEHR reference model Java ITS [document online]. The openEHR

Foundation; 2006 February 2 [cited 2009 May 11]. Available from:

http://www.openehr.org/releases/1.0.2/its/Java/openEHR-JavaITS.pdf

Coiera E. Guide to health informatics. 2nd ed. London: Arnold; 2003. p. 331-43.

Connolly T, Begg C. Database systems: a practical approach to design,

implementation, and management. 4th ed. Harlow (England): Addison-Wesley;

2005. p. 830-6.

Evans RS, Pestotnik SL, Classen DC, Clemmer TP, Weaver LK, Orme JF et al. A

computer-assisted management program for antibiotics and other antiinfective

agents. N Engl J Med 1998 January 22;338(4):232-8.

Evans RS, Wallace CJ, Lloyd JF, Taylor CW, Abouzelof RH, Sumner S et al. Rapid

identification of hospitalized patients at high risk for MRSA carriage. J Am Med

Inform Assoc 2008 Jul-Aug;15(4):506-12.

Falkenhav M. Intensive care physician. Personal communication. 22nd October 2009.

Forsman J. Visualisering som stöd för beslutsfattandet: optimering av

antibiotikaanvändning på brännskadeintensiven. Master thesis. Department of

learning, informatics, management and ethics, Karolinska Institutet; 2009.

Fowler M. UML distilled: a brief guide to the standard object modeling language.

3rd ed. Boston: Addison-Wesley; 2004. p. 35-52, 65-88.

Garde S, Hovenga E, Buck J, Knaup P. Expressing clinical data sets with openEHR

archetypes: a solid basis for ubiquitous computing. Int J Med Inform 2007 Dec;76

Suppl 3:334-41.

Haug PJ, Rocha BH, Rvans RS. Decision support in medicine: lessons learned from

the HELP system. Int J Med Inform 2003 Mar;69(2-3):273-84.

Literature

61

Haux R, Winter A, Ammenwerth E, Brigl B. Strategic information management in

hospitals: an introduction to hospital information systems. New York: Springer-

Verlag; 2004. p. 27, 30.

HL7. [Online]. 2009 [cited 2009 October 6]. Available from: http://www.hl7.org/

Koch S. Stockholm County Council and Karolinska University Hospital. Presented at

the Frank - van Swieten Lectures. Amsterdam, 2009 Jun 25.

Kollef MH. Optimizing antibiotic therapy in the intensive care unit setting. Crit Care

2001 Aug;5(4):189-95.

Kroenke DM. Database processing: fundamentals, design, and implementation. 8th

ed. Upper Saddle River (NJ): Pearson Education; 2002. p. 62-7.

Musen MA, Shahar Y, Shortliffe, EH. Clinical decision-support systems. In:

Shortliffe EH, Cimino JJ, editors. Biomedical informatics: computer applications in

health care and biomedicine. 3rd ed. New York: Springer; 2006. p. 700-7.

openEHR. [Online]. 2009 [cited 2009 May 8]. Available from

http://www.openehr.org/home.html

The openEHR Clinical Knowledge Manager. [Online]. 2009 [cited 2009 July 22].

Available from: http://www.openehr.org/knowledge/

The openEHR Foundation. Governments and openEHR. [Online]. [2008?] [cited

2009 Jul 8]. Available from: http://www.openehr.org/shared-

resources/usage/government.html

The openEHR Foundation. The openEHR Java reference implementation project.

[Online]. 2009 [cited 2009 May 11]. Available from:

http://www.openehr.org/projects/java.html

Literature

62

Samore MH, Bateman K, Alder SC, Hannah E, Donnelly S, Stoddard GJ et al.

Clinical decision support and appropriateness of antimicrobial prescribing: a

randomized trial. JAMA 2005 Nov 9;294(18):2305-14.

Sintchenko V, Coiera E, Gilbert GL. Decision support systems for antibiotic

prescribing. Curr Opin Infect Dis 2008 Dec;21(6):573-9.

Sittig DF, Wright A, Osheroff JA, Middleton B, Teich JM, Ash JS et al. Grand

challenges in clinical decision support. J Biomed Inform 2008 Apr;41(2):387-92.

Sun Developer Network (SDN). Java platform, Standard Edition 6 API specification.

[Online]. [2008?] [cited 2009 Jun 12]. Available from:

http://java.sun.com/javase/6/docs/api/

Sun Developer Network (SDN). JDBC. [Online]. [2009?] [cited 2009 May 4].

Available from http://java.sun.com/javase/6/docs/technotes/guides/jdbc/index.html

Sun Developer Network (SDN). JDK 6 documentation. [Online]. [2006?] [cited 2009

Jun 12]. Available from: http://java.sun.com/javase/6/docs/

Thursky KA, Buising KL, Bak N, Macgregor L, Street AC, Macintyre CR et al.

Reduction of broad-spectrum antibiotic use with computerized decision support in an

intensive care unit. Int J Qual Health Care 2006 Jun;18(3):224-31.

van Bemmel JH, Musen MA, Miller RA. Methods for decision support. In: van

Bemmel JH, Musen MA, editors. Handbook of medical informatics. Houten (the

Netherlands): Bohn Stafleu Van Loghum; 1997. p. 255, 258.

Van Hoecke S, Decruyenaere J, Danneels C, Taveirne K, Colpaert K, Hoste E et al.

Service-oriented subscription management of medical decision data in the intensive

care unit. Methods Inf Med 2008 Apr;47(4):364-80.

Appendices

63

Appendices

Appendix A: Examples of openEHR Archetypes

openEHR archetype ‘Glascow Coma Scale’ (taken from [The openEHR Clinical Knowledge

Manager, 2009])

openEHR archetype ‘Blood Gas Assessment’ (taken from [The openEHR Clinical Knowledge

Manager, 2009])

Graduate Degree Thesis in Medical Informatics Integration ... · openEHR archetype: ‘A computable...

Documents

Transcript of Graduate Degree Thesis in Medical Informatics Integration ... · openEHR archetype: ‘A computable...