Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Prenatal testing wikipedia , lookup
Adherence (medicine) wikipedia , lookup
Rhetoric of health and medicine wikipedia , lookup
Epidemiology wikipedia , lookup
Race and health wikipedia , lookup
Patient safety wikipedia , lookup
Seven Countries Study wikipedia , lookup
Electronic prescribing wikipedia , lookup
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