1
Evaluation of feasibility of openEHR and
Guideline Definition Language for automatic
data transfer between electronic health records
and the Auricula quality registry for Atrial
fibrillation Una Ismaili
Master's Programme in Health Informatics
Spring Semester 2014
Degree thesis, 30 Credits
Author: Una Ismaili
Main supervisor: MD, PhD, Rong Chen, Department of LIME, Karolinska and
Cambio Healthcare Systems, Sweden
Co supervisor: Konstantinos Kalliamvakos, Cambio Healthcare Systems, Sweden
Examiner: Dr. Andrzej Kononowicz, Department of LIME, Karolinska Institutet,
Sweden
Affirmation
I hereby affirm that this Master thesis was composed by myself, that the work contained
herein is my own except where explicitly stated otherwise in the text. This work has not
been submitted for any other degree or professional qualification except as specified; nor
has it been published.
Stockholm, 2014/05/XX
__________________________________________________________
Una, Ismaili
Master's Programme in Health Informatics
Spring Semester 2014
Degree thesis, 30 Credits
Master's Programme in Health Informatics
Spring Semester 2014
Degree thesis, 30 Credits
Evaluation of feasibility of openEHR and Guideline Definition
Language for automatic data transfer between electronic health
records and the Auricula quality registry for Atrial fibrillation
Abstract
Background: Currently there is no integration between the electronic health records
(EHR) and the atrial fibrillation quality registry (QR) Auricula. This hinders the
automatic transfer of information from the EHR to the QR.
Objective: The aim is to evaluate if openEHR technology and GDL can make it feasible
to integrate EHR to the atrial fibrillation QR, Auricula.
Methods: The study uses a qualitative approach. It was performed in five steps. The first
was to collect information about AF for the guideline where literature and certain criteria
were used. In the second step expert feedback was given on the selected elements for the
guideline. The third step was the modelling of openEHR archetype and the guideline. A
semi-structured interview was performed with a cardiology nurse. Content analysis was
used to analyze the interview with the expert. Furthermore, the fourth step was to specify
computer interpretable CDS rules by using GDL. The last step was the validation of the
guideline using mock patient data.
Results: The expert feedback provided the study with important data about the
information needed for the guideline. The qualitative methods helped answering the
questions regarding the problems today without the integration and what could be
improved with it. For this one guideline was modelled for the atrial fibrillation registry.
The results from the validation of the guideline corresponded with the created mock
patient data, a manual check was also performed.
Conclusion: The integration between the EHR and QR is theoretically possible with the
use of openEHR technology and GDL. The validation proved that GDL can model
guidelines in the clinical area of atrial fibrillation and that the criteria can be supported.
Keywords: openEHR, Electronic Health Records, GDL, Atrial Fibrillation
Acknowledgements
First of all I would like to give my thanks to my supervisor Konstantinos Kalliamvakos
for his guidance and support during this thesis. It was a real pleasure working with you
and thanks to your patience. You made me feel more secure about myself and in my work.
Thanks again for your guidance.
I would also like to thank Rong Chen for giving me support and inspiration from your
expertise with openEHR. Thanks for the opportunity to work with you.
Furthermore I would like to thank Sabine Koch for her guidance and insightful feedback
for my thesis writing. Your support and helpful advices improved my thesis.
I would also like to thank Annika Önnerlöv and Martin Koch for using their valuable
time to read the thesis and provide me with their valuable feedback.
Finally I would like to thank my family for their love and support and for believing in me.
5
Table of Contents
Introduction ........................................................................................................................ 1
Background ..................................................................................................................... 1
Atrial Fibrillation ......................................................................................................... 3
Auricula ....................................................................................................................... 3
Interoperability ........................................................................................................... 4
OpenEHR ..................................................................................................................... 4
Guideline Definition Language .................................................................................... 5
Exchanging information between systems ................................................................. 5
Problem analysis ............................................................................................................. 6
Aims and objectives ........................................................................................................ 6
Research question .......................................................................................................... 7
Method ............................................................................................................................... 7
Study Design ................................................................................................................... 7
Study approach ............................................................................................................... 8
Data collection and analysis ........................................................................................... 9
Interview with expert ............................................................................................... 10
Content analysis ........................................................................................................ 11
Software tools ........................................................................................................... 14
Validity and reliability .............................................................................................. 14
Ethical considerations ................................................................................................... 15
Results ............................................................................................................................... 15
Selection of guideline ................................................................................................... 16
Selection of text-based rules ........................................................................................ 16
Modelling of openEHR archetypes and the guideline .................................................. 17
openEHR archetypes ................................................................................................. 17
Terminologies ........................................................................................................... 18
Model of the guidelines ................................................................................................ 19
Results from the content analysis................................................................................. 20
Research .................................................................................................................... 20
Manual entry............................................................................................................. 21
Quality registry.......................................................................................................... 22
Model of the integration .............................................................................................. 22
Specification of GDL rules ............................................................................................. 23
Basmodulen guideline .............................................................................................. 23
Validation using mock patient data .............................................................................. 28
Discussion ......................................................................................................................... 29
Discussion of results ..................................................................................................... 30
Limitations .................................................................................................................... 31
Strengths and weakness of the study ........................................................................... 32
Future research ............................................................................................................. 33
Conclusion ........................................................................................................................ 34
Appendices Appendix A – Archetypes Appendix B – GDL rules Appendix C – Mock Patient Data Appendix D – Execution Logs
Appendix E - Interview questions
0
List of Figures
Figure 1 process of authoring rules Zhou L et al. (8) .......................................................... 2
Figure 2 The study framework ............................................................................................ 7
Figure 3 The three phases in content analysis .................................................................. 12
Figure 4 The Basmodulen archetype ................................................................................ 18
Figure 5 Model over the connections between the used guidelines ............................... 19
Figure 6 How the integration could work ......................................................................... 23
Figure 7 Condition & Action for registration date ............................................................ 24
Figure 8 The execution from GDL ..................................................................................... 25
Figure 9 The rule list ......................................................................................................... 27
Figure 10 Thyroid test rule ................................................................................................ 27
Figure 11 The result of how many patients that have AF ................................................. 28
Figure 12 Execution outcome ........................................................................................... 29
List of Tables
Table 1 Mock patients for Basmodulen ............................................................................ 35
Abbreviations
AF Atrial Fibrillation
AM Archetype Model
ADL Archetype Definition Language
CDS Clinical Decision Support
EACTS Endorsed by the European Association for Cardio-Thoracic Surgery
EHRA European Heart Rhythm Association
EHR Electronic Health Record
GDL Guideline Definition Language
ICT Information and Communication Technology
QR Quality Registry
RM Reference Model
TM Template Model
1
Introduction
Background Health informatics is increasing within the health care and information systems are
important for the measurement of the quality and the improvement of the health care
(1). ”An information system is interpreted here as a computer-supported system which
provides a set of people (users) with information on specified topics of interest in a
certain organizational context” (2).
Electronic health records (EHR) system collects patients’ health data like medical
treatments and their health in general. It is an integrated physical or virtual repository
system(3). It can decrease workload, medical errors, cost, improve the client care, the
quality of care and also support physicians in their daily practice (4). An EHR’s primary
purpose is to “foster the quality of healthcare and support all stakeholders in the process
of healthcare, it is crucial that EHRs themselves adhere to rigid systems of quality
assurance and management.” (4) (5). The information in the EHR can be shared across
different systems, but it can also improve the research field that is beneficial for patients
and health professionals by enabling the reuse of data and information(4)(6).
Clinical decision support (CDS) is a system that can be delivered through an EHR and it
can also be a standalone application. In fact many of the CDS today is standalone and a
huge effort is put to actually integrate it within the EHR and the clinical practice. A CDS
assists clinicians in their decision making (7) (8). It aids clinicians in monitoring and
preventing tasks, drug prescription, diagnosis and management (9)(4). The idea behind
CDS is to improve the quality, safety and efficiency in health care (10). CDS has the
potential to increase guideline adherence and efficiency (9). Medical knowledge is
usually presented as text-based documents like clinical guides and the information needs
to be converted to executable CDS rules (11). Figure 1 presents the process of how to
author rules from text-based to executable CDS rules. Clinical guidelines are used to
support clinicians in their decision making and to improve the quality of patient care (12).
2
Figure 1 process of authoring rules Zhou L et al. (8)
Quality registry
Quality registries (QR) are also important for the improvement of today’s healthcare. The
creation of the first quality registry (QR) began on the 1800-century. It was already then
seen as important to measure and follow up hospitals activities to improve safety and
efficiency in the health care (13). Since then this need has evolved and improved. The
focus throughout the years has always been on the quality of care (13). A QR is a
collection of individual patient data like interventions and the outcome of interventions. It
could be background variables (clinical or other) like age, weight, diagnosis and
treatments. The data is used to evaluate outcomes particularly for diseases, or conditions
(14). This data can be used to analyze and evaluate the health care. QR is mostly used for
monitoring, quality development and research in health care (13).
The primary purpose with the registries is the continuous improvement and support
within the health care sector (13). QR could improve the medical results in some areas, it
also could make the health services more effective and also involved the patient more in
the care. It also gives the possibility to compare and evaluate different treatment methods,
drugs and processes to get the best results (13). The strength with registries is that courses
of diseases can be understood by the collected data, for example variations in treatments
and the outcomes that might have an influence on the quality of life and the prognosis.
3
The feedback gives the opportunity to change the behavior to something more appropriate
for the patient, like monitor safety assess effectiveness and to see the care patterns (14).
Atrial Fibrillation
The last decade’s QR has become an important part in Swedish healthcare. Today there
are about 80 registries. In Sweden the most prevalent cardiac arrhythmia (heart rhythm
disorder) is the atrial fibrillation AF that it is a risk factor for stroke. AF is a growing
health concern where the treatments are complex and the condition burdensome (15).
Ineffective contractions and chaotic electrical activation is what distinguishes AF. The
total estimation of people with AF in Sweden is around 300,000 which correspond to
almost 3% of the population.
There is a fast going development of pharmacological and non-pharmacological therapies
for AF (16). Pharmacological interventions for AF prevention are Warfarin, Novel oral
anticoagulants, rate and rhythm control. The non-pharmacological interventions are
electric cardioversion, Catheter ablation, left atrial appendage closure, lifestyle advice and
patient education (15). The results of the methods are improving rapidly, meaning that
more patients will get the same treatment during the coming years.
Auricula
Auricula is an internet based national QR for patients with AF, and the idea of founding a
web based QR for AF started in 2004 (17). Together with Uppsala Clinical Research
Center (UCR) this registry was ready to use in 2007. Auricula’s purpose is to improve the
quality of health care so results and health care interventions will have a high quality as
possible but also be efficient. It is today used both from hospitals and health care centres.
Of approximately 224 care units, 70 are hospitals and about 140 are in primary care, more
than 114.930 patients are registered in this registry. It is supported by Sweden’s Local
Authorities and Regions and the registry is following the Patient data law and PUL which
is the Personal Privacy Act.
Auricula QR
The QR can map incidences, diagnosis, treatment and the consequences of the AF. With
this gathered information there will be a possibility to improve and modernize the
treatment for patients with AF (16). To be able to improve and increase the safety of the
treatment the registry can monitor the anticoagulants. Some key variables the Auricula
4
registry has are; demographic data, date and place the patient sought care, ECG,
cardiovascular events, risk factors/concurrent diseases, medical treatments, previous
diseases, blood pressure, life quality, body weight and length (18) (17).
Interoperability
To share data across different systems is known as interoperability. Some of the reasons
why interoperability is needed today are due to the fact of saving time and connecting
different systems to each other to make improvements on Information Communication
Technology (ICT) and to exchange information between these systems (19). Currently
there is no integration between the EHR and the QR for atrial fibrillation (AF). There lie
potentials with an integration between these systems that could make it possible to
transfer data fully automatically and could decrease the manual labour and reduce human
errors. Interoperability in health care has shown to be important and successful and is
vital for the assurance of the care and for patient safety (20). To make it clear on what is
meant by interoperability:
The SemanticHealth definition of interoperability (21):
“Functional and syntactic interoperability: the ability of two or more systems to
exchange information (so that it is human readable by the receiver)”; and
“Semantic interoperability: the ability for information shared by systems to be
understood at the level of formally defined domain concepts (so that the information is
computer processable by the receiving system).”
OpenEHR
OpenEHR is a flexible open domain-driven platform for e-health systems under
development (22)(23). One essential attribute for open source software is the open source
concept, which means that the access for the source code is free to use (24). 15 years of
research from different projects and standards from around the world is what embodies
the openEHR (25). OpenEHR have a core design specification that consists of the
Reference Model (RM), Archetype Model (AM) and the Template Model (TM). The
specifications are described in detail below:
Reference Model: RM consists of data types, data structures and EHR models and the
classes of RM are the building blocks of archetypes but they also provide basic semantics
of the data. The EHR RM has different Entry types that have built-in clinical meaning,
Evaluation, Instruction, Observation and Action (22).
5
Archetype Model: AM is the design specification for the archetypes, it provides limiting
mechanism over RM classes. An archetype can be described as a model that captures
clinical information. With the use of the RM, the archetype is a readable specification of
how to store patient data and both are keystones for the openEHR architecture. They
allow clinicians and domain experts to be involved in the design to create standardized
clinical content for EHR. It is designed for all imaginable clinical situations (22). The
definitions are kept broad and constraints minimal and this is to maximize the
interoperability “to share and re-use the archetype across many types of healthcare and
the broadest range of clinical scenarios” (26). Archetype Definition Language (ADL) is a
standard that is used to express the specifications. It can also be revived in other formats
like structured definitions or mind maps. “By design, they provide structure and specify
content which means that archetypes can be both clinically meaningful AND interpretable
by EHR systems“ (26).
Template Model: TM is grouping the archetypes and also constraining to meet the local
requirements. It is the next step towards building clinical models. They contain one or
more archetypes “and add further constraints required for the use of those archetypes in a
particular setting” (27). With the archetypes they can build up a template that will fit what
is wanted to be examined. Templates define data sets with the help of archetypes and it
forms data specific to a particular use e.g. definition of a message or a form of any kind
presented.
Guideline Definition Language
GDL is a formal language for expressing GDL rules and to represent clinical knowledge
for computerized decision support (28). It is created based on the openEHR Reference
Model and Archetype Model providing scalable CDS rules across different electronic
health record systems (29). Natural languages, reference terminologies and technical
implementations are languages that CDS rules in GDL format will be natural to (28).
GDL is at the moment still under development but it allows openEHR archetypes to
combine with rules.
Exchanging information between systems
To exchange EHR data between systems that have different suppliers is a challenge.
openEHR and CEN/ISO have developed an EHR communication that is based on
6
archetype methodology. There is very limited research where the experience of this
methodology is deployed in EHR systems (30). It has also been challenging for medical
informatics research to provide CDS across organizations that are using different types of
EHR systems. “The lack of commonly shared EHR models and terminology bindings has
been recognised as a major barrier to sharing CDS content among different
organisations.”(29). No research regarding integration particularly between the EHR and
the QR was found.
Problem analysis
The manual labour is a problem today in the care. Nurses are hired to fill out the QR
forms for the cardiologists and this job task is taking a lot of their time (31). It is
something that is beneficial to reduce for a better health care. A hypothesize is that if a
high interoperability and integration between EHR and QR existed this could minimize
the problems. This is achieved by important factors leading to a continued good
development for QR’s:
An information infrastructure based on one standard
A transfer function from EHR to register that is simple
A quick feedback of findings from analysis of registry data(32)
OpenEHR technologies could be the solution to the problem mentioned above. With
archetypes and templates data forms can be standardized, and it could populate the
registry easier with the existing data from the EHR (32). Adjustments, easy modifications
and maintenance of the registry could be done.
Aims and objectives
The primary aim of the study is to evaluate the feasibility integrating EHR and the QR
Auricula using openEHR technology including archetypes, templates and Guideline
Definition Language (GDL). The main objectives are how informatics could improve the
integration for a fully automated transfer between the systems and decrease the manual
labour.
7
The work will be to review existing archetypes and identify the need for new ones and
then to create specific templates and finally to model a guideline with GDL facilitating
the transformation. The CDS is only a small portion of the thesis, by using GDL a couple
of rules are set up to identify patients and extract data from EHR for automatic transfer to
Auricula.
Research question
The specific research questions addressed in this study are:
How can openEHR technology and GDL improve the transfer of information
between EHR and Auricula quality registry for AF?
What problems could be solved with the integration between these systems?
Method
The aims of this study are to assess if the integration using openEHR technology can
make the data transfer automatic between the EHR and the QR. The report is using an
empirical method to gain expert knowledge about the integration of EHR and Auricula
QR for AF. Content analysis is used to analyze the collected data. To get a more in-depth
analysis over the situation today the choice of method was qualitative methods.
Furthermore, the modelled guideline will be presented and the validation of the data will
be done by using the CDS workbench tool. The study framework is presented in figure 2.
Figure 2 The study framework
Study Design
There are a lot of different study designs that can be used in a research study. The
different designs differ from each other making the choice multiple for researchers and
8
their studies (33). Study designs all have different techniques and methods that are used
for the collection and analyse of the generated data. It is important to choose a study
design that suits the problem description and the aims of the study to get the best results.
To answer a research question there are a series of steps that must be done. These
necessary steps are defined by the different study designs and this is because they are like
a systematic plan (33).
For this study a descriptive study design has been selected. It is a study that is identified
to “describe systematically and accurately the facts and characteristics of a […] area of
interest” (34). This study design allows the research to use both qualitative and
quantitative approaches. Both one-time and over-time are interactions that can be done
with the respondents. For this study one-time interaction is used where the respondents
give feedback and participate in a semi-structured interview. With a descriptive study
design the collection of the information takes place before the experiment. The collected
data is later included in the experiment (34). According to the aims set in the previous
chapter the descriptive study design suits the needs of the study as it gives the possibility
to provide a qualitative answer regarding the feasibility of the integration between EHR
and the QR. It can also provide answers regarding what problems this integration could
solve. The information is firstly collected and the applied to the modelling for the data
transfer.
Study approach
With a qualitative method, it is usually easier to get measurable data of a phenomenon
with different backgrounds and from different environments by e.g. semi-structured
interviews. It is usually hard to sort the collected data (33).
For this study the mixed-method approach is used allowing the research to combine both
qualitative and quantitative methods. Johnson Onwuegbuzie describes this method more
precisely: “Mixed-methods research is formally defined as the class of research where
the researcher mixes or combines quantitative and qualitative research techniques,
methods, approaches, concepts or language into a single study(35).
Taking the aims, objectives and the second research question into considerations a
qualitative approach was more appropriate to provide the needed answer. The first
research question was better to answer with a quantitative approach regarding the
9
modelling with data collected from the interview. By collecting qualitative data from an
expert using semi-structured interview the evaluation of the study was possible to
examine. The interview with the expert also provides the study with feedback for the
selected elements for the modeling of the archetype and the guideline for the AF QR.
This qualitative data was important and crucial for the modelling of the archetype and the
guideline. It was also important to get feedback on why these elements were significant
which could only get done by using a qualitative approach. Subsequent modelling of the
acquired knowledge is done by using OpenEHR technology and GDL.
Data collection and analysis The first step, as shown in figure 2, was the selection of existing archetypes and
guidelines. A literature review was preformed to assemble a collection of information
about AF using databases such as PubMed, the online university library of Karolinska
Institutet and the search engines Google and Google Scholar. The following keywords
were used:
Atrial Fibrillation
Protocols
Diagnosis
Guidelines
Quality criteria
Standards
The guideline was analyzed with certain criteria that were based on previous studies for
the needs of this study. The following criteria were used:
For better future research the guideline needed to be written within the past four
years.
The guideline needs to be national or international for the generalization of the
results.
The guideline needs to be in English language.
The second step in the study framework was the elicitation of the text-based rules from
the selected guideline, which was the European society of cardiology (ECG). ECG
10
guidelines were followed due to the reason that the National Board of Health and Welfare
in Sweden didn’t update their guidelines. Expert feedback from a specialized cardiology
nurse was given on the text-based rules. Some of the rules were deselected and new ones
were added (presented under section “Selected guideline”).
The third step was the elicitation of the archetype and guideline. GDL is built upon the
openEHR RM and archetypes, therefore it needs to use archetypes to be able to operate.
In order to locate the archetypes needed for the study the International Repository of
Archetypes was used. The required codes to locate the external terminology were
searched in the following databases: the Anatomical Therapeutic Chemical (ATC) and the
International Classification of Disease (ICD).
A semi-structured interview was also performed with the expert to notice possible gaps
that could be identified that later was analyzed using content analysis.
Interview with expert
The questions used for the interview were semi-structured, which means that they are
open and the respondents can answer with their own words (36). The medical expert was
a specialized cardiology nurse who was selected because of the involvement within the
Auricula registry. It was important that the respondent had a significant role in the project
involvement for the AF QR. The information about the guideline for the registry needed,
to be as up-to-date as possible. Therefore it was important that the respondent worked
closely with the Auricula registry. A medical background was preferably due to the
importance of the selection of the text-based rules for the guideline. The interview
questions were asked in English language, which is not the native language of the
respondent or the researcher. There were no difficulties reported in the communication
during the interview. A speculation is that the answers could have been answered
differently if they were asked in the native language (Swedish) of the respondent. The
study was performed at a place where the environment was familiar for the respondent.
Some of the questions asked were to clarify how the situation is today without the
integration between EHR and Auricula QR, and what problems it hypothetically could
solve. The importance of the integration and how it would decrease the manual labour
was of interest, and also how it could be in the future and if this integration could make
any improvements. A model of today’s situation without the integration and how it could
11
be if the integration was successfully implemented was presented to the expert to get
feedback on possible corrections.
Content analysis
In this research study the method Content analysis is applied. There are two main
directions in the content analysis, quantitative and qualitative. For this study the
qualitative direction was chosen. This method is differently interpreted by those who
use the method. It can help the researcher to get a clearer picture on how the situation
is about specific things. There are some downsides with this method and it is the
transcription of the interviews. It takes a long time and can make it hard for the
researcher to get finished in time. Another thing is how the researcher will choose to
analyze the collected data, there are a lot of interpretations on how to do this. One
thing to keep in mind when using content analysis is to always be as objective as
possible in the analyze of the data. Content analysis is carried out in three phases
which are more described under “Study design. They are the preparation phase, the
organizing phase and the reporting phase, where the researcher is analyzing the
process and the results. These analyzing steps are used to help answering the research
question (37).
How content analysis is applied
To analyze the data collected from the interview the method content analysis was chosen.
Because only one interview was performed this method was best suited for the results to
become as eligible as possible. The collected data is analyzed through three phases. The
first phase is the preparation phase, the second one is the organizing phase and the third is
the reporting phase, see figure 3.
12
Figure 3 The three phases in content analysis
For content analysis there is not a systematic way or set of rules of how to analyze the
data, even though there are different steps. The important thing is that the words get
classified into categories. In the preparation phase the researcher starts by selecting e.g.
words that are of interests. Before that it is important that the researcher decides on what
is going to be analyzed and in what detail. Before the analysis begins the researcher needs
to decide if the latent content or the manifest content should be analyzed (37). The
collected data from the interview was taken in by the researcher with open eyes, which
means without preconceptions. Glaser (38) describes this technique as following:
“The mandate is to remain open to what is actually happening and not to start filtering
data through preconceived hypotheses and biases to listen and observe and thereby
discover the main concern of the participants in the field and how they resolve this
concern”.
The researcher needs to get familiar with the collected data by reading the interview
several times. The researcher read through the transcription of the interviews and
analyzed it by using “line-by-line” (39). This means that each row in the transcription was
separately coded. This gives the research an opportunity to stop and think about what
each thing is about and how the respondent thinks. Gibbs is saying that (39) “What is the
most useful about it is the headings you get, the codes you come up with in the end. That
you might want to reuse “ (39).
The interview gets transcribed and the parts that are interesting or thought-provoking get
highlighted, this step is called open coding. The next step is to organize the data. Short
summaries can be noted down on the side. After when the researcher has done this
13
process through the whole transcription the summaries will be compared to each other to
see if they are similar enough to create clusters. Depending on the similarities or
differences of the cluster they will create different core categories. If the result from the
first step are of satisfaction and providing the researcher with a complete picture the next
step can take place. All the categories, heading and notes will be grouped according to
similarities or dissimilarities. The aim is to reduce the categories and notes, this step is
called grouping. The last step in phase two is the abstraction. In this step the categories
are getting organized according to the relationship they have to each other and then it all
gets woven into a core process. Depending on the relationship to the categories they can
have main categories, a generic category and sub-categories.
The last phase is the “Reporting the analyzing process and the results”. This is where the
models or the conceptual systems, conceptual map or the categories can be presented. It
depends on how the researcher wants to present the result.
Finally a model over how the integration could work and improve the situation today is
created (presented in the results section).
The fourth step of the study framework shown in figure 2 is to convert the text-based
rules to computer interpretable CDS rules using GDL.
The final step was to evaluate the GDL using a validation, which in this study means that
the purpose is to answer questions like “Is it doing what it is supposed to do?” (40). To
answer questions like that mock patient data was used on the GDL (see appendix C) for
the automatic compliance using a CDS workbench tool.
A manual check is performed as well. For the validation 15 mock patients were created
with different values, some of them got extreme values and some less to assess how GDL
manages the different input values. It should be noticed that the expert did not review the
final guideline, but the supervisors of the thesis did. They have experience regarding the
modelling for archetypes and the guidelines.
14
Software tools
The following tools were used in the study to create the archetype, template and the
guideline:
1. Ocean Archetype Editor1 is an open source tool developed by Ocean Informatics. The
tool supports modelling “of archetypes as part of the openEHR initiative and the CEN
HER standardization.” (41).
2. Ocean Template Designer5
is also developed by Ocean Informatics. “The Template
Designer allows users to compose a set of archetypes into a collection called a
template. This can be used for data entry, as the basis for a form or for creating a data
schema for bringing data into the openEHR environment. The user can use those
archetypes and features of archetypes that are required as well as setting default
values, limiting choices, naming fields, removing unwanted fields etc. as required for
a particular use environment” (42).
3. GDL Editor2 is an open sourced multiplatform desktop application developed by
Cambio Healthcare systems. “The GDL editor is multiplatform application that
allows users to create, edit and run GDL files. GDL is a formal language designed to
represent clinical knowledge for decision support. It is designed to be natural
language- and reference terminology- agnostic by leveraging the designs of openEHR
Reference Model and Archetype Model. The tool provides an editing and testing
environment capable of generating forms based on the elements defined in the GDL.”
(43).
4. The CDS workbench tool is developed by Cambio Healthcare Systems. CDS
workbench is an application that simulates and EHR environment where patients with
mock data can be created and CDS rules can be applied. Therefore it can also be used
to validate GDL rules. Mock patient data was applied on the GDL guideline.
Validity and reliability
Validity determines if the research is measuring what is wanted to be measured and
reliability is the ability a research can be relied on. Validity and reliability is perceived
1 http://oceaninformatics.com/solutions/knowledge_management
2 http://sourceforge.net/projects/gdl-editor/
15
differently in qualitative and quantitative research studies. For this qualitative study two
validations strategies of Creswell and Miller’s eight were used for the insurance of better
validity and reliability of the results (44).
Rich , thick description
Member checking
The results in this research study are generalized, meaning that this study is not specific
to just on setting. Other researchers are offered abundant descriptions of the methods used
and the results. Even if the study is amid for the QR for AF the same technical solution
would work for other registries that want to have an automatic transfer of information
between the EHR and the specific registry.
Ethical considerations
There are ethical and legal consequences when carrying out a study. This study is both
using theoretical aids and expert feedback to help answer the research question. The
respondent was interviewed in his/her professional role and will be kept anonymous in
the study. The expert was asked if he/she wanted to participate and got an explanation on
what the report was about. The respondent was also asked if it was ok to record the
interview for better possibilities to analyze and transcribe the interview. Due to the fact
that no real patient data was used the ethical considerations regarding patient privacy was
not an issue. The work in this study is independent of Cambio Healthcare Systems
interests to avoid considered biased.
Another thing that should be mentioned is that the co-supervisors role was to provide
guidance and feedback to make sure that the research followed was correct on the relation
to openEHR, archetypes and the GDL. The study’s reliability is not threatened and there
are no ethical concerns from his involvement.
Results This part presents the results from the different steps described in the method. The
different section will describe how the integration could be possible with openEHR
technology and what improvement it could mean. The assessment of GDL for AF in the
clinical area will also be presented.
16
Selection of guideline From the first step described in the method information about what distinguishes AF and
other important factors regarding the cardiac arrhythmia was researched for. “Guidelines
for the management of atrial fibrillation - The Task Force for the Management of Atrial
Fibrillation of the European Society of Cardiology (ESC) 2010” was the selected
guideline according to the criteria described in the method . This guideline is “developed
with the special contribution of the European Heart Rhythm Association (EHRA) and
Endorsed by the European Association for Cardio-Thoracic Surgery (EACTS)” (18).
Over the course the Swedish National Board of Health and Welfare have been working
on releasing guidelines and for future work those can be used and discussed.
Important factors that were selected for atrial fibrillation: Registration date, Type AF
(first-time / non-permanent / permanent), Thyroid samples, Echocardiography, Heart
failure, Hypertension, Diabetes, Stroke/TIA, Vascular disease, Anticoagulants
(Warfarin/Dabigatran/Rivaroxaban/Apixaban), S-creatinine (creatinine), GFR, Reason
for not anticoagulants (contraindication/unwillingness of patient/other), Platelet
(ASA/Clopidogrel), Patient education has been offered. The elements were acknowledged
based on expert feedback.
Selection of text-based rules Expert feedback from the cardiology nurse was given on the selected text-based rules.
Two of the rules were removed and one was added. The elements S-creatinine (creatinine)
and GFR were taken away. The two elements were removed because the steering
committee for the Auricula registry always reflects on how to improve the registry and
how to make it as effective and useful for the users as possible. Ideal scenario would be to
ask much more questions than presented. But that would need a lot of action from the
user which is something that can’t be expected from them.
1. Registration date - (00 00 00)
2. Type AF - (first-time / non-permanent / permanent)
3. Echocardiography - (date of last ECG/ no ECG performed)
4. Thyroid samples (Present / Absent)
5. Heart failure (Present / Absent)
6. Hypertension (Present / Absent)
17
7. Diabetes (Present / Absent)
8 Stroke / TIA (Present / Absent)
9. Vascular disease (Present / Absent)
10. Anticoagulants (Warfarin / Dabigatran / Rivaroxaban / Apixaban / Absent)
11. Reason for Not anticoagulants (contraindication / unwillingness of patient / other)
12. Platelet (ASA / Clopidogrel) (Present /Absent)
13. Patient education has been offered (Present / Absent)
Modelling of openEHR archetypes and the guideline
openEHR archetypes
The archetypes presented in this section are the ones that were used to model the
guideline for the integration in GDL.
Two reused archetypes in this study without any changes:
openEHR-EHR-COMPOSITION.medication_list.v1
openEHR-EHR-EVALUATION.problem-diagnosis.v1
Three archetypes were modified for the needs of this study:
openEHR-EHR-OBSERVATION.imaging_exam.v1
o openEHR-EHR-OBSERVATION.imaging_exam-Echogardiography.v1
openEHR-EHR-OBSERVATION.lab_test-thyroid.v1
openEHR-EHR-EVALUATION.stroke_prevention_review.v1
One new archetype was created for this study:
openEHR-EHR-OBSERVATION.basmodulen.v1
Figure 4 shows what the created archetype contains and what questions will be asked
when it is in use. The rest of the mentioned archetypes are provided in appendix “A”.
18
Figure 4 The Basmodulen archetype
The Basmodulen archetype was further modelled as a guideline in GDL to make the next
step of the integration. When archetypes are created the templates are created - and in the
GDL the template of each archetype is used and this is to be able to reuse it several times.
Basmodulen is the name of the created archetype. The name Basmodulen is also applied
for the guideline for the Auricula QR, which is presented further down.
Terminologies
The terminology codes used in this work was ATC and ICD10. They were used to bind
relevant diagnosis from an EHR.
ATC codes
Warfarin - B01AA03
19
Dabigatran - B01AE07
Rivaroxaban - B01AF01
Apixaban - B01AF02
ASA - B01AC06
Clopidogrel - B01AC04
ICD10 codes
Heart failure ICD10 I5.0
Hypertension ICD10 I12 , I13 , I10 , I11 , I15
Diabetes ICD10 E11 , E10 , E13 , E12 , E14
Stroke/TIA ICD10 G45.9 , I63 , I69.3
Vascular disease ICD10 I24.9 , I25.8 , I25.9 , I25.5 , I25.6 , I73.9 , I25.0 , I25.1 ,
I25.2 , I72 , I71 , I21 , I22 , I70 , Z95.1
Model of the guidelines To ease the extraction over how the guidelines are used and connected to each other they
can be seen in a graphical representation showed in figure 5. Only selected parts from the
guidelines are presented.
The different colours indicate whether it is a guideline, an archetype, a template or if it is
taken from an EHR or CDS. The green boxes are the three guidelines used in this study.
The yellow shows that the information is taken from the EHR. The purple shows that
information is stored from the guidelines or that information stored from a previous
guideline is used as input for the next guideline. In some of the yellow and purple boxes
the letter A and T are shown and they stand for archetype and template. The green box to
Figure 5 Model over the connections between the used guidelines
20
the left is the Basmodulen guideline and it shows if the guideline is using archetypes and
templates and if it is taken from the CDS or the EHR. In this case the Basmodulen
guideline is using the Basmodulen template, it is the purple box under the green. The
yellow boxes are templates taken from the EHR, and they are the medication,
throid_function_test, echocardiography and Basmodulen. The two purple boxes are an
evaluation archetype called stroke_prevention_review and chadvas_diagnosis_review.
These are used for the Basmodulen guideline, then to further build it two other guidelines
are used, in the middle is the CHA2DS2VASc__diagnosis_review because the archetype
is used for the Basmodulen and the last guideline used to the right is the
Stroke_prevention_alert. The arrows show how they are connected and used. Each yellow
and purple box has their own elements as well.
Results from the content analysis Three core categories were shaped by the interview using content analysis and they are:
research, manual entry and quality registry. Except only getting information about the
guideline it was also of interest to understand the importance of the integration and what
problems it could improve. The three categories presented below were the main findings
where the work process is described without the integration and what possible
improvement the integration could have.
Research
Research is an important part for the health care but the way of collecting available
information today is not as good as it could be. A lot of information is entered manually
into the medical records that later is written down on paper. The research field could
benefit a lot from the integration between the EHR and the Auricula registry. New
research findings could be found easier and much faster than today. With the registry the
possibility to ask more questions to gain more research would also be a possibility.
"I believe that with the integration you will be able to ask much more questions than we
do today so that we get better research, faster research, you could pull reports in minutes
so that you have information that currently takes an incredibly long time to obtain. So I
think we will be able to accelerate research immensely if we integrate and utilize the
information we have, it's probably the biggest."
Reports could be printed out in minutes that today take a very long time. The research
could accelerate immensely due to the integration and utilization of the information that is
21
present. Another thing with the integration would be a much clearer connection to the
research and the QR that is connected to the different medical records. There will be
quick ways to affect what questions are asked in the registries and how it is built up and
how the information will be caught. This is not an easy task, how will this be documented
and who has written what and when, are important questions. It is important that the user
knows what information is accessed.
"It is a win for the workers in the health sector from a staff perspective but also a big win
for both research and ultimately patients if the integration gets implemented. That I'm
sure of."
Manual entry
The manual input will always be deselected, it is a user resistance that only increases - the
technology is there it is just not used yet.
"[...] to conduct research at a level so that you have a better basis for what it is being
claimed. Manual input will always be deselected because the health care today is so
congested, it is a moment that feels very unnecessary and it is a user resistance that only
increases because we know that the technology exists"
Another thing would be that the time is more on the administrative work than on the
patients. It takes a long time to do the manual input and that time could instead be spent
on patients. The integration makes the time to a much greater extent and it can obtain
larger volumes of data with less effort from the users. This is a great benefit for patients
but also to the health care because it is not burdening.
"It's a frustration out there in the health care, it can be done smarter if you now maybe
want to be there for the patients' sake, or I think many people feel that they are there for
the sake of the patients but they need to put a lot of time on administrative tasks."
A problem today is that the Auricula registry have patient from the specialized medical
care, but the large group is out in the primary care and there is not enough information
about that group. That’s where the big treatment problem is, so the problem is that the
data you get up – either the Auricula registry is very good at treating it because they are
in the registry or there are registries in places where they are very good at treating. It is
hard to know what is what here. And this is a big problem with the manual entry that
could be solved with the integration. It is important to know that the integration won’t
22
solve everything because it will need some action from the caregiver but a lot could be
solved with it.
Quality registry
An incentive for a user to input information is that they get something in return from the
system that is usable. If the user only gets a report one year later that would be poor
payback for the manual work. If there is integration to a decision support then the output
from the system could be possible.
"An incentive for a user to input information is that you get something out of using the
system. If I as a user do not get anything back, perhaps a research paper a year later then
it is poor payback of using a system."
It is hard to say what role QR plays for the future development of knowledge and quality
in the health care due to legal aspects. There are registries that contains good research but
they are not legal making the future for the development for QR hard. If there is a way to
meet the legal requirements of collection patient data and to share it the quality registries
can be used in their full potentials.
"Very many registry today that have good research and succeeded, they're not legal, it's
the only problem, if you can resolve the legal aspects then this has a place otherwise you
have to think differently."
Model of the integration If the openEHR technology was used it would report everything automatically to the QR.
Everything happens on the regional level where the general practitioners, hospitals, health
centres, private clinics are. Today they are all reporting manually to the Auricula QR, and
it is often the nurses that get the extra workload. Because there are a lot of reporting to do
to the QR this is the task they sometimes end up with instead of focusing on their actual
job and spending more time with patients. The CDS gets information from the EHR and
the cardiologist is using the CDS to get the information they need. With the integration
the cardiologist could directly report everything with the help of openEHR technology to
the QR. Figure 6 presents a model of how it looks without the integration today and how
it could look in the future with the integration.
23
Figure 6 How the integration could work
Another goal with the integration is that everyone who meets fibrillation patients is
recording that in to the registry. It does not matter if they are in the health care system, if
they are at a private clinic, at the emergency department or a specialist department.
Specification of GDL rules One GDL guideline was modelled for the Auricula QR to meet the needs of this study:
Basmodulen guideline for patients with AF.
Basmodulen guideline
The modelled guideline for the registry in this study is named by a Swedish name called
“Basmodulen”, to keep a consistency throughout the research the Swedish term will be
used. The Basmodulen guideline is used to collect information and evaluate fibrillation
patient’s condition. It monitors what kind of AF the patient have, if they’ve got a
diagnosis, what kind of medication they are treated with, the thyroid and
echocardiography is tested and if the patient has been offered patient education or if there
is any reason for deviation. To make the guideline and the data input more accurate a rule
24
for the registration date was set. If any values are missing in the registry when data is
being inputted then the outcome was empty for all elements. The cardiologist needs to fill
out everything, e.g. if the patient don’t have the diagnosis diabetes then he/she needs to
put the value to “Absent”. From a health informaticians perspective this is the better way
to get accurate data in the registry. The risk could otherwise be that the registry get
reports with missing values. Figure 7 presents how the condition and the action for the
registration date is built in the GDL.
Figure 7 Condition & Action for registration date
Dream scenario would be to ask much more questions than presented, but that would
need a lot of action from the user which is something that can’t be expected from them.
Figure 8 shows the execution of the registry for AF from the GDL. All the text-based
rules are present there. The different elements and their function will be described below.
25
Figure 8 The execution from GDL
Type of AF
There are different types of AF a person can have and in this section the cardiologist will
check if the patient have a permanent AF condition or if it is the first time or not
permanent.
Co-morbidity
The co-morbidity is the part where the different diseases the patient have or doesn’t have
are presented. What the cardiologist will do is to put the value to each disease to
either ”Present” if the patient have the disease or ”Absent” if the patient doesn’t have it.
Medication
In this section the cardiologist can search for a medication that is going to be given to the
AF patient. In this registry the medications that can be selected are the Warfarin,
Dabigatran, Rivaroxaban, Apixaban, ASA (Acetylsalicylic acid, Aspirin) and Clopidogrel.
26
Thyroid Result
This section is to check the thyroid. There are several ways of calculating this but the
only thing that is of interest from an informaticians perspective is not what the result is
but if there is any result. So if the cardiologist puts in any information about the patient
thyroid condition it will show ”Present” and if there is no information then it will be set
to ”Absent”.
Echocardiography
This part is similar to the thyroid result. The result value works the same way. If there is
information available then the system will show that it is ”Present” and if not then it will
put it to ”Absent”. Another thing is that the cardiologist can set the date when this was
last performed.
Reason for non-anticoagulant
This is to get more information about reasons for deviation for treatment. The different
choices are; contraindication, patient choice (unwillingness of patient) and any other
reason. There is also a choice for patients to get patient education if they want, if they do
then it will be set to present.
To execute all the elements in the Basmodulen guideline as described above rules needs
to be modelled. Each element will have their own rule, figure 9 shows the list of rules for
this guideline to generate and execute everything.
27
Figure 9 The rule list
Each element in the Basmodulen guideline needs to have a rule. They have different rules
that tell how they need to function. For example the rule for the thyroid test is built so
that the rule checks if there is any result existing. That is the only thing that is of interest
here. In the conditions seen in figure 10 the rules are set and in the action is where the
actions are, meaning that thyroid tests for the QR taken from the CDS is set to ”Present”.
All the rules for the guideline are provided in detail in appendix ”B”.
Figure 10 Thyroid test rule
28
Validation using mock patient data To validate the design of the Basmodulen guideline mock patient data was applied using
the CDS workbench tool where the automatic compliance was checked with a manual
check. The execution of the guideline contains fifteen patients that all have a unique
combination that is tested.
The GDL guideline was assessed according to how it handled patient data with different
values, some of them are extreme to see if the guideline could handle it and if the results
came out correct. Figure 11 presents the different types of AF and how many patients that
got it. Out of 15 patients 13 were diagnosed with AF, five patients got first time, five got
permanent, three got not permanent and two patients are missing the diagnosis. This is the
result the CDS workbench produced and they were all correctly identified. In appendix
“D” the execution log for each patient can be found.
Figure 11 The result of how many patients that have AF
All 15 patients were correctly classified which is very important for the function of the
integration, figure 12 presents the statistical numbers for all rules. It shows what rule is
tested and how many patients out of fifteen that has the specific diagnosis.
29
Figure 12 Execution outcome
To assess if GDL could handle extreme values some mock patients got everything filled
out while some patients only got two, three elements and the rest was set to empty. Each
mock patient got their values checked if it was correctly identified.
Discussion This section presents the discussion of the results from the interview and from the
guideline validation. The limitations this study has encountered will be discussed and also
the strengths and weaknesses with the study. At the end possible future research will be
mentioned.
In accordance to the aims and objectives described for this study a guideline of the AF
QR was modelled in GDL, which is a computer interpretable model. The guideline
Basmodulen was based on expert feedback and then applied and validated using mock
patient data in the CDS workbench. There is a process of modelling the GDL guideline
using different steps such as creating the archetype for it and then the template. To get
30
more understanding about the guideline and the elements used for AF an interview with
an expert in the field was performed. This gave an understanding of how the situation is
today and how this could change and improve the work process in some areas in the
health care. Moreover, the situation today and how it could be with the integration
successfully implemented was presented in a model. The guideline and what
archetypes/templates were used were also presented in a graphical model showing how it
all is connected. The last step was to validate the guideline using mock patient data using
the workbench.
Discussion of results The result of content analysis provided the study with an insight of how the process of
collection information is today without the integration and how it could be if it existed.
The result from the expert feedback was very important for the CDS rules to become
accurate. The interview provided the study with an understanding of the importance with
the integration and what is means for the health care. A lot of time can be saved and the
health care personnel that are doing the reporting today to the QR can spend more time
focusing on the patients instead of the administrative work. The health care would also
benefit from the integration in the way of getting more information through research. This
means that collection information could be done faster which would lead to faster
improvements on treatments for the patients. A model was created over how the situation
is today without the integration and how it could be with it. It was a good way to use as
an example to communicate with the expert. The feedback on the model was important
to be able to show how the integration could be integrated and where the openEHR
technology and GDL would be used and implemented in the health care system on the
regional level.
Another interesting finding was noticed during the modelling of the guideline. Type of AF
didn’t have any ICD10 terminology binding in GDL for the classification of diagnoses
(permanent, not permanent and first time). This is something that could be of interest for
future research on how to improve and make the GDL guideline more accurate regarding
details that the cardiologist is more familiar with. This is also important to acknowledge
that the integration is meant to bind two “sides” of the health care which is the health
informatics and the cardiologists/nurses sides. The communication here is important and
therefore the basmodulen guideline needs to be as familiar for them as possible otherwise
31
the risk could be that it will not be used in the manner it should be. But it is also
important to mention the flexibility GDL offers regarding the type of AF. Since there
wasn’t any terminology binding existing GDL still gave the possibility to check what
kind of AF condition that was assessed.
Regarding the integration for the data transfer from EHR to Auricular QR is shown to be
theoretically/technically possible. The openEHR technology using archetypes and
templates together with GDL gives the integration an opportunity to be automatic. The
openEHR technology provides the user with archetypes that can be reused as an input and
output, and this is based on the work created. Only one archetype needed to be created
from scratch, as described under the result there were other published archetypes that
could be reused for the need of this study. Archetypes used as input or output in GDL
makes the sharability possible to share CDS rules across different systems, GDL
enhances that which makes the opportunity of an automatic transfer of data possible.
The distribution of health care computing by exchanging data across different systems is
today a major challenge but also an important requirement (30) (29). The openEHR
standard has advantages for the integration of EHR and the QR. Archetypes and
templates are used to achieve standardization of data formats (29). The registries might
get easier to populate with already existing data from the EHR and to create and maintain
the registry and make adjustments to it (32). Another advantage that openEHR might
have for the integration is to simplify modifications and reduce the effort to create and
maintain the registry. Another advantage could be that already existing data in the EHR
could be used for more rapid population for the registry (22)(32). The validity of the
claims mentioned above is of interest for the thesis.
Limitations A primary limitation of this study was that only one person was interviewed. The
respondent is an expert in the area and therefor the collected information was qualitative
representative. But more interviews with experts with the same title for other registries
would be interesting to interview too. It could have shaped the results differently in the
matter of GDL rules but also for the picture of how the integration could work from their
perspective and experience.
32
This study has been limited to one quality registry, specifically for AF. A comparison
between more registries could give more interesting result so time is one limitation.
Comparing several registries with each other and that more people could be involved in
the developing and maintenance of the QRs are needed to be interviewed to give the
study additional interesting findings.
Another limitation is that the final guideline did not get reviewed by the expert. If it did
there might have been some changes from the respondent’s perspective and background.
The verification of the modelling in openEHR, GDL and the integration architecture did
however get reviewed by the supervisors of this thesis.
Strengths and weakness of the study A strength with this study was using the content analysis method. This approach gives the
researcher the possibility to collect richer information (45). The qualitative result and
information is the strength of this study because it gives an understanding of the situation
today and provides a wide understanding of GDL guideline.
Another strength of the study would be that the respondent is involved with both sides -
the healthcare and the health informatics. If the respondent did not have any involvement
with informatics and did not have an understanding of their picture of the situation then
the result could have got another shape. This way the respondent had a lot of knowledge
and experience from both perspectives.
A weakness with the study would be that there only is one person being interviewed.
Even if the result from the respondent is qualitative representative, they could have been
generalized if there were more experts with the same title interviewed. Not only for the
AF registry but others too.
Alternative method
Qualitative and quantitative are two approaches a study can have that differ from each
other. Using a quantitative approach it is often easier to sort the collected data and to
quantify and validate it. The focus for quantitative methods is more on numerical data and
answer to questions like how many? And how much? (33). For this study a questionnaire
could be used as an alternative method together with the Delphi method where a lot of
33
different questions could be asked regarding the standards of transferring data between
the systems.
The Delphi method is an iterative process where experts in the field of Clinical Research
are included and shares their expert knowledge and feedback according to the area. A
Delphi panel could be used where a couple of panel members are chosen after
consideration. According to literature it can be good to have about five to twenty
panelists where they are all mixed but still have experience in the area(46). Using more
expert feedback and knowledge could have given the study different results. Maybe,
according to their knowledge and opinion there could have been other standards of
transferring the data, for example by using HL7.
This also means that the study can get guided according to Clinical Research trends (40).
The expert knowledge would also lead the study to what is most important to focus on.
Furthermore, the validity of the study results would be higher because of the iterative
integration of expert knowledge.
Future research For future research more experts should be involved and interviewed from other registries
to overcome the study’s limitations. A comparison between the integration for the
Auricular QR and another registry would be an interesting research. If the outcome of
both registries would be the same then there is a stronger argument for an automatic
integration between the EHR and the QR. To get more reliable results the integration
using the GDL should be assessed on real patient data.
Another future study is how to use the integration in its fullest potential. It would also be
interesting to include more elements in the GDL guideline for the registry to get more
information and knowledge about AF patients and how to treat them better. But for this
study the focus would lie more on QR and how to use them in their fully potentials.
Today there are legal aspects that blocks the QR’s from being used as they could. The
results from this could give QR the chance to be used as they should meaning that the
need of integration could be even bigger than today.
34
Conclusion
This study aimed at evaluating the feasibility in the integration and transfer of EHR to
QR by using openEHR technology and GDL. The expert feedback provided the study
with important data about the information needed for the guideline. The knowledge from
the expert assisted the researcher in shaping the rules by feeling the gaps in the
information for the guideline. The interview helped answering the questions regarding the
problems today without the integration and what could be improved with it and why it is
important to have integration between these systems. The rules for the GDL guideline
basmodulen was later validated as CDS rules in the workbench with mock patient data.
The validation indicated that GDL can be used for modelling guidelines in the area for
AF but also that the results corresponded with each other.
The openEHR technology can be used for an automatic transfer of information between
EHR and QR with the opportunity of reusing already existing archetypes as input and
output in together with GDL. Archetypes and templates were used in GDL to model the
basmodulen guideline. One new archetype was created and the possibility to reuse
already existing archetypes made it possible to base them on each other in GDL to model
the guideline. The openEHR technology and GDL makes the sharability of CDS rules
possible across these systems making the possibility of an automatic transfer of data
between them. Theoretically/technically the integration can be done.
35
References
1. Hynes D, Perrin R, Rappaport S, Stevens J, Demakis J. Informatics Resources to
Support Health Care Quality Improvement in the Veterans Health Administration.
J Am Med Inform Assoc 2004; 11(5): 344–350.
2. Livari J, Hirschheim R. Analyzing Information Systems Development : A
Comparison and Analysis of Eight is Development. Information Systems
1996;21(7): 551–75.
3. Kalra D. Electronic Health Record Standards. Yearb Med Inform. 2006:136-44.
4. Menachemi N, Collum TH. Benefits and drawbacks of electronic health record
systems. Risk management and healthcare policy. 2011;01 47–55.
5. Hoerbst A, Ammenwerth E. Electronic health records. A systematic review on
quality requirements. Methods Inf Med 2010;49(4): 320-36
6. Weiskopf NG, Weng C. Methods and dimensions of electronic health record data
quality assessment: enabling reuse for clinical research. J Am Med Inform Assoc
2013 Jan 1;20(1):144-51.
7. Robert Wood Johnson Foundation, MGH Institute for Health Policy, George
Washington University Medical Center. Health Information Technology in the
United States: The Information Base for Progress. 2006. Available at
http://publichealth.gwu.edu/departments/healthpolicy/CHPR/downloads/EHR_ann
ual_report_2006.pdf
8. Federal Register. Department of Health and Human Health Information
Technology : Initial Set of Standards , Implementation Specifications , and
Certification Criteria for Electronic Health Record Technology 2010.
9. Committee on Quality of Health Care in America, Institute of Medicine. Crossing
the Quality Chasm: A New Health System for the 21st Century, Washington, DC:
The National Academies Press; 2001.
10. Richardson JE, Ash JS, Sittig DF, Bunce A, et al. Multiple Perspectives on the
Meaning of Clinical Decision Support. AMIA 2010 Nov 13;2010:1427-31.
11. Zhou L, Karipineni N, Lewis J, Maviglia SM, et al. A study of diverse clinical
decision support rule authoring environments and requirements for integration.
BMC Med Inform Decis Mak 2012 Nov 12;12:128.
12. Pelec M, Tu S, Bury J, et.al. Comparing Computer-interpretable Guideline
Models : A Case-study Approach. J Am Med Inform Assoc 2003;10: 52–68.
13. Sveriges Kommuner och Landsting. Översyn av de nationella kvalitetsregistren -
Guldgruvan i hälso- och sjukvården. Socialdepartementet och Sveriges
36
Kommuner och Landsting 2010. Available at
http://www.registercentrum.se/sites/default/files/dokument/guldgruvan_i_halso_o
ch_sjukvarden.pdf
14. Agency for Healthcare Research and Quality. Registries for Evaluating Patient
Outcomes : A User ’ s Guide. AHRQ 2007;04. Available at
http://www.effectivehealthcare.ahrq.gov/repFiles/PatOutcomes.pdf
15. Ferguson C, Inglis SC, Newton PJ, Middleton S, Macdonald PS, Davidson PM.
Atrial fibrillation: Stroke prevention in focus. Aust Crit Care 2013;08 92-98.
16. Auricula. AuriculA Atrialt Flimmer och Antikogulationsregistret. Uppsala; 2012.
Available from: www.ucr.uu.se/auricula
17. Auricula. "Om Auricula". Available at
http://www.ucr.uu.se/auricula/index.php/om-auricula (last accessed 25 April
2014)
18. Camm JA, Kirchhof P, Schotten U, Savelieva I, et al. Guidelines for the
management of atrial fibrillation: the Task Force for the Management of Atrial
Fibrillation of the European Society of Cardiology (ESC). Eur Heart J 2010;10
(19):2369–429.
19. Gasser U, Palfrey J. Breaking down digital barriers: When and How ICT
Interoperability Drives Innovation When and How ICT Interoperability Drives
Innovation 2007. Available at http://cyber.law.harvard.edu/interop/pdfs/interop-
breaking-barriers.pdf
20. Chen R. Towards Interoperable and Knowledge-Based Electronic Health Records
Using Archetype Methodology [ No.1280]. Linköping: Linköpings universitet
2009.
21. Rodrigues, J. M., V. Stroetmann, et al. Conceptual Framework for eHealth
Interoperability, Deliverable 1.1 of the SemanticHEALTH Project 2006. Available
at
http://www.semantichealth.org/DELIVERABLES/SemanticHealth_D4_1_final.pd
f
22. Kalra D, Beale T, Heard S. The open EHR Foundation. Stud Health Technol
Inform 2005;115:153-73.
23. openEHR Foundation. "What is openEHR?" . Available at
http://openehr.org/what_is_openehr (last accessed 3 April 2014)
24. Raymond ES. The cathedral and the bazaar: musings on Linux and open source by
an accidental revolutionary. Sebastopol CA: O’Reilly Media Inc; 2001.
37
25. Beale T, Heard S, Kalra D, Lloyd D. Architecture Overview. Ocean Informatics
2006: 1–45. Available at
http://www.informedici.nl/downloads/literatuur/EHR_overview.pdf
26. Leslie H. "Introduction to Archetypes and Archetype classes" Available at
http://www.openehr.org/wiki/display/healthmod/Introduction+to+Archetypes+and
+Archetype+classes (last accessed 26 April 2014).
27. openEHR Foundation "Clinical Models Program". Available at
http://www.openehr.org/programs/clinicalmodels/ (last accessed 25 April 2014).
28. Chen R, Corbal I. Guideline Definition Language ( GDL ). Release 0.9. 2013: 1–
23.
29. Anani N, Chen R, Moreira TP, Koch S. Retrospective checking of compliance
with practice guidelines for acute stroke care: a novel experiment using
openEHR’s Guideline Definition Language. BMC Med Inform Decis Mak 2014:
14:39 1-18
30. Chen R, Klein GO, Sundvall E, Karlsson D, Åhlfeldt H. Archetype-based
conversion of EHR content models: pilot experience with a regional EHR system.
BMC Med Inform Decis Mak 2009 Jul 1;9:33 1-13
31. Cook RI, Render M, Woods DD. Gaps in the continuity of care and progress on
patient safety. BMJ 2000 Mar 18;320(7237):791-4.
32. Center för eHälsa i samverkan . IFK-del 2 Gemensam utveckling av
informationshantering för Nationella Kvalitetsregister. Center för eHälsa i
samverkan 2011 Available at
http://www.cehis.se/images/uploads/dokumentarkiv/Slutrapport_IFK_2_11.pdf.
33. Walliman N. Research Methods the basics. Oxford: Routledge; 2011.
34. Dulock HL. Research Design: Descriptive Research. J Pediatr Oncol Nurs 1993
;10(4):154–7.
35. Johnson RB, Onwuegbuzie A J. Mixed Methods Research: A Research Paradigm
Whose Time Has Come. Educational Researcher 2004;33(7): 14–26.
36. Green JL, Camilli G, Elmore PB. Handbook of Complementary Methods in
Education Research, London: Routledge; 2008.
37. Elo S, Kyngäs H. The qualitative content analysis process. J Adv Nurs 2008;04:
107–15.
38. Glaser BG, Holton J. Remodeling Grounded Theory. Forum: Qualitative Social
Research 2004.
38
39. Gibbs GR "Grounded Theory - Line-by-line Coding". Available at
https://www.youtube.com/watch?v=Dfd_U-24egg (last accessed 16 April 2014).
40. Brender J. Handbook of evaluation methods for health informatics. Burlington:
Elsevier Academic Press; 2006.
41. Editor AO "Ocean Archetype Editor 2.2" . Available at http://ocean-archetype-
editor.software.informer.com/2.2b/ (last accessed 7 April 2014).
42. Designer OT "Ocean Template Designer 2.6". Available at http://ocean-template-
designer.software.informer.com/2.6b/ (last accessed 7 April 2014).
43. GDL Editor "Computerized guideline editor for clinical decision support".
Available at http://sourceforge.net/projects/gdl-editor/ (last accessed 15 May
2014).
44. Creswell JW. Qualitative Inquiry and Research Design: Choosing Among Five
Approaches, 3rd ed. California: Sage Publications; 2007.
45. Hsieh H-F, Shannon SE. Three approaches to qualitative content analysis. Qual
Health Res 2005;11 :77–88.
46. Baker J, Bouchlaghem D, Emmitt S. Categorisation of fire safety management:
Results of a Delphi Panel. Fire Saf J 2013;59:37–46.
39
Appendix A – Archetypes
Two reused archetypes in this study without any changes:
openEHR-EHR-COMPOSITION.medication.v1
40
Appendix A – Archetypes
41
Appendix A – Archetypes
openEHR-EHR-EVALUATION.problem-diagnosis.v1
42
Appendix A – Archetypes
43
Appendix A – Archetypes
Three archetypes were modified for the needs of this study:
openEHR-EHR-OBSERVATION.imaging_exam.v1 – the mother archetype for
Echocardiography
44
Appendix A – Archetypes
o openEHR-EHR-OBSERVATION.imaging_exam-Echogardiography.v1
45
Appendix A – Archetypes
openEHR-EHR-OBSERVATION.lab_test-thyroid.v1
46
Appendix A – Archetypes
openEHR-EHR-EVALUATION.stroke_prevention_review.v1
47
Appendix B – GDL rules
The rule list for Basmodulen:
48
Appendix B – GDL rules
49
Appendix B – GDL rules
50
Appendix B – GDL rules
51
52
Appendix C – Mock Patient Data
Input values in the CDS workbench for mock patients.
Table 1 Mock patients for basmodulen
53
Appendix D – Execution Logs
54
Appendix D – Execution Logs
55
Appendix D – Execution Logs
56
Appendix D – Execution Logs
57
Appendix D – Execution Logs
58
Appendix D – Execution Logs
59
Appendix D – Execution Logs
60
Appendix D – Execution Logs
61
Appendix D – Execution Logs
62
Appendix D – Execution Logs
63
Appendix D – Execution Logs
64
Appendix D – Execution Logs
65
Appendix D – Execution Logs
66
Appendix D – Execution Logs
67
Appendix D – Execution Logs
68
Appendix E –Interview questions
1. Why is it important to have integration between EHR, CDS and the QR for AF?
2. What problems will this integration solved and for whom?
3. What risks are there today without the integration?
4. Do you think that QR plays a crucial role for the future development of
knowledge and quality in the health care? Why?
5. How will this integration affect nurses and cardiologists in their work?
6. Do you know something about openEHR technologies with Archetypes and
Templates? If yes, where did you hear/learn about it? If no, why do you think
that is?
7. Do you know something about the GDL editor? If yes, where did you hear/learn
about it? If no, why do you think that is?
(Computerized guideline editor for clinical decision support)
8. For what reasons do you think this integration hasn’t been done yet?
9. What do you think this integration means for the future?
10. Could you comment this picture and see if this is how you see the situation
today and if there is something you would like to add or if something is
misplaced?