Design and development of a decision support system for screening of Lynch syndrome using openehr

Transcription

1 Master's Programme in Health Informatics Spring Semester 2015 Degree thesis, 30 Credits Design and development of a decision support system for screening of Lynch syndrome using openehr Author: Blanca Flores Author: Blanca Flores Main supervisor: MD, PhD Rong Chen, Cambio Healthcare Systems, LIME Karolinksa Institutet Co supervisor: MD, PhD Patrik Hemming, KI Center for Rare Diseases Examiner: PhD, Andrzej Konowicz, LIME Karolinska Institutet 1

2 Master's Programme in Health Informatics Spring Semester 2015 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. Stockholm, Blanca Flores 2

3 Master's Programme in Health Informatics Spring Semester 2015 Degree thesis, 30 Credits Design and development of a decision support system for screening of Lynch syndrome using openehr Abstract Background: Lynch Syndrome is a genetic rare disease associated with increased risks for developing colorectal cancer at an early age (2). Individuals can be screened based on family s medical history using the Amsterdam Criteria II and Bethesda Guidelines. The implementation of a CDSS could support clinicians in preventive care during the screening process to refer patients with suspected diagnosis for testing. Objective: The aim was to assess the feasibility of a CDSS for the Lynch Syndrome screening process followed in primary care settings. The main objective was to design a CDSS application modeling the clinical guidelines with openehr and GDL. The secondary objectives were to identify the requirements in terms of clinical data, archetypes and rules, and validate them to ensure they delivered the expected results. Methods: A qualitative analysis was followed to evaluate the case study of the screening process of Lynch Syndrome. The phases followed were requirements analysis, design & development and testing. The clinical guidelines were analyzed to map the requirements to openehr archetypes and rules that were used during the development of GDL guidelines. Mock data on 25 patients was used for validation. Results: Three GDL guidelines were developed with openehr archetypes. They modeled the screening process using input data from the patient and relative s medical history to determine if referral for testing was recommended. They were validated with mock patient data and results were accurate with the expected outcome. A user interface prototype was designed to visualize user interaction. Conclusion: OpenEHR and GDL offer the capabilities of developing a CDSS that can model a patient s screening process and support accurate referral of Lynch Syndrome. The architecture of OpenEHR provides the flexibility of further adapting the system to new requirements and additional features. Keywords: Rare diseases, Lynch Syndrome, colorectal cancer, clinical decision support systems, openehr, screening 3

4 Acknowledgements Thanks to all those who contributed and made this thesis project an enjoyable journey. To my supervisor Rong Chen, for the opportunity to perform this thesis at Cambio, providing me the necessary resources and inspiring me in pursuing a project involving CDSS and openehr. To my supervisor Patrik Hemming, for supporting the idea of this project and providing me valuable knowledge and advice on the topic of rare diseases and Lynch Syndrome. To the Mexican National Council of Science and Technology (CONACYT) for funding my scholarship to study this program at Karolinska Institutet. To my friends and family, for all their support. To Andreas, for motivating me and making sure I never ran out of study food. To Mom and Dad, for supporting me to accomplish one more goal. To Jorge, for inspiring my interest in IT. And to Valery, for reminding me there is always time to take a break. 4

5 Table of Contents 1. Introduction Lynch Syndrome Clinical Decision Support Systems OpenEHR and GDL Problem Definition Aim and objectives Research questions Methods Research methodologies Study design Data collection Working tools Ethical considerations Results Requirements Analysis Guideline design Process flowchart Mapping of archetypes Guideline development Archetype definitions Creation of rules Preconditions Guideline execution Testing Mock patient data Testing results Interface prototype Discussion General findings Limitations Strengths and weaknesses Future research Conclusions References Appendices Appendix A. Time frame of study Appendix B. Archetype details Appendix C. GDL Definitions, rules and execution Appendix D. Guide details Appendix E. Mock patient data case descriptions Appendix F. Log results

6 List of Abbreviations CDSS CIG EHR GDL HNPCC LS MSI Clinical Decision Support System Computer Interpretable Guidelines Electronic Health Record Guideline Definition Language Hereditary Nonpolyposis Colorectal Cancer Lynch Syndrome Microsatellite Instability List of Figures Figure 1 - Lynch Syndrome Cancer Risks compared to general population 8 Figure 2 Decision flow for Lynch Syndrome screening 10 Figure 3 - Study Framework 15 Figure 4 - Algorithm flowchart for Lynch Syndrome screening 20 Figure 5 Mapping of openehr archetypes and elements to Lynch Syndrome guidelines 21 Figure 6 - Definition of archetypes for Amsterdam Criteria 22 Figure 7 - Guideline archetypes 23 Figure 10 - Rules for Amsterdam Criteria 24 Figure 11 - Rules for Bethesda Guidelines 24 Figure 12 - Amsterdam Criteria Rule for default values 25 Figure 13 - Rule for number of relatives with LS cancer greater than 3 25 Figure 14 Amsterdam Criteria rule to set to Present value 26 Figure 15 Bethesda Guideline rule to set to Present value 26 Figure 16 - Bethesda Guidelines precondition rule 27 Figure 17 - Amsterdam Criteria for GDL execution 28 Figure 18 - Execution of rules for 25 cases 30 Figure 19 - Execution results in CDS workbench 31 Figure 20 - Referral results on mock patient 31 Figure 21 - Interface Prototype 32 List of Tables Table 1 - Amsterdam Criteria II 9 Table 2 - Revised Bethesda Guidelines 9 Table 3 - Modeling, design and validation tools 17 Table 4 - Criterions, Data and Rules for LS screening 19 Table 5 - Mock patient data 30 6

7 1. Introduction 1.1 Lynch Syndrome Rare diseases are chronically, debilitating conditions that affect less than 5 in people in EU countries (1). Although this statistic can lead to believe that these diseases are uncommon, around 7000 rare diseases have been identified currently affecting 6-8% of the EU population, which translates to between 27 and 36 million people (1). A genetic rare disease associated with increased risks for developing colorectal cancer at an early age is Lynch Syndrome, also referred to as Hereditary Nonpolyposis Colorectal Cancer (HNPCC) (2). Detection of colorectal cancer is important since it is the third most common cancer in men and the second in women (3). Lynch Syndrome also increases the risk of developing other cancers known as Lynch-associated cancers. These are cancers of the endometrium, stomach, ovaries, pancreas, ureter and renal pelvis, biliary tract, brain, sebaceous gland adenomas and small bowel cancers (4). Diagnosis for this familial syndrome can be made based on a patient s medical history, family s medical history or testing for germline mutation. Since an individual diagnosed has two copies of the Lynch Syndrome genes, there is a 50% chance that the mutation gets passed to a child from birth. (5). Moreover, males and females are equally likely to be affected and this syndrome does not skip generations (5). For this reason, diagnosis in a patient can help identify family members that may be at risk of having this syndrome. Efficient screening practices to diagnose Lynch Syndrome are important due to the high number of Lynch-associated cancers present each year. Although individuals with Lynch Syndrome are predisposed to numerous types of cancer, the risk of developing colorectal cancer is the highest. Colorectal cancer accounts for 8% of all cancer deaths, with an estimated 1.4 million cases of colorectal cancer diagnosed worldwide in 2012 and about 693,900 deaths caused by it (3). From all colorectal cancers, 3-5% are caused by Lynch Syndrome, which represents between to cases each year (2). The estimated risk is 66% to 80% in men and 43% to 60% in women, with half of the individuals developing this cancer before the age of 50 years old (5 7). The median age for diagnosis in men and women drops from 68 years and 72 years to 42 years and 47 years respectively with Lynch Syndrome (6). In addition, women have an increased lifetime risk of 40% to 60% for endometrial cancer (5). Figure 1 represents the estimated risks of some cancers for men and women who have been diagnosed with Lynch Syndrome, compared to the risks for the general population (5). Since LS is a genetic disease, it is possible to detect patients who are at high risk of developing Lynch-associated cancers by evaluating specific criteria from their relatives medical history and from the patient itself. 7

8 Figure 1 - Lynch Syndrome Cancer Risks compared to general population 1 Colorectal cancer usually develops slowly over a period of 10 to 15 years and often has no symptoms at an early stage, which is why screening is crucial (6). In addition, colorectal cancers tend to develop from adenomatous polyps, which are noncancerous growths in the colon and rectum and can be detected through screening and removed to prevent further development of cancer (6). Evidence suggests that when LS is diagnosed and families are kept under frequent screening, colorectal cancer can be prevented. For example, a study performed in Finland indicated that surveillance of 22 families with a follow-up duration of 10 years led to a reduction of colorectal cancer by 62% (7). For this reason, it is important that families with a history of LS can be accurately identified and testing can start at an early age (6). Once an individual is identified with high risks for LS, specific pathology tests can be performed on tumors to find characteristics that could be caused by this syndrome. These are known as microsatellite instability (MSI) assay and immunohistochemical (IHC) analysis. (5). Genetic testing is then performed on a blood sample if the pathology results suggest the possibility of Lynch Syndrome, looking for mutations in the genes to confirm the diagnosis (5). In 1991, the Amsterdam Criteria I was established by the International Collaborative Group on Hereditary Nonpolyposis Colorectal Cancer to standardize the diagnostic criteria of Lynch Syndrome; it was revised in 1998 and defined as the Amsterdam Criteria II, focusing on the families medical history of Lynch-associated cancers among relatives (8). This criteria has proven to be highly successful, with an estimated sensitivity of 60% and specificity of 70% (9). The Amsterdam Criteria II, presented in Table 1, consists of six criterions that have to be met by a patient s relatives to suspect Lynch Syndrome. The criterions involve the diagnosis of Lynch-associated cancers on relatives, the degree of relationship, age at the moment of diagnosis and specific characteristics of the cancers. This information is usually obtained from a patient by asking about its relatives medical history. 1 The University of Texas MD Anderson Cancer Center. Lynch Syndrome [Internet]. Available from: 8

9 Amsterdam Criteria II The Amsterdam Criteria II defines the minimum requirements for a clinical diagnosis of Lynch Syndrome/HNPCC. There should be at least three relatives with a Lynch/HNPCC-associated cancer One should be a first-degree relative to the other two At least two successive generations should be affected At least one should be diagnosed before age 50 Familial adenomatous polyposis should be excluded Tumors should be verified by pathological examination Table 1 - Amsterdam Criteria II In addition, the Bethesda Guidelines were developed in 1996 by the National Cancer Institute, to identify individuals with HNPCC and recommend testing for microsatellite instability (MSI), a common characteristic of HNPCC (4). In 2002, an HNPCC workshop was held at the National Cancer Institute in Bethesda to revise and improve these guidelines, and the Revised Bethesda Guidelines were outlined to identify individuals at risk for Lynch Syndrome (4). Sensitivity for these guidelines has been shown to be at 96% (4). Table 2 presents the criteria specified for the Revised Bethesda Guidelines. These guidelines consist of five independent criterions and Lynch Syndrome can be suspected when at least one is met. These involve the variables such as the diagnosis of colorectal cancer and other Lynchassociated cancers in a patient or its relatives, age at the moment of diagnosis, degree of relationship, amount of relatives diagnosed and specific features of the cancers. Revised Bethesda Guidelines Individuals should be tested in the following situations: 1. Colorectal cancer diagnosed in a patient who is less than 50 years of age. 2. Presence of synchronous, metachronous colorectal, or other HNPCC-associated tumors* regardless of age. 3. Colorectal cancer with the MSI-H histology diagnosed in a patient who is less than 60 years of age. 4. Colorectal cancer/hnpcc-related tumor diagnosed in one or more first-degree relatives, with one of the cancers being diagnosed under age 50 years. 5. Colorectal cancer/hnpcc-related tumor diagnosed in two or more first- or seconddegree relatives, regardless of age. * HNPCC-related tumors include colorectal, endometrial, stomach, ovarian, pancreas, ureter and renal pelvis, biliary tract, and brain (usually glioblastoma as seen in Turcot syndrome) tumors, sebaceous gland adenomas and keratoacanthomas in Muir Torre syndrome, and carcinoma of the small bowel Table 2 - Revised Bethesda Guidelines 9

10 When a clinician meets a patient that has been diagnosed with a Lynch-associated cancer or has are other reasons to suspect the presence of Lynch Syndrome, the clinical guidelines are validated to determine if genetic testing is necessary. Thus, the screening process takes place for preventive care. Figure 2 represents the decision flow that is followed during the screening process, which can involve the use of one or both guidelines depending on the clinical scenario (4,8). The Amsterdam Criteria II is validated first with data from the relatives medical history, to verify if the six criterions are met. If all of them are positive, then the patient should be referred for genetic testing to a specialist, and family members can also be offered testing. When the Amsterdam Criteria II is not met, the Revised Bethesda Guideline is validated with data from the patient and its relatives. If the individual meets one of the five criterions from this guideline, then the patient should be referred for genetic testing, otherwise the possibility of Lynch Syndrome is discarded. Figure 2 Decision flow for Lynch Syndrome screening The dissemination of these guidelines and their use is important to ensure that patients get diagnosed as early as possible. Since these guidelines evaluate patients and families using the clinical and pathological features of the families pedigree and their medical history, having complete and accurate data is key for an efficient and effective screening process. Diagnosis of Lynch Syndrome can improve quality of healthcare for patients and their families. Identifying a patient that carries this hereditary syndrome can alert relatives to be aware of their high risks of developing or having Lynch-associated cancers, and for clinicians to take preventive measures. For example, clinicians can keep a long-term surveillance and perform appropriate testing on these individuals to detect cancers at an early stage, when they are more likely to be cured with a less extensive treatment and faster recovery (6). 10

11 1.2 Clinical Decision Support Systems Clinical decision support systems are designed to provide clinicians with knowledge and patient-specific information, presented at appropriate times to optimize decision-making and enhance healthcare (10,11). Because Lynch Syndrome requires different criteria to be met in order to suspect a diagnosis and refer patients for testing, the use of computer prompts similar to those that alert general practitioners about issues in prescriptions are a promising avenue to explore (12). CDSS applied for screening of Lynch Syndrome could benefit and support clinicians at various stages in the care process, such as preventive care, diagnosis and implementing treatment (11). Some of the benefits of screening are identifying presymptomatic individuals at high risk for cancer or other diseases due to hereditary syndromes, allowing for targeted screening based on genetic risk, helping in direct management and decision-making, and in some cases even preventing cancer development (13). The implementation of CDSS for preventive care on rare diseases is a motivating area to explore, since the optimization of screening practices could improve diagnosis at proper times and prevent delays in treatment for Lynch Syndrome and other rare diseases. Three common features in CDSS are the knowledge base, the inference engine and a mechanism to communicate with the user (10). The knowledge base is information in the form of rules, the inference engine consists of formulas that combine rules with patient data and the communication mechanism involves the input and output of data used in decisionmaking. These three features were important considerations in the design of a CDSS that could support Lynch Syndrome screening. The Amsterdam Criteria II and Revised Bethesda Guidelines could provide the GDL rules for the knowledge base, openehr could provide the structure for the inference engine and these could be integrated with a proper user interface or an EHR for input and output of data. 1.3 OpenEHR and GDL OpenEHR is an open domain-driven platform for developing flexible e-health systems, such as electronic health records (EHRs), and can be used to develop CDSS applications (14). The specifications for a health information reference model have been defined by the OpenEHR Foundation, and consist of a language intended to build clinical models, or archetypes, that are independent from the software and query language (14). The multi-level architecture allows the use of external health terminologies and supports interoperability. There are three main benefits to using openehr (14): The possibility to adapt systems to new requirements, since models can be developed separately and integrated to the EHR as needed. The reduction of the amount of work and improved semantic traceability due to the possibility to reuse parts of the software with templates and archetypes. Portable queries, which are based on content models, enable decision support tools and allow an ongoing development for EHRs. 11

12 Archetypes are structures of data used in openehr that can be reused as building blocks for different health information models. These are external to the software, and due to their adaptability, health information systems can be computed at a semantic level and enable functions such as decision support and research query (14). Clinical concerns and the technical design of data storage can be separated through archetypes and the two-level modeling (15). The first level involves the technical concerns, information structure and data types using the Reference Model, while the second level handles clinical domains and semantics (15). Key attributes of health records are managed by the reference model and do not need to be addressed by each archetype. The archetypes represent discrete specifications of clinical information, which are as inclusive as possible; they offer great advantages since data can be specified in an understandable manner to health professionals and IT staff (14). In addition, different archetypes can be aggregated into templates, which add further constraints for their use in specific settings and support semi-automatic derivation of user interfaces (14,15). Computer Interpretable Guidelines (CIG) constitute the knowledge base for a guidelinebased CDSS and represent the decision criteria relating to clinical abstractions (15). The Guideline Definition Language is one example of CIG and was developed by Cambio Healthcare Systems to support the expression of clinical rules with openehr archetypes. In addition, it was designed to represent clinical knowledge for decision support featuring natural language neutrality (16). The clinical rules can be expressed on top of openehr archetypes without depending on a particular language or terminology (17). In GDL, data from elements in the archetypes are used as input and output of CDS rules. Furthermore, a set of common language expressions can support arithmetic calculations, logic operations and functions (16). GDL guidelines can be created for a specific clinical purpose and can be reusable for different contexts. They can be created relating several rules into one guideline and different guidelines can be linked together to support complex decision support by selecting the output of a rule as the input of another rule (16). Previous research works have studied the feasibility of implementing data requirements with openehr and GDL. González-Ferrer et al. addressed the MobiGuide project, aimed for data integration for CDS based on openehr archetypes, initially covering the domains of Gestational Diabetes Mellitus and Atrial Fibrillation (15). In this project, a Personal Health Record (PHR) accessed patient data from hospital EHRs and wearable sensors, and contained recommendations provided by the CDSS (15). Other studies have been performed in this area at Karolinska Institutet as master thesis projects. Engblom, K. studied the applications of openehr and GDL to optimize the screening of Familial Hypercholesterolemia and the reporting to quality registries (18). In addition, Kalliamvakos, K. evaluated the use of GDL in the area of severe sepsis and septic shock (19). 12

13 1.4 Problem Definition Patients who suffer from rare diseases tend to experience particular obstacles in healthcare such as lack of access to correct diagnosis, delays in diagnosis and lack of quality information and support at the time of diagnosis (20). Supporting clinicians in screening practices for preventive care of rare diseases could benefit the efficiency of the clinical workflow and patients health care. In the case of Lynch Syndrome, it is vital to ensure that clinicians are aware of the possibility of this disease in their patients and can refer them accordingly for diagnostic investigations or further testing (12). Since expertise is usually needed to establish a precise diagnosis, having clear referral pathways is important (12). This screening process could be optimized with the implementation of a CDSS using openehr and GDL. Currently, clinicians check each guideline individually and obtain the data from the patient. A CDSS could collect data and integrate both guidelines into one application. This could support faster and accurate referrals based on the clinical guidelines and ensure that genetic testing is performed on patients only when the disease is suspected. In order to develop a CDSS for the screening process, the clinical guidelines should be analyzed to determine if it is feasible to model them into openehr archetypes and GDL rules. 1.5 Aim and objectives The implementation of a CDSS could support the current need of screening and early detection of Lynch Syndrome. It could also raise awareness in clinicians of the existence of this syndrome, optimize the screening process and support the referral of these patients to specialists at proper times for testing and diagnosis. The aim of this study was to assess the feasibility of implementing a CDSS in preventive care for the Lynch Syndrome screening process followed in primary care settings. The two clinical guidelines used in Sweden, Amsterdam Criteria II and Revised Bethesda Guidelines, were modeled and validated using openehr and GDL guidelines. To achieve this, an understanding of the screening process and of the information collected from patients for decision-making was necessary. Thus, the main objective was to design a CDSS application to screen patients for Lynch Syndrome, based on the clinical guidelines and using openehr and GDL. The secondary objectives were to identify the requirements for this application in terms of clinical data, archetypes and rules, and validate it with mock patient data that addressed different clinical scenarios to ensure that it could deliver the expected results. 1.6 Research questions This study focused on the following research questions: What information is needed to support clinicians decision-making during the screening process of Lynch syndrome? How can openehr and GDL be applied to design a CDSS that is used during this screening process? 13

14 2. Methods 2.1 Research methodologies To assess the feasibility of using a CDSS during preventive care of rare diseases, the screening process of patients for Lynch Syndrome was selected as a case study. To develop a deep understanding of a case and gain insight into the interaction between a phenomenon and a case, the case study methodology investigates a contemporary phenomenon within its real life context (21). A case can be a relatively bounded object or a process, being theoretical, empirical or both (23). Considering the three principles of reasoning: deductive, inductive and abductive, generalizations are made from a case using one or a combination of these principles (22). One major feature of the case study is that different methods can be followed with the purpose of illuminating a case from different angles (22). A qualitative analysis was used to evaluate this case study. A qualitative method can be used initially in a study to create a theory about an phenomenon and identify important variables (21). This was used first to describe and analyze the screening process followed by physicians when they encounter a potential candidate for diagnosis. The results from this qualitative analysis included the clinical guidelines in the form of text-based rules to represent the decision process and clinical data expressed as openehr archetypes, which were validated by an expert on this area. Afterwards, the rules and the workflow were modeled as GDL rules to develop an application that would be theoretically integrated into an EHR. Afterwards, mock patient data was created to simulate possible clinical scenarios and the CDSS application was validated to demonstrate it worked effectively and the results were as expected. Furthermore, a prototype for a user interface was designed to obtain a visual concept of how a user could interact with the CDSS. These results provided valuable information to evaluate the feasibility of implementing this application in a clinical setting. 2.2 Study design The study was performed in three different phases to answer the proposed research questions. The phases were adapted from Royce s waterfall model for software development, which consists of the following steps: system requirements, software requirements, analysis, program design, coding, testing and operations (24). Due to the scope of this study and considering the technical tools to be used, the steps were adapted into the phases represented on Figure 3. These were: Requirements Analysis, Design and Development and Testing. 14

15 Figure 3 - Study Framework During the first phase, a literature review was performed to gain insight and knowledge regarding rare diseases, particularly Lynch syndrome. Also, it supported the understanding of tools such as openehr and GDL, and how they could be used to develop a CDSS application. Three meetings were held during the time period of December 2014 to March 2015 with Dr. Patrick Hemming, a clinician and expert in the area of rare diseases, and Dr. Rong Chen, a clinician and expert in CDSS development and implementation. During the meetings, the current screening workflow followed by general practitioners, the theory behind the clinical guidelines used and the opportunities for CDSS applications in this area were discussed, along with recommendations and feedback for this study. Supervision was held during the entire thesis project to support questions on specific areas of the development process and clinical knowledge. From the literature research and the meetings, the appropriate clinical guidelines were identified and analyzed. Afterwards, the guidelines were translated into text-based rules and the clinical data required for decision-making was classified to determine how to express it as openehr archetypes. The second phase involved creating a workflow of how the screening process takes place and mapping the relationships of the clinical data with openehr archetypes. This mapping allowed to properly design the application and to determine that both existing and new archetypes were needed. Also, the clinical guidelines were analyzed to determine which rules were followed for each criterion. After the creation of new archetypes and selection of existing archetypes, the clinical guidelines in the form of text-based rules were converted into three GDL guidelines to develop a complete CDSS screening application. Finally, during the third phase, mock patient data was created for 25 patients, to simulate different clinical scenarios. The data was saved into four csv files corresponding to four different archetypes that were used for input of data: Family History, Basic Demographics, 15

16 Amsterdam Criteria and Bethesda Guidelines. Each of these archetypes contained different elements for specific data to be used to evaluate the criteria. Tests were run with the data to validate the effectiveness of the application. The results from validation provided useful information to determine how this application could impact the screening process. After the testing phase was completed, a prototype was designed to illustrate an interface and how it would work following an example for a clinical scenario. 2.3 Data collection Data collection was required during the first and second phases of the study. A literature review was performed through databases and journals from the online Karolinska Institutet library and the Internet search engine Google scholar. Keywords used during the search were: Rare diseases, Lynch syndrome, guidelines, diagnosis, colorectal cancer clinical decision support systems, openehr, software development models. Data was also collected from meetings with both clinicians regarding the screening process and the clinical guidelines: Amsterdam Criteria II and Revised Bethesda Guidelines. Afterwards, the clinical guidelines were analyzed and data was collected and classified into two sections: clinical data required from the patient and the relatives and data regarding requirements for the design of the CDSS. The data was used to translate the guidelines into text-based rules and determine which archetypes were needed. The data was mapped according to the archetype that it was related to and an algorithm workflow was created to determine which type of questions were needed for physicians to ask patients and collect all the necessary data. This was then used to model the text-based rules into GDL guidelines. 2.4 Working tools The six different tools used during this study for modeling, design and validation of the CDSS application are described below in Table 3. Tool Description Use Archetype Editor GDL Editor v This tool was developed by Ocean Informatics as a client-side tool and released as open-source since It is used to create and edit archetypes for openehr information concepts, guidelines and various types of entry such as observation, evaluation, action, instruction and administration (25). Software funded and developed by Cambio Healthcare Systems that allows users to create and edit clinical models, run rules and execute GDL files. It was used to create and edit the six necessary archetypes to be used in the three GDL guidelines for this study. It was used to integrate the archetypes and rules in three GDL guidelines to model the clinical 16

17 CDS Workbench Pencil project VUE XMind Software funded and developed by Cambio Healthcare Systems. It allows users to execute rules from the GDL guidelines using provided data in the form of.csv files, and outputs results in the form of logs and charts. An open-source prototyping tool that allows users to create mockups with common shapes, basic web elements and widgets for different desktop platforms such as Windows XP, Android and ios. The Visual Understanding Environment is an open source project from Tufts University, focused on creating tools for managing and integrating digital resources and provides a flexible visual environment for structuring, presenting, and sharing digital information (26). A mind mapping and brainstorming open source project software aimed to support clarified thinking, management of complex information, brainstorming and organizing work, sponsored by XMind Ltd (27). guidelines of the LS screening process. It was used to run mock data files with the created GDL guidelines, validate them and obtain statistics and results. Used to create the prototype for the user interface to be used by a clinician to screen patients. Used to create a graphical workflow of the Lynch Syndrome screening process based on the guidelines and how rules are followed. Used to create a mind map of the relationship between the clinical data, openehr archetypes and elements to plan for the design of GDL guidelines. Table 3 - Modeling, design and validation tools 2.5 Ethical considerations In order to validate the application and since the scope of this study did not require real patient data, mock patient data was used. Thus, patients confidentiality was not an issue to be considered. Furthermore, although the supervisor for this thesis is an employee from Cambio Healthcare Systems, this study had an academic perspective and there were no conflicts of interest. A non-disclosure agreement was signed at the company to ensure that the software tools provided by them were used responsibly and no information was disclosed regarding other current projects from the company. 17

18 3. Results 3.1 Requirements Analysis The Amsterdam Criteria II and the Revised Bethesda Guidelines were identified as the clinical guidelines currently used to screen patients and determine if they may be at risk of Lynch Syndrome (4,8). Each guideline was analyzed in terms of how clinicians collect data, the required type of data and how data was processed during the decision-making process. The guidelines were translated into questions for each criterion that clinicians go through to collect all the necessary information from a patient in the most optimal way. Amsterdam Criteria II consists of six criterions, while the Revised Bethesda Guidelines have five. Results from the analysis were organized in a table, mapping the categories of Data and Rules to each question to facilitate the design of the application. The column for Data referred to information that should be collected from the patient, including personal information and family history. These data could have as a source the EHR and be automatically extracted from it or manually obtained from a consultation with the patient. On the other hand, the Rules column referred to how the data affected the process followed during screening with both clinical guidelines, and it was used to translate these text-based rules into GDL rules during the design process. Table 4 presents the results from this analysis, with each column corresponding to the questions, data and rules, and each row corresponding to each criterion from both guidelines. Question Data Rule Amsterdam Criteria II 1. Three or more relatives with an HNPCC-associated cancer? - Number of relatives - Relative s diagnosis IF true THEN Question 2 ELSE Bethesda Guidelines 2. One is a first-degree relative of the other two? 3. At least two successive generations are affected? 4. At least one relative was diagnosed before age 50? 5. Excluding familial adenomatous polyposis? 6. Tumors verified by a pathological examination? - Degree of relationship IF true THEN Question 3 ELSE Bethesda Guidelines - Degree of relationship IF true THEN Question 4 ELSE Bethesda Guidelines - Relative s diagnosis - Relative s age IF true THEN Question 5 ELSE Bethesda Guidelines - Exclusion true or false IF true THEN Question 6 ELSE Bethesda Guidelines - Pathological verification present or absent IF true THEN Referral ELSE Bethesda Guidelines Revised Bethesda Guidelines 7. Colorectal cancer diagnosed in - Patient s diagnosis IF true THEN 18

19 the patient at age less than 50? - Patient s age Referral ELSE Question 8 8. Presence of synchronous, metachronous colorectal or other HNPCC-associated tumors? 9. One or more first degree relatives with an HNPCC-related tumors diagnosed under age 50? 10. Colorectal cancer with MSI-H histology diagnosed in a patient at age less than 60? 11. Two or more first or second degree relatives with HNPCCrelated tumors? - Patient s diagnosis IF true THEN Referral ELSE Question 9 - Degree of relationship - Relative s diagnosis - Relative s age - Patient s diagnosis - Patient s age Table 4 - Criterions, Data and Rules for LS screening - Degree of relationship - Number of relatives - Diagnosis for each relative IF true THEN Referral ELSE Question 10 IF true THEN Referral ELSE Question 11 IF true THEN Referral ELSE No referral The organization of data into a table allowed for a structured view of the type of data involved in each criterion. Moreover, color-coding the type of data facilitated the identification of repeated data used in different criterions from both guidelines, such as the degree of relationship from a relative present in questions 2, 3, 9 and 11 or number of relatives diagnosed with HNPCC-related cancer in questions 1 and 11. This indicated that some data could be input once and reused to check both guidelines. In addition, defining the rules with IF-THEN expressions demonstrated that when executing the Amsterdam Criteria II, not all rules would need to be run if at any moment one of criterions was not met. In this case, the algorithm could skip from the Amsterdam Criteria II to validating the Revised Bethesda Guidelines, which would result in an efficient execution of the system. This analysis concluded that both clinical guidelines could be integrated into one CDSS that would have as an input the different data required, process the appropriate rules and would output a message for referral if necessary. 3.2 Guideline design Process flowchart Once the required type of data that was identified, a process flowchart was designed to visualize the algorithm in which both guidelines interact together when a clinician determines if a patient should be referred to a specialist. This is represented in Figure 4. The first part illustrated in purple corresponds to the Amsterdam Criteria II and the second part in blue corresponds to the Revised Bethesda Guidelines. For the first part, there are six criterions that have to be met in order to provide a referral. If this is not met, then one out of five criterions have to be met from the second part of the flowchart. If the Amsterdam Criteria is met, the algorithm ends and does not have to check the Bethesda Guidelines, which saves time in the execution process. For the Revised Bethesda Guidelines, once one 19

20 of the criterions is met, the algorithm ends in providing a referral for testing; otherwise all criterions are verified until the algorithm ends with a result for no referral. Figure 4 - Algorithm flowchart for Lynch Syndrome screening Mapping of archetypes The next phase in the design of the application was the translation of clinical guidelines into GDL guidelines with the use of rules and openehr archetypes following the algorithm previously designed for the process. The GDL Editor v was the tool used for this development phase. The first step was the identification of openehr archetypes that included all the necessary data structures to build the guidelines. A search was performed in the openehr CKM 2, a repository of existing archetypes, using keywords related to the required type of data. Three archetypes that fulfilled the requirements were identified. In addition, three archetypes were defined to have a specific purpose for these guidelines and 2 OpenEHR Clinical Knowledge Manager is a library of clinical knowledge artifacts, currently openehr archetypes and templates. 20

21 were created specifically for this application. A detailed description for each archetype can be found in Appendix B - Archetype details. The openehr archetypes used to develop this application were: openehr-ehr-evaluation.family_history.v1 (existing) openehr-ehr-observation.basic_demographics.v1 (existing) openehr-ehr-action.referral (existing) openehr-ehr_evaluation.amsterdam_criteria.v1 (new) openehr-ehr-evaluation.bethesda_criteria.v1 (new) openehr-ehr-evaluation.lynch_syndrome_screening.v1 (new) Before creating the guidelines, a mapping of the archetypes related to Lynch syndrome and a detailed description of their elements was done in order to plan the structure of the guidelines. The mapping is shown in Figure 5. Each of the archetypes contained different elements that were classified as coded text, count or date/time, depending on the type of data they would refer to. It was determined that for elements containing coded text, they would provide data from a classification of the criteria as being absent or present. Elements such as age and number of relatives were classified as a count type and elements such as birth date and present time were classified as date/time type. Figure 5 Mapping of openehr archetypes and elements to Lynch Syndrome guidelines 3.3 Guideline development Archetype definitions Three different GDL guidelines were created to model the screening process. These were named Amsterdam Criteria, Bethesda Guidelines and Lynch Syndrome. There was also the possibility to create only one guideline that included the algorithm for both guidelines and the decision process. However, it was decided that having three separate guidelines would allow a better visualization of the process and modeling of how the process is followed in clinical settings. Thus, the Amsterdam Criteria and Bethesda GDL guidelines modeled each 21

22 of their criteria and were designed to work together and provide an end result of present or absent patient referral. The Lynch Syndrome GDL guideline obtained the results from the other two guidelines as an input value and determined the end result of referral for a patient. These guidelines were not intended for screening or referral process of other rare diseases. For each of the guidelines a description was provided regarding their purpose, use, misuse and references that validated it. Afterwards, the necessary archetypes and elements were defined. These archetypes were classified as belonging to an EHR or CDS source, depending if the data was collected from the EHR or determined by the CDS application. The definition of archetypes for the Amsterdam Criteria guideline is shown in Figure 6. The definition of archetypes for Bethesda Guidelines and Lynch Syndrome guidelines is included in Appendix C Guideline definitions and rules. Figure 6 - Definition of archetypes for Amsterdam Criteria The relationship of archetypes for the Amsterdam Criteria, Bethesda Guideline and Lynch Syndrome guidelines is shown on Figure 7. The archetypes used to input data into the guideline are named as EHR, and those used for decision-making and output of values are named as CDS. It is important to note that the Lynch Syndrome guideline does not require input data from the user, since the decision-making is made from the output results from the other two guidelines. The archetypes used for each guideline are listed below: Amsterdam Criteria openehr-ehr-evaluation.family_history.v1(ehr) openehr-ehr-evaluation.amsterdam _criteria.v1(ehr) openehr-ehr-evaluation.amsterdam_criteria.v1(cds) 22

23 openehr-ehr-evaluation.lynch_syndrome_screening.v1(cds) Bethesda Guidelines openehr-ehr-observation.basic_demographic.v1(ehr) openehr-ehr-evaluation.bethesda_criteria.v1(ehr) openehr-ehr-eval UATION.family_history.v1(EHR) openehr-ehr-evaluation.lynch_syndrome_screening.v1(cds) openehr-ehr-evaluation.bethesda_criteria.v1(cds) Lynch Syndrome openehr-ehr-evaluation.lynch_syndrome_screening.v1(cds) openehr-ehr-action.referral.v1(cds) Figure 7 - Guideline archetypes Creation of rules Once archetypes were defined, rules were created under the Rule list tab for each guideline according to the criteria from the clinical guidelines. A complete list of the rules and the content of each is included in Appendix D Guide details. Figures 10 and 11 show the list of rules defined for the Amsterdam Criteria and Bethesda Guidelines respectively. The rules were to be executed in the order they appear. Both guidelines started with a default rule that ensured that all values from CDS elements were set to absent or negative to avoid incorrect values being processed if any of the rules was not executed. Following the default value, 23

24 rules were defined according to each criterion on the guidelines. For the Amsterdam Criteria, the six rules following the default rule corresponded to each criterion that had to be defined as present. The last rule would check if all the conditions had been met, and if so, the Amsterdam Criteria would be set to a present value. For the Bethesda Guidelines, the five rules following the default rule matched a criterion that could be defined as present or absent. In the same way, the last rule would verify if any of the conditions had been met, and if so, the Bethesda Guidelines were set as a present value. The present value for either of the guidelines would trigger the Lynch Syndrome guideline, which would set the referral of a patient as positive. Figure 8 - Rules for Amsterdam Criteria Figure 9 - Rules for Bethesda Guidelines Different conditions were defined under each rule, requiring input values as data from the patient and providing an output value. These conditions related different elements from the archetypes in terms of variables for each rule. Figure 12 presents the content for the default 24

25 rule on Amsterdam Criteria, with the conditions of non-existing values for each CDS element and the action to set them to absent or negative values before running any other rules. The criteria rules contained specific expressions to verify if the criterion was met. Figure 13 shows the rule conditions from a criterion in Amsterdam Criteria, which evaluated if there were 3 or more relatives diagnosed with a Lynch-associated cancer. If this were true, this rule would set the CDS criteria to present. Each criterion rule worked this way to set the CDS values to present or absent depending on the input data. Figure 10 - Amsterdam Criteria Rule for default values Figure 11 - Rule for number of relatives with LS cancer greater than 3 Finally, once all the rules for the criteria had been set, it was necessary to create a final rule which would set the guideline with an output value Present or Absent, depending on the criteria that had been met. Figure 14 presents six different conditions, which checked if the CDS criterions for Amsterdam Criteria had been met. If all these conditions were true, then the element named as All criteria is met would be set to a present value and sent as an input for the Lynch Syndrome guideline to produce a referral for the patient. For the Bethesda 25

26 Guidelines rule in Figure 15, five conditions were checked under an OR statement to determine if any of the criterions had been met. If any of these conditions had been set to present, then a present value was sent as an input for the Lynch Syndrome guideline. Otherwise, an absent value was sent as input and the Lynch Syndrome guideline would determine the referral outcome. Figure 12 Amsterdam Criteria rule to set to Present value Figure 13 Bethesda Guideline rule to set to Present value 26

27 3.3.3 Preconditions The GDL Editor allows for guidelines to have preconditions, which ensure that a guideline will not be executed unless specific conditions are met. This feature was useful to develop this application, since the Amsterdam Criteria is required to always execute first. The Bethesda Guideline had as a precondition that the Amsterdam Criteria had been set to absent, which is shown in Figure 16. This meant that this guideline would only execute if the Amsterdam Criteria was not met and ensured that execution time was efficient and unnecessary rules would not run. If the Amsterdam Criteria were present, the Bethesda Guidelines would never be executed and referral for a patient would be set as a positive value in the Lynch Syndrome GDL guideline. Figure 14 - Bethesda Guidelines precondition rule Guideline execution The next stage in the development process was to execute the guidelines in the GDL Editor. This tool allows the user to input data, run the guideline and obtain the output values according to the rules to verify that the guidelines are working properly. Figure 17 shows the user interface in which all values for the Amsterdam Criteria GDL guideline were set to positive. When it was executed with these values, the output was a Present value for the guideline. Each of the three GDL guidelines was verified with different values to ensure that the rules were working as expected. Screenshots for the Bethesda Guideline and Lynch Syndrome guideline during execution are included in Appendix C - GDL Definitions, rules and execution. 27