Exploring clinical guidelines and the representation of their clinical statments using openEHR

SET | 2012 5th ed Exploring clinical guidelines and the representation of their clinical statements using openEHR Gustavo Marísio Bacelar da Silva 2 iii Ricardo João da Cruz Correia Faculty of Medicine, University of Porto Rong Chen Chief Medical Informatics Officer, Cambio Healthcare Systems 5th ed Exploring clinical guidelines and the representation of their clinical statements using openEHR Gustavo Marísio Bacelar da Silva SET | 2012 iv v Contents Contents .................................................................................................... v Acknowledgements .................................................................................. ix Abbreviations and Acronyms ................................................................... xi List of Figures ........................................................................................ xiii List of Tables ........................................................................................... xv Abstract ................................................................................................. xvii Resumo................................................................................................... xix Scientific Results .................................................................................... xxi 1. Introduction ..................................................................................... 1 2. Objectives ....................................................................................... 7 3. State of the art ................................................................................. 9 Clinical guidelines ................................................................................................. 9 JNC7 ........................................................................................................... 10 Agree II ...................................................................................................... 11 vi Semantic interoperability .................................................................................. 11 openEHR ..................................................................................................... 12 4. Study #1: Perceiving and illustrating clinical information relevance and its constraints for sharing .................................................. 17 Methods ............................................................................................................... 17 Results .................................................................................................................. 18 Discussion ........................................................................................................... 21 5. Study #2: Assessing the clarity of presentation and describing difficulties in understanding JNC 7 content ........................................... 23 Methods ............................................................................................................... 23 Results .................................................................................................................. 24 The recommendations are specific and unambiguous ....................... 24 The different options for management of the condition or health issue are clearly presented ............................................................................. 25 Key recommendations are easily identifiable ....................................... 27 Discussion ........................................................................................................... 28 6. Study #3: Developing an open EHR-based structure to describe JNC7 guideline recommendations ........................................................... 31 Methods and results ........................................................................................... 31 Discussion ........................................................................................................... 35 vii 7. Study #4: Developing open EHR content to be used at different moments in the Obstetrics scenario........................................................ 37 Methods ............................................................................................................... 37 Results .................................................................................................................. 38 Discussion ........................................................................................................... 41 8. Discussion .................................................................................... 43 9. Limitations ................................................................................... 45 10. Conclusions and recommendations ............................................. 47 11. Future work .................................................................................. 49 12. References ..................................................................................... 51 Appendix ................................................................................................. 57 viii ix Acknowledgements I would like to express my gratitude to all those who supported this work to my friends in Brazil, in Portugal and anywhere in the world, to my supervisor Ricardo Cruz-Correia, to my parents-in-law, Vírgina Menezes and Edílson Menezes, to my sister, Carolina Bacelar da Silva, my parents, Maria das Graças Bacelar da Silva and Ubirajara Paulo da Silva, to my wife, Daniele Bacelar, and to all those that supported somehow this two-years adventure across the ocean. Thank you all. xvi xvii Abstract The healthcare professional activities are highly dependent of information which may have many different sources and uses according to different moments of care. The clinical guidelines are an attempt to standardize the best clinical knowledge to support decision and practice, but they often have vague recommendations. In order to take advantage of the health information systems (HIS) to support decision it is important to use standards (e.g. openEHR) to structure and code data that healthcare professionals are used to describe using free text to avoid ambiguities. The primary objective of this work is to explore the clinical guidelines and the data needed to represent their clinical statements using an electronic structure in openEHR (i.e. templates and archetypes). The secondary objectives include (1) to perceive and illustrate what kind of clinical guidelines information is important, where to search for and the constraints of time for presenting according to the decision moments of a selected situation of medical care; (2) to describe the process and the issues related to developing openEHR content to be used during different moments in a particular ordinary scenario (labor), namely to retrieve patient's data; (3) to assess the clarity of presentation and describe the difficulties in understanding patient evaluation items of particular clinical guideline (high blood pressure control) and recommend better-suited descriptions for its contents; and (4) to develop an openEHR-based structure (a template) that is able to describe the data structure to represent the high blood control guideline recommendations and to unveil the issues related to this task. Four studies were done, two of them related to obstetrics guidelines and the other two related to the high blood pressure control guideline. An obstetrics scenario developed contributed to illustrate the differences of clinical guidelines xviii information needs according to two different moments of care, as well as where to search for this information and the time constraints to make it available for use. The high blood pressure control guideline was assessed regarding the clarity of its recommendations. Both clinical areas (high blood pressure control and obstetrics) had a formalized content in openEHR. The obstetrics area had two templates designed with archetypes to represent each one of the two moments of care. The high blood pressure had one templates designed with archetypes. Most of these archetypes were obtained from the international online repository of openEHR Foundation and from the Australian online repository (NEHTA). Four archetypes were created using tools available on the internet. After some practice and understanding of the information model, the development of the template and archetypes becomes a not so difficult task. The representation of clinical guidelines information data using openEHR archetypes is very comprehensive, even considering the context, this form of representation can contribute to the creation of better designed clinical guidelines in the future, as well as contribute to the development of HIS. xix Resumo As atividades dos profissionais de saúde são altamente dependentes de informação a qual pode ter diferentes fontes e usos de acordo com diferentes momentos do cuidado de saúde. As diretrizes clínicas são uma tentativa de padronizar o melhor conhecimento clínico para apoiar a decisão e prática diária, mas muitas vezes elas têm recomendações vagas. A fim de fazer bom uso dos sistemas de informação em saúde (SIS) para apoiar a decisão, é importante o uso de padrões (por exemplo, openEHR) para estruturar e codificar os dados que os profissionais de saúde estão habituados a descrever em forma de texto livre de modo a evitar ambiguidades. O objetivo principal deste trabalho é explorar as diretrizes clínicas e os dados necessários para representar os seus conceitos clínicos utilizando uma estrutura eletrónica em openEHR (ou seja, modelos e arquétipos). Os objetivos secundários incluem (1) a perceber e ilustrar que tipo de informação das diretrizes clínicas é importante, onde procurar e as limitações de tempo para a apresentação de acordo com os momentos de decisão de uma situação selecionada de assistência médica; (2) descrever o processo e as questões relacionadas ao desenvolvimento de conteúdos em openEHR para serem usados em diferentes momentos de um determinado cenário (trabalho de parto), mais especificamente para recolher os dados do paciente; (3) avaliar a clareza da apresentação e descrever as dificuldades na compreensão dos itens de avaliação do paciente de diretriz clínica em particular (controle da hipertensão arterial) e recomendar melhores descrições do seu conteúdo; e (4) desenvolver uma estrutura baseada em openEHR (um template) que seja capaz de descrever a xx estrutura de dados para representar as recomendações das diretrizes de controlo da hipertensão arterial e desvendar as questões relacionadas a esta tarefa. Foram elaborados quatro estudos, dois deles relacionados com as diretrizes de obstetrícia e os outros dois relacionados com a diretriz de controlo da hipertensão arterial. Um caso clínico de obstetrícia desenvolvido contribuiu para ilustrar as diferenças da necessidade de informação das diretrizes clínicas de acordo com dois diferentes momentos de atendimento, bem como onde procurar essa informação e as limitações de tempo para torná-la disponível para uso. A alta diretriz de controlo de hipertensão arterial foi avaliada quanto à clareza das suas recomendações. Ambas as áreas clínicas (hipertensão arterial e obstetrícia) tiveram uma formalização do seu conteúdo em openEHR. A área de obstetrícia teve dois templates concebidos com arquétipos para representar cada um dos dois momentos de cuidado de saúde. A hipertensão arterial teve um modelo criado com arquétipos. A maioria destes arquétipos foi obtida a partir dos repositórios online internacional da Fundação openEHR e do governo australiano (NEHTA). Quatro arquétipos não foram encontrados e portanto foram criados utilizando ferramentas disponíveis na internet. Após alguma prática e entendimento do modelo de informação, o desenvolvimento do template e dos arquétipos torna-se uma tarefa não muito complicada. A representação dos dados clínicos das diretrizes utilizando arquétipos openEHR mostrou-se muito abrangente, considerando inclusive o contexto. Esta forma de representação pode contribuir para a criação de diretrizes clínicas melhor projetadas no futuro, bem como contribuir para o desenvolvimento de SIS. xxi Scientific Results These are the achievements during the development time of the present work: Articles published G.M. Bacelar-Silva, P. Vieira-Marques, and R. Cruz-Correia, "Identifying Relevant Data Along Selected Medical Care Situation", CISTI, 2011, pp.350353. G.M. Bacelar-Silva, R. Chen, and R. Cruz-Correia, "Transforming a High Blood Pressure Clinical Guideline into a CDSS - Difficulties in Understanding", Proc. HEALTHINF, 2012, pp.405-408. Articles submitted and approved G.M. Bacelar-Silva, R. Chen, and R. Cruz-Correia, "From Clinical Guideline to openEHR: Converting JNC7 into Archetypes and Template", CBIS, 2012. Articles submitted and waiting for approval G.M. Bacelar-Silva, and R. Cruz-Correia, "Creating openEHR Content to Different Moments of Care – Obstetrics Emergency Scenario", Proc. HEALTHINF, 2013. Other contributions during the last two years not directly associated with this research G.M. Bacelar-Silva and P.P. Rodrigues, "Applying TOC Buffer Management in Health Information Systems to Improve Hospital Performance", Proc. HEALTHINF, 2012, pp.345-349. xxii C. Travassos, I.C. Moreira, P. Ferreira, and G.M. Bacelar-Silva, "Security and Privacy in European EHRs - Should Portugal Follow Denmark and Sweden's Examples?", Proc. HEALTHINF, 2012, pp.354-357. I.C. Moreira, G.M. Bacelar-Silva, and P.P. Rodrigues, "Compliance of Publicly Available Mammographic Databases with Established Case Selection and Annotation Requirements", Proc. HEALTHINF, 2012, pp.337-340. Furthermore, in June 2012 I could participate as a speaker of the 1 st openEHR Course in the Faculty of Medicine of University of Porto. Four new archetypes were created and one of them was already accepted to be included in the CKM. Introduction 1 1. Introduction The healthcare professional activities are highly dependent of information. This information may have many different sources and uses according to different moments of care. At a first contact (initial moment) it can be represented as patients’ complaints, physical examinations, previous lab analysis results. At an intermediate moment it is consisted as the necessary information to evaluate the earlier obtained information, which now is associated with personal experience and knowledge acquired from published scientific evidence-based (e.g. clinical guidelines). The result of the healthcare professional activity, at the last moment, is also many times represented as information (which may trigger an action), for instance as a diagnosis, a treatment plan, a goal and a prognosis. Therefore, the quality of healthcare delivery is closely related to the quality of information available to the healthcare professional at the moment of care (Nygren et al., 1998; T. Beale and S. Heard, 2007a; Gschwandtner et al., 2011). The increasing adoption of health information systems (HIS), e.g. electronic health records (EHR) and clinical decision support systems (CDSS), replacing the paper records is expected to bring new features provided by information and communication technology (ICT) and improve the healthcare delivery (Tang et al., 2006; Vaitheeswaran, 2010). Nevertheless, most of these features depend on structuring and coding data that healthcare professionals are used to describe using free text (Powsner et al., 1998). Due to the large variety of clinical concepts different in their nature, ranging from biomolecular level to psychological level, the inherent complexity goes even further to develop a systematic structure and code to describe in detail the attributes of each one of 2 Introduction them. It is a difficult task to represent such complex concepts into data making them human-readable and understandable, as well as electronically computable, i.e. capable of being used and processed in different systems (Wright et al., 1998; Chute, 2005). Attempts to classify and organize the medical knowledge are not new, one of the oldest dates from ancient Greece with Aristotle´s classification of animals biology and the conceptual unity (Pellegrin and Preus, 1986). Nowadays the Systematized Nomenclature of Medicine (SNOMED) and the International Classification of Diseases (ICD) are consistent examples of classifications to code clinical data. However, classifications, terminologies and vocabularies lack logical descriptions necessary to consistently define clinical concepts. These logical descriptions are described by Ogden and Richards’ work on context language and concepts, as well as by Church’s work on mathematical logic, as an element of a “semantic triangle” (Figure 1), which includes the reference object itself and an associated symbol (e.g. a name or a classification). The referred element of the triangle is the set of assumptions or rules to determine the specific conditions of classification (Ogden and Richards, 1923; Church, 1956). Although SNOMED terms were adapted to be connected using description logics, their rules are imprecise. For instance, it is Figure 1. Semantic triangle, adapted from Ogden and Richards (1923). 3 possible to correctly describe “viral conjunctivitis” in many ways, as illustrated in Figure 2. It is necessary to use an ontology (a descriptive organization of a domain concept) to specify the clinical information. The Clinical Investigator Record Ontology was created for this purpose and serves as the basis for the Entry classes in the openEHR reference model, which has already proved to be semantically robust to describe clinical concepts and be applied in HIS, such as EHR (T. Beale and S. Heard, 2007a; Chen et al., 2009). Furthermore, a scientific approach to standardize clinical decision and practice using the best available evidence was needed in order to improve the quality of healthcare processes and outcomes, so emerged the evidence-based medicine. It includes many different approaches, such as randomized clinical trials and statistical meta-analysis. A common implementation of evidencebased medicine is the development of clinical guidelines (Garber, 2005; Timmermans and Mauck, 2005). These are expected to gather the best current scientific evidence available to support the medical decision and practice. Nevertheless, there are at least two obstacles to improve the physician adherence to clinical guidelines: (1) the awareness of the relevance of the clinical guideline contents and (2) its contents availability for the healthcare professional at the moment of care. In order to overcome these two obstacles, there is a consensus that clinical guidelines should be deployed through clinical information systems (Sonnenberg and Hagerty, 2006; Latoszek-Berendsen et al., 2010). Despite this, a major problem to implementation is the difficulty to 1. Viral conjunctivitis (disorder) – 45261009 2. Viral eye infection (disorder) – 312132001 Conjunctival structure (body structure) – 29445007 Inflammation (morphologic abnormality) – 23583003 3. Eye infection (disorder) – 128351009 Inflammation (morphologic abnormality) – 23583003 Conjunctival structure (body structure) – 29445007 Virus (organism) – 49872002 4. Infective conjunctivitis (disorder) – 299699004 Virus (organism) – 49872002 Figure 2. Possible ways to describe correctly “viral conjunctivitis” using SNOMED. 10 State of the art outcome-based performance measures, which are adapted from clinical guidelines recommendations. Problems do exist; clinical guidelines are developed considering the provision of the best evidence-based knowledge to support clinical decision and care, not to be a framework for rewarding clinical performance. In addition, they are not an ideal platform for performance incentives since even the well-accepted guidelines include many vague recommendations. But the solution to this problem is expected to come with the increasing adoption and evolvement of HIS, decreasing the costs and improving the translation of guidelines recommendations into performance measures (Garber, 2005). JNC7 The Seventh Report of the Joint National Committee on the Prevention, Detection, Evaluation, and Treatment of High Blood Pressure (JNC 7) was published in 2003 and since then has been serving as an important reference to the management of high blood pressure worldwide. The JNC 7 updated and introduced new concepts to hypertension guidelines. The blood pressure classification (i.e. normal, prehypertension and hypertension) was simpler than previous versions and each category should lead to different approaches to hypertension management. It also brought new epidemiologic data concerning the risk of the blood pressure levels, treatment and control rates and how to apply the guideline concepts to public health and in medical care practices (Chobanian et al., 2003). Transforming the JNC 7 to an electronically readable format could bring many benefits to health providers. It could improve the development of EHR and CDSS being a framework to a more efficient clinical approach to prevent and manage hypertension, a cardiac chronic condition that affected nearly one billion people worldwide in 2000 and is expected to affect 1.56 billion by 2025 (Kearney et al., 2005). The physician compliance to the JNC guidelines recommendations is not very clear; some studies suggested a high compliance to recommended therapy (72-80%) meanwhile they suggest that the intensity of care should be increased (Milchak et al., 2004; Ardery et al., 2007). Another common point of these studies is the necessity of an accurate State of the art 11 documentation in medical recording that reflects the practice. The variation found on clinical documentation can reflect different concepts of documentation adequacy according to local settings and in turn lead to variation on the overall results. Agree II The Appraisal of Guidelines for Research & Evaluation II (AGREE II) is an instrument that was developed by an independent body established in 2004 to address the issue of variability in guideline quality. Its purpose is to provide a generic framework to (1) assess the quality, (2) serve as a methodological strategy for the development of guidelines and (3) inform what information and how information ought to be reported in guidelines. The instrument is composed of 23-item organized into six domains. Among other definitions of what is desirable to a guideline, the AGREE II highlights the clarity of presentation, which involves the assessment of specificity, unambiguity, clearly presentation of different options for management and easiness to identify key recommendations (The AGREE Next Steps Consortium, 2009). Semantic interoperability In a scenario involving the delivery of healthcare services, where information is often highly distributed across multiple settings (e.g. healthcare institutions, clinical guidelines), fast access to critical information can be crucial sometimes (e.g. an episode of allergy while travelling). In order to take full advantage of EHR and CDSS it is of utmost importance to support the standardized health information exchange and interoperability (HIEI). However, due to the great variety of HIS available, with each one using their own proprietary information model, sharing health information becomes a hard task (Hillestad et al., 2005; Vaitheeswaran, 2010). To support the data sharing between different systems, HIS should be created using a common and agreed structure of data. Widely adopted, this measure would support not only the data 12 State of the art sharing between organizations but also would allow different systems to compute shared data, therefore achieving the semantic interoperability. Walker et al (2005) created a functional taxonomy to classify interoperability into four levels according to the amount of human involvement, complexity level of information technology (IT) and the level of standardization. The level 1 refers to sharing information with no electronic data, e.g. traditional mail. The ultimate one, level 4, is an ideal state where all systems exchange information using structured messages which contains standardized (same formats) and coded data (same vocabularies). In addition, Veltman (2001) defined semantic interoperability as “the ability of information systems to exchange information on the basis of shared, preestablished and negotiated meanings of terms and expressions”. open EHR openEHR is a non-proprietary standard for EHR architecture that allows capturing the clinical knowledge in a structured way, independently of the software, enabling semantic interoperability of HIS. This means avoiding vendor lock-in of data and supporting distributed clinical workflow. openEHR is already translated to multiple languages and, therefore, has been used in many countries (e.g. England, Australia, Sweden and Brazil). But its use is not only restricted to enable EHR interoperability, it also has been associated with development of computerized guideline using archetypes (structured clinical knowledge concepts) and templates (combination of archetypes related to a particular clinical task), for instance, to represent a chemotherapy guideline data with associated rules, which eases integration with EHR (Leslie, 2007; Chen et al., 2009). The traditional way to design and build EHR software is based on the single-level modeling. In this model, the clinical concepts are represented within the database and code. Although it may seem to be quicker at a first moment, it is much harder to be kept up-to-date. The nature of healthcare knowledge is very dynamic, every day new clinical concepts are added and State of the art 13 older ones change, get improved or obsolete. It is impossible to follow this rhythm to update EHR using the traditional single-level modeling because any updating means changing the structures of the code and database. Furthermore, it is usually the programmers that are responsible to create the definitions of medical concepts. openEHR uses a completely new and different approach that is known as two-level modeling. This approach separates the clinical knowledge from the information model. The former comprises the archetypes representing the clinical knowledge, which are mostly created by clinicians. The latter is the reference model (RM), which is mostly in charge of the informaticians and describes all the structure and rules related to data storage and retrieval. This two-level modeling allows the separation of tasks, with clinicians defining the clinical content and also easily updating the medical concepts without requiring any modification of the software, meanwhile the informaticians deal with the software database and code (Leslie and Heard, 2006; T. Beale and S. Heard, 2007b). The archetypes are the core elements of openEHR architecture. Each Figure 3. Example of a discharge report and the use of different archetypes and its elements to compose the document. 14 State of the art archetype represents a complete data set of a clinical concept (e.g. blood pressure) including relevant information to interpret the data, such as the context (State) and the method used to obtain (Protocol). They are used to store data and to further retrieve them keeping the same meaning regardless the EHR system or language used. The archetypes can be developed in any language and be later translated to other languages (e.g. Portuguese, English, Chinese, Swedish) keeping their original meaning. In addition, terminologies can be associated within archetypes elements supporting their definition. There are three classes of archetypes (see Figure 3):  Compositions: They represent clinical documents. A composition can be related not only to separated healthcare events (e.g. encounters, laboratory tests, interventions), but to information that have long-lived significance (e.g. problem list, vaccination history), as well.  Organizational archetypes: Composed by Section elements, which can be used as document headings to organize and group the data entries within a Composition or within another section according to local clinical criteria.  Entries: These elements are the most important of openEHR in terms of actual content, as long as they define the semantics of all recorded data. They are initially divided in two categories: Administrative Entry and Care Entries (see Figure 4). The former encompasses the information not generated by the care process, but related to its organization and the logistics of care to be delivered (e.g. appointments). The latter includes the elements related to the clinical statements that might be recorded at any point of a care process; its subcategories are Observation, Evaluation, Instruction and Action (Leslie and Heard, 2006; Leslie, 2007; T. Beale and S. Heard, 2007b). State of the art 15 A template is an aggregation of archetypes used to define the content of a particular document or a message. They can be used to build forms content representing the layout of an EHR and to be associated with terminologies. Although a template is built using archetypes, it is not mandatory to use all their elements. It is possible to adjust, remove unneeded elements and combine archetypes according to what is desired to fulfill specific local needs and use cases (Leslie, 2007; Beale, 2012). For instance, a blood pressure archetype includes as many as possible elements to represent this clinical concept (Figure 5), but rarely all the elements are used in a single form. Thus, it is possible to use only the relevant elements to a specific scenario (e.g. Figure 4. Clinical infomation ontology representation, the Entry archetypes are bold (adapted from T. Beale and S. Heard, 2007a). Figure 5. Blood pressure archetype with its elements. 16 State of the art systolic, diastolic) and define as a Zero Occurrence to the other possibly unnecessary elements (e.g. pulse pressure, sleep status). Since openEHR two-leveling approach has the archetypes and their re-use as the core elements that define its common and shareable clinical content description, the indiscriminate local development of archetypes followed by their use may compromise the semantic interoperability. In order to avoid creating new archetypes, the existing ones must be easily found, so they must be kept in a centralized and easily locatable repository. This fosters the re-use of the archetypes and prevents creating different and incompatible archetypes to represent the same concept. Other advantages of being in a centralized repository is to integrate all efforts to improve its variety, including new archetypes, and the complexity of the existing ones also keeping them semantically interoperable (Garde et al., 2007). This international and online repository is the openEHR Clinical Knowledge Management (CKM). The openEHR CKM regulates the archetypes development, acceptance and availability, under the coordination of a group of experts (mostly clinicians and informaticians). Its contributors are from over 50 different countries from different areas (clinicians, informaticians, software engineers, terminologists, administrators and consumers) participating on a voluntary basis as an active community. Although exists an international CKM, it is possible to set up national instances of CKM (e.g. National E-Health Transition Authority (NEHTA), from Australia) to fulfill their local requirements, but this national CKM has to be federated with the international openEHR CKM (Leslie, 2007, 2010). Study #1 17 4. Study #1: Perceiving and illustrating clinical information relevance and its constraints for sharing Methods Initially, in order to choose a relevant medical condition to be studied, it was identified the most frequent admission reasons of a large University Hospital (Hospital São João – Porto, Portugal). The list generated by the Diagnosis Related Groups (DRG) statistical analysis software named ARCHI [6], pointed out pregnancy and labor as the top reasons, corresponding to 10.7% of the total admission reasons in 2009. Due to the relevancy of the numbers (the second main reason was pneumonia, with 1.82%) it was decided to focus on the pregnancy and labor. Based on the defined theme, it was made a storyboard to serve as a keystone: A 29 years old female patient, from Vila Nova de Gaia, 38 weeks pregnant, was admitted in the Hospital São João Emergency Department (ED) due to abdominal pain and forgot her pregnancy book at home. Prenatal care was done in a health center, a private practice and lab analysis in two different institutions. 18 Study #1 A list of relevant clinical and diagnostic information to be potentially used during an attending episode at the hospital was done initially based on established guidelines (Akkerman et al., 2010; Creedon et al., 2011). At last, a set of interviews was conducted with three specialists to define and validate the patient process flow, considering the various stages and their optimistic mean durations (according to the specialist experience). It was also asked the specialist to analyze the list of relevant clinical and diagnostic information, allowing him/her to suggest inclusions or exclusions, and to determine the priority relevancy of the information according to its potential period of use along the use case patient attending flow. So it would be possible to determine the priority order of the patient’s information to be electronically collected at other healthcare facilities (e.g. hospitals, labs, health centers), the necessary time to accomplish the task and in a manner to do it without consuming the ICT resources. Results The interviews with gynecology and obstetrics specialists included Portuguese and Brazilian medical doctors (2:1). These interviews allowed developing and consolidating a process flow detailing the various events, as well as an optimistic estimated mean time (expressed in minutes inside each bar of Figure 6) of the patient along a medical attending at a Hospital ED based on the use-case, as illustrated at the top bar of Figure 6. The estimated mean time was an optimistic one because should better represent a constrained limit to search and collect the healthcare data. An important point to clarify the understanding of the patient care flow bar is the workup. It is the known by the healthcare professionals as the period when many necessary actions related to diagnosis and treatment are performed. During the workup is when necessary medications are administrated and blood collected to analysis, for example. At this time, there is also the participation of other important health professionals (e.g. nurses, technicians). Study #1 19 The chart below the patient care flow bar illustrates an example of automated data collection divided into 2 groups according to the priorities. The Priority I Data is the most required information for the early stage of healthcare attending. The Priority II Data is also considered important, but it includes information that can wait to be used by the healthcare professional at a later stage. The color indicates the avaibility of the data, red bars indicate unavailable data and green bars mean available data. The set of interviews also made possible to identify the relevant patient health information considering the selected use case situation and to create a list of possible sources in which to search for. Table 1 describes the groups of priority data and the main source of information. In order to better illustrate the probability of each source, three symbols were used to sign it. So, (-) was used when it was not probable to find the information, (+) signs a probable chance, and (✪) as a source with great probability to hold the information. Figure 6. Patient and Information Flow: On the top is the patient flow bar, which describes the various events along a typical attending. Inside each bar is the duration (minutes) of the referred event. The other bars describe the process of collecting and making data available before a possible use (minutes are inside each bar). 26 Study #2 Figure 7. Structured representation of JNC7 guideline including patient evaluation model. The bullets indicate the clinical statements. Study #2 27  Although the identification of concomitant disorders that may affect prognosis and guide treatment is mentioned in the Patient Evaluation chapter, the list which describes them is presented only four chapters later (“Special Situations in Hypertension Management”). At least the existence of the list should be mentioned in the “Patient Evaluation” chapter referencing the content to follow.  Lifestyle assessment is recommended, but the items are not grouped. However, lifestyle modifications are grouped as a table in the treatment chapter, including items not mentioned within the patient evaluation items (e.g. alcohol consumption). The lifestyle evaluation items should be described within medical history.  The guideline recommendations are conducted through two paths, the Objectives-oriented (evidence-based thinking) and the Semiologyoriented (traditional medical thinking) paths. The problem is that these paths are rarely correlated, for instance describing the objective of examining the lungs. The establishment of a connection between these two paths would improve the comprehension of the guideline as a whole.  Electrocardiography is presented as a routine laboratory test, but it is not a laboratory test, it is a diagnostic tool (Meek and Morris, 2002). A new name, such as “Routine diagnostic procedures” would be more appropriated.  “Other diagnostic procedures” are not clearly grouped. They are cited and are initially described in the “Patient Evaluation” chapter but continue and end in the next chapter (“Identifiable Causes of Hypertension”). They are also referred as “additional diagnostic procedures”. They should have been cited before as a unique term and completely described in the chapter. Key recommendations are easily identifiable  Recommendations for patient follow-up based on initial blood pressure measurements are presented in the chapter named Calibration, 28 Study #2 Maintenance, and Use of Blood Pressure Devices. It would be better to present the recommended approach after the patient has been classified.  Quick reference card contains the sections “Diagnostic Workup of Hypertension”, “Assess risk factors and comorbidities” and “Reveal identifiable causes of hypertension” in a manner that they seem to be different aspects to evaluate, but actually the last two sections are items of the first one. “Assess risk factors and comorbidities” and “Reveal identifiable causes of hypertension” sections should be presented in a different manner to demonstrate they are within “Diagnostic Workup of Hypertension”. Discussion As already mentioned, the JNC 7 guideline is a very important document, which has been serving as a reference to over 10,500 articles worldwide since 2003. But despite the efforts of the medical informatics community, this document, as many others, has several issues that make it difficult to BE understood and converted it into an EHR structure or CDSS. Five years before the release of the JNC 7, Douglas K. (Owens, 1998) (1998) published a paper about the implementation of guidelines into the clinical practice. The potential of clinical guidelines to improve quality of healthcare and the increased benefit of their integration to an EHR and CDSS were reported and are well known today. But (Owens, 1998) also described two main reasons why guidelines were rarely used: (1) the lack of computing infrastructure to support computer-based guidelines; and (2) the substantial technical challenges related to the guideline development, namely the medical vocabularies insufficiently standardized and guidelines produced without precise enough recommendations. Nowadays, the lack of computing infrastructure may not be still a problem thanks to the evolving technology solutions, for example, wider access and use of Internet and mobile devices Study #2 29 allow an easier resolution. Nevertheless, the second reason (the substantial technical challenges) is not so easy. Some initiatives have been made, as the Guideline Elements Models (GEM) and development of guideline model representations. However, GEM has some limitations, such as its little potential to resolve the ambiguities that are easily found in many guidelines (Shiffman et al., 2000). This attempt to formalize the JNC 7 guideline allowed discovering many ambiguities, concepts related to prior knowledge and issues related to the distribution of the content presentation. Since the date JNC 7 was published many efforts were made in order to put together the paper and electronically computable version of guidelines. The guideline developers should consider, during its developing time, to use the medical informatics tools so to develop both versions made (paper and electronically computable versions). This would also improve the quality and comprehension of the guidelines statements and meet the needs of healthcare stakeholders to build a more affordable and reliable practice. 30 Study #2 Study #3 31 6. Study #3: Developing an open EHR-based structure to describe JNC7 guideline recommendations Methods and results This work consisted in (1) identify the clinical statements within its recommendations, (2) develop a structured representation of these statements, (3) search for existing archetypes in the openEHR Clinical Knowledge Manager (CKM) (openEHR Clinical Knowledge Manager, n.d.) and National E-Health Transition Authority (NEHTA) CKM (NEHTA Clinical Knowledge Manager, n.d.) to represent the clinical statements, (4) develop new archetype if there is no archetype representing a clinical statement, (5) create the template. For the purpose of easing the reading, this study presents the methods of each task described in detail followed by its results as well. Clinical statements – A clinical statement is defined as the minimal indivisible unit of information to be recorded by clinicians. openEHR maps the clinical statements using specific types of Entries (Administrative, Observation, Evaluation, Instruction, and Action) according to the nature of the statement (Beale et al., 2008). So the first task of this work was to identify the clinical statements within the guideline recommendations and list them. 32 Study #3 After several readings of JNC7 it was possible to identify a total of 70 clinical statements. The nature of these clinical statements goes from diagnosis (e.g. diabetes) to imaging analysis (e.g. Doppler flow study), including physical examination (e.g. optic fundi), prescription (e.g. pharmacologic treatment) and lab tests (e.g. triglycerides). Structured representation – After reading the guideline and listing its clinical statements, these were represented in a structured manner. This task considered the organizing criteria (e.g. workflow, objectives) used by the authors of the guideline and was expected to allow an easier visualization of the items as well as their use along the moment of care. Figure 7 illustrates the structured representation of the guideline. The items preceded by a bullet, inside the whiter boxes of Figure 7, are the clinical statements. They were firstly organized according to the patient evaluation and treatment. The former includes recommendations involving two different, but related paths, the Objectives-oriented path and the Semiology-oriented path. They are related because the Objectives-oriented path represents what the physician wants to know or assess while the Semiology-oriented path includes the elements to measure it. The patient treatment includes only three clinical statements (lifestyle modifications, pharmacologic treatment and adverse reaction). Obtain existing archetypes – Once the clinical statements were defined, they were submitted to a "Complete search", which searches "inside" resources, including all metadata, and for archetypes, archetype definition, and the archetype ontologies. The search was conducted on two clinical knowledge management (CKM) repositories – openEHR and National E-Health Transition Authority (NEHTA) – for the archetypes to represent the clinical concepts. The last search made was on June 1st, 2012. The archetypes found on each CKM were individually compared for each clinical concept according to the JNC7 requirements. When the archetypes had differences, the better-suited one was chosen. If both CKMs had archetypes considered able to represent a JNC7 clinical statement, then it was considered from openEHR CKM for being the Study #3 33 main international repository. If there is still no existence or adequacy of an archetype a new one will be created, as explained below. The final group of chosen and created archetypes was used to design the templates. Searching both CKMs (openEHR and NEHTA) for all 70 clinical statements resulted in obtaining 33 archetypes (30 from openEHR CKM, 3 from NEHTA CKM) to be used. Most of them could be represented by an archetype (or more) – 66 clinical statements, which mean 94%. Four clinical statements had no archetype to represent them, which means 6% of the JNC7 clinical statements. If someone decided to represent the clinical statements using only openEHR CKM it would be able to cover 65 clinical statements (93%). To accomplish the same task using only NEHTA CKM it would be able to cover 36 clinical statements (51%). Only 13% of the clinical statements needed more than 1 archetype to represent them. Development of new archetypes – If after searching on the referred repositories and no available archetype could not be found to represent a clinical statement, the creation of a new archetype will be considered. The development of new archetypes were made considering the information within the JNC7, respecting the recommendations of the openEHR Information Model document (Beale et al., 2008) and using the Ocean Archetype Editor, a tool to support the authoring of archetypes (available for free download on the Ocean Informatics website). The four clinical statements were:  Neurological assessment. Although the guideline did not mentioned any reference to what is supposed to assess, the conducted search on the Internet for a recommended neurological assessment for hypertensive patients allowed to find the National Institutes of Health Stroke Scale (NIHSS). This is a 15-item neurologic examination stroke scale used to evaluate acuity of stroke patients, determine appropriate treatment, and predict patient outcome. The NIHSS was originally designed as a research tool to measure baseline data on patients in acute stroke clinical trials. Now, the scale is also widely used as a clinical assessment tool to evaluate acuity of stroke patients, determine appropriate treatment, and 34 Study #3 predict patient outcome (National Institute of Neurological Disorders and Stroke, 2003). This clinical statement archetype was done and submitted for approval to be included in openEHR CKM.  Estimated Glomerular filtration rate. The JNC7 mentioned a website as a reference, so it was easier to develop this archetype. The referred website was a starting point and after searching for new practices (Stevens et al., 2006) it was possible to develop the archetype with an updated content. This clinical statement archetype was done and submitted for approval to be included in openEHR CKM.  Sleep study with O 2 saturation. This was the most difficult archetype to be developed. It was not an easy task to find a description of what a report is supposed to record. So it was necessary to ask a neurophysiology technician to collaborate with its development providing some information and scientific references (Redline et al., 2007; Silber et al., 2007). This clinical statement archetype was done and will be submitted for approval to be included in openEHR CKM.  Life style modification advises. The content of this archetype was extracted directly from recommendations of JNC7 and adjusted considering some prior practical clinical knowledge of the authors – Done and currently under analysis to be included in openEHR CKM. This clinical statement archetype was done and submitted for approval to be included in openEHR CKM. Creation of the template – Since the structured representation of the clinical guideline and the archetypes are available, it will be possible to create the template. The structured representation will help to create the framework of the template, where the archetypes will be arranged. The development of the template will be made on the Ocean Template Designer – software that allows composing a set of archetypes into a template – which is also available for free download on the Ocean Informatics website. Study #3 35 Following the order of the listed topics, the obtained and the created archetypes were added within a new Composition archetype created to represent the clinical guideline document (COMPOSITION.jnc7_clinical_guideline.v1). Discussion CDSS can allow healthcare professionals to access required data for medical decision-making. Studies have shown that it allows reducing medical error, lowering medical costs (e.g. avoiding unnecessary tests) and improving the quality of care (Garg, 2005). The present study suggests designing templates to describe the information needs and data structure. Their further deployment includes serving as a structure to support clinical recommendations and to associate with decision rules to be presented to healthcare professionals at the moment of care. As the templates were designed using specifications of an open standard and can be exported as many different formats, e.g. Extensible Markup Language (XML), they can be used to support the operational methods of interaction between systems. The developed template was meant to support the data structure needs to describe the JNC7 recommendations. This allowed identifying many of the clinical knowledge not included within the clinical guideline document, but which is necessary to be aware of. Also the fact of being made following open standard specifications can bring other further benefits. Governmental institutions, medical associations or other groups that produce clinical knowledge (e.g. clinical guidelines) could develop a template to represent the concepts within the clinical knowledge and recommendations. This method seems to be a reasonable way to describe the clinical statements and recommendations, creating an electronic document of a clinical guideline would objectively represent the information structure and its needs. It can be used as a reference to development of EHR, clinical decision support systems (CDSS) and health information exchange (HIE) applications, thus contributing to 42 Study #4 which can be used as a reference to development of EHR, clinical decision support systems (CDSS) and HIEI applications, thus contributing to decrease the heterogeneity of similar applications and contributing toward semantic interoperability (Owens, 1998). Once again the existence of more than one CKM was a controversial point. Although it was possible to represent almost all clinical concepts of this study using the archetypes from either CKM, many of these archetypes have different content and no name distinction, for instance openEHR-EHROBSERVATION.menstrual_cycle.v1. This archetype has similar contents, but the one from openEHR CKM includes a detailed list of contraception methods. Another archetype (openEHR-EHROBSERVATION.body_weight.v1) also has differences according to the CKM, the one from NEHTA seemed to be more adequate, probably due to modifications along the review process. The governance coordination between CKMs can be a challenging, but of utmost importance task. Discussion 43 8. Discussion This work explored some clinical guidelines (obstetrics and hypertension) and the data needed to represent their clinical statements using an electronic structure in openEHR (i.e. templates and archetypes). The tools used to develop the templates and archetypes, i.e. Archetype Editor, Template Designer and the content of both CKMs made possible to represent the data structure of the guidelines clinical concepts in detail, e.g. including the protocol of a blood pressure measurement. Many of the details covered by the archetypes were not mentioned or mentioned vaguely (e.g. a thorough examination of the heart and lungs) on the guideline recommendation, as demonstrated with Study#2. In addition, it was possible to illustrate with an example of different information needs to provide appropriate clinical information at different moments of care. The presented results can be helpful considering an automated search of healthcare data of a patient. Mainly when considering an ED attending, as the situation demonstrated in this study, where the considerably little time is a constraint to make the information available to clinical use. During the process of assessing the JNC 7 recommendations under the framework of AGREE II Instrument it was possible to find many ambiguities, concepts related to prior knowledge and issues related to the organization of the content. As the representation of these data using openEHR archetypes is very comprehensive, even considering the context, this form of representation can contribute to the creation of better designed clinical guidelines in the future, also being able to easily share and update data. 44 Conclusions and recommendations Most of the necessary archetypes to represent the data structure of the clinical guidelines were available online, however it would be of great value a better integration of the Australian CKM (NEHTA) to the international (openEHR) CKM. The archetypes that were created had the search of document with a clear description of the clinical concept as the most difficult task of the process. After that, with some practice using the applications any computerfriendly physician with some discernment regarding the openEHR information model can collaborate with the archetypes development and improvement. In the end, three templates were created using the archetypes. Two of them described the data needed during the obstetrics scenario, the other one described the data needs of JNC 7. A wide adoption of openEHR information model representing the clinical guidelines would bring benefits regarding the variability of documentation. The EHR could be more easily built considering the evidence-based data. CDSS would have a well-known and robust structure to be completed with an additional level containing the rules; such separation would ease the process of updating the software, the data structure or the rules independently of each other. These two systems (EHR and CDSS) would be able to communicate sharing the same information model. This work proposal of using openEHR archetypes and templates to represent a guideline structure was also proposed by Marcos and Martínez-Salvador (2011) using a chronic heart failure guideline but did not considered different needs according to the moments of care. Their results were very similar to the two studies regarding the representation of clinical guidelines using archetypes. They used 15 archetypes from openEHR CKM and considered most of them able to fulfill the data needs with 5 would require specialization. Limitations 45 9. Limitations Due to the exploratory nature of this study it was not possible to go further in some questions. The time constraints did not allow assessing the obstetrics guidelines using the AGREE II Instrument as well as perform a better understanding of the different moments of care and information needs regarding the JNC 7. During the process of selection of the archetypes to represent JNC 7 clinical concepts it was not explained the reasons for using a specific archetype when there was availability in both CKM, as it was done during the following study (with obstetrics guidelines). The templates developed were only tested with a tool that automatically generates EHR forms, task accomplished with success. Although only one storyboard was considered to illustrate the different in different moments of care, it is expected to contribute to the development of future works to support a higher adaptability degree of the information needs in a dynamic environment. 46 Limitations Conclusions and recommendations 47 10. Conclusions and recommendations These four studies presented made possible to explore the clinical guidelines recommendations in an emergency situation (labor) and in a non-critical situation (high blood pressure control) illustrating the data structure needed to describe the recommendations of associated guidelines using an open standard electronic structure. During the last decade many efforts were made in order to put together paper and machine-readable versions of guidelines, but the simple adoption of HIT will not improve the healthcare delivery by itself if it is not associated with the easy access to clinical information of good quality. This attempt to formalize some clinical guidelines allowed discovering many ambiguities, concepts related to prior knowledge and issues related to the distribution of the content presentation. Furthermore it illustrates the different information needs during different moments of care in an Obstetrics scenario. With this work was possible to create openEHR archetypes and templates that describe the information needs of different clinical guidelines and also demonstrate different procedures used to create archetypes. This seems to be a reasonable way to represent clinical content and recommendations and can have a variety of applications (e.g. support CDSS). This method could be adopted by groups that produce clinical knowledge so they could objectively represent the clinical information contributing to decrease the difficulties in understanding and converting the guideline recommendations. 48 Conclusions and recommendations The guideline developers should consider during its developing time to use the medical informatics tools to have, in the end, both versions made. This would also improve the quality and comprehension of the guideline’s statements and meet the needs of healthcare stakeholders to build a more affordable and reliable practice. It is expected that the suggestions presented in this work can help improving the future guidelines development. Future work 49 11. Future work As future work it is expected to use the templates developed as a message to agents so they can search and retrieve data from different systems, contributing to achieve the main goal of the SAHIB project, which is to contribute for the improvement of health data availability at the point of care. In addition the templates will be associated with the guideline rules and routine EHR data to analyze the decisions and their outcomes. 50 Future work 51 Referências 12. References Akkerman, D., Rabie, K., Stark, C., Rose, C., Croft, G., Levine, A., Vickers, J., Bowker, D., Esch, C., 2010. Health Care Guideline: Routine Prenatal Care, 14th ed. ICSI - Institute for Clinical Systems Improvement. Ardery, G., Carter, B.L., Milchak, J.L., Bergus, G.R., Dawson, J.D., James, P.A., Franciscus, C., Kim, Y., 2007. Explicit and Implicit Evaluation of Physician Adherence to Hypertension Guidelines. The Journal of Clinical Hypertension 9, 113–119. Beale, T., 2012. openEHR Templates. Beale, T., Heard, S., 2007a. An ontology-based model of clinical information. Stud Health Technol Inform 129, 760–764. Beale, T., Heard, S., 2007b. Architecture Overview. Beale, T., Heard, S., Kalra, D., Lloyd, D., 2008. EHR Information Model, 5.1.1 ed. The openEHR Foundation. Bohmer, R.M.J., 2009. Designing care : aligning the nature and management of health care. Harvard Business Press, Boston, Mass. Chen, R., Georgii-Hemming, P., Ahlfeldt, H., 2009. Representing a chemotherapy guideline using openEHR and rules. Stud Health Technol Inform 150, 653–657. Chobanian, A.V., Bakris, G.L., Black, H.R., Cushman, W.C., Green, L.A., Izzo, J.L., Jr, Jones, D.W., Materson, B.J., Oparil, S., Wright, J.T., Jr, Roccella, E.J., 2003. Seventh report of the Joint National Committee on Prevention, Detection, Evaluation, and Treatment of High Blood Pressure. Hypertension 42, 1206–1252. 58 Anexos