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
75
Embed
Graduate Degree Thesis in Medical Informatics Integration ...ki.se/sites/default/files/integration_nadim_anani.pdf · Graduate Degree Thesis in Medical Informatics Integration of
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
prescribing at the burn ICU.
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
Figure 4. Screenshot 2 of visualisation for antibiotic prescribing at the burn ICU (by Johanna Forsman, Medical Informatics student at Karolinska Institutet)
Research Topic
18
Figure 5. Screenshot 3 of visualisation for antibiotic prescribing at the burn ICU (by Johanna Forsman, Medical Informatics student at Karolinska Institutet)
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,
• 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
Existing Database Structures
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.
Existing Database Structures
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.
Existing Database Structures
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.
Existing Database Structures
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
Existing Database Structures
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
Existing Database Structures
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.
Data Integration Model
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
Data Integration Model
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
Data Integration Model
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
Data Integration Model
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)
Data Integration Model
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.
Data Integration Model
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’.
Data Integration Model
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.
Data Integration Model
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