Journal of Biomedical Informatics 56 (2015) 112–126
Contents lists available at ScienceDirect
Journal of Biomedical Informatics journal homepage: www.elsevier.com/locate/yjbin
Formalize clinical processes into electronic health information systems: Modelling a screening service for diabetic retinopathy Aitor Eguzkiza a,⇑, Jesús Daniel Trigo a,1, Miguel Martínez-Espronceda a,1, Luis Serrano a,c,1, José Andonegui b a b c
Department of Electrical and Electronic Engineering, Public University of Navarra, Campus de Arrosadia, 31006 Pamplona, Spain Department of Ophthalmology, Complejo Hospitalario de Navarra, 31008 Pamplona, Spain Institute of Smart Cities – ISC, Public University of Navarra, Campus de Arrosadia, 31006 Pamplona, Spain
a r t i c l e
i n f o
Article history: Received 17 September 2014 Revised 22 May 2015 Accepted 26 May 2015 Available online 3 June 2015 Keywords: Clinical knowledge modelling Diabetic retinopathy Dual-model layered architecture Electronic health record Semantic interoperability Ophthalmology
a b s t r a c t Most healthcare services use information and communication technologies to reduce and redistribute the workload associated with follow-up of chronic conditions. However, the lack of normalization of the information handled in and exchanged between such services hinders the scalability and extendibility. The use of medical standards for modelling and exchanging information, especially dual-model based approaches, can enhance the features of screening services. Hence, the approach of this paper is twofold. First, this article presents a generic methodology to model patient-centered clinical processes. Second, a proof of concept of the proposed methodology was conducted within the diabetic retinopathy (DR) screening service of the Health Service of Navarre (Spain) in compliance with a specific dual-model norm (openEHR). As a result, a set of elements required for deploying a model-driven DR screening service has been established, namely: clinical concepts, archetypes, termsets, templates, guideline definition rules, and user interface definitions. This model fosters reusability, because those elements are available to be downloaded and integrated in any healthcare service, and interoperability, since from then on such services can share information seamlessly. Ó 2015 Elsevier Inc. All rights reserved.
1. Introduction The development of telemedicine-based screening strategies in ophthalmology enables ubiquitous and instant medical information to clinicians. Given that traditional face-to-face consultation in ophthalmology is limited by the scarcity of specialists, this
Abbreviations: CDS, clinical decision support; CKM, clinical knowledge manager; DICOM, digital imaging and communications in medicine; DME, diabetic macular edema; DR, diabetic retinopathy; EHR, electronic health record; ETDRS, early treatment for diabetic retinopathy study; GDL, Guideline Definition Language; GP, general practitioners; ICD-10, international statistical classification of diseases and related health problems; IOP, intraocular pressure; PACS, Picture Archiving and Communication System; PC, personal computer; SNOMED-CT, systematized nomenclature of medicine, clinical terms; SNS-O, Health Service of Navarre (Servicio Navarro de Salud – Osasunbidea); UI, user interface. ⇑ Corresponding author. Tel.: +34 948 169671. E-mail addresses: [email protected] (A. Eguzkiza), jesusdaniel.trigo@ unavarra.es (J.D. Trigo), [email protected] (M. MartínezEspronceda), [email protected] (L. Serrano), [email protected] (J. Andonegui). 1 Tel.: +34 948 169671. http://dx.doi.org/10.1016/j.jbi.2015.05.017 1532-0464/Ó 2015 Elsevier Inc. All rights reserved.
new scenario facilitates the redistribution of the workload toward more efficient clinical practices. In this sense, previous experiences have proved that specifically trained general practitioners (GPs) can screen patients for diabetic retinopathy (DR) using non-mydriatic retinal photography [1,2]. Specifically trained nurses and imaging technicians also can perform the diagnostic tests required in this healthcare process [3]. Whereas traditional consultation considers that the expert ophthalmologist is responsible for handling the entire process, this new framework distinguishes different active roles in the process of detecting DR [4]: The ‘‘test acquisition’’ role involves the use of medical devices to obtain images and data of sufficient quality for diagnosis. Nurses or technicians can reliably perform this task. The ‘‘DR screening’’ role includes observation of diagnostic tests to identify signs of DR and determine if the patient being examined has treatable DR. GPs can reliably perform this task. The ‘‘medical care supervision’’ role is that in which retina specialists assume the ultimate responsibility in this process by interpreting the signs of DR to classify the disease and choose
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
the appropriate treatment. Occasionally, they also supervise the work of other clinicians to verify correct functioning of the service. A primary consequence of this new assignment of different tasks to specialized personnel based on fundus photography is that it is more cost effective compared to traditional methods of DR assessment [5–8]. However, the implementation of new healthcare proposals is hindered by the intense modelling efforts required to update the knowledge base, already registered into static and vendor-specific electronic health information systems [9]. This is due to several factors. First, there is an important interdisciplinary gap between clinicians and software developers when it comes to define the specific healthcare scenarios; and, second, the continuous evolution of medical knowledge. The consequent developmental costs resulting from this endless redesign become unaffordable for any healthcare service [9]. Further, specifically in ophthalmology, electronic health records (EHR) have special requirements regarding other clinical specialties that are not considered by traditional information systems [10]. Nevertheless, the advent of more adaptive health information standards based on dual-model layered architecture, such as the CEN/ISO 13606 or openEHR, has simplified all of those factors, i.e., agreement among clinicians and software developers, continuous need to adapt the information system, and system customization to ophthalmology. These new information standards have simplified the management of the clinical knowledge inside the EHR [11,12]. This architecture includes, on the one hand, a reference model that standardizes the way the information is handled inside the software, and, on the other hand, an archetype model that gathers knowledge about the clinical process to be managed [13]. In this way, experts in the clinical domain determine the components in the archetype model to customize the information in their own EHR systems, whereas software developers work in conformance with the reference model toward better tools to achieve interoperability among information systems [14]. Therefore, with regard to modelling clinical knowledge, the archetypes are the keystone of dual-model architecture, formally defined as computable expressions of the domain knowledge in the form of structured constraint statements. In other words, they are computer interpretable definitions of the semantics and structure of clinical concepts. In principle, archetypes must be formulated toward wide re-use of clinical concepts validated by an international community of experts in the clinical domain. Thus, regarding local implementation, archetypes must be adapted according to the requirements of specific healthcare scenarios. Therefore, templates are modelled to constrain and group those archetypes into larger structures analogous to the paper medical records [15]. Then, the elements of knowledge that comprise both, i.e., archetypes and templates, can likewise be bound to equivalent concepts within standardized medical terminologies. Those connections provide semantic relationships and unambiguous identification for each data element when information is exchanged among different information systems [15]. In connection with this model-driven design strategy, the changes concerning the domain knowledge are included on the fly, in contrast to traditional information systems that require planning all causality before implementation [16]. In consequence, dual-model architecture has significantly improved the maintainability regarding time, cost, and simplicity of the software [17]. With consideration of all the above, the approach of this paper is twofold. First, this article presents a generic methodology to model clinical processes and, second, a proof of concept thereof in a specific scenario of DR screening in the SNS-O. Regarding the
113
methodology, all information involved within clinical processes is modelled considering different levels of interoperability (technical, syntactic, semantic, process/organizational, and presentation) for a faithful data exchange among information systems. This methodology therefore goes one step further than computerize the domain knowledge in compliance with dual-model architectures, hence also proposes modelling the organizational management of the service and the specifications for the user interface (UI) (how that information is presented to users). Therefore, the patient information must comprise not only the information gathered during an isolated clinical encounter, but also a whole system of organizational concepts to ensure a secure exchange toward ubiquitous and instant delivery of the information required by each healthcare provider involved in a particular clinical process. Additionally, besides modelling the information handled during clinical encounters, clinicians must be involved in the definition of the UI specifications to guarantee a faithful representation of that information to the final users. In this way, there is no need of intermediaries to give a context and a purpose of use to the information modelled. Thus, the resulting UI models provide the flexibility required to reuse the same information depending on the specific purposes of clinicians at any given time (research, epidemiology, population health, health administration, best practice care testing, financing, healthcare procedure comparison, healthcare goal planning, etc.). The consequent methodology would provide a framework to ensure the continuity of care within patient-centered complex clinical processes such as chronic disease management, which require tight coordination of resources. Therefore, this article will guide the readers in the definition of an entire set of knowledge artefacts that comprise a model with the aforementioned properties: clinical concepts, archetypes, termsets, templates, clinical decision support rules (CDS), and UI specifications. Once the methodology is presented, the second step is to exemplify the application thereof. As a proof of concept, the DR screening service of the Health Service of Navarre (Servicio Navarro de Salud – Osasunbidea [SNS-O]) was analyzed. In fact, such service succeeded on using information and communication technologies to redistribute efficiently the workload resulting from DR screening [1]. However, the lack of normalization of the information inside the service made it difficult, if not impossible, extend this strategy to other healthcare facilities. Therefore, the authors of this article work toward a methodology to formalize the aforementioned clinical process so as to extend this experience to other DR screening services. This report is organized as follows: the methodology used to study an e-Ophthalmology-based clinical model and its implementation into the SNS-O is presented in Section 2; the results of the transcription of the clinical process into a standardized electronic model are described in Section 2.2.4; the discussion including the main challenges found during the modelling of this screening service is in Section 4; and the conclusions are presented in Section 4.3. 2. Materials and methods The methodology described in this section is based on common patterns identified in similar clinical knowledge modelling experiences found in the literature. Most publications studied focused on the archetypes, since the point of departure for the model was the dual-model layered architecture. First, the development and maintenance of archetypes were studied at the theoretical level [18–22]. The research then focused on identification of the common patterns in real healthcare scenarios in which archetypes were modelled [23–25]. Some publications have gone one step
114
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
beyond and considered including the use of standard terminology services to support the semantic interoperability among heterogeneous information systems [26–28]. Once the modelling of clinical concepts was normalized, the information registered during clinical encounters could be used to provide computerized decision support to clinicians. Thus, publications on computerization of clinical guidelines were analyzed to establish a normalized procedure for their integration into information systems for healthcare. Those guidelines are comprised of CDS rules that trigger a specific action or another, depending on the clinical reasoning reached. However, the conditions governing the guideline rules depend strongly on the context information registered in the information system; therefore, most guideline definitions found were patchwork solutions designed specifically to satisfy the requirements of particular implementations [29– 32]. Alternatively, Chen et al. presented the Guideline Definition Language (GDL) that leverages the archetype model with which different information systems compliant with dual-model architecture exchange guideline rules [33]. The implementations of CDS rules that use dual-model architecture are used to generate reminders, alerts, and recommendations to ease the work of clinicians. Nonetheless, this methodology aspired to integrate the workflow in the modelling strategy proposed. Therefore, state of the art workflow modelling was studied, but the use cases in the literature did not contemplated normalization of a workflow model integrated with information systems based on dual-model architecture knowledge [34,35]. Thus, the methodology proposed the use of GDL rules to determine the clinical pathways for patients on a care plan. Another stage not usually considered in other methodologies modelling clinical knowledge is the definition of UI specifications as part of the clinical process. In fact, standardization of the information fosters interoperability at different levels, whereas normalization of the way that information is presented to clinicians enables reusability of those data according to different uses intended in the healthcare service. An interesting article was that in which Palau et al. presented the UI templates as a solution to normalize the definition of a UI model [36]. 2.1. Methodology proposed to formalize clinical processes into information systems As a result of the literature research, the patterns identified in the experiences reviewed above were unified into a comprehensive methodology. That guaranteed a suitable level of quality to provide a model-driven framework that would ensure continuity of care in patient-centered clinical processes. Considering all this, the modelling strategy proposed is comprised of three main phases (Fig. 1): 2.1.1. Definition of the project In response to deficiencies detected in daily clinical practice for a particular healthcare scenario, a work team is convened to analyze available information resources and define requirements to redesign the clinical procedure accordingly. A.1. Detection of a need within a healthcare process: The process of modelling healthcare guidelines into standardized knowledge repositories begins when healthcare providers identify in their daily practice the absence of formally described domain knowledge specifications for a particular healthcare scenario. A.2. Establishment of a work team: When this occurs, a work team must be established, to determine the objectives and scope of the project initiated. Such work team is comprised of multidisciplinary experts, who assume different roles depending on their capabilities to cover broad viewpoints about the
healthcare scenario to be modelled. Thereby, experts in diverse clinical domains transcribe their knowledge into computerized models, specialists in the technical domain guarantee the compliance of technical standards covered by those models, and terminologists supply detailed terminologies and ontologies for the artefacts modelled. Each discussion team (the work team could be divided into smaller groups) designates a convener to lead the progress of the modelling process, registers the decisions reached by the group and determines the scope of the project. A.3. Analysis of resources: Then, the work team proposes a solution for the issue identified during clinical practice, but it must be supported by reliable sources of information (scientific literature, work experience, healthcare standards/guidelines) resulting from a comprehensive review of the state of the art. 2.1.2. Design of the clinical process It must satisfy the requirements of the project described previously. This clinical process is a combination of activities, decisions, and conditions that constitute the clinical pathways in the healthcare service. Those pathways are completed with the clinical concepts identified and then organized hierarchically according to the healthcare scenario chosen. B.1. Definition of the clinical process: The work team proposes a clinical process in conformance with the specifications defined during the previous phase of the modelling. That process constitutes the workflow between the stages corresponding to different clinical encounters a patient has to go through to receive continuous clinical care. So first of all, the overall clinical process is agreed in a set of healthcare activities, conditions and decisions that represent the pathways between clinical stages. In this regard, activity diagrams in UML provides a suitable way to represent that workflow [37]. To conclude this step, the work team defines a project report that specifies every clinical practice conducted inside each one of the clinical stages identified on that activity diagram. B.2. Study of clinical concepts: Every clinical concept of interest to the clinical service being modelled is listed in a table which is added to the project report to keep every domain expert up-to-date about which parameters have to be included in the modelling. B.3. Hierarchical organization of knowledge artefacts: Considering the specifications of the main archetype-based information systems, the knowledge artefacts are structured according to the hierarchy described in Fig. 2 [11,38,39]: – UI templates: Set of rules that determine how the knowledge artefacts modelled – defined by archetypes, templates, and bindings to standard terminologies – will be displayed to clinicians. – Workflow: The dynamic side of clinical care; the process that guides patient healthcare through the stages of the clinical process [40,41]. – CDS rules: These rules based on medical evidence or by consensus from domain experts, provide notification services to support clinicians toward best healthcare practices. CDS rules also can be used to manage other guidelines, e.g., alerts, unit conversion, and automatic filling out of data among archetypes. For now, the only rules defined here are those concerning the stages of patient flow through the clinical process [41]. – Stages and roles: Each stage is a clinical scene inside the healthcare process handled by personnel with specific capabilities (roles).
115
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
DEFINITION
DESIGN OF THE CLINICAL PROCESS
OF THE PROJECT
BUILDING THE ELECTRONIC MODEL
C.1 - CREATION AND UPDATE OF ARCHETYPES A.1 - DETECTION OF A NEED WITHIN A HEALTHCARE PROCESS
B.1 - DEFINITION OF THE CLINICAL PROCESS
A.2 - ESTABLISHMENT OF A WORK TEAM
B.3 - HIERARCHICAL ORGANIZATION OF KNOWLEDGE ARTEFACTS
A.3 - ANALYSIS OF RESOURCES
C.2 - DEFINITION OF SEMANTIC LINKS TO CLINICAL TERMINOLOGIES
B.2 - STUDY OF CLINICAL CONCEPTS
C.3 - BUILDING TEMPLATES C.4 - MODELLING GUIDELINE RULES AND WORKFLOW C.5 - MODELLING UI TEMPLATES
Fig. 1. Proposed methodology for building an electronic model of a clinical process.
WORKFLOW
CDS RULES
STAGES
COMPOSITIONS ROLES TEMPLATES
SECTIONS
ENTRY CLASS ARCHETYPES UI TEMPLATES OBSERVATION
INSTRUCTION
EVALUATION
ACTION TERMSETS
GROUPABLE ARCHETYPES CLUSTER or STRUCTURE
Fig. 2. Conceptual diagram of the overall hierarchy between the knowledge artefacts involved in model-based architecture.
– Templates: They constrain the concepts and terminology from the archetypes they contain to define a form in which clinicians register the results of clinical encounters [15]. – Compositions: They are the smallest units for data exchange between information systems. They include all clinical and administrative information of a clinical care session. As such, they must include meta-information to contextualize the healthcare session regardless of the EHR system. In this sense, when a contribution to a specific composition is filled out, it is signed by the responsible professional; hence compositions have the same medico-legal validity as paper clinical documents. The extra information in compositions guarantees the ACID characteristics of transactions: Atomicity, Consistency, Isolation, Durability, indelibility, modification, and traceability [40]. – Sections or organizational archetypes: They organize the information inside compositions for human readability. They usually are used to arrange archetypes, but they also can enclose templates [40].
– Entry type or descriptive archetypes: These define the semantics for the information to be recorded in the information system. Four categories are distinguished depending on their function in the iterative clinical problem-solving cycle used in medicine: observation, evaluation, instruction, and action [30,40]. – Groupable archetypes: Clusters and structures are used embedded in different entry type archetypes to reuse context information they have in common. 2.1.3. Building the electronic model Finally, the clinical process designed in the previous phase is formalized electronically using archetypes, templates, terminology bindings, CDS rules, and UI specifications. Most articles found on the literature are focused on specific implementations and models. However, our proposal considers a model-driven EHR architecture that leverages standardization to coordinate federated information systems toward a unique care plan. Thus, the methodology proposed yields diverse electronic models aimed at govern different aspects of healthcare.
116
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
2.2. Application of this methodology to model the DR screening service in the SNS-O As a proof of concept for this methodology, the DR screening service of the SNS-O was modelled. The outcomes of the resulting model are specified in the Results section. 2.2.1. Definition of the project The aim was to develop a specific archetype-based model that could automatically manage the information generated during follow-up of DR in patients with diabetes. Expert ophthalmologists along with specialists in information and communication technologies participated in a multidisciplinary discussion committee. Once the work team was established, different knowledge sources were reviewed (literature, work experience, healthcare standards/guidelines) to establish the clinical process to handle DR screening [4,42,43]. 2.2.2. Design of the clinical process The design of the clinical process proposed for the SNS-O comprises the following steps: B.1. Definition of the clinical process: The process regarding DR screening was defined according to the different stages a patient goes through in the healthcare service (Fig. 3). First, patients in a population at risk for DR are evaluated before they begin the follow-up. Then, if convenient, those patients are scheduled for periodic necessary diagnostic tests to detect existing DR, ensuring the quality of acquisitions for diagnostic purposes. GPs trained to detect symptoms of DR then remotely review images and information acquired during evaluations. Retina specialists reassess the cases positive for DR. Depending on disease severity, the specialists reach a therapeutic decision and schedule a clinical procedure accordingly. Finally, the corresponding treatment is administered depending on each patient’s specific diagnosis. Once the work team identified those different stages, they were analyzed in detail (Fig. 3). – STAGE 1 (Admission and follow-up schedule): A patient can be referred for follow-up of DR since diabetes was diagnosed by an endocrinologist or if there is suspicion of DR due to symptoms detected while evaluating another eye disease during an ophthalmologic consultation or a routine primary care examination. In that sense, the admission stage is used to gather relevant patient clinical information. That preliminary information will be useful during follow-up and to determine the convenience of including or not including the patient in the screening service. Thereafter, the follow-up of DR can start, and the diagnostic tests to detect and classify the disease can be scheduled. – STAGE 2 (Acquisition and validation of diagnostic tests): The diagnostic tests of SNS-O consist of non-mydriatic funduscopy and the measurement of intraocular pressure (IOP). Most healthcare organizations recommend repeating these tests at least once annually for patients with diabetes even in those without signs of DR. This prevents clinicians from overlooking serious symptoms of disease progression during the intermediary period between revisions [43]. The development of digital and interoperable diagnostic devices implemented in the SNS-O provides ubiquitous access from remote workstations to the results of the diagnostic tests. So, the results of these tests can be evaluated remotely [44]. This allows nurses or imaging
technicians (referred to as ‘‘imagers’’) to use those devices to perform diagnostic tests, whereas traditionally the presence of ophthalmologists was required during consultations [45]. At this point, the imagers must guarantee the quality of the acquisitions, so that the ophthalmologists can make reliable evaluations of those acquisitions. The measurement of corrected IOP involves tonometry and pachymetry. However, the results of those tests include a single IOP value, and registering this measurement is sufficient for later diagnostic purposes. Initially, the IOP measurement was not a component in the screening procedure for DR, but it later was included due to the epidemiologic interest in identifying early symptoms of other ophthalmic diseases associated with diabetes. In fact, measuring the IOP identifies patients with dangerous IOP levels (P22 mmHg), the point at which patients must be referred directly to the corresponding ophthalmologist, even if other tests do not show evidence of disease. However, validation of the funduscopic photographs is more complex since imagers must review the quality of each acquisition at the capture stage before referring them for assessment. The procedure chosen for that purpose involves classifying fundus images according to the overall photographic quality using a scale based on objective findings [6,46,47]. Different proposals have been reported when choosing a scale to measure quality; we used a scale ranging from 1 to 5, in which 1 indicates the worst and 5 indicates the best as Lamirel et al. proposed in the FOTO-ED study [46]. For diagnostic purposes, images of level 3 or lower that can confuse imagers are discarded. With unreadable images (62), the patient is referred immediately for a face-to-face ophthalmic consultation. When images of the ocular fundus are obtained, the numbers of retinal fields photographed vary depending on the purpose of the study. Considering the seven fields defined by the Early Treatment for Diabetic Retinopathy Study (ETDRS) [42,48], Vujosevic et al. suggested [49] that a central 45-degree color image is sufficient to determine the absence or presence of DR and diabetic macular edema (DME); however, a minimum of three fields is needed to classify the disease according to the international classification of DR proposed by the American Academy of Ophthalmology [50,51]. Nevertheless, according to clinical criteria, within the specific scenario of the SNS-O, two fields were considered adequate to manage the DR screening: one focused on the papilla and one focused on the macula. During acquisition, some artefacts can appear due to small pupils, cataracts, or other complications resulting from the capture. Therefore, acquisition is repeated when the image is inadequate for diagnostic purposes. To avoid extending this procedure unnecessarily, the test is limited to three attempts unless a technical issue is identified. From the fourth attempt on, the probability of obtaining a high-quality photograph is 20% at most [46]. In patients with a small pupil, the imager can request a mydriatic agent to obtain suitable retinal images; an ophthalmologist must supervise the drug instillation to reduce the risk of angle-closure glaucoma. For this reason, these patients must be referred directly for a face-to-face ophthalmic consultation.
117
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
STAGE 1: Patient admission and follow-up schedule
DIABETES MELLITUS DIAGNOSED OR SUSPICION OF DR
LEGEND:
NO
STAGE INTIAL STATE
DR SCREENING CONVENIENT FOR PATIENT
ACTION FINAL STATE DECISION
YES
STAGE 2: Acquisition and validation of diagnostic tests
NON MYDRIATIC FUNDUS PHOTOGRAPHY + INTRAOCULAR PRESSURE
SCHEDULE THE NEXT REVIEW IN A YEAR
QUALITY ASSESSMENT DURING ACQUISITION
IMAGES SUITABLE FOR DIAGNOSIS (QUALITY 4:5, 5:5)
IOP VALUE ≥ 22 mmHg
CONFUSING IMAGES (QUALITY 3:5)
UNREADABLE IMAGES (QUALITY 1:5, 2:5)
STAGE 3: DR screening WITHOUT RETINAL ALTERATIONS
REMOTE ASSESSMENT BY GENERAL PRACTITIONERS
ALTERATIONS WITHIN THE RETINA
STAGE 4: Disease classification and therapeutic decission
DIRECT OPHTHALMOSCOPY
ASSESSMENT BY OPHTHALMOLOGIST
WITHOUT RETINAL ALTERATIONS
CLASSIFICATION OF DR AND THERAPEUTIC DECISION
FOCAL DIABETIC MACULAR EDEMA
PROLIFERATIVE DIABETIC RETINOPATHY
STABLE DIABETIC RETINOPATHY
DIFFUSE DIABETIC MACULAR EDEMA
LASER
SURGERY
TREATMENT: INTRAVITREAL INJECTION
TREATMENT: INTRAVITREAL INJECTION
MACULAR LASER / PANRETINAL PHOTOCOAGULATION
VITRECTOMY
CORTICOIDS (Dexamethasone)
ANTIANGIOGENICS (Bevicizumab, Ranibizumab)
STAGE 5: Treatment
Fig. 3. Activity diagram showing the workflow of DR screening service in the SNS-O.
118
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
Once the necessary images for DR assessment are acquired and validated (quality level 4 or 5), they are sent to a Picture Archiving and Communication System (PACS) accessible to image reviewers. These acquisitions are labelled with the same study identification number, making it possible for a reviewer to retrieve every image corresponding to that specific diagnostic study. – STAGE 3 (DR screening): Image studies suitable for diagnosis are loaded from the PACS to remote workstations where image reviewers search for symptoms of DR. DR can be classified with different levels of precision, although for screening purposes it is sufficient to classify patients into two categories: those presenting with signs of DR and those without signs of DR (ETDRS value 620) [4]. There is a third option in case of uncertain images: the patient is referred to a specialist for review. To support this classification, it is recommended that the findings identified during the examination of the posterior chamber and the criteria chosen to reach a diagnostic decision be described. Given that most patients with diabetes do not present with symptoms of DR, this screening will markedly reduce the workload of ophthalmologists, since only retinopathies and uncertain studies need more specific assessment [52]. – STAGE 4 (Disease classification and therapeutic decision): The images in this stage must show signs of DR except for: false positives generated during screening, images that created uncertainty for GPs, or diagnostic test acquisitions without sufficient quality for remote screening [52]. Ophthalmologists then assess diagnostic tests, determine the best procedure to avoid disease progression, and review the different signs of DR found in diagnostic tests to identify the DR type. By reviewing the findings and diagnostic criteria registered during screening, the assessment can be accelerated. Even so, the final DR classification must be based on the criteria and findings of the ophthalmologists. Before reaching a therapeutic decision, the studies are classified using the International Clinical Diabetic Retinopathy and Macular Edema Disease Severity Scale proposed at the American Academy of Ophthalmology [50,51]. Therefore, according to the DR types, the studies can show proliferative or non-proliferative disease; the latter, depending on symptom severity, is classified as mild, moderate, or severe. Macular edema, if present, also can be classified as mild, moderate, or severe. Thereafter, different therapies will be chosen according to the severity and specific symptoms of DR (Fig. 3). – STAGE 5 (Treatment): Once the most suitable treatment is determined, the special features of the procedure being performed are documented. Intraocular injections, laser therapy, and surgery are the procedures considered in this model. Diffuse DME is treated by injection of antiangiogenic drugs, either bevacizumab (Avastin, Genentech Inc., South San Francisco, CA) or ranibizumab (Lucentis, Genentech Inc.); focal DME is treated by macular laser or panretinal photocoagulation; stable DR is treated with injection of corticoids (dexamethasone). In contrast, proliferative DR requires vitrectomy [43]. B.2. Study of Clinical Concepts: The clinical concepts involved in the clinical process of DR screening were determined according to the scenario described in previous step. The concepts considered relevant are listed in Table 1. However, given that archetypes are formal definitions of concepts from a clinical domain, their modelling involves
registering the clinical knowledge in a standardized and reusable manner [15]. According to this, before modelling every concept from scratch, the work team reviewed the archetypes available in the openEHR clinical knowledge manager (CKM) repository [53]. Three situations were identified: some archetypes perfectly fit the concepts consulted, so they were downloaded from the CKM and used directly in the model; other archetypes needed modifications to match the needs of the current model; and other concepts were new, so their archetypes were created from scratch (Table 1). B.3. Hierarchical Organization of Knowledge Artefacts: The design of archetypes for the healthcare scenario of DR screening did not begin until the discussion committee agreed to the overall screening service. To do so, the work team designed a diagram in which the hierarchical relationships between the concepts were defined according to the hierarchy described in Section 2.1.2 (Fig. 4). In this sense, collaborative diagramming tools were used to accelerate the transfer of knowledge from domain experts to a standardized healthcare model managed by archetypes [30,54,55]. 2.2.3. Building the electronic model Once the work team discussed the theoretical clinical process, similar modelling experiences documented in the literature were considered to transcribe the clinical knowledge of the SNS-O. Thus, archetypes and templates defined the information handled in the clinical process [23,24]. CDS rules also were created to support clinicians to take the decisions about guiding patients through the service [29,30,56]. Finally, UI specifications determined how all that information would be presented to clinicians. This procedure and its consequent models are further explained in the section corresponding to ‘‘Results’’. 2.2.4. Establishment of the interoperability framework To integrate the use of the electronic models defined along this article into the DR screening service from the SNS-O, every information system, diagnostic device, and workstation involved in the clinical process must be adapted beforehand so as to guarantee ubiquitous and instant access to the information registered. So that, the technical environment was analyzed to accordingly establish a framework based on standards. This clinical process involves three types of workspaces: one for diagnostic test acquisition, one for DR screening, and, one for DR assessment. The first contains the tonometry plus pachymetry instruments for IOP measurement, a non-mydriatic retinal camera, and a personal computer (PC) workstation to register findings identified during acquisitions. The second workspace is located in the workplace of the GPs; there, a PC workstation has access to the PACS and EHR to remotely visualize clinical images and register the consequent clinical reports. The third workspace is similar to the screening workstation but is in the consulting room of the ophthalmologist in the same building where diagnostic tests are performed. If a patient needs more extensive analysis, immediate face-to-face consultations are possible with retina specialists. To interconnect those workplaces, two independent but complementary standards coordinate the information among different devices and locations: the first, Digital Imaging and Communications in Medicine (DICOM), handles the interchange of imaging diagnostic test acquisitions as multimedia files. The second, openEHR, manages any health information registered during clinical evaluations. In this sense, medical imaging devices from the health service were connected under fulfilment of the DICOM standard. As in Section 2.2.2, diagnose of DR requires acquisition of fundus images. Retinal cameras involved in screening were connected through the corporative network to a PACS server that manages clinical images
119
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126 Table 1 Clinical concepts to be modelled as a result of study of each stage in the service of DR screening. Identified concept name
Class
Availability and suitability
Reason for encounter
Evaluation
Found on CKM Usable as is
Patient admission
Clinical synopsis
Evaluation
Found on CKM Usable as is
Patient admission, DR screening, DR assessment
Problem/diagnosis
Evaluation
Found on CKM Usable as is
Patient admission, DR screening, DR assessment
Diagnostic criteria DR
Cluster
Concept modelled from scratch
Examination findings – posterior chamber of eye
Cluster
Concept modelled from scratch
Story
Observation
Found on CKM Usable as is
Patient admission
Symptom
Cluster
Found on CKM Usable as is
Patient admission
DR screening convenient
Evaluation
Referral request
Instruction
Found on CKM Usable as is
Follow-up schedule, DR screening
Imaging examination request
Instruction
Found on CKM Usable as is
Follow-up schedule
Concept modelled from scratch
Concept modelled from scratch
Process stages in which it is applicable
Patient admission, DR screening, DR assessment Patient admission, DR screening, DR assessment
Patient admission
Acquisition details on eye fundus images
Cluster
Procedure undertaken
Action
Found on CKM Usable as is
Diagnostic tests, DR treatment
IOP measurement
Observation
Found on CKM It was adapted
Diagnostic tests
Device
Cluster
Found on CKM Usable as is
Diagnostic tests, DR screening, DR assessment
Device details
Cluster
Found on CKM Usable as is
Diagnostic tests, DR screening, DR assessment
Imaging examination
Action
Found on CKM Usable as is
Diagnostic tests
Anatomic location
Cluster
Found on CKM Usable as is
Diagnostic tests
Mydriasis application
Cluster
Medication amount
Cluster
Concept modelled from scratch
Examination details – eye fundus images
Cluster
Concept modelled from scratch
Diagnostic report request
Instruction
Concept modelled from scratch
Funduscopic examination of eyes
Observation
Found on CKM Usable as is
Found on CKM It was adapted Concept modelled from scratch
Follow-up schedule
Diagnostic tests Diagnostic tests, DR treatment Diagnostic tests, DR screening, DR assessment Diagnostic tests, DR screening DR screening, DR assessment
Classification of Diabetic Retinopathy
Cluster
Exclusion of a problem/diagnosis
Evaluation
Found on CKM Usable as is
DR screening, DR assessment
Recommendation
Evaluation
Found on CKM Usable as is
DR assessment
Medication order
Instruction
Found on CKM Usable as is
DR treatment
Medication action
Action
Found on CKM Usable as is
DR treatment
Medication administration
Cluster
Found on CKM Usable as is
DR treatment
Medication ingredients
Cluster
Found on CKM Usable as is
DR treatment
Procedure request
Instruction
Found on CKM Usable as is
DR treatment
Photocoagulation details
Cluster
Concept modelled from scratch
DR treatment
Ophthalmic surgery details – Posterior segment of eye
Cluster
Concept modelled from scratch
DR treatment
from the entire health service. This server is accessible from remote workstations where image viewing tools were installed in accordance with DICOM specifications (Fig. 5).
DR assessment
Concurrently, the PACS must be connected to an EHR compliant with openEHR standards, making it possible to manage the information originated as a result of the healthcare process.
120
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
SYMBOL LEGEND KNOWLEDGE DOMAIN
ARCHETYPE MODEL ENTRY CLASS ARCHETYPES
GROUPABLE ARCHETYPES
ARCHETYPE AVAILABILITY
COMPOSITION
WORKFLOW STAGE
SECTION
ROLE
TERMSET
OBSERVATION
INSTRUCTION
EVALUATION
ACTION
* GP: general practitioner
INSTRUCTION – ACTION COORDINATION
ARCHETYPE FROM CKM
CLUSTER or STRUCTURE
NEW ARCHETYPE
MODIFIED ARCHETYPE
** IOP: intraocular pressure
Encounter PATIENT ADMISSION
Patient's background
Reason for encounter Clinical synopsis
Primary care physician
Problem/diagnosis
Endocrinologist
Story DR screening convenient
No
Diagnostic criteria DR Examination findings – post. chamber of eye
Ophthalmologist
Patient’s admittance
Symptom
DR screening convenient
Yes
Referral FOLLOW-UP SCHEDULE
Diagnostic test planning
Referral request (IOP**) Imaging examination req.
Guideline rule engine
Imaging details – eye fundus
Zones of retina DR Study fields
Trained GP* Ophthalmologist
Progress note DIAGNOSTIC TESTS
Intraocular pressure study
Procedure undertaken IOP** measurement
Device
Imaging examination
Anatomic location
Zones of retina
IOP < 22 mmHg & Image quality ≥ 4:5
Mydriasis application (If necessary)
Mydriatic agents
Yes
Medication amount
Trained Nurse
Device details
Imaging technician Clinical image acquisition No
Examination details – eye fundus images Next step planning
Diagnostic report request
Report Funduscopic examination of eyes
Automated processing
Examination details – eye fundus images Examination findings – posterior chamber of eye
Trained GP*
Device
DR SCREENING
Image test analysis
Device details No
Alterations within the retina
Clinical decision
Clinical synopsis Problem/Diagnosis
Yes
Exclusion of a problem/Diagnosis
Clinical stage/grade – DR classification
Classification of DR for screening
Diagnostic criteria DR Examination findings – post. chamber of eye
Next step planning
Diagnostic report request Referral request
Report DR ASSESSMENT
Image test analysis
Funduscopic examination of eyes
Ophthalmologist
Examination details – eye fundus images Examination findings – posterior chamber of eye Device
No
Treatable retinopathy Yes
Device details Clinical decision
Clinical synopsis Problem/diagnosis
Clinical stage/grade – DR classification
Classification of DR
Exclusion of a problem/Diagnosis
Diagnostic criteria DR
Classification of macular retinal edema
Examination findings – post. chamber of eye Recommendation – DR treatment
Procedures on posterior segment of eye
Progress note Medication administration DR TREATMENT
Intraocular injection
Medication order Medication ingredients
Angiogenesis inhibitor subst.
Medication amount
Synthetic glucocorticoid subst.
Photocoagulation details
Photocoagulation procedure (panretinal, macular drusen...)
Medication action
Ophthalmologist
Laser
Procedure request Procedure undertaken
Surgical procedure
Procedure request
Laser device (dye, diode, gas)
Ophthalmic surgery details Posterior segment of eye
Operative procedures on posterior segment of eye
Procedure undertaken
Fig. 4. Hierarchy of information of the model for DR screening, according to archetype-based EHR systems.
121
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
Dual-model architecture EHR compliant with openEHR (DR screening)
Main EHR in the healthcare service
Archetype model
Healthcare data store
EHR Extract
Electronic referral notes
Electronic referral notes
PACS Server
DICOM images
DICOM images
Diagnostic test acquisition by nurse
DR screening by trained GP
DR evaluation by ophthalmologist
Clinical report
Clinical report
Clinical report
DICOM worklist
DICOM images
Legend DR: diabetic retinopathy GP: general practitioner
Fig. 5. Flux of information through the service for DR screening.
Healthcare information, such as diagnoses and measurements derived from clinical tests, will be registered in that EHR. However, most information systems available within current healthcare services do not yet support the openEHR standard. Consequently, a dedicated EHR server capable of interpreting openEHR archetypes must be setup to work in parallel with the main EHR server of the healthcare service. This EHR is exclusively responsible for managing the information generated during any clinical procedure corresponding to follow-up of DR. And as such, it also integrates any service resulting from the use of medical records concerning that clinical process, such as CDS, workflow management, and UI customization. In that respect, the clinical process has been completely modelled using archetypes, templates, CDS rules, and UI specifications; upon loading into the EHR system, all those provide the necessary tools to guide clinicians in efficient care practices. When necessary, this server will send EHR extracts with relevant healthcare results to the main information system of the health service, making that information reusable for other clinical processes. These extracts will be constructed in compliance with healthcare messaging standards, according to the different EHRs involved (Fig. 5). A primary advantage of the EHR based on archetypes is its flexibility, because it can load a model to manage the DR screening service and apply changes to it as necessary. There is no need to
introduce any changes in the main EHR system of the service, even if there are modifications in the clinical process. 3. Results This section provides the electronic models designed to manage the information generated by the DR screening service in the SNS-O. To that end, the same work team that defined the clinical process was convened to transcribe the resulting models into electronic health information systems. First, the concepts identified during the design of the clinical process were integrated into archetypes that could be used in any clinical scenario; then, those concepts in the archetypes were linked to standard terminologies. Once archetypes were available, they were enclosed and constrained in templates. Each template was designed according to the specifications of the clinical scenario in which it will be used. Then, the CDS rules aimed at manage the service workflow were defined in compliance with GDL. Finally, the archetypes, templates, CDS rules, and UI specifications were loaded into an EHR capable of interpreting them to test the model in a real-use case scenario. 3.1. Creation and update of archetypes Most required archetypes already existed in public clinical knowledge repositories, so they were used directly in the model. Nonetheless, based on experience with archetype creation in the
122
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
literature, the work team designed the following procedure to create/update archetypes [18–20,30]: Elicitation of content: The archetypes identified in the clinical process (Section 2.2.2) were dismantled into data elements. Once these elements were defined, data types were assigned to them according to the reference model from the openEHR standard. Each element then could be associated with equivalent clinical concepts defined in standardized terminologies (Section 3.2). Content organization: The structure of archetypes was defined by establishing connections among those concepts. Collaborative mind-mapping tools were used to optimize the contributions of different work team members [54]. Building archetypes: The clinical concepts already modelled at a theoretical level were written using the archetype definition language defined by openEHR, with the archetype editor of Ocean Informatics [57]. Publishing and validating the archetypes: Once archetypes were uploaded into the openEHR CKM, they must follow the authoring process defined by the standard. This process described different phases of the lifecycle of archetypes, which are based on peer review [20,58,59]. Theoretically, archetypes must be designed to be independent of the usage context. Nevertheless, our efforts focused especially on development of elements required in DR screening. Therefore, some archetypes from the CKM were reviewed and completed to match the requirements of the proposed clinical process. In the same way, it is expected that our uploaded archetypes will be completed by other users. For this reason, new archetypes and proposals for modification were uploaded to the CKM to be discussed worldwide among experts in healthcare modelling. This model will be in constant evolution depending on the progress of the methodology for the follow-up of DR. Consequently, extending this clinical process to other healthcare facilities and periodic updating of that model occur immediately. Each healthcare organization adopting these archetypes also will be interoperable worldwide.
3.2. Definition of semantic links to clinical terminologies This section was established simultaneously with the creation of archetypes and templates. First, the semantics of data elements were established for local use; at the same time, those data elements were bound to their equivalent terms defined in standardized terminology services.
Considering that most archetypes from the CKM were defined in English, they were translated into Spanish for use in the SNS-O. However, new archetypes were created directly in both languages to reach as many modellers as possible. In addition, because as many data elements as possible were linked to standard terminology services such as Systematized Nomenclature of Medicine Clinical Terms (SNOMED-CT) or International Statistical Classification of Diseases (ICD-10); even some references to equivalent concepts from technical standards like DICOM were included. In this way, these terms maintain the semantic meaning independently from the translation, since selected terminology services support multiple languages. Some elements identified during this process can adopt different values. Those values are bound to lists known as termsets, defined by standardized terminology services (Fig. 4). 3.3. Building templates Templates are local representations of the stages of the clinical process. Therefore, the archetypes were enclosed in the templates according to the hierarchy in Fig. 4. Because archetypes contain generic elements to support every use case, most elements were disabled at the template level to register only those data elements required for the healthcare service proposed within the SNS-O. Thus, a template was created using the template designer from Ocean Informatics [57] to constrain the archetypes contained in each section-type archetype (Fig. 4). New templates then were created to group those templates according to the composition archetypes containing them. 3.4. Modelling guideline rules and workflow Different rules were configured to handle the decisions about workflow. To define these rules, the GDL editor developed by Cambio Healthcare Systems was used because it makes use of the reference and archetype models from openEHR [60]. GDL language queries to an EHR the information registered by means of archetypes or templates, and it applies conditions and consequent actions accordingly, making it possible to trigger automatically real-time alerts or events for CDS when data are registered in the EHR. In this sense and based on the clinical guidelines defining the workflow, different CDS events were configured such that clinicians receive specific instructions about how to refer patients through the screening service. These rules identified in Fig. 4 are described below (Fig. 6). However, clinicians are free to handle the service manually as desired.
Fig. 6. CDS rules developed with the GDL rule editor.
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
DR screening convenience: The first encounter is used to check if the patient meets the criteria for inclusion in the screening process. This rule activates (or not) the archetypes involved in requesting the diagnostic tests necessary to start follow-up. Diagnostic tests valid for assessment: Once the diagnostic tests have been acquired, this rule discards any unusual value for the screening stage; in case of dangerously high IOP values (>22 mmHg) or low-quality fundus images (
Contents lists available at ScienceDirect
Journal of Biomedical Informatics journal homepage: www.elsevier.com/locate/yjbin
Formalize clinical processes into electronic health information systems: Modelling a screening service for diabetic retinopathy Aitor Eguzkiza a,⇑, Jesús Daniel Trigo a,1, Miguel Martínez-Espronceda a,1, Luis Serrano a,c,1, José Andonegui b a b c
Department of Electrical and Electronic Engineering, Public University of Navarra, Campus de Arrosadia, 31006 Pamplona, Spain Department of Ophthalmology, Complejo Hospitalario de Navarra, 31008 Pamplona, Spain Institute of Smart Cities – ISC, Public University of Navarra, Campus de Arrosadia, 31006 Pamplona, Spain
a r t i c l e
i n f o
Article history: Received 17 September 2014 Revised 22 May 2015 Accepted 26 May 2015 Available online 3 June 2015 Keywords: Clinical knowledge modelling Diabetic retinopathy Dual-model layered architecture Electronic health record Semantic interoperability Ophthalmology
a b s t r a c t Most healthcare services use information and communication technologies to reduce and redistribute the workload associated with follow-up of chronic conditions. However, the lack of normalization of the information handled in and exchanged between such services hinders the scalability and extendibility. The use of medical standards for modelling and exchanging information, especially dual-model based approaches, can enhance the features of screening services. Hence, the approach of this paper is twofold. First, this article presents a generic methodology to model patient-centered clinical processes. Second, a proof of concept of the proposed methodology was conducted within the diabetic retinopathy (DR) screening service of the Health Service of Navarre (Spain) in compliance with a specific dual-model norm (openEHR). As a result, a set of elements required for deploying a model-driven DR screening service has been established, namely: clinical concepts, archetypes, termsets, templates, guideline definition rules, and user interface definitions. This model fosters reusability, because those elements are available to be downloaded and integrated in any healthcare service, and interoperability, since from then on such services can share information seamlessly. Ó 2015 Elsevier Inc. All rights reserved.
1. Introduction The development of telemedicine-based screening strategies in ophthalmology enables ubiquitous and instant medical information to clinicians. Given that traditional face-to-face consultation in ophthalmology is limited by the scarcity of specialists, this
Abbreviations: CDS, clinical decision support; CKM, clinical knowledge manager; DICOM, digital imaging and communications in medicine; DME, diabetic macular edema; DR, diabetic retinopathy; EHR, electronic health record; ETDRS, early treatment for diabetic retinopathy study; GDL, Guideline Definition Language; GP, general practitioners; ICD-10, international statistical classification of diseases and related health problems; IOP, intraocular pressure; PACS, Picture Archiving and Communication System; PC, personal computer; SNOMED-CT, systematized nomenclature of medicine, clinical terms; SNS-O, Health Service of Navarre (Servicio Navarro de Salud – Osasunbidea); UI, user interface. ⇑ Corresponding author. Tel.: +34 948 169671. E-mail addresses: [email protected] (A. Eguzkiza), jesusdaniel.trigo@ unavarra.es (J.D. Trigo), [email protected] (M. MartínezEspronceda), [email protected] (L. Serrano), [email protected] (J. Andonegui). 1 Tel.: +34 948 169671. http://dx.doi.org/10.1016/j.jbi.2015.05.017 1532-0464/Ó 2015 Elsevier Inc. All rights reserved.
new scenario facilitates the redistribution of the workload toward more efficient clinical practices. In this sense, previous experiences have proved that specifically trained general practitioners (GPs) can screen patients for diabetic retinopathy (DR) using non-mydriatic retinal photography [1,2]. Specifically trained nurses and imaging technicians also can perform the diagnostic tests required in this healthcare process [3]. Whereas traditional consultation considers that the expert ophthalmologist is responsible for handling the entire process, this new framework distinguishes different active roles in the process of detecting DR [4]: The ‘‘test acquisition’’ role involves the use of medical devices to obtain images and data of sufficient quality for diagnosis. Nurses or technicians can reliably perform this task. The ‘‘DR screening’’ role includes observation of diagnostic tests to identify signs of DR and determine if the patient being examined has treatable DR. GPs can reliably perform this task. The ‘‘medical care supervision’’ role is that in which retina specialists assume the ultimate responsibility in this process by interpreting the signs of DR to classify the disease and choose
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
the appropriate treatment. Occasionally, they also supervise the work of other clinicians to verify correct functioning of the service. A primary consequence of this new assignment of different tasks to specialized personnel based on fundus photography is that it is more cost effective compared to traditional methods of DR assessment [5–8]. However, the implementation of new healthcare proposals is hindered by the intense modelling efforts required to update the knowledge base, already registered into static and vendor-specific electronic health information systems [9]. This is due to several factors. First, there is an important interdisciplinary gap between clinicians and software developers when it comes to define the specific healthcare scenarios; and, second, the continuous evolution of medical knowledge. The consequent developmental costs resulting from this endless redesign become unaffordable for any healthcare service [9]. Further, specifically in ophthalmology, electronic health records (EHR) have special requirements regarding other clinical specialties that are not considered by traditional information systems [10]. Nevertheless, the advent of more adaptive health information standards based on dual-model layered architecture, such as the CEN/ISO 13606 or openEHR, has simplified all of those factors, i.e., agreement among clinicians and software developers, continuous need to adapt the information system, and system customization to ophthalmology. These new information standards have simplified the management of the clinical knowledge inside the EHR [11,12]. This architecture includes, on the one hand, a reference model that standardizes the way the information is handled inside the software, and, on the other hand, an archetype model that gathers knowledge about the clinical process to be managed [13]. In this way, experts in the clinical domain determine the components in the archetype model to customize the information in their own EHR systems, whereas software developers work in conformance with the reference model toward better tools to achieve interoperability among information systems [14]. Therefore, with regard to modelling clinical knowledge, the archetypes are the keystone of dual-model architecture, formally defined as computable expressions of the domain knowledge in the form of structured constraint statements. In other words, they are computer interpretable definitions of the semantics and structure of clinical concepts. In principle, archetypes must be formulated toward wide re-use of clinical concepts validated by an international community of experts in the clinical domain. Thus, regarding local implementation, archetypes must be adapted according to the requirements of specific healthcare scenarios. Therefore, templates are modelled to constrain and group those archetypes into larger structures analogous to the paper medical records [15]. Then, the elements of knowledge that comprise both, i.e., archetypes and templates, can likewise be bound to equivalent concepts within standardized medical terminologies. Those connections provide semantic relationships and unambiguous identification for each data element when information is exchanged among different information systems [15]. In connection with this model-driven design strategy, the changes concerning the domain knowledge are included on the fly, in contrast to traditional information systems that require planning all causality before implementation [16]. In consequence, dual-model architecture has significantly improved the maintainability regarding time, cost, and simplicity of the software [17]. With consideration of all the above, the approach of this paper is twofold. First, this article presents a generic methodology to model clinical processes and, second, a proof of concept thereof in a specific scenario of DR screening in the SNS-O. Regarding the
113
methodology, all information involved within clinical processes is modelled considering different levels of interoperability (technical, syntactic, semantic, process/organizational, and presentation) for a faithful data exchange among information systems. This methodology therefore goes one step further than computerize the domain knowledge in compliance with dual-model architectures, hence also proposes modelling the organizational management of the service and the specifications for the user interface (UI) (how that information is presented to users). Therefore, the patient information must comprise not only the information gathered during an isolated clinical encounter, but also a whole system of organizational concepts to ensure a secure exchange toward ubiquitous and instant delivery of the information required by each healthcare provider involved in a particular clinical process. Additionally, besides modelling the information handled during clinical encounters, clinicians must be involved in the definition of the UI specifications to guarantee a faithful representation of that information to the final users. In this way, there is no need of intermediaries to give a context and a purpose of use to the information modelled. Thus, the resulting UI models provide the flexibility required to reuse the same information depending on the specific purposes of clinicians at any given time (research, epidemiology, population health, health administration, best practice care testing, financing, healthcare procedure comparison, healthcare goal planning, etc.). The consequent methodology would provide a framework to ensure the continuity of care within patient-centered complex clinical processes such as chronic disease management, which require tight coordination of resources. Therefore, this article will guide the readers in the definition of an entire set of knowledge artefacts that comprise a model with the aforementioned properties: clinical concepts, archetypes, termsets, templates, clinical decision support rules (CDS), and UI specifications. Once the methodology is presented, the second step is to exemplify the application thereof. As a proof of concept, the DR screening service of the Health Service of Navarre (Servicio Navarro de Salud – Osasunbidea [SNS-O]) was analyzed. In fact, such service succeeded on using information and communication technologies to redistribute efficiently the workload resulting from DR screening [1]. However, the lack of normalization of the information inside the service made it difficult, if not impossible, extend this strategy to other healthcare facilities. Therefore, the authors of this article work toward a methodology to formalize the aforementioned clinical process so as to extend this experience to other DR screening services. This report is organized as follows: the methodology used to study an e-Ophthalmology-based clinical model and its implementation into the SNS-O is presented in Section 2; the results of the transcription of the clinical process into a standardized electronic model are described in Section 2.2.4; the discussion including the main challenges found during the modelling of this screening service is in Section 4; and the conclusions are presented in Section 4.3. 2. Materials and methods The methodology described in this section is based on common patterns identified in similar clinical knowledge modelling experiences found in the literature. Most publications studied focused on the archetypes, since the point of departure for the model was the dual-model layered architecture. First, the development and maintenance of archetypes were studied at the theoretical level [18–22]. The research then focused on identification of the common patterns in real healthcare scenarios in which archetypes were modelled [23–25]. Some publications have gone one step
114
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
beyond and considered including the use of standard terminology services to support the semantic interoperability among heterogeneous information systems [26–28]. Once the modelling of clinical concepts was normalized, the information registered during clinical encounters could be used to provide computerized decision support to clinicians. Thus, publications on computerization of clinical guidelines were analyzed to establish a normalized procedure for their integration into information systems for healthcare. Those guidelines are comprised of CDS rules that trigger a specific action or another, depending on the clinical reasoning reached. However, the conditions governing the guideline rules depend strongly on the context information registered in the information system; therefore, most guideline definitions found were patchwork solutions designed specifically to satisfy the requirements of particular implementations [29– 32]. Alternatively, Chen et al. presented the Guideline Definition Language (GDL) that leverages the archetype model with which different information systems compliant with dual-model architecture exchange guideline rules [33]. The implementations of CDS rules that use dual-model architecture are used to generate reminders, alerts, and recommendations to ease the work of clinicians. Nonetheless, this methodology aspired to integrate the workflow in the modelling strategy proposed. Therefore, state of the art workflow modelling was studied, but the use cases in the literature did not contemplated normalization of a workflow model integrated with information systems based on dual-model architecture knowledge [34,35]. Thus, the methodology proposed the use of GDL rules to determine the clinical pathways for patients on a care plan. Another stage not usually considered in other methodologies modelling clinical knowledge is the definition of UI specifications as part of the clinical process. In fact, standardization of the information fosters interoperability at different levels, whereas normalization of the way that information is presented to clinicians enables reusability of those data according to different uses intended in the healthcare service. An interesting article was that in which Palau et al. presented the UI templates as a solution to normalize the definition of a UI model [36]. 2.1. Methodology proposed to formalize clinical processes into information systems As a result of the literature research, the patterns identified in the experiences reviewed above were unified into a comprehensive methodology. That guaranteed a suitable level of quality to provide a model-driven framework that would ensure continuity of care in patient-centered clinical processes. Considering all this, the modelling strategy proposed is comprised of three main phases (Fig. 1): 2.1.1. Definition of the project In response to deficiencies detected in daily clinical practice for a particular healthcare scenario, a work team is convened to analyze available information resources and define requirements to redesign the clinical procedure accordingly. A.1. Detection of a need within a healthcare process: The process of modelling healthcare guidelines into standardized knowledge repositories begins when healthcare providers identify in their daily practice the absence of formally described domain knowledge specifications for a particular healthcare scenario. A.2. Establishment of a work team: When this occurs, a work team must be established, to determine the objectives and scope of the project initiated. Such work team is comprised of multidisciplinary experts, who assume different roles depending on their capabilities to cover broad viewpoints about the
healthcare scenario to be modelled. Thereby, experts in diverse clinical domains transcribe their knowledge into computerized models, specialists in the technical domain guarantee the compliance of technical standards covered by those models, and terminologists supply detailed terminologies and ontologies for the artefacts modelled. Each discussion team (the work team could be divided into smaller groups) designates a convener to lead the progress of the modelling process, registers the decisions reached by the group and determines the scope of the project. A.3. Analysis of resources: Then, the work team proposes a solution for the issue identified during clinical practice, but it must be supported by reliable sources of information (scientific literature, work experience, healthcare standards/guidelines) resulting from a comprehensive review of the state of the art. 2.1.2. Design of the clinical process It must satisfy the requirements of the project described previously. This clinical process is a combination of activities, decisions, and conditions that constitute the clinical pathways in the healthcare service. Those pathways are completed with the clinical concepts identified and then organized hierarchically according to the healthcare scenario chosen. B.1. Definition of the clinical process: The work team proposes a clinical process in conformance with the specifications defined during the previous phase of the modelling. That process constitutes the workflow between the stages corresponding to different clinical encounters a patient has to go through to receive continuous clinical care. So first of all, the overall clinical process is agreed in a set of healthcare activities, conditions and decisions that represent the pathways between clinical stages. In this regard, activity diagrams in UML provides a suitable way to represent that workflow [37]. To conclude this step, the work team defines a project report that specifies every clinical practice conducted inside each one of the clinical stages identified on that activity diagram. B.2. Study of clinical concepts: Every clinical concept of interest to the clinical service being modelled is listed in a table which is added to the project report to keep every domain expert up-to-date about which parameters have to be included in the modelling. B.3. Hierarchical organization of knowledge artefacts: Considering the specifications of the main archetype-based information systems, the knowledge artefacts are structured according to the hierarchy described in Fig. 2 [11,38,39]: – UI templates: Set of rules that determine how the knowledge artefacts modelled – defined by archetypes, templates, and bindings to standard terminologies – will be displayed to clinicians. – Workflow: The dynamic side of clinical care; the process that guides patient healthcare through the stages of the clinical process [40,41]. – CDS rules: These rules based on medical evidence or by consensus from domain experts, provide notification services to support clinicians toward best healthcare practices. CDS rules also can be used to manage other guidelines, e.g., alerts, unit conversion, and automatic filling out of data among archetypes. For now, the only rules defined here are those concerning the stages of patient flow through the clinical process [41]. – Stages and roles: Each stage is a clinical scene inside the healthcare process handled by personnel with specific capabilities (roles).
115
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
DEFINITION
DESIGN OF THE CLINICAL PROCESS
OF THE PROJECT
BUILDING THE ELECTRONIC MODEL
C.1 - CREATION AND UPDATE OF ARCHETYPES A.1 - DETECTION OF A NEED WITHIN A HEALTHCARE PROCESS
B.1 - DEFINITION OF THE CLINICAL PROCESS
A.2 - ESTABLISHMENT OF A WORK TEAM
B.3 - HIERARCHICAL ORGANIZATION OF KNOWLEDGE ARTEFACTS
A.3 - ANALYSIS OF RESOURCES
C.2 - DEFINITION OF SEMANTIC LINKS TO CLINICAL TERMINOLOGIES
B.2 - STUDY OF CLINICAL CONCEPTS
C.3 - BUILDING TEMPLATES C.4 - MODELLING GUIDELINE RULES AND WORKFLOW C.5 - MODELLING UI TEMPLATES
Fig. 1. Proposed methodology for building an electronic model of a clinical process.
WORKFLOW
CDS RULES
STAGES
COMPOSITIONS ROLES TEMPLATES
SECTIONS
ENTRY CLASS ARCHETYPES UI TEMPLATES OBSERVATION
INSTRUCTION
EVALUATION
ACTION TERMSETS
GROUPABLE ARCHETYPES CLUSTER or STRUCTURE
Fig. 2. Conceptual diagram of the overall hierarchy between the knowledge artefacts involved in model-based architecture.
– Templates: They constrain the concepts and terminology from the archetypes they contain to define a form in which clinicians register the results of clinical encounters [15]. – Compositions: They are the smallest units for data exchange between information systems. They include all clinical and administrative information of a clinical care session. As such, they must include meta-information to contextualize the healthcare session regardless of the EHR system. In this sense, when a contribution to a specific composition is filled out, it is signed by the responsible professional; hence compositions have the same medico-legal validity as paper clinical documents. The extra information in compositions guarantees the ACID characteristics of transactions: Atomicity, Consistency, Isolation, Durability, indelibility, modification, and traceability [40]. – Sections or organizational archetypes: They organize the information inside compositions for human readability. They usually are used to arrange archetypes, but they also can enclose templates [40].
– Entry type or descriptive archetypes: These define the semantics for the information to be recorded in the information system. Four categories are distinguished depending on their function in the iterative clinical problem-solving cycle used in medicine: observation, evaluation, instruction, and action [30,40]. – Groupable archetypes: Clusters and structures are used embedded in different entry type archetypes to reuse context information they have in common. 2.1.3. Building the electronic model Finally, the clinical process designed in the previous phase is formalized electronically using archetypes, templates, terminology bindings, CDS rules, and UI specifications. Most articles found on the literature are focused on specific implementations and models. However, our proposal considers a model-driven EHR architecture that leverages standardization to coordinate federated information systems toward a unique care plan. Thus, the methodology proposed yields diverse electronic models aimed at govern different aspects of healthcare.
116
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
2.2. Application of this methodology to model the DR screening service in the SNS-O As a proof of concept for this methodology, the DR screening service of the SNS-O was modelled. The outcomes of the resulting model are specified in the Results section. 2.2.1. Definition of the project The aim was to develop a specific archetype-based model that could automatically manage the information generated during follow-up of DR in patients with diabetes. Expert ophthalmologists along with specialists in information and communication technologies participated in a multidisciplinary discussion committee. Once the work team was established, different knowledge sources were reviewed (literature, work experience, healthcare standards/guidelines) to establish the clinical process to handle DR screening [4,42,43]. 2.2.2. Design of the clinical process The design of the clinical process proposed for the SNS-O comprises the following steps: B.1. Definition of the clinical process: The process regarding DR screening was defined according to the different stages a patient goes through in the healthcare service (Fig. 3). First, patients in a population at risk for DR are evaluated before they begin the follow-up. Then, if convenient, those patients are scheduled for periodic necessary diagnostic tests to detect existing DR, ensuring the quality of acquisitions for diagnostic purposes. GPs trained to detect symptoms of DR then remotely review images and information acquired during evaluations. Retina specialists reassess the cases positive for DR. Depending on disease severity, the specialists reach a therapeutic decision and schedule a clinical procedure accordingly. Finally, the corresponding treatment is administered depending on each patient’s specific diagnosis. Once the work team identified those different stages, they were analyzed in detail (Fig. 3). – STAGE 1 (Admission and follow-up schedule): A patient can be referred for follow-up of DR since diabetes was diagnosed by an endocrinologist or if there is suspicion of DR due to symptoms detected while evaluating another eye disease during an ophthalmologic consultation or a routine primary care examination. In that sense, the admission stage is used to gather relevant patient clinical information. That preliminary information will be useful during follow-up and to determine the convenience of including or not including the patient in the screening service. Thereafter, the follow-up of DR can start, and the diagnostic tests to detect and classify the disease can be scheduled. – STAGE 2 (Acquisition and validation of diagnostic tests): The diagnostic tests of SNS-O consist of non-mydriatic funduscopy and the measurement of intraocular pressure (IOP). Most healthcare organizations recommend repeating these tests at least once annually for patients with diabetes even in those without signs of DR. This prevents clinicians from overlooking serious symptoms of disease progression during the intermediary period between revisions [43]. The development of digital and interoperable diagnostic devices implemented in the SNS-O provides ubiquitous access from remote workstations to the results of the diagnostic tests. So, the results of these tests can be evaluated remotely [44]. This allows nurses or imaging
technicians (referred to as ‘‘imagers’’) to use those devices to perform diagnostic tests, whereas traditionally the presence of ophthalmologists was required during consultations [45]. At this point, the imagers must guarantee the quality of the acquisitions, so that the ophthalmologists can make reliable evaluations of those acquisitions. The measurement of corrected IOP involves tonometry and pachymetry. However, the results of those tests include a single IOP value, and registering this measurement is sufficient for later diagnostic purposes. Initially, the IOP measurement was not a component in the screening procedure for DR, but it later was included due to the epidemiologic interest in identifying early symptoms of other ophthalmic diseases associated with diabetes. In fact, measuring the IOP identifies patients with dangerous IOP levels (P22 mmHg), the point at which patients must be referred directly to the corresponding ophthalmologist, even if other tests do not show evidence of disease. However, validation of the funduscopic photographs is more complex since imagers must review the quality of each acquisition at the capture stage before referring them for assessment. The procedure chosen for that purpose involves classifying fundus images according to the overall photographic quality using a scale based on objective findings [6,46,47]. Different proposals have been reported when choosing a scale to measure quality; we used a scale ranging from 1 to 5, in which 1 indicates the worst and 5 indicates the best as Lamirel et al. proposed in the FOTO-ED study [46]. For diagnostic purposes, images of level 3 or lower that can confuse imagers are discarded. With unreadable images (62), the patient is referred immediately for a face-to-face ophthalmic consultation. When images of the ocular fundus are obtained, the numbers of retinal fields photographed vary depending on the purpose of the study. Considering the seven fields defined by the Early Treatment for Diabetic Retinopathy Study (ETDRS) [42,48], Vujosevic et al. suggested [49] that a central 45-degree color image is sufficient to determine the absence or presence of DR and diabetic macular edema (DME); however, a minimum of three fields is needed to classify the disease according to the international classification of DR proposed by the American Academy of Ophthalmology [50,51]. Nevertheless, according to clinical criteria, within the specific scenario of the SNS-O, two fields were considered adequate to manage the DR screening: one focused on the papilla and one focused on the macula. During acquisition, some artefacts can appear due to small pupils, cataracts, or other complications resulting from the capture. Therefore, acquisition is repeated when the image is inadequate for diagnostic purposes. To avoid extending this procedure unnecessarily, the test is limited to three attempts unless a technical issue is identified. From the fourth attempt on, the probability of obtaining a high-quality photograph is 20% at most [46]. In patients with a small pupil, the imager can request a mydriatic agent to obtain suitable retinal images; an ophthalmologist must supervise the drug instillation to reduce the risk of angle-closure glaucoma. For this reason, these patients must be referred directly for a face-to-face ophthalmic consultation.
117
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
STAGE 1: Patient admission and follow-up schedule
DIABETES MELLITUS DIAGNOSED OR SUSPICION OF DR
LEGEND:
NO
STAGE INTIAL STATE
DR SCREENING CONVENIENT FOR PATIENT
ACTION FINAL STATE DECISION
YES
STAGE 2: Acquisition and validation of diagnostic tests
NON MYDRIATIC FUNDUS PHOTOGRAPHY + INTRAOCULAR PRESSURE
SCHEDULE THE NEXT REVIEW IN A YEAR
QUALITY ASSESSMENT DURING ACQUISITION
IMAGES SUITABLE FOR DIAGNOSIS (QUALITY 4:5, 5:5)
IOP VALUE ≥ 22 mmHg
CONFUSING IMAGES (QUALITY 3:5)
UNREADABLE IMAGES (QUALITY 1:5, 2:5)
STAGE 3: DR screening WITHOUT RETINAL ALTERATIONS
REMOTE ASSESSMENT BY GENERAL PRACTITIONERS
ALTERATIONS WITHIN THE RETINA
STAGE 4: Disease classification and therapeutic decission
DIRECT OPHTHALMOSCOPY
ASSESSMENT BY OPHTHALMOLOGIST
WITHOUT RETINAL ALTERATIONS
CLASSIFICATION OF DR AND THERAPEUTIC DECISION
FOCAL DIABETIC MACULAR EDEMA
PROLIFERATIVE DIABETIC RETINOPATHY
STABLE DIABETIC RETINOPATHY
DIFFUSE DIABETIC MACULAR EDEMA
LASER
SURGERY
TREATMENT: INTRAVITREAL INJECTION
TREATMENT: INTRAVITREAL INJECTION
MACULAR LASER / PANRETINAL PHOTOCOAGULATION
VITRECTOMY
CORTICOIDS (Dexamethasone)
ANTIANGIOGENICS (Bevicizumab, Ranibizumab)
STAGE 5: Treatment
Fig. 3. Activity diagram showing the workflow of DR screening service in the SNS-O.
118
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
Once the necessary images for DR assessment are acquired and validated (quality level 4 or 5), they are sent to a Picture Archiving and Communication System (PACS) accessible to image reviewers. These acquisitions are labelled with the same study identification number, making it possible for a reviewer to retrieve every image corresponding to that specific diagnostic study. – STAGE 3 (DR screening): Image studies suitable for diagnosis are loaded from the PACS to remote workstations where image reviewers search for symptoms of DR. DR can be classified with different levels of precision, although for screening purposes it is sufficient to classify patients into two categories: those presenting with signs of DR and those without signs of DR (ETDRS value 620) [4]. There is a third option in case of uncertain images: the patient is referred to a specialist for review. To support this classification, it is recommended that the findings identified during the examination of the posterior chamber and the criteria chosen to reach a diagnostic decision be described. Given that most patients with diabetes do not present with symptoms of DR, this screening will markedly reduce the workload of ophthalmologists, since only retinopathies and uncertain studies need more specific assessment [52]. – STAGE 4 (Disease classification and therapeutic decision): The images in this stage must show signs of DR except for: false positives generated during screening, images that created uncertainty for GPs, or diagnostic test acquisitions without sufficient quality for remote screening [52]. Ophthalmologists then assess diagnostic tests, determine the best procedure to avoid disease progression, and review the different signs of DR found in diagnostic tests to identify the DR type. By reviewing the findings and diagnostic criteria registered during screening, the assessment can be accelerated. Even so, the final DR classification must be based on the criteria and findings of the ophthalmologists. Before reaching a therapeutic decision, the studies are classified using the International Clinical Diabetic Retinopathy and Macular Edema Disease Severity Scale proposed at the American Academy of Ophthalmology [50,51]. Therefore, according to the DR types, the studies can show proliferative or non-proliferative disease; the latter, depending on symptom severity, is classified as mild, moderate, or severe. Macular edema, if present, also can be classified as mild, moderate, or severe. Thereafter, different therapies will be chosen according to the severity and specific symptoms of DR (Fig. 3). – STAGE 5 (Treatment): Once the most suitable treatment is determined, the special features of the procedure being performed are documented. Intraocular injections, laser therapy, and surgery are the procedures considered in this model. Diffuse DME is treated by injection of antiangiogenic drugs, either bevacizumab (Avastin, Genentech Inc., South San Francisco, CA) or ranibizumab (Lucentis, Genentech Inc.); focal DME is treated by macular laser or panretinal photocoagulation; stable DR is treated with injection of corticoids (dexamethasone). In contrast, proliferative DR requires vitrectomy [43]. B.2. Study of Clinical Concepts: The clinical concepts involved in the clinical process of DR screening were determined according to the scenario described in previous step. The concepts considered relevant are listed in Table 1. However, given that archetypes are formal definitions of concepts from a clinical domain, their modelling involves
registering the clinical knowledge in a standardized and reusable manner [15]. According to this, before modelling every concept from scratch, the work team reviewed the archetypes available in the openEHR clinical knowledge manager (CKM) repository [53]. Three situations were identified: some archetypes perfectly fit the concepts consulted, so they were downloaded from the CKM and used directly in the model; other archetypes needed modifications to match the needs of the current model; and other concepts were new, so their archetypes were created from scratch (Table 1). B.3. Hierarchical Organization of Knowledge Artefacts: The design of archetypes for the healthcare scenario of DR screening did not begin until the discussion committee agreed to the overall screening service. To do so, the work team designed a diagram in which the hierarchical relationships between the concepts were defined according to the hierarchy described in Section 2.1.2 (Fig. 4). In this sense, collaborative diagramming tools were used to accelerate the transfer of knowledge from domain experts to a standardized healthcare model managed by archetypes [30,54,55]. 2.2.3. Building the electronic model Once the work team discussed the theoretical clinical process, similar modelling experiences documented in the literature were considered to transcribe the clinical knowledge of the SNS-O. Thus, archetypes and templates defined the information handled in the clinical process [23,24]. CDS rules also were created to support clinicians to take the decisions about guiding patients through the service [29,30,56]. Finally, UI specifications determined how all that information would be presented to clinicians. This procedure and its consequent models are further explained in the section corresponding to ‘‘Results’’. 2.2.4. Establishment of the interoperability framework To integrate the use of the electronic models defined along this article into the DR screening service from the SNS-O, every information system, diagnostic device, and workstation involved in the clinical process must be adapted beforehand so as to guarantee ubiquitous and instant access to the information registered. So that, the technical environment was analyzed to accordingly establish a framework based on standards. This clinical process involves three types of workspaces: one for diagnostic test acquisition, one for DR screening, and, one for DR assessment. The first contains the tonometry plus pachymetry instruments for IOP measurement, a non-mydriatic retinal camera, and a personal computer (PC) workstation to register findings identified during acquisitions. The second workspace is located in the workplace of the GPs; there, a PC workstation has access to the PACS and EHR to remotely visualize clinical images and register the consequent clinical reports. The third workspace is similar to the screening workstation but is in the consulting room of the ophthalmologist in the same building where diagnostic tests are performed. If a patient needs more extensive analysis, immediate face-to-face consultations are possible with retina specialists. To interconnect those workplaces, two independent but complementary standards coordinate the information among different devices and locations: the first, Digital Imaging and Communications in Medicine (DICOM), handles the interchange of imaging diagnostic test acquisitions as multimedia files. The second, openEHR, manages any health information registered during clinical evaluations. In this sense, medical imaging devices from the health service were connected under fulfilment of the DICOM standard. As in Section 2.2.2, diagnose of DR requires acquisition of fundus images. Retinal cameras involved in screening were connected through the corporative network to a PACS server that manages clinical images
119
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126 Table 1 Clinical concepts to be modelled as a result of study of each stage in the service of DR screening. Identified concept name
Class
Availability and suitability
Reason for encounter
Evaluation
Found on CKM Usable as is
Patient admission
Clinical synopsis
Evaluation
Found on CKM Usable as is
Patient admission, DR screening, DR assessment
Problem/diagnosis
Evaluation
Found on CKM Usable as is
Patient admission, DR screening, DR assessment
Diagnostic criteria DR
Cluster
Concept modelled from scratch
Examination findings – posterior chamber of eye
Cluster
Concept modelled from scratch
Story
Observation
Found on CKM Usable as is
Patient admission
Symptom
Cluster
Found on CKM Usable as is
Patient admission
DR screening convenient
Evaluation
Referral request
Instruction
Found on CKM Usable as is
Follow-up schedule, DR screening
Imaging examination request
Instruction
Found on CKM Usable as is
Follow-up schedule
Concept modelled from scratch
Concept modelled from scratch
Process stages in which it is applicable
Patient admission, DR screening, DR assessment Patient admission, DR screening, DR assessment
Patient admission
Acquisition details on eye fundus images
Cluster
Procedure undertaken
Action
Found on CKM Usable as is
Diagnostic tests, DR treatment
IOP measurement
Observation
Found on CKM It was adapted
Diagnostic tests
Device
Cluster
Found on CKM Usable as is
Diagnostic tests, DR screening, DR assessment
Device details
Cluster
Found on CKM Usable as is
Diagnostic tests, DR screening, DR assessment
Imaging examination
Action
Found on CKM Usable as is
Diagnostic tests
Anatomic location
Cluster
Found on CKM Usable as is
Diagnostic tests
Mydriasis application
Cluster
Medication amount
Cluster
Concept modelled from scratch
Examination details – eye fundus images
Cluster
Concept modelled from scratch
Diagnostic report request
Instruction
Concept modelled from scratch
Funduscopic examination of eyes
Observation
Found on CKM Usable as is
Found on CKM It was adapted Concept modelled from scratch
Follow-up schedule
Diagnostic tests Diagnostic tests, DR treatment Diagnostic tests, DR screening, DR assessment Diagnostic tests, DR screening DR screening, DR assessment
Classification of Diabetic Retinopathy
Cluster
Exclusion of a problem/diagnosis
Evaluation
Found on CKM Usable as is
DR screening, DR assessment
Recommendation
Evaluation
Found on CKM Usable as is
DR assessment
Medication order
Instruction
Found on CKM Usable as is
DR treatment
Medication action
Action
Found on CKM Usable as is
DR treatment
Medication administration
Cluster
Found on CKM Usable as is
DR treatment
Medication ingredients
Cluster
Found on CKM Usable as is
DR treatment
Procedure request
Instruction
Found on CKM Usable as is
DR treatment
Photocoagulation details
Cluster
Concept modelled from scratch
DR treatment
Ophthalmic surgery details – Posterior segment of eye
Cluster
Concept modelled from scratch
DR treatment
from the entire health service. This server is accessible from remote workstations where image viewing tools were installed in accordance with DICOM specifications (Fig. 5).
DR assessment
Concurrently, the PACS must be connected to an EHR compliant with openEHR standards, making it possible to manage the information originated as a result of the healthcare process.
120
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
SYMBOL LEGEND KNOWLEDGE DOMAIN
ARCHETYPE MODEL ENTRY CLASS ARCHETYPES
GROUPABLE ARCHETYPES
ARCHETYPE AVAILABILITY
COMPOSITION
WORKFLOW STAGE
SECTION
ROLE
TERMSET
OBSERVATION
INSTRUCTION
EVALUATION
ACTION
* GP: general practitioner
INSTRUCTION – ACTION COORDINATION
ARCHETYPE FROM CKM
CLUSTER or STRUCTURE
NEW ARCHETYPE
MODIFIED ARCHETYPE
** IOP: intraocular pressure
Encounter PATIENT ADMISSION
Patient's background
Reason for encounter Clinical synopsis
Primary care physician
Problem/diagnosis
Endocrinologist
Story DR screening convenient
No
Diagnostic criteria DR Examination findings – post. chamber of eye
Ophthalmologist
Patient’s admittance
Symptom
DR screening convenient
Yes
Referral FOLLOW-UP SCHEDULE
Diagnostic test planning
Referral request (IOP**) Imaging examination req.
Guideline rule engine
Imaging details – eye fundus
Zones of retina DR Study fields
Trained GP* Ophthalmologist
Progress note DIAGNOSTIC TESTS
Intraocular pressure study
Procedure undertaken IOP** measurement
Device
Imaging examination
Anatomic location
Zones of retina
IOP < 22 mmHg & Image quality ≥ 4:5
Mydriasis application (If necessary)
Mydriatic agents
Yes
Medication amount
Trained Nurse
Device details
Imaging technician Clinical image acquisition No
Examination details – eye fundus images Next step planning
Diagnostic report request
Report Funduscopic examination of eyes
Automated processing
Examination details – eye fundus images Examination findings – posterior chamber of eye
Trained GP*
Device
DR SCREENING
Image test analysis
Device details No
Alterations within the retina
Clinical decision
Clinical synopsis Problem/Diagnosis
Yes
Exclusion of a problem/Diagnosis
Clinical stage/grade – DR classification
Classification of DR for screening
Diagnostic criteria DR Examination findings – post. chamber of eye
Next step planning
Diagnostic report request Referral request
Report DR ASSESSMENT
Image test analysis
Funduscopic examination of eyes
Ophthalmologist
Examination details – eye fundus images Examination findings – posterior chamber of eye Device
No
Treatable retinopathy Yes
Device details Clinical decision
Clinical synopsis Problem/diagnosis
Clinical stage/grade – DR classification
Classification of DR
Exclusion of a problem/Diagnosis
Diagnostic criteria DR
Classification of macular retinal edema
Examination findings – post. chamber of eye Recommendation – DR treatment
Procedures on posterior segment of eye
Progress note Medication administration DR TREATMENT
Intraocular injection
Medication order Medication ingredients
Angiogenesis inhibitor subst.
Medication amount
Synthetic glucocorticoid subst.
Photocoagulation details
Photocoagulation procedure (panretinal, macular drusen...)
Medication action
Ophthalmologist
Laser
Procedure request Procedure undertaken
Surgical procedure
Procedure request
Laser device (dye, diode, gas)
Ophthalmic surgery details Posterior segment of eye
Operative procedures on posterior segment of eye
Procedure undertaken
Fig. 4. Hierarchy of information of the model for DR screening, according to archetype-based EHR systems.
121
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
Dual-model architecture EHR compliant with openEHR (DR screening)
Main EHR in the healthcare service
Archetype model
Healthcare data store
EHR Extract
Electronic referral notes
Electronic referral notes
PACS Server
DICOM images
DICOM images
Diagnostic test acquisition by nurse
DR screening by trained GP
DR evaluation by ophthalmologist
Clinical report
Clinical report
Clinical report
DICOM worklist
DICOM images
Legend DR: diabetic retinopathy GP: general practitioner
Fig. 5. Flux of information through the service for DR screening.
Healthcare information, such as diagnoses and measurements derived from clinical tests, will be registered in that EHR. However, most information systems available within current healthcare services do not yet support the openEHR standard. Consequently, a dedicated EHR server capable of interpreting openEHR archetypes must be setup to work in parallel with the main EHR server of the healthcare service. This EHR is exclusively responsible for managing the information generated during any clinical procedure corresponding to follow-up of DR. And as such, it also integrates any service resulting from the use of medical records concerning that clinical process, such as CDS, workflow management, and UI customization. In that respect, the clinical process has been completely modelled using archetypes, templates, CDS rules, and UI specifications; upon loading into the EHR system, all those provide the necessary tools to guide clinicians in efficient care practices. When necessary, this server will send EHR extracts with relevant healthcare results to the main information system of the health service, making that information reusable for other clinical processes. These extracts will be constructed in compliance with healthcare messaging standards, according to the different EHRs involved (Fig. 5). A primary advantage of the EHR based on archetypes is its flexibility, because it can load a model to manage the DR screening service and apply changes to it as necessary. There is no need to
introduce any changes in the main EHR system of the service, even if there are modifications in the clinical process. 3. Results This section provides the electronic models designed to manage the information generated by the DR screening service in the SNS-O. To that end, the same work team that defined the clinical process was convened to transcribe the resulting models into electronic health information systems. First, the concepts identified during the design of the clinical process were integrated into archetypes that could be used in any clinical scenario; then, those concepts in the archetypes were linked to standard terminologies. Once archetypes were available, they were enclosed and constrained in templates. Each template was designed according to the specifications of the clinical scenario in which it will be used. Then, the CDS rules aimed at manage the service workflow were defined in compliance with GDL. Finally, the archetypes, templates, CDS rules, and UI specifications were loaded into an EHR capable of interpreting them to test the model in a real-use case scenario. 3.1. Creation and update of archetypes Most required archetypes already existed in public clinical knowledge repositories, so they were used directly in the model. Nonetheless, based on experience with archetype creation in the
122
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
literature, the work team designed the following procedure to create/update archetypes [18–20,30]: Elicitation of content: The archetypes identified in the clinical process (Section 2.2.2) were dismantled into data elements. Once these elements were defined, data types were assigned to them according to the reference model from the openEHR standard. Each element then could be associated with equivalent clinical concepts defined in standardized terminologies (Section 3.2). Content organization: The structure of archetypes was defined by establishing connections among those concepts. Collaborative mind-mapping tools were used to optimize the contributions of different work team members [54]. Building archetypes: The clinical concepts already modelled at a theoretical level were written using the archetype definition language defined by openEHR, with the archetype editor of Ocean Informatics [57]. Publishing and validating the archetypes: Once archetypes were uploaded into the openEHR CKM, they must follow the authoring process defined by the standard. This process described different phases of the lifecycle of archetypes, which are based on peer review [20,58,59]. Theoretically, archetypes must be designed to be independent of the usage context. Nevertheless, our efforts focused especially on development of elements required in DR screening. Therefore, some archetypes from the CKM were reviewed and completed to match the requirements of the proposed clinical process. In the same way, it is expected that our uploaded archetypes will be completed by other users. For this reason, new archetypes and proposals for modification were uploaded to the CKM to be discussed worldwide among experts in healthcare modelling. This model will be in constant evolution depending on the progress of the methodology for the follow-up of DR. Consequently, extending this clinical process to other healthcare facilities and periodic updating of that model occur immediately. Each healthcare organization adopting these archetypes also will be interoperable worldwide.
3.2. Definition of semantic links to clinical terminologies This section was established simultaneously with the creation of archetypes and templates. First, the semantics of data elements were established for local use; at the same time, those data elements were bound to their equivalent terms defined in standardized terminology services.
Considering that most archetypes from the CKM were defined in English, they were translated into Spanish for use in the SNS-O. However, new archetypes were created directly in both languages to reach as many modellers as possible. In addition, because as many data elements as possible were linked to standard terminology services such as Systematized Nomenclature of Medicine Clinical Terms (SNOMED-CT) or International Statistical Classification of Diseases (ICD-10); even some references to equivalent concepts from technical standards like DICOM were included. In this way, these terms maintain the semantic meaning independently from the translation, since selected terminology services support multiple languages. Some elements identified during this process can adopt different values. Those values are bound to lists known as termsets, defined by standardized terminology services (Fig. 4). 3.3. Building templates Templates are local representations of the stages of the clinical process. Therefore, the archetypes were enclosed in the templates according to the hierarchy in Fig. 4. Because archetypes contain generic elements to support every use case, most elements were disabled at the template level to register only those data elements required for the healthcare service proposed within the SNS-O. Thus, a template was created using the template designer from Ocean Informatics [57] to constrain the archetypes contained in each section-type archetype (Fig. 4). New templates then were created to group those templates according to the composition archetypes containing them. 3.4. Modelling guideline rules and workflow Different rules were configured to handle the decisions about workflow. To define these rules, the GDL editor developed by Cambio Healthcare Systems was used because it makes use of the reference and archetype models from openEHR [60]. GDL language queries to an EHR the information registered by means of archetypes or templates, and it applies conditions and consequent actions accordingly, making it possible to trigger automatically real-time alerts or events for CDS when data are registered in the EHR. In this sense and based on the clinical guidelines defining the workflow, different CDS events were configured such that clinicians receive specific instructions about how to refer patients through the screening service. These rules identified in Fig. 4 are described below (Fig. 6). However, clinicians are free to handle the service manually as desired.
Fig. 6. CDS rules developed with the GDL rule editor.
A. Eguzkiza et al. / Journal of Biomedical Informatics 56 (2015) 112–126
DR screening convenience: The first encounter is used to check if the patient meets the criteria for inclusion in the screening process. This rule activates (or not) the archetypes involved in requesting the diagnostic tests necessary to start follow-up. Diagnostic tests valid for assessment: Once the diagnostic tests have been acquired, this rule discards any unusual value for the screening stage; in case of dangerously high IOP values (>22 mmHg) or low-quality fundus images (
