Graduate Degree Thesis in Medical Informatics Integration ...ki.se/sites/default/files/integration_nadim_anani.pdf · Graduate Degree Thesis in Medical Informatics Integration of
Post on 09-Mar-2018
216 Views
Preview:
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
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:
See definition of CRP.
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
prescribing at the burn ICU.
Thrombocyte count:
See definition of CRP.
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
Johanna Forsman, Medical Informatics student at Karolinska Institutet)..................16
Figure 4. Screenshot 2 of visualisation for antibiotic prescribing at the burn ICU (by
Johanna Forsman, Medical Informatics student at Karolinska Institutet)..................17
Figure 5. Screenshot 3 of visualisation for antibiotic prescribing at the burn ICU (by
Johanna Forsman, Medical Informatics student at Karolinska Institutet)..................18
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
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,
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
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
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]
Data Integration Model
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
OBSERVATION [2] is a [1]
Laboratory Test
Result
Microbiology
Culture Finding
OBSERVATION [2] is a [1]
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
EHR Review EVALUATION [2] consists of [1]
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
EHR Review EVALUATION [2] consists of [1]
Data Integration Model
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:
Data Integration Model
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’,
Data Integration Model
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
Data Integration Model
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.
Data Integration Model
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
prescribing at the burn ICU.
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.
Data Integration Model
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)
Data Integration Model
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.
Data Integration Model
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
Data Integration Model
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_
Data Integration Model
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
Data Integration Model
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])
top related