Download Applying openEHR and GDL for streamlining

Master's Programme in Health Informatics
Spring Semester 2014
Degree thesis, 30 Credits
Applying openEHR and GDL for streamlining the process
between screening and reporting to quality registries – the
case of familial hypercholesterolemia
Author: Karl Engblom
Author: Karl Engblom
Main supervisor: Rong Chen, MD PhD, Cambio AB and Health Informatics
Centre, Karolinska Institutet
Examiner: Dr. Andrzej Kononowicz, Department of LIME, Karolinska Institutet
Master's Programme in Health Informatics
Spring Semester 2014
Degree thesis, 30 Credits
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.
City, date
__________________________________________________________
Author name, surname
Master's Programme in Health Informatics
Spring Semester 2014
Degree thesis, 30 Credits
Applying openEHR for streamlining the process between
screening and reporting to quality registries – the case of
familial hypercholesterolemia
Abstract
Background: familial hypercholesterolemia (FH) belongs to a category of
diseases that present particular challenges for health care information
management. It is not clinically obvious, it depends on information from relatives,
and has frequently been underdiagnosed. There was a perceived need for an
investigation of how modern informatics tools such as openEHR and GDL can
support the documentation and decision making surrounding the disease.
Objective: to examine how openEHR and GDL can help optimize the
documentation and decision making process from making the first decision to
investigate a patient for FH to when the case is reported to a quality registry for
the disease.
Methods: the study is essentially a case study. Available screening criteria,
diagnostic criteria and registry forms were surveyed to find information
requirements. Existing archetypes and terminologies corresponded to the
requirements were surveyed. An interview with a quality registry professional was
made to understand real-world demands and context. A GDL guideline of the
most common diagnostic criteria was created and validated.
Results: There was a large overlap in the information requested at the different
stages. Most the data types were covered by existing archetypes, but for various
reasons, creating new ones was frequently more practical. The created guideline
worked.
Conclusion: openEHR and GDL has a role to play in the organizational context,
and can support the integration of EHR:s, decision support, and quality registries,
a development that may have real benefits for the health care system in general
and patients with familial hypercholesterolemia in particular.
Keywords: electronic health records, standards, hypercholesterolemia,
screening, registries
Acknowledgements
Thanks to my supervisor Rong Chen, Konstantinos Kalliamvakos at Cambio for
assistance, Sabine Koch at KI for advice, Andrzej Kononowicz for feedback, Una
Ismaili for discussions, and my family for moral support.
Table of Contents
1 Introduction...........................................................................................................9
1.1 Familial hypercholesterolemia......................................................................9
1.1.1 Cause......................................................................................................9
1.1.2 Treatment and risk assessment..............................................................9
1.1.3 Prevalence............................................................................................10
1.1.4 Rate of diagnosis..................................................................................10
1.1.5 Making the diagnosis...........................................................................10
1.1.6 Responsibilities within the health care system....................................11
1.2 EHR:s and openEHR...................................................................................11
1.3 Guidelines and GDL....................................................................................12
1.4 Quality registries.........................................................................................13
1.5 Problem description.....................................................................................14
1.6 Aim and objectives......................................................................................15
1.7 Research questions......................................................................................15
1.8 Ethical considerations..................................................................................16
2 Methods...............................................................................................................17
2.1 Research approach.......................................................................................17
2.2 Study design................................................................................................17
2.2.1 Information gathering..........................................................................18
2.2.2 Gaining familiarity with the tools........................................................18
2.2.3 Describe the information needed for screening, diagnosis, and
reporting........................................................................................................18
2.2.4 Elicitation of archetypes and terminology...........................................19
2.2.5 Analysis of coverage and recurrence...................................................19
2.2.6 Expert interview...................................................................................19
2.2.7 Implementation and validation of GDL guideline...............................20
3 Results.................................................................................................................22
3.1 The process from identification to registry.................................................22
3.1.1 Screening.............................................................................................22
3.1.2 Setting diagnosis..................................................................................24
3.1.3 Treatment.............................................................................................26
3.1.4 Reporting to quality registry................................................................26
3.2 General requirements on the decision support............................................28
3.3 Information requirements and corresponding archetypes...........................29
3.3.1 Direct clinical information about the patient.......................................29
3.3.2 The patient's diagnosis.........................................................................30
3.3.3 Current lipid lowering therapies..........................................................30
3.3.4 Other procedures and medical information on the patient...................30
3.3.5 Information about relatives..................................................................30
3.4 Required terminologies and terms...............................................................34
3.5 Analysis of coverage and recurrence...........................................................35
3.6 Results of the expert interview....................................................................36
5
3.7 Creation and validation of GDL guideline..................................................38
3.7.1 Used archetypes...................................................................................38
3.7.2 Rules....................................................................................................39
3.7.3 Comments on the design process.........................................................39
3.7.4 Validation with mock patients.............................................................39
4 Discussion...........................................................................................................40
4.1 OpenEHR, GDL and existing EHR:s..........................................................40
4.2 Usefulness of available information............................................................40
4.3 Limitations of the study...............................................................................41
4.4 Strengths and weaknesses of the study........................................................42
4.5 Generalizing the results...............................................................................42
4.6 Further research...........................................................................................42
5 Conclusion...........................................................................................................44
6 References...........................................................................................................45
7 Appendices..........................................................................................................48
6
List of abbreviations
ADL
CDS
CVD
DLCN
EHR
FH
GDL
GP
ICD-10
LDL
SNOMED_CT
Archetype Definition Language
Clinical Decision Support
Cardiovascular disease
Dutch Lipid Clinic Network
Electronic Health Record
Familial Hypercholesterolemia
Guideline Definition Language
General Practitioner
International Classification of Diseases-10
Low Density Lipoprotein
Systematized Nomenclature of Medical Terms
7
List of figures
Figure 1. Genetic vs clinical diagnosis................................................................11
Figure 2. Study design.........................................................................................18
Figure 3. The genetic relative archetype, viewed in the Archetype Editor.........34
List of tables
Table 1. Units of information of different criteria sets.......................................36
Table 2. Repository archetypes covering the data types.....................................36
8
1 Introduction
Approximately 5% of the population is considered to have a genetic disorder of
some kind. Some of these disorders have a phenotype that is obvious, which
means that the diagnosis is rarely missed, and the correct treatment can be
commenced as soon as possible. Other disorders might present less obvious
symptoms, and these symptoms may be confused with temporary conditions. This
leads to the disorder frequently remaining undiagnosed, with resulting lack of
correct treatment. Dealing with these disorders represents a particular challenge
for the health care system. This is a challenge which information technology may
or may not have a part in solving. This study is about one such disorder, familial
hypercholesterolemia. It is also about one particular tools, openEHR and GDL
and their possible role in managing the information that forms the basis for
decisions surrounding the disease, such as performing screening of EHR:s, setting
a diagnosis, and reporting cases to a quality registry.
1.1 Familial hypercholesterolemia
Familial hypercholesterolemia (FH) is a genetic disorder that affects the ability of
the body to metabolize the cholesterol circulating in the blood. The level of LDL,
“bad cholesterol,” increases to levels that may result in various cardiovascular
problems such as atherosclerosis, stroke and angina(1).
1.1.1 Cause
FH is usually caused by mutations in three genes, LDLR, ApoB and PCSK-9.
These mutations affect the ability of the LDL receptor protein to remove the
cholesterol from the blood. There are more than 1700 different mutations in the
genes that may cause the disease(2).
FH is autosomally dominant, i.e. having a mutation in one copy of the genes,
received from either parent, is sufficient to get the disease. Having two copies of
mutations causes homozygous FH, a serious and uncommon condition that is not
the focus of this study.
The main complication resulting from the high cholesterol levels are
cardiovascular problems. Untreated men have a 50% risk of a coronary event by
the age of 50 years, for women the risk is 30% by the age of 60 years(3). Apart
from the cardiovascular effects, there are a number of other effects on the body
that are visible as symptoms. These include xanthomas, depositions of
cholesterol-rich material close to tendons, that are visible on the skin and that may
help with diagnosis(1).
1.1.2 Treatment and risk assessment
As a genetic disease, FH cannot be treated but must be managed during the rest of
the patient's life. The management of the disease is similar to the management of
other patients with cardiovascular problems. The first line of treatment is statins.
9
The guidelines are different for adults and children. Common suggested target
levels for children are LDL levels of <130 mg/dl or >50% reduction from baseline
values. Because of the side effect of statins among children, at what age the
treatment should start has been a controversial question(1). For adults, the general
recommendation is “maximal potent statin dose”(4). However, they may
considered a successful treatment, reducing the risks of CVD among carriers to
levels much closer to the general population(5).
It is important to discover and start managing the disease as early as possible. The
reason for this is that the cardiovascular risk depends on the accumulated
exposure to high cholesterol levels during the patients entire lifetime, essentially
since birth.
However, it is emphasized in the literature that because of the accumulated
exposure that FH carriers have received during their lifetimes, risk assessment
tools such as SCORE or the Framingham Risk Score do not give correct
assessment of cardiovascular risk(1).
Another important part of the treatment is lifestyle adjustments, such as diet,
smoking cessation, physical exercise and alcohol consumption(5).
1.1.3 Prevalence
The prevalence of FH has not been conclusively determined in most countries.
The prevalence is believed to be around 1:500 in most of the world's populations,
with larger proportions in populations with founder effects(4). The rate of
prevalence also varies depending on what criteria is used – for example, if a
genetic diagnosis is enough or if clinical symptoms are necessary as well (as in
Fig 1).
1.1.4 Rate of diagnosis
One of the defining characteristics of FH, and one of the stated reasons that the
disease is the subject of this study, is the fact that it so frequently goes
undiagnosed. The rate of diagnosis varies across different countries and time
periods, but is strikingly low, with less than 1% being diagnosed even in
developed countries such as Japan and the USA, while the highest rates are in the
Netherlands and Norway with 71% and 43% respectively(4).
1.1.5 Making the diagnosis
There are two major sets of guidelines setting a diagnosis for FH:
•
The Simon Broome Registry Criteria, which is used by general
practitioners to determine whether to refer the patient to a specialist clinic.
•
The Dutch Lipid Clinic Network Criteria, which is used by specialist to set
the diagnosis.
These will be further analysed in the “results” section.
10
Since all the genetic causes for FH have not been discovered yet, it is possible to
have a clinical diagnosis without a genetic diagnosis. Also, because of favorable
lifestyle factors, it is possible to have a genetic diagnosis without having the
symptoms required for a clinical diagnosis(4). See Figure 1.
Figure 1. Genetic vs clinical diagnosis. Adapted from Nordestgaard (2013)
1.1.6 Responsibilities within the health care system
Through the available literature, it was difficult to get a clear view of how the
disease is managed in different health care systems – what proportion of cases are
discovered by primary care and specialists respectively, who is responsible for the
subsequent treatment, and what the state of the diagnosis is when the referral is
made from GP to specialist. The most common path is that an initial diagnosis
based on the Simon Broome criteria is made by the general practitioner, who
makes the referral to the lipid clinic, where the “final” diagnosis is made on the
DLCN criteria (based on personal communication, source needed).
1.2 EHR:s and openEHR
Electronic Health Records (EHR:s) are an integral part of modern medicine. One
definition of an EHR is that it is “a repository of electronically maintained
information about an individual’s lifetime health status and health care, stored
such that it can serve the multiple legitimate users of the record.”(6)
There has been a continuous development of EHR:s from being a simple record of
the care performed when the patient is ill to covering the continuity of the
patients health state during longer periods of time, involving multiple illnesses
and also a variety of health care providers and settings(6).
There are a multitude of EHR solutions from a multitude of providers.
11
OpenEHR is an open standard for EHR:s, maintained by the openEHR
Foundation. The intention is to support interoperability and computability in ehealth(7). Interoperability in e-health is frequently divided into technical and
semantic interoperability. Semantic interoperability signifies “the ability for
information shared by systems to be understood at the level of formally defined
entities, so that the receiving system can process the information effectively and
safely.(8)” In the context of this research, it means that the units of information is
“understood” well enough so that it can be operated on by decision support
systems and transferred to quality registries.
OpenEHR has a number of defining features that gives it distinct properties. One
of these is a multi-level architecture, with the intention of separating information
and knowledge. There is a distinction between:
•
A reference model or information model. This model includes the objects
from which objects are built, data structures, data types etc. However, it is
separated from actual clinical knowledge or information. It is intended to
be stable.
•
An archetype model. The instances of this model are referred to as
“archetypes” and “templates”. Archetypes are intended to formally define
a re-usable unit of clinical data, such as the results of a lab test or an
examination.
There is a common repository of archetypes available at www.openehr.org/ckm.
When using openEHR the objective is to re-use these archetypes when possible,
to support compatibility.
1.3 Guidelines and GDL
Clinical practice guidelines (CPG:s) are an integral part of modern health care.
They may be defined as “systematically developed statements to assist
practitioner and patient decision-making about appropriate health care for specific
clinical circumstances”(9). There are many purposes of guidelines – to embody
best practices, improve health care quality, reduce variation, and improve
efficiency and workflow. Guidelines that are designed to be interpretable by
computer are referred to as computer-interpretable guidelines (CIG:s). Using
computers to run guidelines confers several advantages, the most obvious is the
ability to make use of the computers logical processing power(9). CIG:s are a
form of clinical decision support systems (CDS)(9).
There are also a number of shortcomings associated with guidelines. Historically,
one of the main problems with CIG:s has been that the information required as
input for the guidelines needs to be manually entered. This takes a large amount
of effort. Therefore, an important ideal has emerged, that CIG:s should be able to
use information already in the EHR:s. This, of course, makes it necessary that the
rules engine and the EHR are semantically interoperable(9). This is a challenge
since there are many rules engines and many different EHR:s(6).
12
The Guideline Definition Language (GDL) is an example of an attempt to
ameliorate this. It is an initiative to create a “formal language designed to
represent clinical knowledge for computerized decision support” and is “designed
to be natural language- and reference terminology- agnostic by leveraging the
designs of openEHR Reference Model and Archetype Model”(10). It has been
shown that GDL is able to represent clinical knowledge in the form of CPG:s as
CDS rules in the EHR(11)(12).
The introduction of CIG:s have been subject to some criticism. The main
complaint is that they make it too easy to apply simplistic reasoning, known as
“cook-book” medicine, and that professionals should not “outsource” decisionmaking to computers(9). Some approaches of countering this criticism is to use
guidelines where there is clear evidence that the work situation of professionals
causes them to ignore issues that may seem unimportant at the moment, but might
make a large difference in a longer perspective for a defined group of patients(9).
An example of this using GDL is the application of a guideline to suggest which
patients would benefit the most from stroke prevention (11).
1.4 Quality registries
Disease registries are an important part of modern health care. They have several
purposes, such as providing a source of data for monitoring and follow-up of the
success of specific types of treatment, long-term monitoring of medications for
chronic diseases, the rate of accidents and injuries, etc(13).
The contents of a typical registry are:
•
patient demographic data
•
the actions performed on the patients during care
•
the effects of these treatments on the patients
•
complications and variables affecting care
•
complimentary care and care at other units(14).
The information is delivered through various degrees of automation, with paper
forms filled in by either a doctor or a nurse after the case is finished still very
common(14).
Which organization is responsible for maintaining a registry varies between
different countries and different diseases. In Sweden, a large number of registries
are managed by the Uppsala Clinical Research Center, UCR.
Quality registries have been subject to some criticism. One recent report listed a
number of issues with the Swedish quality registry system(14). These include a
lack of professional incentives for health care staff to contribute to the registries,
incomplete coverage, and that the contents of the registries did not reflect the
actual care performed. But the most pervasive problem, as well as a root cause of
some of the other problems, was the administrative burden that the registries put
on the health care staff(14).
13
One way of reducing this burden is to re-use information from electronic health
records. There are several attempts at this ongoing in Sweden – attempts to
automatically re-use information from EHR:s in registries, attempts to send
information from registries to EHR:s, attempts to simultenously enter data into
both EHR:s and registries, and attempts to transfer data from one registry to
another(13). Many of these initiatives have encountered problems of
interoperability on different levels(13).
During recent years there has been some developments towards common technical
standards for quality registries. For example, all of UCR's registries use the same
open source platform, OpenQreg, which in turn uses MySQL, Java, JSP and
HTML(15).
However, technical standards are not enough, semantic interoperability is also
required to reap all the advantages of EHR interoperability mentioned above.
There has been attempts at this as well. In the IFK2 project(16), openEHR
archetypes and templates, as well as SNOMED CT terminology bindings, were
used to create a system where the RiksSvikt registry forms could be accessed
from inside various EHR systems, and some parts of the form was populated
automatically using EHR information(16). The exact fields where this was
possible depended on which county council handled the implementation(16).
It is in this context that the situation for FH must be viewed. At present there is no
quality registry for the disease in Sweden, but there is one in the planning stages
at Linköping University(17). The view exists that there is a genuine need for a
registry, for many of the reasons given for existing registries - for follow-up and
comparisons, long term patient monitoring as well as research(17). During this
study, no source was found that contained any specific reasons that this registry
does not already exist, suggesting that it is the issues surrounding quality
registries discussed above that are the culprit here as well.
1.5 Problem description
The characteristics of FH described in the previous sections are also reasons that
the choice was made to make the disease the subject of study. These reasons are:
•
The disease is relatively common despite being relatively unknown, might
have serious effects for untreated patients, and is underdiagnosed.
•
Screening and diagnosis of the disease requires information from several
sources, including a clinical examination, genetic and laboratory testing, as
well as information from the EHR.
•
The information that is required or useful for screening or diagnosis comes
both from the patient's own EHR as well as the EHR:s of relatives.
•
A quality registry for the disease has been considered for a long time but
has not been considered worth the effort.
•
There are many other diseases that share these characteristics, on which
the results of this study could be applied.
14
A disease like FH presents challenges for health care documentation. The
information needs to be structured to be available for decisions made about which
individuals to investigate and to set the diagnosis, whether these decisions are
made manually or by automated guidelines. It also needs to be structured for easy
re-use by quality registries.
The problems with technical and semantic interoperability discussed above
presents the interesting possibility that the efficiencies made possible by
integration with EHR:s could assist in making a quality registry cross the line
from unviable to viable. Compared to creating a registry by itself, EHR
integration might confer several advantages:
•
It might decrease the effort of creating and maintaining the registry, and
simplify making modifications to it – modifications that are usually more
frequent than expected(16).
•
It might make it easier to populate the registry with data that already exists
in electronic health records.
•
It might make it easier to make international comparisons in the future, if
similar quality registries are established in other countries. This is
particularly important for rare diseases where the patient base might be too
small in Sweden to make significant conclusions.
However, it is not clear how much of these advantages can be realized, and
determining this is part of the investigation.
1.6 Aim and objectives
As stated above, it has been shown that GDL is able to represent clinical
knowledge in the form of CPG:s as CDS rules operating on the EHR. However,
there was a perceived need for investigating how these capabilities can be applied
on the entire process from discovery to reporting of a long-term disease.
So the overall aim of the study is to examine how openEHR and GDL can help
optimize the documentation and decision making process from the first decision
to investigate a patient for FH to when the case is reported to a quality registry for
the disease.
The objective is to gain a clearer view of whether openEHR and GDL can be a
part of the solution to the general problem of data integration between electronic
health records and quality registries.
1.7 Research questions
The primary research questions are:
•
What information is involved in decisions in the FH care process,
specifically in decisions surrounding who to investigate, the setting of
15
diagnosis, and reporting of the disease? How can this information be
expressed in openEHR archetypes, preferably existing ones?
•
Is it possible so that they can be operated on by decision support systems
and transferred to quality registries?
1.8 Ethical considerations
During the study, no information about real patients was gathered. The sources
used are taken from established scientific publications, and therefore has already
been subject to ethical approval.
The study was undertaken without financial support, so there are no conflicts of
interest based on such support.
When it comes to the topic, there is a wealth of ethical considerations to take into
account. These belong to two main categories – the ethics of diagnosing and
informing about genetic diseases, and the ethics of transferring patient data
between EHR:s and registries. There are well developed frameworks for how the
health care systems should manage these considerations. It is, however, essential
that any real implementation of the solutions discussed in this thesis are only set
up within the context of these frameworks.
16
2 Methods
2.1 Research approach
This study is essentially a case study, with the “case” being the disease of FH
itself.
A case study can be defined as a “phenomenon where we report only a single
measure on any pertinent variable,” an “empirical inquiry that investigates a
contemporary phenomenon within its real life context, especially when the
boundaries between phenomenon and context are not clearly evident”(18). It
involves “understanding an event, activity, process, or one or more
individuals”(18).
The main reasons for choosing a case study approach is that from the beginning, it
was clear that it was only going to be about one disease, and there was no reason
to make any comparisons or repeat the study with any other disease. There was no
intention of doing any evaluation of the tools used, either, or comparison with
other tools (This, however would be an interesting topic if a real application
becomes closer to reality).
Also, it was not known where the boundaries were on this particular system until
the study has begun. It was not known which actors were involved, what events
occurred, or what exactly defined the beginning and end of the process to be
studied.
However, it was clear from the beginning that it would be necessary to make use
of data sources that approached the same phenomenon using different
methodologies. This is also a defining feature of case studies(18).
The case study is a frequently applied method in health informatics education to
analyse phenomena that pinpoint underlying problems in the health care
system(19). In these situations, there is a tendency among most students to look at
the immediate problems of the case study or to focus on the technological aspects
of the case(19). Of course it is important to elaborate on the ways that health
informatics can adress the issues, but it is important to define the underlying
problem first(19).
Despite the lack of comparisons with other diseases, there is still the ambition that
the results gained in this study will be useful when approaching similar situations
with other, similar diseases.
2.2 Study design
The study design has the following stages:
17
Figure 2. Study design
2.2.1 Information gathering
For the data collection, a number of searches were made on PubMed through the
KI university library. The search included the following concepts:
•
familial hypercholesterolemia (screening, diagnosis, prevalence, registry)
•
openEHR
•
Clinical Practice Guidelines
•
quality registries
•
Simon Broome Criteria
•
Dutch Lipid Clinic Network Criteria
One particular part of the information gathering was the selection of the registry
forms to use for the comparison. They were selected because they were the only
ones found.
2.2.2 Gaining familiarity with the tools
In order to be able to apply openEHR and GDL, it was necessary to learn both
about the concepts themselves as well as the software tools used to create and edit
archetypes and guidelines. This included a literature study of the documentation
involved(20)(21)(22)(23)(10) as well as experimenting with the software tools.
The software tools include:
1. The Archetype Editor.
2. The Template Designer.
3. The Guideline Definition Language and the GDL Editor.
2.2.3 Describe the information needed for screening,
diagnosis, and reporting
After some initial research, it was clear that the process has four main parts,
screening, investigation, treatment and reporting to registry.
For each of these, the information required, as well as how this information is
used in decisions, is defined. Treatment is dealt with only briefly.
2.2.4 Elicitation of archetypes and terminology
Once the process has been described and the information requirements been
defined, the next step is to find the archetypes that correspond to the requirements.
This is made for each element at a time. First, the search function of the openEHR
repository is used to find the element. Then, there is a manual scan of the
18
repository to find useful archetypes that may not be found by a regular search. If
any useful archetypes are found, they are added to a list.
If there is no equivalent in the repository, a new element is created that
corresponds to it, if this is possible.
If it is impossible to create an element with the desired function, a short analysis is
made to understand the reason for this and how it affects the value of openEHR
and GDL in the context of the study.
2.2.5 Analysis of coverage and recurrence
The analysis is made according to two basic measures – the extent to which
archetypes are covered and the extent to which the same units of information
reoccur during the different stages.
If the same units of information appear in the different stages, it indicates the
possibility of reuse of information between the EHR and quality registries. If the
information is covered by existing archetypes, it indicates the possibility of using
it as a source for automated decision support that are compatible with openEHR.
2.2.6 Expert interview
The expert interview had a number of purposes. One purpose was to determine the
conditions for of the guideline to work in a real, clinical environment – both in
terms of the likelihood that the requested information was present in the first place
in the EHR and could be retrieved using the criteria presented by the guideline,
and also about other barriers such as legal barriers. Other purposes was to gain
general insights into the problems of integration between registries and EHR:s, the
design process of registries, problems encountered, compliance and fulfilment of
their intended function.
The reasoning behind the choice of subject is as follows. Since a registry for FH
in Sweden does not exist, it was not possible to find someone with experience of
it. There is one person, an “enthusiast”, that would be an interesting interview
subject as he is developing such a registry. However, interviewing him was not
managed during the time of the project.
The chosen subject is a nurse and the national coordinator for the Auricula
registry, which is also about cardiovascular disease. She was familiar with FH
although she was not a specialist in it. She is also familiar with the efforts
surrounding CDS and guidelines related to this registry. Finally, she is familiar
with EHR:s.
The “enthusiast” would know more about FH, but he would not have as many
insights into existing registries and decision support systems that are already
functional.
The interview was semi-structured. This means that they are structured around a
number of pre-defined questions around which it is possible to create larger
discussions(24). The reason for choosing this approach is that at the time of the
19
interview, a number of topics to be covered were already decided, but it was not
known the specific approach for covering them, and a lot of questions would have
to be asked as follow-up questions, based on what the interview subject said
during the interview.
The interview was recorded, transcribed, and analysed through qualitative content
analysis(25). This type of analysis includes the following main steps:
•
The transcript was read to make sure it was understandable.
•
Units of meaning were identified using open coding. These units are of
different level of generalization, they may be single words or entire subdiscussions. When applicable, codes were assigned to the units.
•
The units were was grouped into concepts and the meaning of these
concepts were analyzed, as well as the reasons why concepts were
reoccurring, or presented contradictions. Redundant units were removed.
•
The concepts were sorted into a small number of themes. These themes
were presented as results.
The time used for the interview was approximately one hour. The interview form
is provided in Appendix B.
2.2.7 Implementation and validation of GDL guideline
This was a mostly an ad hoc process, in which the different criteria were gradually
added to the guideline and tested.
An important fact is that the archetypes elicitated during the previous stages were
not considered “read-only”. If necessary for the guideline to work, they were
modified, or new ones created.
Templates were added with the purpose of adding terminology bindings.
During the process I relied on existing samples of created GDL guidelines, and
the specification of the language as well as the documentation for openEHR. On a
couple of occasions, I was unable to find a solution to a problem and requested
help from Cambio through a Skype conference.
Once finished the guideline was validated. Validation is a straightforward process
where the results provided by the GDL code based on a number of mock patients
are compared to values calculated from the original guideline and the same
patients.
It can be done through a Java application called CDS Workbench. It can also be
done manually through the form that is generated by the editor.
In either case, it is important that the comparison is made between those generated
by the code itself and the results that are calculated based on the paper guideline,
and not some intermediate stage.
20
3 Results
3.1 The process from identification to registry
There are three major steps of the process: screening, investigation, treatment, and
reporting.
3.1.1 Screening
As described in the introduction, FH does not necessarily lead to clinically
obvious symptoms. In order to start an investigation, there must be something that
triggers it. An important question about the process is how it is decided which
individuals should be subject to investigation for FH. There are several possible
identification venues(5):
•
Through screening of relatives of existing cases. In this case, patients are
subject to testing because a relative of them either got diagnosed with FH
or suffered from premature cardiovascular disease. This is described
below.
•
Through the discovery of the clinical symptoms such as xanthomas by the
patient or by the health care system on a non-FH related health care visit.
•
Through a non-FH related test of cholesterol levels.
•
Finally (and this may be considered the least desirable venue of discovery)
the patient may be investigated for FH because he or she is already
suffering from premature CVD.
In most countries, even the presence of the above signs do not lead to an
investigation, which keeps the detection rate for FH very low(4). However, there
is a wide consensus that these venues are not sufficient even when implemented,
with an estimate that in the UK, the measures above would only find 50% of cases
(5).
Some countries have experimented with or considered screening of entire
populations, either through cholesterol testing or genetic testing(4).
3.1.1.1 Cascade screening
The most promising method of FH identification is considered to be the screening
of the relatives of known cases of FH and CVD(1)(3). This is referred to as
cascade screening. The first patient identified with the disease, the starting point
of further investigations among his or her relatives, is referred to by the
epidemiological term “index case.” “Consultand” is another term used.
Relatives of the consultand are identified and classified according to the degree of
the relationship. For each degree of separation, the amount of shared genes with
the consultand is halved. A parent is a first-degree relative, an uncle is a second
degree relative, a cousin third degree, and so on. The degree that is of interest
depends on the ambition of investigation.
21
3.1.1.2 Sets of criteria for screening
There are a number of different sets of criteria for screening – this stage is not as
standardized as the diagnosis setting.
One set of criteria, recommended recently by the European Atherosclerosis
Society, for recognizing a person as an index case are(4):
1. plasma total cholesterol ≥8 mmol/L (≥310 mg/dL) in an adult or adult
family member(s) (or 95th percentile by age and gender for country),
2. premature CVD in the subject or family members
3. tendon xanthomas in the subject or family members
4. sudden premature cardiac death in a family member.
Note that it is required that all four criteria are met. Since the same article also
advocates for using the DLCN criteria described below to set the diagnosis, it is
possible to get a diagnosis but still not be an index case.
A Swedish criteria for screening, acquired from the cardiology clinic at Linköping
University Hospital, are:
A. The total cholesterol is ≥8mmol/L for adults or ≥6mmol/L for children.
B. A first-grade relative has at least one of the following criteria
1. The total cholesterol is ≥8mmol/L for adults or ≥6mmol/L for children.
2. Premature CVD
3. Premature sudden cardiac death (<55 years men, <60 for women)
4. Tendon xanthomas
A referral for investigation should be sent if either
•
A and B are met.
•
A is almost met (total cholesterol ≥7mmol/L) and B is “abundantly” met
(several of the criteria are met, the criteria are met by several first-grade
relatives, or any of the criteria are met with a large margin)
•
A is “abundantly” met (total cholesterol ≥9mmol/L) and B is almost met.
There are also examples of proactively searching EHR data. In one such study,
12000 journals were searched for practice codes of ischemic heart disease,
cholesterol and statins. Twelve cases were found, of which two were new cases.
The study took half an hour.
The most interesting fact about the screening is that the criteria for starting an
investigation is very similar to the criteria for actually setting the diagnosis.
There is a tendency to put up “unnecessarily” detailed criteria for screening, as if
the greatest problem was getting too many false alarms. It is perfectly possible, as
in (Nordestgaard) to complain about the low rate of discovery, and simultaneously
put forth criteria that are almost as detailed as the one used for diagnosis.
22
There is also a certain variety of criteria. Both in terms of the cholesterol level –
with different criteria sets applying cutoffs of 7.5, 8 mmol/L. There is also a
variation in terms of the different logical combinations of the same basic units of
information of the patient's and the patient's relatives. It brings to mind the old
hippocratic saying that “if there are many suggested treatments for the same
problem, all of them are bad.”
3.1.2 Setting diagnosis
Once a decision has been made to perform an FH investigation in a patient, the
question arises on what criteria to use for the diagnosis. There is no single set of
internationally accepted criteria for the diagnosis of FH(26). There are, however,
two sets that are frequently used: the Simon Broome Register criteria and the
Dutch Lipid Center Network Criteria.
3.1.2.1 The Simon Broome Register Criteria
The Simon Broome criteria are the following for “definite” FH:
• total cholesterol above 6.7mmol/l or LDL cholesterol above 4.0mmol/l in a child
aged under 16 years or
total cholesterol above 7.5mmol/l or LDL cholesterol above 4.9mmol/l in an adult
(levels either pre- treatment or highest on treatment)
plus
• tendon xanthomas in patient, or in 1st degree relative (parent, sibling, child), or
in 2nd degree relative (grandparent, uncle, aunt)
or
• DNA-based evidence of an LDL receptor mutation, familial defective apo B100, or a PCSK9 mutation.
Possible familial hypercholesterolaemia is defined as the criteria for cholesterol
above plus one of the criteria below:
• family history of myocardial infarction: below age of 50 years in 2nd degree
relative or below age 60 years in 1st degree relative
• family history of raised total cholesterol: above 7.5mmol/l in adult 1st or 2nd
degree relative or above 6.7mmol/l in child or sibling aged under 16 years.
3.1.2.2 The Dutch Lipid Clinic Network Criteria
Family history
First-degree relative with known premature coronary and/or vascular 1
disease (men <55 years, women <60 years)
23
or
First-degree relative with known LDL-cholesterol above the 95th
percentile for age and sex
First-degree relative with tendinous xanthomata and/or arcus 2
cornealis
or
Children aged less than 18 years with LDL-cholesterol above the 95th
percentile for age and sex
Clinical history
Patient with premature coronary artery disease (ages as above)
2
Patient with premature cerebral or peripheral vascular disease (as 1
above)
Physical Examination
Tendinous xanthomata
6
Arcus cornealis prior to age 45 years
4
LDL-cholesterol (mmol/L)
LDL-C ≥8.5
8
LDL-C 6.5–8.4
5
LDL-C 5.0–6.4
3
LDL-C 4.0–4.9
1
DNA analysis: functional mutation in the LDLR, APOB or 8
PCSK9 gene
STRATIFICATION
Definite FH ≥8
Probable FH 6–7
Possible FH 3–5
Unlikely FH <3
24
3.1.3 Treatment
In this study, only the most basic aspect of treatment will be taken into account:
the lowering of cholesterol levels by statins. This is considered as a simple
feedback loop where the latest measurements are used as the basis for adjustment
of dosage. Of course, it is possible to make treatment decisions much more
advanced, taking into account any other afflictions that may affect the patient.
3.1.4 Reporting to quality registry
As mentioned in the introduction, automatic transfer of information between
EHR:s and registries demands semantic compatibility.
As described in the methods section, a number of searches was made for forms of
existing or planned quality registries. Two international registries were found.
One of them is the CAscade SCreening for Awareness and DEtection for Familial
Hypercholesterolemia
(CASCADE
FH)
created
by
the
Familial
Hypercholesterolemia Foundation in the United States. The forms for this registry
includes both a baseline form and a follow-up form intended to be completed six
months later. They are found in Appendix 1. The other is the Australia and New
Zealand Registry for Familial Hypercholesterolemia (ANZRFH) created by the
Western Australia Department of Health. A summary of the common data set
identified for inclusion in this registry is provided in Appendix 2.
The requested information by the registries is the following.
3.1.4.1 CASCADE FH baseline form
The CASCADE FH registry form has nine sub-sections, as follows:
Demographics
This sections contains standard demographic information.
Past medical history
This section includes yes/no questions of whether the patient's medical history
includes smoking, hypertension, thyroid disease, diabetes, myochardial infarction
(MI), stroke, transient ischemic attack (TIA), coronary artery bypass graft
(CABG), PCI or stent, peripheral revascularization, and heart failure. If yes, the
age of onset or first episode is to be provided.
Family FH history
This section asks if anyone in the family has been diagnosed with FH,
hypercholesterolemia (non-familial), premature MI (under the age of 60 for both
men and women), xanthoma, peripheral vascular disease (PVD) and arcus.
Patient FH history
This section asks about the type of diagnosis for FH (heterozygous, homozygous,
or compound heterozygous), the method of diagnosis, (Dutch Lipid, Simon
25
Broome, MedPed, other, or DNA testing (LDL, B-100, or PCSK9), year or age of
diagnosis, the highest pre-treatment LDL and TC (level and date), and if the
patient has ever been treated with lipid lowering medication (if yes, since when).
Physical examination findings
This section asks about height, weight, BMI, blood pressure, corneal arcus, tendon
xanthomas, xanthelasmas, tanner stage and menarche.
Current lipid lowering therapies
This section first asks about the use of seven different statins. If any of them is
used, the daily dose and frequency is to be provided. If none of them are used, the
reason(s) for this are to be selected from a list that includes allergy, intolerance,
patient preference, physician preference, cost, pregnancy, clinical trial, or other.
This is followed by a series of yes/no questions about ten other therapies, namely
fibrate, ezetimibe, bile acid sequestrants, niacin, phytosterols, fish oils/omega 3
fatty acids, PCSK9 inhibitors, lomitapide (Juxtapid), mipomersten (Kvnamro),
psyllium, and LDL apheresis.
Imaging/procedures
This section only contains yes/no questions of whether four different tests have
been performed during the last five years: stress test (with or without imaging),
coronary angiography or coronary CT angiography, coronary/carotid CT calcium
scan, and peripheral angiogram.
Laboratory data
This section is for the most recent result of eleven laboratory tests: TC, LDL, TG,
HDL, Lpa, AST, ALT, creatinine, fasting blood glucose, HbA1c, and TSH.
Clinical trial participation
This section contains only a question of whether the patient is currently in a
clinical trial for the treatment of FH.
3.1.4.2 CASCADE FH 6 month follow-up data collection form
This form is intended to be sent in 6 month after the baseline form. It has six
sections, including a basic demographics section that has no new contents. The
other sections are:
Procedures/events since last entry
This section includes yes/no questions for MI, stroke, TIA, CABG, PCI or stent,
or “hospitalization for other reason.” If yes, the date is to be given.
Genetic testing
This section asks whether the patient has undergone any testing for mutations
since the last entry, if a mutation was confirmed, and in this case, if it was the
LDL, B-100, or PCSK-9 genes.
Current lipid lowering therapies
26
A choice between “No, discontinued since last entry”, and yes. If yes, the same
questions are asked about statins as in the baseline. If discontinued, the same eight
reasons can be checked as in the baseline form.
Current lipid lowering therapies (part 2)
For each of the same ten therapies in the baseline study, a choice of
no/yes/discontinued since last entry. If discontinued, the same eight reasons can
be checked as in the statin portion of the baseline form.
Laboratory data
Oddly enough, here there are a total of 16 lab tests, including five that were not
asked for in the baseline form, namely VLDL, hsCRP, total CK, Hcy, and total
bilirubin.
3.1.4.3 ANZRFH
For ANZRFH, only the “common data set” was found, not the actual entry form.
This set is divided into three parts: identifying elements, clinical elements and
genetic elements.
Identifying elements
This part includes demographic, identifying and contact information for the
patient and the patient's next of kin. It includes a reference to an “index or
relative” but it does not include the possibility to suggest relatives for screening.
Clinical elements
This part includes age at diagnosis of FH, index or relative, some physical
examination findings, family history of FH and premature CVD, personal history
of premature CVD, xanthoma or arcus, highest pre-treatment and on-treatment lab
results, whether the patient is on statins now, other CVD risk factors (smoking,
diabetes, hypertension, measurements of blood pressure).
Genetic elements
This part includes any positive confirmation of the three most common mutations.
3.2 General requirements on the decision support
Based on the characteristics of the identification and diagnosis process for FH,
there are some conclusions to be made about the need for decision support.
There is a need for guidelines that suggest whether an investigation for FH should
be carried out, as well as guidelines that represent the diagnostic criteria. The
benefits of automatic guidelines seem more clear in the screening stage. Once an
investigation has started, a different type of analysis begins where automated
guidelines is of less use. Such an analysis would include a discussion of the
relevance of each data point, if secondary information is trustworthy, and so on.
27
There will be factors taken into account such as if one criteria is particularly
severe, it may compensate for the absence of other criteria. There will be a
discussion of any exacerbating or mitigating factors outside the criteria, such as
lifestyle factors.
Guidelines depend both on the information from the patient as well as information
about the patient's relatives. This is the case for both the screening criteria as well
as the diagnosis criteria.
The guidelines depend both on new events registered in the EHR:s as well as
previous events in them. In the beginning of any screening program, there will be
a lot of investigations that arise as a result of previous events, such as
cardiovascular disease among relatives.
3.3 Information requirements and corresponding
archetypes
Based on the description of the process, it is possible to elicit the requirements for
archetypes.
3.3.1 Direct clinical information about the patient
Lab results of cholesterol levels
This information is needed for all four stages. The archetype
•
openEHR-EHR-OBSERVATION.lab_test-lipids.v1
can be used for lab results of cholesterol levels.
In this archetype includes slots for both total cholesterol and LDL cholesterol. The
units are either mmol/L or mg/dl.
Genetic markers
This information is used for screening, diagnosis and the registry. It was not
possible to find specialized archetypes for genetic tests in the repository. The
closest is a general archetype for lab tests.
Visible symptoms and physical examination findings
The symptoms of xanthomas and arcus cornealis are used in the screening, setting
of diagnosis, and the registry. They may be stored in the following archetypes
•
openEHR-EHR-OBSERVATION.exam.v1
•
openEHR-EHR-CLUSTER.inspection-skin.v1
The findings that are used for general assessment have their own archetypes.
Cardiovascular disease
CVD is used for screening, diagnosis and the registry. Existing cardiovascular
disease is a diagnosis, and may thus be stored in the
28
•
openEHR-EHR-EVALUATION.problem_diagnosis.v1
3.3.2 The patient's diagnosis
Once the diagnosis for FH has been set, it can be recorded using the archetype
•
openEHR-EHR-EVALUATION.problem_diagnosis.v1
Just recording the diagnosis is not enough, preferably it should include the method
that was used to set it (Simon Broome, DLCN)
3.3.3 Current lipid lowering therapies
The archetype used for drug therapies is
•
openEHR-EHR-ACTION.medication.v1.
For the information about the starting time and dose, it makes sense to make use
of the openEHR reference model, which provides attributes such as “current
action state.”
An interesting challenge is to extract the reasons for not taking the statins. It is not
hard to look for whether the terms exist in the EHR, but that does not mean that it
is the actual reason for avoiding statins. One suggestion is to provide the
suggestion, and use the “consent” archetype to confirm this.
3.3.4 Other procedures and medical information on the
patient
In this category is placed information requested by the registries.
Imaging/procedures
•
openEHR-EHR-ACTION.imaging_exam.v1
Laboratory data
•
openEHR-EHR-OBSERVATION.lab_test.v1
Other CVD risk factors
•
openEHR-EHR-COMPOSITION.lifestyle_factors.v1
3.3.5 Information about relatives
A particular requirement on the archetypes is that they should be able to carry
information about relatives. This information is needed for both screening and
diagnosis.
There are two basic approaches to this. One is to follow the direction of the
“cascade” and start at the index patient. A guideline is executed on this patient
that takes the patient's status as index (or the information necessary to qualify the
patient as index) as input, and returns the identities of the relatives of the patient
29
that are to be screened, along with the information about the index patient that is
needed for the investigation of these relatives.
Another approach is to begin at the other end: to run a guideline on ordinary, nondiagnosed individuals. This guideline would have as input the relatives'
identification numbers, and would fetch information from the journals of these
relatives. This information, together with information from the individual, is used
as input for the guideline. The output would be a recommendation if an
investigation should be started on the person.
As far as FH is concerned, it is mainly the first degree relatives that are of interest.
The main reason for this is that the disease is dominant so it cannot skip
generations. Therefore, it makes sense to recreate the cascade with guidelines that
reaches just step at a time, even though there are screening and diagnosis criteria
that use relationships of a degree greater than one. If a first-degree relative is
discovered not to have the disease, the relatives further away that would depend
on the first degree relative having the disease can be excluded. One issue that may
arise is that the relative is not available for investigation. In this case, a simple
marker can be added to the EHR of this person, so that his or her first-degree
relatives can still take advantage of the knowledge that exist of their second
degree relatives.
So which one of the approaches is of most interest? For a few different reasons,
the second approach will be the main path forward. In a cascade, it is the relative
next in line which is the subject of the investigation, so it makes sense to run the
guideline here and fetch information from the index.
The following information are needed about the relative:
Relative's medical history
It is necessary to know the medical history of the relative in terms of the specific
symptoms that is used for the diagnosis – ie coronary heart disease and xanthoma.
An interesting question is whether other parts of the relative's medical history
could be useful as well. There could possibly be elements of the medical history
that are related to the disease, and reveal symptoms and attempts at managing
these symptoms, even though the relative was never diagnosed with the disease.
For example, any recordings of the relative's LDL levels during his or her lifetime
could be useful.
Relative's genetic markers
If the relative has performed genetic testing for the relevant markers associated
with FH, the results of these tests is necessary to know. There are three known
genes involved.
Relative's sex
Since the cutoff age in the guidelines for coronary heart disease among relatives is
different depending on the relatives sex, with 55 years the limit for men and 60 for
women, the sex of the relative is required.
30
Relative's date of birth, deceased or not, date of death
The age of the relative is necessary to know, as well as whether he or she is
deceased, and in that case, the age at the time of death.
There are also some pieces of information that are not useful in the basic version
of the screening, but might be useful if the screening does not work
Relationship and degree of relationship
It is necessary to know what kind of relationship the relative has with the patient.
The degree of relationship is not stored information about the relative him- or
herself, but calculated.
Other relatives
In order to continue mapping relationships until the desired number of steps from
the patient has been covered, it is necessary to know the other relatives of the
Race and/or ethnicity
The genetic relative archetype also includes two other fields that are potentially of
interest, race and ethnicity. Since the prevalence of FH varies among different
populations of the world, this is potentially useful information. However, it
necessitates the correct terminology for describing the categories. The populations
that are affected does not necessarily correspond to national boundaries. Perhaps a
specific terminology can be created consisting of the populations that are known
to have a particularly high prevalence of the disease. This would require the
scientific knowledge about these populations to be fairly stable though.
31
Fig 3. The Genetic Relative archetype, viewed in the
Archetype Editor
So how is this information supposed to be managed? An archetype that is
specifically created for managing information about relatives is the Genetic
Relative archetype, also included as part of the Family History archetype. See Fig.
2. It is based on a model from the HL7 special interest group in Clinical
Genomics(27). Through these archetypes, is it possible to represent a pedigree in
two different ways(27):
•
through the pointers to the mother and father, based on the Maternal and
Paternal identifiers. The pedigree is created at runtime.
32
•
through recursion of instances of the Genetic Relative archetype. Note the
slot for “Genetic Relative” at the end of the archetype definition in Fig 2.
In the common openEHR repository, the genetic relative archetype is a part of the
Family History archetype. The name of the archetype is
•
openEHR-EHR-EVALUATION.family_history.v1
Note that there are no slots for children in the archetype. These exist in archetypes
such as
•
openEHR-DEMOGRAPHIC-PERSON.person.v1.
3.4 Required terminologies and terms
Terminologies are useful for recognizing contents of the proband's and relative's
EHR:s.
ICD-10
Familial hypercholesterolemia: one complicating factor when researching the
number of FH cases is that the disease was not given an independent code in ICD10(4). It shares the code E78.0 with Fredrickson hyperlipoproteinaemia type Iia,
Hyperbetalipoproteinaemia, Hyperlipidaemia group A, and low-densitylipoprotein-type [LDL] hyperlipoproteinaemiaI(28).
Tendinous xanthomata: E78.2. This code is also not unique, it is shared with a
number of similar diseases, including Broad- or floating-betalipoproteinaemia,
Fredrickson hyperlipoproteinaemia, type IIb or III, Hyperbetalipoproteinaemia
with prebetalipoproteinaemia, Hypercholesterolaemia with endogenous
hyperglyceridaemia, Hyperlipidaemia group C.
Cardiovascular disease: I30-I51
Cerebral and peripheral vascular disease: I61, I63, I65, I66, I73, I74, I77, I78, I81,
I82, I87.
Arcus cornealis: H18.4
33
3.5 Analysis of coverage and recurrence
Table 1: Units of information of the different criteria sets
Table 2: repository archetypes covering the units of information
34
As seen, there is a great deal of recurrence among the units of information. Nine
of them were included in three of the stages.
For a person going through the different stages, it is reasonable that 36 requests
for information are made during the four stages of disease. Of these, 26 requests
are made for units of information that are made on at least three occasions.
3.6 Results of the expert interview
The following were the main themes to emerge during the interview.
Compliance
The subject considers quality registries to have several problems. The first of this
what she refers to a “Catch-22”: the low coverage of registries lowers the
usefulness of them, reducing the incentive to contribute to them in the first place.
Design of registries
It makes sense to only include content in registries that are useful from a decision
support viewpoint, and not just for some undefined research far into the future.
This is what has happened in the registry where the subject is coordinator.
It is important to take the user group into account. The main distinction here is
between specialist and primary care. For primary care, it needs to be much more
straightforward and minimalistic, and tied to decision support.
A lot of time and resources is wasted in making stuff that is out of date by the
time it is finished. Technology has a way of making things possible that are more
advanced than what we could previously even imagine.
The design process for many registries is sometimes rather unstructured and not
very co-ordinated. Frequently it begins with an expert in the field who starts to
maintain a list of cases, using simple tools such as Excel to analyze them. Once a
steering group is created, there are strong opinions involved and a certain amount
of prestige in how registries should look. There is also discussion about which
guidelines to use and the guidelines themselves keep changing.
Integration between EHR:s and registries
One issue is that registries, in general, are not able to put demands on EHR
systems. It is usually only the “object owners” ie the county council IT
organizations themselves, that can do this. The effect of this is that it is easier for
the registries to adapt to the EHR:s than the other way around.
Barriers to integration
The subject considers legal issues to be a main barrier to integration. The
information in the EHR:s are a result of regular health care visits and participants
never consented to be part of a registry when they made the visits.
35
There is also a cultural divide between the health care side and the information
technology side. This divide is most visible in the sense that the IT people have
difficulties in placing reasonable demands on the medical side.
The future of registries
The subject believes that registries should be closed and the same functionality
should be added to journals. She has this opinion “even though it would cost me
my job.” She believes that many quality registries will not exist in a decade
because the premise is old-fashioned.
Previous experience about managing information in registries
The obvious advice is to look for information that is already in the journal and as
hard-coded as possible.
In Auricula had been included some fields of a qualitative nature, such as asking
if the patient has undergone education about the subject of the registry, but they
are short and we give the care providers the option to customize their response.
They had include some readings from medical devices that are not always
accurate but interpretable by staff. For this, they havd arranged so that it is
possible for staff to make the interpretations and then enter the information in a
standardized format that is different from the output of the device. The lesson, she
believed, was that just because there is interpretation involved does not mean that
the information cannot be standardized.
The information in the FH registry
This was followed by the discussion of the information in the eventual registry, if
there was something that could be misunderstood or not entered correctly.
Demographic information. No special comments.
Information about relatives. The immediate opinion of the subject is that the
concept of using information about relatives represents perhaps insurmountable
problems, because the relatives have not provided consent to participate. The
guideline, if applied on the general population, works essentially backwards to
how consent is supposed to work – it scans for relatives, so they can by design not
explicitly give their consent to participate.
Cholesterol levels. This will normally not present any problems but in the current
attempts to create an FH registry, it has played a role. The county council where
the “enthusiast” worked had different providers of the main EHR and the software
for lab result. This had complicated things because the cholesterol readings are the
most important part of any screening and registry.
Symptoms and diagnosies, compliance with ICD-10. The larger problem is that
the codes have not been entered in the first place, rather than being entered as a
different code. This is especially likely for xanthoma and arcus cornealis. There is
also no way to know if the lack of codes depends on the symptoms never being
discovered or just not recorded. Cardiovascular diseases, on the other hand, are
36
more likely to be entered but difficult to cover with codes because of the plurality
of codes for related diseases.
Genetic tests. The subject did not know, genetic tests are a new introduction to
the area, do not know about data formats.
Medication. This would not represent any problems from a standards perspective.
Obviously it is not possible to know if someone is actually taking the medication.
3.7 Creation and validation of GDL guideline
3.7.1 Used archetypes
During the creation of the guideline, it was considered a goal to make use as much
as possible of existing guidelines from the repository. However, this was related
to a number of problems, some of which were solved and others that were not.
They included:
•
The genetic relative archetype included an age format, based on the
openEHR data type DV_DURATION, whose correct usage was never
discovered.
•
A guideline with all involved archetypes (each of which worked
separately) caused the program to crash repeatedly.
One conclusion from the interview is that the guideline should not be designed to
gather information about relatives from their EHR. Instead, the screening will
likely be made based on information only about the patient, with the cholesterol
level as the defining factor. Once the patient has arrived for an encounter with a
physician, he or she can be interviewed about knowledge of any diagnoses,
symptoms etc found among relatives. These memories will frequently be very
vague – so there is little point in specifying what kind of cardiac disease etc that
the relative has suffered from.
Thus a new archetype was created, EVALUATION.dlcn_fh_relative.v1, to
manage all of the requested information about the relative. It included the
following:
•
Gender.
•
A choice of the type of first degree relationship: sibling, child or parent.
•
Xanthoma or arcus – present or not present.
•
Cardiovascular disease, present or not present.
•
Birth date.
•
LDL-C cholesterol level.
For the information about the patient, the “standard” archetypes from Table 2
were used except for the genetic test. For this, new archetype was created by
adding a “result” slot, with the values postive/negative, to the existing
37
OBSERVATION.lab_test.v1 archetype.
OBSERVATION.lab_test_genetic.v1.
This
archetype
was
named
Most archetypes were placed inside templates. The templates added one main
piece of functionality: to define the accepted terminology for the terminologybased fields to facilitate input. Another reason to have templates is that the GDL
Editor requires it to be able to create instances from cluster archetypes that are
placed within other archetypes. This was ultimately not needed when the Family
History archetype was no longer used.
The definitions of the instances looked as follows:
38
3.7.2 Rules
As seen in section 3.1.2.2, the DLNC criteria consists of eight score-giving rules.
They were represented as follows:
First-degree relative with known premature coronary and/or vascular disease (men
<55 years, women <60 years)
or
First-degree relative with known LDL-cholesterol above the 95th percentile for
age and sex
39
First-degree relative with tendinous xanthomata and/or arcus cornealis
or
Children aged less than 18 years with LDL-cholesterol above the 95th percentile
for age and sex
Criteria1 and 2 are simplified to one age and one LDL-C level. Since the
threshold is always lower with age and the same number of points is given, it is
just a matter of increasing the number of rules that identical except for the age and
level.
It is assumed that both sexes have the same thresholds for LDL-C and the same
age interval. Otherwise, just divide each rule with an OR for each gender and add
40
rules for each interval. An assumption is made that a child with >5.3mmol/dl
satisfies both criteria 1 and 2, thus giving 3 points.
Patient with premature coronary artery disease (ages as above)
41
Patient with premature cerebral or peripheral vascular disease (as above)
42
Tendinous xanthomata
43
Arcus cornealis prior to age 45 years
44
LDL-C ≥8.5 (identical rules for the other intervals)
45
DNA analysis: functional mutation in the LDLR, APOB or PCSK9 gene
46
When the guideline was run, this was the appearance of the form:
3.7.3 Comments on the design process
At the beginning of the assignment, the author was somewhat familiar with
openEHR. Even so, creating the guideline took a lot of time. Some of the reasons
for this are:
47
•
the language and tools being unintuitive
•
the tools being not well documented
•
bugs in the software
•
lack of proficiency by the author
It is difficult to generalize how much of this time usage depended on each of the
reasons. However, if these tools are to gain wider acceptance, the learning curve
should be as smooth as possible.
The following are some of the questions that took time (and help) to get to terms
with:
•
In order to be used in rules, archetypes needs to be instantiated. It is not
very intuitive how instantiating an archetype works and should be
understood conceptually.
•
It is not clear how it is possible to create more than one instantiation of the
same archetype using different templates. Sometimes, the corresponding
entry fields appear on the form in random order.
3.7.4 Validation with mock patients
The validation was carried out successfully.
ehrId gender
1 male
2 female
3 male
4 female
5 male
6 female
7 male
8 female
9 male
10 female
11 male
12 female
birthdate
1950-01-01
1950-01-01
1955-01-01
1955-01-01
1960-01-01
1960-01-01
1950-01-01
1950-01-01
2000-01-01
2000-01-01
2000-01-01
2000-01-01
RELATIVE
PATIENT
type_of_relationship
ldl_c tendinous_xanthomata_and_or_arcus_cornealis
coronary_and_or_vascular_diseases
gender birthdate
diagnosisldl_c result Score guide Manual
sibling
3 yes
yes
male
1950-01-01 i40,e782
3 Negative
8
8
sibling
4 no
yes
female 1950-01-01 i81
4.5 Negative
1
1
sibling
6 yes
no
male
1955-01-01 i41
6 Negative
5
5
parent
3 no
no
female 1955-01-01 i82,h184
7 Negative
10
10
parent
4 yes
yes
male
1960-01-01 i40
9 Negative
10
10
parent
6 no
yes
female 1960-01-01 i81
3 Negative
3
3
child
3 yes
no
male
1950-01-01 i41,e782 4.5 Positive
17
17
child
4 no
no
female 1950-01-01 i82
6 Positive
11
11
child
6 yes
yes
male
2000-01-01 i40
7 Positive
18
18
child
3 no
yes
female 2000-01-01 i81,h184
9 Positive
22
22
child
4 yes
no
male
2000-01-01 i41
3 Positive
10
10
child
6 no
no
female 2000-01-01 i82
4.5 Positive
13
13
48
4 Discussion
4.1 Not really a “process?”
In this study, it has been shown that is possible to create a working guideline in
GDL, operating on openEHR archetypes, that corresponds to a common set of
diagnostic criteria for FH with a significant information overlap by quality
registries.
However, there might not be that much of a “process” to speak about. At the start
of the project, the impression was that there would be different stages – of
screening, diagnosis, treatment and reporting, and it could all be considered a
“process,” and openEHR and GDL could assist in this process by facilitating
reuse information across the different stages. However, both the interview and the
work on the guideline suggests that perhaps it is best if there is only one guideline
based on a combination of screening and a patient visit. The patient would be
screened based on part of the guideline – perhaps only cholesterol values – and
called for a visit, where the rest of the information is entered manually. A report
to the registry is filed immediately based on the visit, maximizing coverage and
minimizing the effort involved.
4.2 OpenEHR, GDL and existing EHR:s
This is a good result, but it does not give a complete picture of the usefulness of
the tools in real life. It does not show that for any real production EHR, it is
possible to query or extract information as intended.
There are many EHR providers, and they have different approaches, as shown
when the interview subject approached them in relation to the Auricula registry
and the case of the laboratory list of the “enthusiast's” county council. The IFK2
project is also an example on the complexity of retrofitting an existing system.
The impression is that it would be easier to approach EHR systems vertically – ie
for the systems' procurers/owners to place requirements on the providers,
(preferably at the time of installation), rather than horizontally, ie approaching an
existing system as a third party.
This is not an unreasonable demand. Supporting the kind of investigations as
detailed in this study should be a core functionality of any EHR. What is the point
of recording a cholesterol level if not to learn that the patient might have a disease
he is not aware of? The notion of going back and using information to find out if
the patient might have another disease is one of the most elegant use cases of an
EHR. It seems strange that this functionality would be considered a superfluous
add-on.
It is not possible to know beforehand if a piece of information should be useful for
CDS in the future. So it is not unreasonable to put the requirement on a system
that all information in an EHR should be structured to be available for queries and
49
investigations that are not considered from the beginning. This would be
preferable to requiring that specific functionality such as FH screening is
included.
An interesting question is whether openEHR and GDL could act as a template or
role model for such an architecture. I believe that this study is an argument that
they can, by showing the ease at which guidelines can be created and
implemented on archetypes that were not created for this specific purpose. This
argument holds despite the need to create and modify archetypes for the guideline.
4.3 Usefulness of available information
No matter how correct any guideline is, it cannot function if there is no
information to trigger the execution of it. One way to understand this is to make a
comparison with one of the existing studies on GDL(11). In this study, it was
possible to perform a retrospective compliance check which showed that
preventive measures for stroke were underprescribed among primary care doctors.
However, this check used criteria such as diabetes and hypertension, that are very
unlikely not to leave a footprint in the EHR.
In a similar study for FH, it would be possible to look at the number of cholesterol
tests made in the general population, and register all the high values that were not
followed by an investigation for FH. Most likely, it would be possible to find
some cases of FH this way. But probably, this study would also show that a major
reason that FH is underdiagnosed is that too few cholesterol tests are done on
young people – as opposed to (11), where there were enough information in the
EHR:s to trigger a CHA2DS2-VASC calculation that provides suggestions for
who would benefit the most from prevention.
When discussing the value of openEHR and GDL, it seems important to keep in
mind that the most sensible approaches are frequently simple, and not dependent
on advanced tools. An example of this could be looking at a single variable that is
already queryable in the EHR, such as cholesterol levels. Another approach could
be to make a query in the cause-of-death registry for all those who died from
CVD at an early age, and then find their children and screen them. These
measures should be possible to do with any reasonably modern EHR system.
Those who have the access should do it as soon as possible.
But all fruits are not as low hanging as this. And once the cases are discovered,
they will need to be treated. Improving care over the long term is the purpose of
quality registries, and it might also be where openEHR and GDL really come out
as their best. Having data that is properly structured makes it easier to finding
deeper correlations among the data.
4.4 Limitations of the study
The main limitations of the study are a consequence of the study design. The
interviewed professional, while experienced in similar CDS solutions and quality
50
registries, was not working with diagnosing FH patients or reporting to or
managing an FH registry.
One limitation is that there is no comparison with other possible solutions. The
study shows that it is possible to use openEHR and GDL to accomplish some
tasks that would be more expensive to do without it, since the standards and tools
free. But it does not mean that it is the only, or even the best way, of
accomplishing the tasks.
Neither does the study take into account the total implications for implementing a
solution based on the tools. There is no assessment of the total costs and work
involved with a real implementation, where the tools would need to work in
tandem with other required components of a system. If there are too many
compatibility issues in the general EHR environment, any cost savings from using
the tools might be negated. These factors should be quantified. After this is done,
the total “costs” can be compared with other possible solutions.
4.5 Strengths and weaknesses of the study
One strength of this study is that the basic approach, of studying the process from
identification to registry reporting is a fruitful one. There is a great similarity
between the requirements on the EHR from screening criteria, diagnostic criteria
and registries. Therefore, it makes sense to consider these simultaneously, and
make sure the requirements are met when making EHR design or procurement
decisions.
One strength is that it creates a working GDL guideline, and this guideline
corresponds to one of the most common diagnostic guidelines for FH.
Another strength is that it outlines the context in which it is supposed to work
when implemented.
Finally, compared to previous literature on openEHR and GDL, the study
broadens the area of application slightly and attempts to use it for something it
was not explicitly designed for, and discusses the problems encountered when
doing this. There is the impression that previous studies have been concerned with
the most straightforward use cases of the language, the “low hanging fruit.”
One shortcoming of the study is that it only takes into account the present
situation of disease discovery, a situation that is likely to change. Since FH is a
hereditary disease with a low rate of de novo mutations, there will be less focus on
trying to find new cases of FH in the general population, and more focus on
tracking the cases as they are inherited from known carriers.
4.6 Generalizing the results
The specific results described in this study are of course only applicable to FH.
However, I believe that it is possible to draw lessons and conclusions from the
study as similar situations occur with other diseases. These situations are
becoming more and more frequent, as many diseases have both genetic and
51
lifestyle aspects, and it is necessary to approach one aspect in the context of the
other – using genetics to understand the current clinical situation, and using the
current clinical situation as the basis for inquiries into heredity.
When it comes to generalizability, it should be stressed that although the
aspiration is for the study to be generalizable (as the aspiration is with most case
studies), the results have a value by themselves. FH is a serious disease that is not
too uncommon, and documentation and decision support related to it is a
worthwhile area of study by itself.
4.7 Further research
The most obvious further research would simply be the realization of the
screening made possible by applying the guideline in a production EHR system.
There would be several interesting side-projects possible in such a study, such as
researching the proportion of misdiagnosis among FH carriers that is caused by
insufficient information, and what proportion is caused by not responding to
information that exists. How frequently is existing medical data that points
towards FH ignored?
Another interesting further venue of study would be the organizational
perspective. What are the underlying reasons for the separation between EHR:s
and registries? Why hasn't registry owners asked county council IT procurers
demand this functionality from EHR vendors?
An interesting project would be a comprehensive survey of all requested
information for all registries and any associated guidelines, and the creation of
their GDL equivalents. This may sound like a large scale endeavor but there are
significant economies of scale. Such a library would be a powerful statement to
decision makers that there is no excuse for the current situation.
Finally, on a more technical level, a comparison study could be made where a
comparison is made between the tools covered in this study and more specialized
software for clinical pathways.
52
5 Conclusion
This aim of this study was to determine if openEHR and GDL could help optimize
the documentation and decision making involved in the process from the first
attempt at identifying carriers to reporting of cases to a quality registry.
Through a case study of the disease familiar hypercholesterolemia, the study
shows that the standards may indeed have such a role. It is possible to create a
working guideline in GDL, operating on openEHR archetypes, that corresponds to
a common set of diagnostic criteria for FH and also uses much of the same
information requested by quality registries. Thus if the EHR system is built or
mapped according to these archetypes, it would work there as well.
However, the chances of realizing this promise seem to depend on whether it is
possible to design the EHR according to these standards from the beginning by
“vertically” influencing those who procure it, or approaching the system
“horizontally” by trying to map archetypes onto an existing system.
This points to the necessity of, from the very beginning of the documentation
process, consider how the gathered information may be used, both according to
specific requests from registries, but also in preparation for requests that may not
be specified yet.
In summary, this study presents one step on the path to a better integration of
EHR:s, decision support, and quality registries, a development that may have real
benefits for the health care system in general and patients with familial
hypercholesterolemia in particular.
53
6 References
1. Varghese MJ. Familial hypercholesterolemia: A review. Ann Pediatr Cardiol
[Internet].
2014;May;7(2):107–17.
Available
from:
http://www.annalspc.com/article.asp?issn=09742069;year=2014;volume=7;issue=2;spage=107;epage=117;aulast=Varghes
e
2. Hammond E, Watts GF, Rubinstein Y, Farid W, Livingston M, Knowles JW, et
al. Role of international registries in enhancing the care of familial
hypercholesterolaemia. Int J Evid Based Healthc [Internet]. 2013 Jun [cited
2014
Jul
15];11(2):134–9.
Available
from:
http://www.ncbi.nlm.nih.gov/pubmed/23750577
3. O’Brien EC, Roe MT, Fraulo ES, Peterson ED, Ballantyne CM, Genest J, et al.
Rationale and design of the familial hypercholesterolemia foundation
CAscade SCreening for Awareness and DEtection of Familial
Hypercholesterolemia registry. Am Heart J [Internet]. Mosby, Inc.; 2014
Mar [cited 2014 Jul 12];167(3):342–349.e17. Available from:
http://www.ncbi.nlm.nih.gov/pubmed/24576518
4. Nordestgaard BG, Chapman MJ, Humphries SE, Ginsberg HN, Masana L,
Descamps OS, et al. Familial hypercholesterolaemia is underdiagnosed and
undertreated in the general population: guidance for clinicians to prevent
coronary heart disease: consensus statement of the European
Atherosclerosis Society. Eur Heart J [Internet]. 2013 Dec [cited 2014 Jul
15];34(45):3478–90a.
Available
from:
http://www.pubmedcentral.nih.gov/articlerender.fcgi?
artid=3844152&tool=pmcentrez&rendertype=abstract
5. Identification and management of familial hypercholesterolaemia ( FH ) Full
guideline August 2008 [Internet]. National Collaborating Centre for
Primary
Care.
2008.
Available
from:
http://www.nice.org.uk/guidance/CG71/chapter/introduction
6. Shortliffe EJ. Biomedical Informatics. New York: Springer; 2006.
7. The OpenEHR Foundation. What is openEHR? [Internet]. Available from:
http://www.openehr.org/what_is_openehr
8. Zanstra PE, Stroetmann VN, Rodrigues JM, Karl A. Conceptual Framework for
eHealth Interoperability. 2007.
9. Greenes R. Clinical Decision Support - The Road Ahead. Elsevier Inc.; 2007.
10. Chen R, Corbal I. Guideline Definition Language ( GDL ). Cambio Healthcare
Systems; 2013. p. 1–23.
11. Chen R, Valladares C, Corbal I, Anani N, Koch S. Early Experiences from a
Guideline-based Computerized Clinical Decision Support for Stroke
Prevention in Atrial Fibrillation. 2013;244–7.
54
12. Anani N, Chen R, Prazeres T, Koch S. OpenEHR-Based Representation of
Guideline Compliance Data through the Example of Stroke Clinical
Practice Guidelines. Quality of Life through Quality of Information. IOS
press; 2012. p. 487–91.
13. Guldgruvan i hälso- och sjukvården. Översyn av de nationella
kvalitetsregistren. Förslag till gemensam satsning 2011-2015. Stockholm;
2010.
14. Riksrevisionen. Statens satsningar på nationella kvalitetsregister. 2013.
15. Uppsala Clinical Research Center. Teknisk Info [Internet]. [cited 2014 Aug 2].
Available
from:
http://www.ucr.uu.se/sv/index.php/kvalitetsregister2/teknisk-info
16. IFK2 – del 2. Gemensam utveckling av informationshantering för Nationella
Kvalitetsregister [Internet]. Stockholm; 2011 p. 0–47. Available from:
http://www.cehis.se/images/uploads/dokumentarkiv/Slutrapport_IFK_2_11
.pdf
17. Sterner S. Register ska rädda fler liv. Norrköpings Tidningar [Internet]. 2013;
Available from: http://www.nt.se/nyheter/norrkoping/register-ska-raddafler-liv-9150809.aspx
18. Vanwynsberghe R. Redefining Case Study. Int J Qual Methods. 2007;80–94.
19. Kagolovsky Y, Brillinger K. A Systematic Approach to Using Case Studies in
Health Informatics Education. 2009;301–5.
20. Beale ET, Heard S, Kalra D, Lloyd D. EHR Information Model. The
openEHR Foundation; 2008.
21. Beale ET, Heard S, Kalra D, Lloyd D. Common Information Model. The
openEHR Foundation; 2008.
22. Beale ET, Heard S, Kalra D, Lloyd D. Data Structures Information Model.
The openEHR Foundation; 2008.
23. Beale ET, Heard S. Architecture Overview. The openEHR Foundation; 2008.
24. Hunn A, Fox N, Hunn A. Trent Focus for Research and Development in
Primary Health Care Using Interviews in a Research Project. Trent Focus.
2002;
25. Elo S, Kyngäs H. The qualitative content analysis process. J Adv Nurs
[Internet]. 2008 Apr [cited 2014 Jul 9];62(1):107–15. Available from:
http://www.ncbi.nlm.nih.gov/pubmed/18352969
26. Fahed AC, Nemer GM. Familial hypercholesterolemia: the lipids or the
genes? Nutr Metab (Lond) [Internet]. BioMed Central Ltd; 2011 Jan [cited
2014
Jul
13];8(1):23.
Available
from:
http://www.pubmedcentral.nih.gov/articlerender.fcgi?
artid=3104361&tool=pmcentrez&rendertype=abstract
55
27. Georgii-hemming P, Chen R. Can we use the openEHR Family History
Archetype to enable Clinical Decision Support in Genetic Medicine?
28. ICD-10 Version:2010 [Internet]. [cited 2014 Aug 2]. Available from:
http://apps.who.int/classifications/icd10/browse/2010/en#/E78.0
56
7 Appendices
Appendix A: Interview form
Introduction
Interested in expertise in registries in general...
Background

Experience of re-use between EHR:s and registries?

Lessons of these experiences?

How much is reuseable for different registries?
Process of designing registries
1. How are registries designed? Who is typically involved at different stages
of the process, and what are their roles?
2. How frequently are registries changed? How do these changes look?
Format? Terminology? What datatypes are used?
3. What are similar problems encountered by all registries?
Process of populating and using registries
1. Problems encountered?
2. How is the problem of compliance managed?
3. Do registries fulfil their function? What else can make them do that?
Discussion of information/data types requested in the FH guideline









Demographics: age of patient, patient deceased, gender. Problems?
Information about relatives – accessible?
Cholesterol and other lab measurements
Clinical symptoms/diagnoses such as xanthoma and arcus: too narrow for
ICD
Coronary vascular disease: many different ICD codes
Genetic tests – standards?
Use of medication? Complicated, time period, compliance?
Cause of death?
The diagnosis/criteria for participation in the registry itself?
Further questions
Anyone else I can ask who might know more about FH?
57