Semantic Interoperability for Health Network. Deliverable 4.2: Ontology / Information models covering the heart failure use case

Transcription

1 Semantic Interoperability for Health Network Deliverable 4.2: Ontology / Information models covering the heart failure use case [Version 1, June 22, 2013] Call: FP7-ICT Grant agreement for: Network of Excellence (NoE) Project acronym: SemanticHealthNet Project full title: Semantic Interoperability for Health Network Grant agreement no.: Budget: EURO Funding: EURO The SemanticHealthNet project is partially funded by the European Commission. Start: End: Website: Coordinators:

2 Document description Deliverable: D4.2 Publishable summary: SemanticHealthNet faces the challenge of improving semantic interoperability of clinical information. It does not propose a new standard. Instead, SemanticHealthNet attempts to formally describe the current interplay between information structures and clinical vocabularies by introducing a semantic layer that addresses most facets of the complex meaning of components of the electronic health record. To this end, WP4 proposes an engineering approach based on formal ontologies, description logics and Semantic Web standards. It addresses the need to precisely describe what information entities in the EHR are, which they are about, and which attributes they have. The connection between instances of information entities and the representational units from medical ontologies, in particular SNOMED CT, they are bound to, are in the centre of the model being proposed. This deliverable discusses and provides examples for the feasibility of the approach by creating representational artefacts that address the heart failure use case, as the main clinical use case in SemanticHealthNet. An initial version of a Heart Failure Summary had been elaborated by the clinical workpackage WP1, with the intention to be used as a basic representation of most of the significant information required to effectively treat the heart failure disease. Although still provisional this summary represents a good mixture of different kinds of clinical data (e.g. medical history, lab test results, medication administration, diagnosis, symptoms, physical examination results, etc. This deliverable exposes, describes and justifies a set of ontology patterns that cover the representation of the information items represented by the Heart Failure Summary. The patterns have been designed in a bottom-up approach. They should evolve, in a later stage of the project, into a usable toolkit of patterns, metapatterns and pattern components. They are supposed to test what we called the hard core tasks of semantic interoperability in a clinical documentation context, viz. (i) the detection of iso-semantic expressions (e.g. structurally heterogeneous clinical models, pre/post-coordinated terminology terms) and (ii) homogeneous queries of iso-semantic clinical information from heterogeneous models. The result as reported in this document should be considered as work in progress, which is iteratively being optimized and completed in cooperation with clinicians and representatives of semantic standards. Several issues are still open and are critical factors for the success of the approach, such as performance, scalability, consensus in the modelling, building and maintenance of the patterns, etc. Although some initial tests have been done in preparation of this deliverable, in order to evaluate that the patterns satisfy the information retrieval need of clinicians, they must be further evaluated by means of a concrete test implementation. Status: Version: Public: No x Yes Deadline: Contact: Catalina Martínez-Costa catalina.martinez@medunigraz.at Editors: Stefan Schulz Catalina Martínez-Costa, Stefan Schulz stefan.schulz@medunigraz.at D4.2 Ontology / Information models covering the heart failure use case Page 2 of 62

3 Table of contents Table of contents Introduction and objectives Background Objectives Heart Failure (HF) The disease The Heart Failure Summary (HFS) Methodology and General Principles Modelling the Heart Failure Summary (HFS) Presentation and symptoms Reason for Encounter Medical history Symptoms Physical exam Body weight Height Blood pressure Oedema Transcutaneous oxygen saturation Pathology test result (Blood count) Electrocardiography (ECG) Echocardiography Lung function Invasive investigation Coronary angiography Assessment Final diagnosis Plan Goals Goal I. Reduce risk of hospitalization Target systolic blood pressure Target resting heart rate Target dry weight D4.2 Ontology / Information models covering the heart failure use case Page 3 of 62

4 3.8.3 Goal II. Symptom control NYHA Class Goal III. Control diabetes Target HBA1C Requests Laboratory test request Healthcare service request Recommended Medication Medication order Competency questions Overview of patterns Final remarks What we have reached What is difficult Success factors Expected use of the document and way forward Annex I: Use Case 2 (data abstraction for querying) Comments on Use case Annex II: Value sets D4.2 Ontology / Information models covering the heart failure use case Page 4 of 62

5 1 Introduction and objectives 1.1 Background Semantic interoperability (SIOp) of clinical information is the main objective addressed by the SemanticHealthNet (SHN) Network of Excellence, which proposes to develop a scalable and sustainable organisational and governance process to achieve this objective across healthcare systems and institutions. One important aspect is the development of a formal framework to support interoperability, which is compliant with current semantic artefacts, such as clinical vocabularies and information models. The clinical focus is set on chronic heart failure and cardiovascular prevention, which drives the development of semantic resources by the workpackage WP4. The deliverable D4.1 (Initial models covering the heart failure use case) reports on how the semantic equivalence of clinical information could be ascertained by general principles and guidelines to properly identifying which things have to be represented by information models (mainly openehr, EN13606 and HL7) and which by ontologies (mainly SNOMED CT), in order to represent clinical information in an unambiguous way. SHN's mission is not proposing a new standard but trying to formally describe the current interplay between information structures and clinical vocabularies. This is done by developing a semantic layer that represents and normalizes a significant amount of the complex, partly hidden, partly explicit meaning electronic health record (EHR) components. This is done by a formal ontological framework based on description logics and Semantic Web standards, rooted in the upper-level ontology BioTopLite, which provides basic types, relations (object properties), and constraints for the foundational entities of biomedicine. BioTopLite is currently undergoing a thorough redesign. The examples shown in this document still use the first version. An adaption to BioTopLite2 is planned, but this will not affect fundamentally our representational choices. For this stage of the project (2 nd project year) an initial version of a Heart Failure Summary (HFS) has been elaborated by the clinical workpackage WP1 (see Deliverable 1.2). This summary, consisting of clinical history, findings, diagnoses and procedures, is still provisional, but it represents a good mixture of different kinds of clinical data. Its use as a testbed of the SHN semantic interoperability framework should therefore give a good insight into the feasibility of this approach. The result as reported in this document should be considered as a draft in progress, which is iteratively being optimized and completed in cooperation with clinicians and representatives of semantic standards. However, the current version already addresses the relevant representational challenges, and the process undertaken so far has clearly pinpointed crucial bottlenecks in the translation of (often implicit and fuzzy) clinical operational knowledge and routines into computational models. The models created during the first project year had been focused on the aspects of diagnostic statements and were mainly intended as easy-to-understand exemplars (deliverable 4.1). In this second deliverable, we go a step further and extend the semantic interoperability approach to a realworld use case. It intends to be used as a minimal representation of most of the significant information required to effectively treat the heart failure disease. Input from clinicians (WP1) had helped to define the clinical items that constitute the summary and to elicit the meaning of data elements. Firstly we had received some documents that helped us to D4.2 Ontology / Information models covering the heart failure use case Page 5 of 62

6 start with the HFS modelling. In a face-to-face meeting of WP1 and WP4 together with external experts some relevant modelling issues were clarified and the scope and tasks to be accomplished were delineated to be reflected in this deliverable. 1.2 Objectives The goal of this joint package 1 and 4 activity is to produce a set of good quality representations for a HF shared care summary. These representations should be ontologically founded, computationally sound and scalable, but also relevant and understandable by clinicians. Although representations are focused on heart failure, most of them should also be applicable to other medical use cases. This will be the subject of study in subsequent deliverables and will determine the feasibility of the approach. The modelling solutions provided in this deliverable by a bottom-up approach should also serve as an example to test the methodology proposed, but they should evolve, in a later stage of the project, into a usable set of patterns and meta-patterns. The depth of the semantic robustness of the patterns needs to be proportionate to the needs of clinical practice. The key of the HFS is a formal, unambiguous representation of all meaningful elements, from headings over attributes and values. The bottleneck is that this requires in-depth knowledge and experience in a formal language (in our case OWL), hardly understandable by clinicians. This gap of understanding needs to be bridged by the provision of free text renderings of the logical expressions. Therefore, in the subsequent sections we analyse each HFS component by providing both, a natural language (NL) description of what we intend to represent and its corresponding logical representation in OWL. In this deliverable we will focus on two main use cases we consider the hard core tasks in order to achieve semantic interoperability of clinical information (see use case two data abstraction for querying - in deliverable 4.1 and Annex I): Detection of iso-semantic expressions (e.g. structurally heterogeneous clinical models, pre/post-coordinated terminology terms) Homogeneous query of iso-semantic clinical information from heterogeneous models Other use cases such as (i) management of clinical models, (ii) data entry validation, (iii) clinical model definition correctness and (iv) clinical model transformation (e.g. from openehr to HL7 CDA) are out of the scope of this deliverable. Finally we will provide a list with some examples of queries, which demonstrate how clinical information represented by following the provided patterns, can be retrieved. 1.3 Heart Failure (HF) The disease Heart failure (HF) 1, often called congestive heart failure (CHF), occurs when the heart is unable to provide sufficient pump action to maintain blood flow to meet the needs of the body. Heart failure can cause a number of symptoms including shortness of breath, leg swelling and exercise 1 Wikipedia heart failure: D4.2 Ontology / Information models covering the heart failure use case Page 6 of 62

7 intolerance. The condition is diagnosed by patient physical examination and confirmed with echocardiography. Blood tests help to determine the cause. Treatment depends on the severity and the cause of the heart failure. In a chronic patient already in a stable situation, treatment commonly consists of lifestyle measures such as smoking cessation, light exercise, dietary changes and medications. Sometimes, depending on aetiology, it is treated with implanted devices (pacemakers or ventricular assist devices) and in very severe cases a heart transplant is required. Common causes of heart failure include myocardial infarction and other forms of ischemic heart disease, hypertension, valvular heart disease and cardiomyopathy. Although the prevalence is often quoted as about 1% of the population, much depends on case definition and ascertainment and whether it describes the whole population (from birth to death) or just a segment of it (e.g.: people years old). Long-term studies suggest that about one in five people will develop HF before they die. The pragmatic definition of heart failure (HF) in common use is: Typical HF symptoms and signs (e.g. breathlessness limiting a normal amount of exertion) Evidence of structural heart disease (usually diagnosed by echocardiography, which, however can be surprisingly subtle and the test requires a highly skilled operator) Expected response to appropriate treatment (particular an improvement in symptoms with diuretics) Increases in plasma concentrations of natriuretic peptides. Normal values indicate either that the patient does not have a heart problem or that the treatment has been highly effective. Increased levels may be due to heart problems but can also be due to kidney problems. The test does not provide information about the nature of the heart problem but gives an idea of how serious it is. 1.4 The Heart Failure Summary (HFS) HF management is complex due to the number of treatments and the existence of older patients with comorbidities. From a data management point of view this constitutes a challenge regarding fact and document retrieval, especially the identification of omissions in care (e.g. which test or treatment should the patient have, which has been forgotten), or duplication (e.g. test result not found and therefore repeated). In current EHR systems time is wasted to ensure that key tests and actions have been done. Moreover, HF management increasingly focuses on multi-disciplinary teams (e.g. family doctor, cardiologist, HF specialist nurse, geriatrician / internist, emergency physician, rehabilitation services, pharmacist, etc.) and such teams require a commonly accessible record to deliver effective and efficient care. Sometimes, important information is missed because someone thought that someone else had done the test or taken that action. Given the above, a comprehensive, readily accessible, and semantically interoperable shared record is essential for HF diagnosis and care, and it is the focus of this deliverable. D4.2 Ontology / Information models covering the heart failure use case Page 7 of 62

8 The heart failure summary presented in this document is conceived as a minimal dataset that contains essential information to be shared across sectors and disciplines in order to optimize HF management. It has been elaborated by WP1 and a more detailed description of its data items can be found in deliverable 1.2. Here, we focus on its modelling, first by using the EHR specification (OpenEHR), and later providing representational patterns for the information items described. As said, the HFS has been modelled by using an OpenEHR template, specifically developed for this deliverable. It can be found in the project tab of the OpenEHR Clinical Knowledge Manager (CKM) 2 tool, under the name EU-SHN Heart Failure Summary. This template uses a subset of OpenEHR archetypes, where textual descriptions for each of the information items included are provided. Figure 1-1 depicts the main structure of the template. Figure 1-1 Main structure of the OpenEHR Heart Failure Summary Each of the sections shown in the above figure can be decomposed in subsections and they will be described through the present document. Sometimes, the representation of the HFS provided differs slightly from the source of clinical information and this is mainly due to the use of existing clinical archetypes from the openehr archetype repository. Our challenge is to provide an initial set of representational patterns that are able to cover this use case. The main purpose of using them is to make explicit the semantic of the information represented in clinical models, in a way that can be interpreted by computers independently of the degree of granularity in which it has been provided. These patterns are based on a formal ontological framework based on description logics and Semantic Web standards. Since they are based on formal ontological principles, this should avoid bad modelling practices. Their representation in OWL will allow their automatic interpretation by computers. 2 D4.2 Ontology / Information models covering the heart failure use case Page 8 of 62

9 Along this deliverable, we will show some pieces of the information of a fictitious patient, represented according to the patterns proposed. The fictitious patient is a 68 years old woman, recovered from admission for worsening heart failure and treated at the cardiology unit at the hospital. Figure 1-2 depicts an excerpt of the clinical information recorded in her EHR. A) Minimum Data Set (Fixed) Aetiology:- CAD MI?: Yes: Anterior 2005 Co-morbidity: Type 2 Diabetes, Arthritis Height: 160cm B) Minimum Data Set (Most Recent & Date) MI?: Yes: Anterior 2005 Co-morbidity: eg:- Type 2 Diabetes, Arthritis Device: No (if yes, drop down of ICD, PM or CRT) LVEF: 32% Heart rhythm: sinus PR interval: 210msec QRS duration: 110msec Mitral regurgitation: moderate Other important valve disease: no FEV1: 2.1 (83% of predicted) FEV1/FVC: 75% Haemoglobin: 10.8g/dL Haematinic screen: iron deficiency HbA1c: 6.9% Sodium: 138mmol/L Potassium: 4.0mmol/L Urea: 11.5mmol/L Creatinine: 137umol/L Albumin: 44g/dL Discharged on Carvedilol 3.125mg bd Ramipril 2.5mg bd Spironolactone 25mg/day Bumetanide 1mg/day Nicorandil 10mg bd Aspirin 75mg/day Metformin 500mg bd Paracetamol Lansoprazole 30mg/day Targets Carvedilol 25mg bd Ramipril 5mg bd Spironolactone 25mg/day Ferrous sulphate stop in 3m Exercise for 10 min x 3/wk Resting heart rate <70bpm Systolic BP <130mmHg Weight 68.0kg Potassium mmol/L Creatinine <150umol/L (Symptom Control) C) Trend Data (Routine Daily Measures if home monitoring; clinic otherwise) Orthopnoea: No Exertional Breathlessness: Moderate Ankle Swelling: No Well-being: Good Heart rate: 101bpm Systolic BP: 154mmHg Diastolic BP: 102mmHg Weight: 69.8kg (BMI calculated ) o Target Dry Weight: 68.0kg Figure 1-2 Excerpt of the heart failure related clinical data of a fictitious patient The data items in bold in panel C represent priority items while in panel B represent items detected by sensors like ECG machines etc. We can find a broad range of clinical data: past history, clinical test results, symptoms, medication administration, target measurements, physical examination results, etc. D4.2 Ontology / Information models covering the heart failure use case Page 9 of 62

10 2 Methodology and General Principles In our first deliverable (Del. 4.1), we outlined the shared logical framework in which our approach is based on. In this section, in order to contribute to a better understanding of the semantic patterns presented, since they are based on that ontological infrastructure, we will provide a quick overview of the main ontology classes used. These classes mainly belong to the top-level ontology BioTopLite, and some additional ones have been added as subclasses. Figure 2-1 depicts a graphical representation of a simplified version of the ontology. The different colours represent the different nature of the entities described (e.g. information object, material object, process, quality, time, etc.). Informa on Object Material Object is-a is-a is-a has-par cipant some Datatype denoted-by some is-about some Informa on Item Plan Process has-realiza on only is-a outcome-of some Clinical Process is-a Value Region is-aboutsitua on only Clinical Situa on is-aboutquality only quality-located only Quality is-a is-a has-process-quality some temporally-related-to some Object Quality Process Quality TIme Figure 2-1 Graphical representation of a simplified view of the ontology used for defining the patterns Following we provide a textual description for each of the classes depicted in the ontology model. Information Object: Piece of information (not necessarily human), as it exists independently of any potential material carrier. Under this class we will place all the information entities used by our patterns. Information Item: A piece of information outcome of some clinical process. For example, a diagnosis, a laboratory result, a physical examination result, a symptom record, etc. Datatype: Information object that represents a type of data (e.g. textual, integer, boolean, etc.). Plan: A plan is am information object that describes a series of steps to be carried out in order to achieve a goal. Plans can only be realized by processes. For instance the plan to reach a patient target weight of 60 kg within two months. D4.2 Ontology / Information models covering the heart failure use case Page 10 of 62

11 Material Object: A material object has exactly one mass and one volume at a time. Material objects may have immaterial parts (e.g. Heart and Heart Ventricle). A person or any of its body parts are material objects. Process: Process is the generic subsumer of anything that "occurs". Processes can span across time and have temporal parts. Clinical Process: A kind of process related with the clinical domain. SNOMED CT concepts from the procedure hierarchy will be mostly represented as subclasses of this top-level concept. Examples of processes are diagnostic procedure, physical examination procedure, etc. Clinical Situation: A phase of a patient s life during which a certain condition of interest (structure, disposition, process) exists during all time. Quality: A quality is a dependent entity that is exhibited if it inheres in some other entity or entities at all. Object Quality: quality that inheres in an object. For instance the height or weight of a person. Process Quality: quality that inheres in a process. For instance the severity of some patient situation as the heart failure disease interpreted as a clinical situation. Value Region: A value region is an abstract region in which (non quantitative) values of qualities are located. For instance all the possible severity values for the heart failure disease. Time: Point or interval on the time axis. For instance, when some clinical test starts or ends, the duration of a clinical situation, etc. As proposed in the work plan and tested in the first project year, the ontology language OWL-DL will be used for representing both, the clinical context and information entities (describing the information in the electronic health record). For our purpose both worlds are kept strictly disjoint, according to the upper level constraints required by BioTopLite, in which the class Information Entity is disjoint with all siblings. It should be highlighted here that OWL DL does not provide special support for temporal reasoning. However we have represented temporal entities as datatype properties. Nevertheless all references to time in this document and the examples and should be regarded as tentative and subject to further modification. Along the document, we walk through each of the sections of the heart failure summary and we provide: (1) a brief introduction of the clinical content being represented; (2) the pattern proposed; (3) a natural language description of what the pattern is representing and (4) a screenshot of the graphical view of the openehr HFS template. The graphical view provided by the openehr HFS template, has only the purpose of facilitating the reader, the understanding of the kind of clinical information being modelled. The OWL DL patterns proposed do not cover aspects of information presentation such as order or indentation. D4.2 Ontology / Information models covering the heart failure use case Page 11 of 62

12 For some patterns, we also provide an example of its instantiation with clinical data of the fictitious patient shown in Section 1.4. Finally, patterns are described in OWL (Manchester syntax) and the following namespace prefixes are used: shn: SemanticHealthNet Ontology, as being modelled in SHN. It represents the bits and pieces of clinical information models. sct: SNOMED CT 3, as the clinical ontology chosen for SemanticHealthNet. btl: BioTopLite 4, providing general classes, relations (object properties), and constraints for the SemanticHealthNet ontology. Symbols ending with a capital letter (e.g. shn:clinicalprocessx) and in blue, are variables, i.e. they represent any subclass of the referred class (in this example a subclass of shn:clinicalprocess). Furthermore, as a terminological convention, we follow the OWL standard using the terms class and object property. Classes in SNOMED CT are referred to as "SNOMED CT concepts". Nevertheless we consider SNOMED CT concepts as classes. The ontology engineering approach pursued in SHN addresses the need to precisely describe information entities in the EHR and their logical connection with DL expressions which are made up of representational units from medical ontologies, here SNOMED CT. This corresponds to what had been called term binding 5. Representing information has to address the phenomenon that a piece of information in a patient record "about X" (like, e.g., the SNOMED CT concept Left heart failure ( )), with regards to a patient does not necessarily imply that the class X is instantiated in this patient, i.e. that the patient does have heart failure. Speculative, hypothetical, and negative statements, as well as contradictory assertions are characteristic for medical discourse and reasoning. Even though, clear entailments can be made, e.g. that "suspicion of left heart failure" implies "suspicion of heart failure", or "no allergy" implies "no food allergy". The need of binding representational units in terminologies, such as SNOMED CT concepts, directly to information instances would, ideally, be achieved by a second-order expressivity, which, however is not supported by the representational language used, based on description logics, which is a decidable subset of first-order logics. In order to circumvent this problem, several approaches are currently being discussed. The modelling pattern as used in the forthcoming examples is just one of these, which has proved pragmatically useful in the models created for D4.1. It can be summarized as follows: Qamar R, Kola J, Rector AL.Unambiguous data modeling to ensure higher accuracy term binding to clinical terminologies. AMIA Annu Symp Proc Oct 11: D4.2 Ontology / Information models covering the heart failure use case Page 12 of 62

13 with and For instance: shn:atomicinformationitemx subclassof isabout_t only sct:x and. sct:x subclassof btl:t shn:atomicinformationitemx subclassof btl:informationobject shn:heartfailurediagnosis subclassof isaboutsituation only sct:heartfailure sct:heartfailure subclassof btl:situation shn:heartfailurediagnosis subclassof btl:informationobject This expression tells that if a heart failure diagnosis is about some clinical situation then this clinical situation is of the type heart failure situation. It does not require that for each diagnosis some clinical entity exists (only instances of information entities will be created). Thus, it permits reference to codes without claiming existence. There are other options, such as instead of using the universal restriction constructor only, using OWL Full expressiveness for linking information to clinical classes by punning. Punning allows for using the same identifier, e.g., for an individual and a class. The class and its corresponding individual are, however, treated as entirely independent. This would be modelled as follows: shn:atomicinformationitemx subclassof isabout_t value sct:x It means that sct:x will be both a class and an individual. The problem here is that the semantics lies outside description logics and punning is ignored by description logics reasoners (which treat the pun as two separate entities). A third approach would be to consider the representational target as a literal, which represents a query. This query obeys the syntactic rules of, e.g. SPARQL. and shn:atomicinformationitemx subclassof isabout_t value Q Q equivalentto "SELECT X, WHERE X subclassof sct:heartfailure In the following examples we follow the first approach, as it appears to best address the reasoning use cases and at the moment we have not found any limitation. Anyway, prospects and limitations, as well as the scalability of the different approaches are currently under scrutiny. Finally, clinical models often include space for narratives, such as comments or refinements. As these texts are written by humans they will not be considered in our model, as natural language processing and text mining are not inside the scope of SemanticHealthNet. Nevertheless, we are aware that large parts of clinical information are exclusively available as free texts. The extraction of information from natural language into pre-existing information models has been subject of research by the text mining and natural language processing communities. Using the SHN approach for semantic interpretation of text-mined clinical content might constitute an interesting spin-off activity for SHN in the future. D4.2 Ontology / Information models covering the heart failure use case Page 13 of 62

14 3 Modelling the Heart Failure Summary (HFS) 3.1 Presentation and symptoms Reason for Encounter Reason of encounter records the reason why the person was attended. As information needed for each contact between a person and a health care actor or institution, this reason can be administrative (Nature of Contact) or clinical (Presenting Problem). It can be reported by the patient, clinician, family member, etc. (several possible providers of information). It can be free or coded text. The distinction between administrative and clinical reason of encounter is the following, according to the authors of the underlying information model: Administrative reasons are routine antenatal visit or pre-operative assessment, i.e. they are motivated by a plan to be executed. Clinical reasons of encounter, are problems, i.e. symptoms, signs, known diseases, lifestyle issues like smoking cessation, diet, etc., shortly, all conditions of a person that motivate them to seek medical advice. Graphical representation: OWL DL representation: Whether their values are free text or are encoded, for retrieval purposes it is necessary to provide a standardized representation for the reason for encounter heading. We have defined a clinical encounter as a process in which participate at least a clinician and a patient: shn:clinicalencounter subclassof btl:process and btl:hasparticipant some shn:clinician and btl:hasparticipant some shn:patient A clinician and a patient are defined in the ontology as human organisms that are bearer of some patient / clinician role. Clinicians distinguish between administrative and clinical reason for encounter. The first is an encounter with a specific goal; the second one is due to a specific problem. Both are subclasses of reason for encounter, which has been defined as some information item result of some kind of clinically related process and that is causally related with the clinical encounter: shn:reasonofencounter subclassof shn:informationitem and btl:outcomeof some shn:clinicalprocess and btl:causallyrelatedto some shn:clinicalencounter An administrative reason for encounter corresponds to some information about a plan that should be realized during some future clinical process. We have modelled it as (R1): D4.2 Ontology / Information models covering the heart failure use case Page 14 of 62

15 shn:administrativereasonofencounter equivalentto shn:reasonofencounter and shn:isabout only (shn:plan and btl:hasrealization only shn:clinicalprocessp) (R1) On the other hand, a clinical reason of encounter is that a patient has some problem. What problems are is difficult to define. We interpret problems as Clinical situations including clinical conditions. These conditions are not necessarily pathologic. A clinical situation is a segment of a person's life in which something of clinical relevance is present or on-going. Therefore, the following OWL DL pattern (R2) will be used: shn:clinicalreasonofencounter equivalentto shn:reasonofencounter and shn:isaboutsituation only shn:clinicalsituations (R2) In blue the variable part of the patterns represent the administrative / clinical reason Medical history Primary diagnosis According to the Ontology of General medical Science, OGMS 6, a diagnosis is the representation of a conclusion of a diagnostic process. Strictly there is a difference between diagnosis in this sense (which also exists when it is not recorded) and a diagnosis record, as a part of a medical record. This is here meant by diagnosis. In this part of the heart care summary, diagnosis corresponds to a working diagnosis on admission. It is fundamental to distinguish between disease (disorder) and diagnosis. Diseases are objectively present in the patient, whereas diagnoses are pieces of information (first in the mind of the clinician, then in the EHR). Our model has to comply with real world scenarios in which a diagnosis may be speculative or even wrong, or in which two clinicians make contradicting diagnostic statements about the same patient. We define a diagnosis as a statement with a given certainty (e.g. hypothetic, confirmed ) which is the outcome of some diagnosing process (in the openehr representation described as evolution value, e.g. initial assessment). Its interpretation is based on some source of evidence (e.g. a clinical guideline or other published information). We would extend here the meaning of evidence also to clinical experience or intuition influencing a medical decision. The diagnosis is about a real or fictitious clinical situation which is supposed to have started at some point in time and be caused by some other situation. 6 D4.2 Ontology / Information models covering the heart failure use case Page 15 of 62

16 Graphical representation: OWL DL representation: We have defined a diagnosis record as the information result of a diagnosing process. shn:diagnosisrecord equivalentto shn:informationitem and btl:outcomeof some shn:diagnosticprocedured We can identify a very general OWL DL pattern (D1) diagnosis: shn:diagnosisrecord subclassof (D1) shn:informationitem and and shn:hasinformationobjectattribute some shn:certaintyattributec and btl:outcomeof some shn:diagnosticprocedured and btl:outcomeof some (shn:interpreting and btl:hasparticipant some shn:evidencee) and shn:isaboutsituation only (shn:clinicalsituationx and and btl:temporallyrelatedto some shn:timet and btl:causedby some shn:clinicalsituationxy) The above pattern represents a diagnosis as information resulting of a diagnosing process, that may have some certainty (e.g. suspected), some source of evidence (e.g. a public web link or guideline) and that refers to a clinical situation of a patient. The last clause in the pattern, relates to the aetiology of the disease (clinical situation), required by the clinical model. Under closer scrutiny this way of referring to a cause is problematic, because if left blank there is an ambiguity in the sense that it could be interpreted (i) that the disease is primary (idiopathic), i.e. it has no cause, or (ii) that the cause is unknown. This example also shows, how these representational patterns may need to be extended very individually, according to clinicians documentation needs and the kind of terminology used (pre- vs. post-coordination). In this case for instance, we would need two patterns, one with the cause and another one without it, but this would increase the number of possible patterns. A better solution could be to study how to modularize them, creating for instance a primitive pattern for a clinical situation in which this is related with its cause, the time it occurred, participants, etc. In the future SHN will investigate approaches to further modularize semantic patterns. The granularity of the pattern will depend on the completeness of the data in the model. Especially in case the model allows for missing data, we have to further investigate how this may impact on the underlying pattern. However, the way how to deal with missing information and how to interpret them ( null flavours ) is, first of all to be solved by the designer of the clinical model. D4.2 Ontology / Information models covering the heart failure use case Page 16 of 62

17 Although not required by the current version of the heart failure summary, there may be additional information object attributes, e.g. provenance of information (e.g. reported by subject of record, family member, family practitioner etc.). Another issue is how to represent vague points in time like last year, about 25 years ago, etc. At the moment the only way of specifying this kind of information is by means of the relation btl:temporallyrelatedto, which can be further specialised and that in this case relates a clinical situation with a temporal entity. This temporal entity can be a point in time or an interval. Therefore, in order to express the meaning of "25 years ago", the only way would be that the time entity would represent a point in time, e.g., the 20 th of June of 1988, seen from now. Relative time references should be avoided. The class PrimaryDiagnosis is a primitive subclass of Diagnosis. shn:primarydiagnosisrecord subclassof shn:diagnosisrecord We leave open whether to introduce distinguishing criteria, as a clear definition of primary diagnosis is difficult to achieve. One possibility would be to define it as: shn:primarydiagnosisrecord subclassof shn:diagnosisrecord and shn:hasinformationobjectattribute some shn:primary Therefore, our 68 old patient, presents a heart failure primary diagnosis, that expressed in OWL DL according to the pattern proposed above, would be represented as: Individual: PrimaryDiagnosis_Patient06 Types: shn:primarydiagnosisrecord and shn:isaboutsituation only sct:heartfailure This shows a major principle of the SHN approach. Information entities are instantiated, whereas clinical entities are only referred to indirectly, as a reference to a terminology class, from which no existence of the clinical entity can be inferred Co-morbidity Co-morbidities are clinical conditions that are present in a patient (i.e. clinical situations) but not necessarily related to the main diagnosis. Which condition is regarded as a main problem and which one as a co-morbidity is a matter of perspective and dependent on the plan to be executed. If a patient has HF and a hip fracture, the latter would be a co-morbidity for the cardiologist, whether the former would be a co-morbidity for the surgeon. This context is only expressed by the choice of the type on information entity. The form used to capture the data is very similar to the previous one, for the primary diagnosis. It provides fields for recording the co-morbidity, its onset and the supporting clinical evidence. D4.2 Ontology / Information models covering the heart failure use case Page 17 of 62

18 Graphical representation: OWL DL representation: CoMorbidityRecord is introduced as a subclass of DiagnosisRecord and follows the same pattern (D1). shn:comorbidityrecord subclassof shn:diagnosisrecord Therefore, our 68 old patient, presents arthritis and diabetes as co-morbidites of the heart failure main diagnosis, expressed in OWL according to the pattern proposed above as: Individual: Comorbidity_Arthritis_Patient06 Types: shn:comorbidityrecord and shn:isaboutsituation only sct:arthritis Individual: Comorbidity_Diabetes_Patient06 Types: shn:comorbidityrecord and shn:isaboutsituation only sct:diabetes As it can be observed in the two instances above created and that represent the co-morbidities of the patient, the main disease (heart failure) has not been explicitly represented. In order to know that you need to ask for the disease referred to by the primary diagnosis record Other medical history In this section the past history of the patient is recorded. The form provides fields for recording the past history of some disease, its cause, clinical evidence and the past history of clinical procedures performed. The exact date and time in which a reportable event happened is left out, as it would be of minor importance to the HFS. It seems that there is little consensus among clinicians about the temporal boundaries of "part" history, especially whether the present illness represents a special case of the past history. Therefore our model may seem not specific enough. D4.2 Ontology / Information models covering the heart failure use case Page 18 of 62

19 Graphical representation: The proposed form allows for recording the past history of disease (as a variation of the general diagnosis pattern), for the explicit exclusion of a certain disease, as well as for a procedure that was performed in the past. OWL DL representation: We have identified two patterns here, as a variation of the diagnosis record one. A pattern to represent the past history record of some situation / clinical process (O1) and a pattern to represent the exclusion of some disease or procedure performed in the past (O2). The past history record of some situation or clinical process is defined as some information about a phase of a patient s life during which he/she is bearer of some clinical condition, or in which some clinical procedure (e.g. surgical intervention) is performed respectively. shn:pasthistoryrecord subclassof (O1) shn:informationitem and shn:isaboutsituation only (btl:biologicallife and btl:hasprocessualpart some (shn:clinicalsituationx and btl:temporallyrelatedto some shn:timet and btl:causedby some shn:clinicalsituationy) or btl:hasprocessualpart some (shn:clinicalprocedurep and btl:temporallyrelatedto some shn:timet )) and shn:hasinformationobjectattribute some shn:certaintyattributec and btl:outcomeof some shn:diagnosticprocedured and btl:outcomeof some (shn:interpreting and btl:hasparticipant some shn:evidencee) D4.2 Ontology / Information models covering the heart failure use case Page 19 of 62

20 Then, a past history of some procedure performed would specialise the above pattern as follows: shn:pasthistoryprocedurerecord equivalentto shn:pasthistoryrecord and shn:isaboutsituation only (btl:biologicallife and btl:hasprocessualpart some shn:clinicalprocedurep) The past history of a clinical situation would then be formulated in a similar way, substituting shn:clinicalprocedurep for shn:clinicalsituationx. The no past history record pattern, represents the exclusion of some disease or procedure performed in the past. It is described as a piece of information about a patient's life that does not include any clinical situation or procedure of some type. This information has to be explicitly represented as an statement by the clinician that the patient did not have a certain disease or procedure in the past. This is not the same as just missing information about that. shn:nopasthistoryrecord subclassof (O2) shn:informationitem and shn:isaboutsituation only (btl:biologicallife and (not (btl:hasprocessualpart some shn:clinicalsituationx) or not (btl:hasprocessualpart some shn:procedurex) and shn:hasinformationobjectattribute some shn:certaintyattributec and btl:outcomeof some shn:diagnosticprocedurep and btl:outcomeof some (shn:interpreting and btl:hasparticipant some shn:evidencee) Not having a past history of some clinical situation or having some clinical procedure not performed, would specialise the above pattern in the same way as the past history record case. Again, our 68 old woman patient, presents a past history of myocardial infarction (2005), expressed in OWL according to the pattern proposed above as: Individual: PastHistory_MI_Patient06 Types: shn:pashistorysituationrecord and shn:isaboutsituation only (btl:biologicallife and btl:hasprocessualpart some (sct:myocardialinfarction and btl:haspointintime some (shn:starttime and btl:denotedby some (shn:datetimeentity and shn:hasdatetimevalue value T00:00:00^^dateTime )))) In the above instance, we have provided a reference to the past date in which the disease (myocardial infarction) was diagnosed by using the relation btl:denotedby, that in this case relates the time entity with the information entity (shn:datetimeentity) that describes it. Note that our approach of representing time is still tentative and requires more in-depth analyses in the future Allergies This section describes the past history of adverse reactions and allergies of the patient that might be relevant for HF treatment. In SNOMED CT, there is a specific concept for representing allergies named propensity to adverse reactions. Under this concept, allergies are classified among others as propensity to adverse reactions to substance. We will use both concepts in order to define the OWL D4.2 Ontology / Information models covering the heart failure use case Page 20 of 62

21 DL annotations for the form. In this case the form provides two fields, one for saying that the patient has no known adverse reactions, and the other one to provide an allergy to some substance. Graphical representation: OWL DL representation: We have identified two patterns: (A1) Allergies not known (globally) and (A2) allergy to some substance. More refined information (e.g. unknown allergies regarding a specific agent) is not needed for the HFS. The pattern for not known allergies is defined as an information item that expresses the lack of knowledge about whatsoever past situation with a propensity to adverse reaction. The epistemic attribute Unknown is represented as an information item epistemic quality. shn:notknownpastallergies subclassof shn:informationitem and shn:isaboutsituation only (btl:biologicallife and btl:hasprocessualpart some sct:propensitytoadversereactions) and shn:hasinformationobjectattribute some shn:unknown (A1) This pattern, however, shows the approximate character of expressing ontology binding by an OWL DL expression using the universal quantifier. Especially this pattern has to carefully investigated for potentially problematic entailments. Past allergy to some substance S is an information item about the past life of the patient in which some allergy situation caused by S happened. This information can be confirmed or hypothetic, according to its provenance. shn:pastallergytosubstances equivalentto shn:informationitem and shn:isaboutsituation only (btl:biologicallife and btl:hasprocessualpart some (sct:propensitytoadversereactionstosubstance and btlbtl:hasagent some sct:substances)) (A2) D4.2 Ontology / Information models covering the heart failure use case Page 21 of 62

22 3.1.3 Symptoms Breathlessness Breathlessness is shortness of breath (dyspnoea) and usually causes the person to sleep propped up in bed or sitting in a chair. In the form provided the breathlessness is evaluated while the patient is doing some physical exercise, lying flat and at rest. For the three cases the intensity or severity of the symptom is recorded with the following values (Trivial, Mild, Moderate, Severe and Very severe). In this form the intensity of the exercise is not recorded, however it could be also interesting to do it. Graphical representation: OWL DL representation: We have defined a symptom record as some information resulting of making an evaluation for signs and symptoms: shn:symptomrecord equivalentto shn:informationitem and btl:outcomeof some sct:evaluationforsignsandsymptoms We have identified the following patterns that can be applied to the previous form: (S1) symptom present; (S2) severity of the symptom and (S3) symptom absent. Symptoms are referred to as Clinical Situations (like diseases), i.e. parts of the life of a patient in which a (static or dynamic) symptom is present. Therefore, the pattern that represents that a symptom is present is defined as a symptom record about a situation of a patient with that symptom. shn:symptompresentrecord subclassof shn:symptomrecord and shn:isaboutsituation only shn:clinicalsituationx (S1) In some cases the severity of the symptom is provided, and we will represent it as: D4.2 Ontology / Information models covering the heart failure use case Page 22 of 62

23 shn:symptomseverityrecord subclassof shn:observationresult and shn:isaboutquality only (shn:situationseverity and btl:processqualityof some shn:clinicalsituations and btl:qualitylocated only shn:severityvaluev ) and btl:outcomeof some sct:evaluationforsignsandsymptoms (S2) Here, we have recorded the symptom severity as a separate information entity because in the form is recorded in a separate field to the symptom itself. Then, in order to link it to the corresponding clinical situation of the patient (e.g. situation with severe exertional breathlessness), we will use a GCI axiom (general class axiom) defined according to the following pattern: shn:symptomseverity subclassof shn:symptomrecord and shn:isaboutsituation only (shn:clinicalsituationx and btl:hasprocessquality some (shn:situationseverity and btl:qualitylocated only shn:severityvalues)) Whether we create a special information entity for that or we represent it directly in the "Symptom present" record pattern is still under consideration and we will have to further elaborate on that in the future. Finally, in order to represent record entries that assert the absence of a symptom in a patient (not meaning absence of information), we will use the following symptom absent record pattern: shn:symptomabsentrecord subclassof shn:symptomrecord and shn:isaboutsituation only (shn:clinicalsituation and not (btl:hasprocessualpart some shn:clinicalsituationx)) (S3) Chest pain Chest pain can be experienced as discomfort, pressure, gas, or a burning or aching feeling. It can indicate a worsening of HF or a heart attack. The form records if the patient has chest pain or if the information about that is not significant. Graphical representation: OWL DL representation: A new pattern has been identified here to express that the information about the symptom is not of significance (S4). Additionally, the patterns applicable here is (S1) symptom present record. shn:symptomnotsignificant subclassof shn:symptomrecord and shn:isaboutsituation only shn:clinicalsituationx and shn:hasinformationobjectattribute some sct:notsignificant (S4) D4.2 Ontology / Information models covering the heart failure use case Page 23 of 62

24 Fatigue People with HF may feel tired all the time and have difficulty performing daily activities such as walking, climbing stair, etc. The tiredness or fatigue occurs because less blood reaches the muscles and tissues, due to the reducing pumping ability of the heart. In the form, it is possible to state that the patient has or has no fatigue. Graphical representation: OWL DL representation: No new patterns are identified. The patterns applicable here are (S1) symptom present record or (S3) symptom absent record Ankle swelling The swelling of ankles, legs, feet or belly are also HF symptoms due to the ineffective pump of the heart that causes the fluid accumulation. The form records if the ankle swelling symptom is present or not. Graphical representation: OWL DL representation: No new patterns are identified. The patterns applicable here are (S1) symptom present record or (S3) symptom absent record Palpitations Palpitation is an abnormality of heartbeat that ranges from often unnoticed skipped beats or accelerated heart rate to very noticeable changes accompanied by dizziness or difficulty breathing. Palpitations are common and occur in most individuals with healthy hearts. Palpitations without underlying heart disease are generally considered benign. However, heart palpitations can be symptoms of illnesses such as coronary heart disease, asthma, or emphysema. Graphical representation: OWL DL representation: No new patterns are identified. The patterns applicable here are (S1) symptom present record or (S3) symptom absent record. D4.2 Ontology / Information models covering the heart failure use case Page 24 of 62

25 Blackout / Syncope Syncope is a transient loss of consciousness and postural tone, characterized by rapid onset, short duration, and spontaneous recovery, due to global cerebral hypo perfusion (low blood flow to the brain) that most often results from hypotension (low blood pressure). Many forms of syncope are preceded by a prodromal state that often includes dizziness and loss of vision ("blackout") (temporary), loss of hearing (temporary), loss of pain and feeling (temporary). Graphical representation: OWL DL representation: No new patterns are identified. The patterns applicable here are (S1) symptom present record or (S3) symptom absent record NYHA Class The New York Heart Association (NYHA) Functional Classification provides a simple way of classifying the HF extent. It places patients in one of four categories based on how much they are limited during physical activity; the limitations/symptoms are in regards to normal breathing and varying degrees in shortness of breath and or angina pain. Graphical representation: OWL DL representation: No new patterns are defined here. The pattern applicable is (S2) symptom severity record. Our 68 old patient, presents several symptoms but we will focus on her moderate exertional breathlessness, expressed in OWL as: Individual: ExertionalBreathlessness_Patient06 Types: shn:symptomrecord and shn:isaboutsituation only (sct:breathlessness and (sct:physicalexercise and btl:hasprocessqualilty some (shn:situationseverity and btl:qualitylocated only sct:moderate))) D4.2 Ontology / Information models covering the heart failure use case Page 25 of 62

26 3.2 Physical exam In this section, some examination procedures are done to the patient. They do not need to have been made at the same time. All the results of any kind of physical examination process will be defined according to the following pattern (P1) physical examination record: shn:physicalexaminationrecord equivalentto shn:informationitem and btl:outcomeof some sct:physicalexaminationprocessp (P1) Most of the information represented in this section corresponds to SNOMED CT observable entities. The observables model is actually being remodelled by the Observable and Investigation model project within IHTSDO. The observable modelling provided here might be in some cases very naive and will be further elaborated to fit the model proposed by the IHTSDO subgroup. Graphical representation: Body weight Measurement of the body weight of an individual. OWL DL representation: In this case, body weight is a single-entity observable (i.e. an observable corresponding to the observation of a single aspect of an entity, e.g. the mass or length of something). D4.2 Ontology / Information models covering the heart failure use case Page 26 of 62

27 We have identified a new pattern (E1), a quality of a human or some human body part that is measured and quantified. shn:measurementresultqualityofhumanrecord equivalentto (E1) shn:observationresult and shn:isaboutquality only (btl:qualityq and btl:inheresin some btl:structuredbiologicalentitye and btl:qualitylocated only (btl:valueregionv and btl:denotedby some shn:datatypeentityd) and outcomeof some shn:measurementprocedurep Our patient weight is of 69.8 kg, expressed in OWL as: Individual: PhysicalExaminationRecord_BodyWeight_PT06 Types: shn:physicalexaminationrecord and shn:isabout some (shn:observationresult and btl:outcomeof some sct:bodyweightmeasurementprocedure and shn:isaboutquality only (sct:bodyweight and btl:qualitylocated only (btl:valueregion and btl:denotedby some (shn:physicalquantityentity and shn:hasabstractpart some shn:units_kg and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 69.8))))) Height Height, or body length, is measured from crown of head to sole of foot. Height is measured with the individual in a standing position and body length in a recumbent position. OWL DL representation: We have not identified any new pattern. The pattern (E1) is applicable here Blood pressure The blood pressure measurement of the patient. In this case we are interested in the results of the systolic and the diastolic arterial blood pressure. Most commonly this term refers to the measurement of the brachial artery pressure in the upper arm. Both are defined in SNOMED as kinds of vital signs. OWL DL representation: We have not identified any new pattern. We will use the previous patterns P1 (physical examination record) and E1 (quality of human body part record). Here the quality will be the systolic / diastolic blood pressure that inheres in some cardiovascular system (body structure) Oedema It is an abnormal accumulation of fluid in the interstitium, in locations beneath the skin or in one or more cavities of the body. OWL DL representation: We have identified two new patterns: (E2) finding in the patient after physical examination and (E3) severity of the finding found in that patient. D4.2 Ontology / Information models covering the heart failure use case Page 27 of 62

28 A finding in the patient found after a physical examination is represented as a physical examination record about some situation of the patient with that finding. shn:physicalexaminationfindingrecord subclassof shn:physicalexaminationrecord and shn:isaboutsituation only shn:clinicalsituationx (E2) The severity of the finding will be represented by following a very similar pattern to the severity of the symptom, but for the procedure used that in this case is physical examination procedure and not evaluation for signs and symptoms. This shows how this is a pattern candidate to be generalized. PhysicalExaminationFindingSeverityRecord subclassof shn:observationresult and shn:isaboutquality only (sct:situationseveritys and btl:processqualityof some shn:clinicalsituationx and btl:qualitylocated only shn:severityvaluev) and btl:outcomeof some sct:physicalexaminationprocessp (E3) Transcutaneous oxygen saturation Saturation of Peripheral Oxygen (SpO2) is an estimation of the oxygen saturation level usually measured with a pulse oximeter device. Pulse oximetry is a non-invasive method allowing the monitoring of a patient's haemoglobin oxygenation. In the form SpO2 is measured when the patient is not breathing and when he is breathing. In this last case the percentage of O2 and FiO2 in the ambient are also recorded. We consider saturation as a special case of concentration and introduce a general concentration pattern 7 as follows. shn:measurementresultsubstanceconcentration equivalentto (E4) shn:observationresult and shn:isaboutquality only (btl:concentration and btl:inheresin some (sct:substance[solute]s and componentpartof some sct:substance[mixture]m) and btl:qualitylocated only (btl:valueregionv and btl:denotedby some shn:datatypeentityd) and outcomeof some shn:measurementprocedurep Substance concentration results are observation results, i.e. information entities. They represent, in the real world, qualities. Such a concentration quality inheres in an amount of homogeneous molecules of a certain type, e.g. haemoglobin which is a component of a mixture (e.g. of the type blood). We consider saturation a special case of concentration, mainly distinguished by the fact that it is measured on a 0 100% scale, which is, however, an epistemic issue and is irrelevant for describing the nature of the thing being measured. Thus, we can consider the oxygen / haemoglobin example as 7 Hastings, J; Steinbeck, C, Jansen, L; Schulz, J. Substance concentrations as conditions for the realization of dispositions CEUR Workshop Proceedings. 2011; 754 : -KR-MED Semantic Applications in Life Sciences. Proceedings of the 4th International Workshop on Formal Biomedical Knowledge Representation, hosted by Bio-Ontologies 2010; July 9-10, 2010; Boston, MA, USA. D4.2 Ontology / Information models covering the heart failure use case Page 28 of 62

29 follows: The concentration of O 2 molecules in haemoglobin is a quality of an amount of O 2, distributed within an amount of haemoglobin. It could be measured as a substance concentration, but here it is measured as a concentration Pathology test result (Blood count) This test records observations on a blood film including microscopic findings and cell counts and is normally reported by a haematology laboratory. The form records the mass concentration of haemoglobin and the number of white blood cell count per litre of blood. It provides also two additional fields, the overall test result status (Registered, Interim, Final, Amended, Cancelled / Aborted) and the status of the measurement result haemoglobin (Registered, Interim, Final, Amended, Cancelled / Aborted). Graphical representation: OWL DL representation: We will use the previous pattern for measuring the substance concentration (E4) and we have identified a new pattern for recording the result of a clinical test (T1), in this case a blood test. We have defined the result of a clinical test as some information outcome of any kind of clinical test. Additionally, information such as when the test was started and finished can be provided: shn:clinicaltestresultrecord equivalentto shn:informationitem and btl:outcomeof some shn:clinicaltestt (T1) Our patient blood test, shows among others, a haemoglobin concentration of 10.8g/dL, we have represented it as: Individual: BloodTestResult_Creatinine_Patient06 Types: shn:informationitem and btl:outcomeof some sct:bloodtest and shn:isabout some (shn:observationresult and shn:isaboutquality only (shn:concentration and btl:inheresin some (sct:haemoglobin and btl:componentpartof some sct:blood) and btl:qualitylocated only (btl:valueregion and btl:denotedby some (shn:physicalquantity and shn:hasabstractpart some shn:units_g/dl and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 10.8))))) D4.2 Ontology / Information models covering the heart failure use case Page 29 of 62

30 3.3 Electrocardiography (ECG) An electrocardiogram (ECG or EKG) is a record of the electrical activity of the heart over time, recorded non-invasively using external skin electrodes. The characteristic shape of a ECG curve is described by well-defined points and intervals called P,Q,R,S,T,U The form records the RR Rate (by measuring the time between two R peaks), the PR interval, the QRS duration and provides the overall interpretation comment on this recording, usually made by some clinician. Graphical representation: OWL DL representation: We will use the pattern (E1) that describes a quality of a human or some human body part that is measured and quantified and the pattern (T1) for representing the test results. 3.4 Echocardiography Records the findings and interpretations of an imaging examination or series of examinations, performed. The form records the left ventricular end-diastolic cavity size and the left atrial dimension. It provides a radiological diagnosis. Graphical representation: OWL DL representation: For representing the sizes of the left ventricular end-diastolic cavity and the left atrial, we will use the pattern (E1) for describing a quality (i.e. size) of a human or some human body part (i.e. heart) that is measured and quantified. We will use the pattern (T1) for representing D4.2 Ontology / Information models covering the heart failure use case Page 30 of 62

31 the test results. We will reuse the diagnosis record pattern for representing a radiological diagnosis. A radiological diagnosis is then represented as a primitive class, and a subclass of shn:diagnosisrecord. shn:radiologicaldiagnosis subclassof shn:diagnosisrecord 3.5 Lung function A Lung function test, also known as spirometry, measures how much and how quickly air can be moved in and out of the lungs. The form records the FEV1 (Forced Expiratory Volume in One Second), the FVC (Forced Vital Capacity) and FEV1 / FVC values. The first one is the volume of air which can be forcibly exhaled from the lungs in the first second of a forced expiratory manoeuvre. The second one is the volume of air which can be forcibly and maximally exhaled out of the lungs until no more can be expired. The third one is the ratio of FEV1 to FVC and it indicates what percentage of the total FVC was expelled from the lungs during the first second of forced exhalation Graphical representation: OWL DL representation: The three parameters provided by the form are volumes of air produced by the lungs. Therefore we will represent them by following the pattern (E1) for describing a quality (i.e. volume) of a human or some human body part (i.e. lung) that is measured and quantified. Pattern (T1) will represent the actual test results. D4.2 Ontology / Information models covering the heart failure use case Page 31 of 62

32 The form distinguishes between the actual and the predicted test result. For this last one, we identify a new pattern: (E5) predicted result record. We have also identified a new pattern for (E6) no test result record. shn:predictedresultrecord equivalentto shn:informationitem and btl:outcomeof some shn:predictionprocess (E5) shn:notestresultrecord equivalentto shn:informationitem and shn:isabout some (shn:clinicaltestprocedurec and not (btl:hasoutcome some shn:informationitemi) (E6) The above pattern (no test result) has to be interpreted as the case in which the clinical test has been performed, but no result has been obtained, what is different from the case in which the clinical process has not been performed. Our patient presents a predicted FEV1 value of 2.53 ml and an actual value of 2.1 ml represented as: Individual: TestResult_FEV1_Patient06 Types: shn:informationitem and btl:outcomeof some sct:lungfunctiontests and shn:isabout some (shn:observationresult and btl:outcomeof some sct:forcedexpirationtechnique and shn:isaboutquality only (sct:fev1_ratio and btl:qualitylocated only (btl:valueregion and btl:denotedby some (shn:physicalquantity and shn:hasabstractpart some shn:units_ml and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 2.1))))) Individual: PredictedTestResult_FEV1_Patient06 Types: shn:predictedtestresult and shn:informationitem and btl:outcomeof some sct:lungfunctiontests and shn:isabout some (shn:observationresult and btl:outcomeof some sct:forcedexpirationtechnique and shn:isaboutquality only (sct:fev1_ratio and btl:qualitylocated only (btl:valueregion and btl:denotedby some (shn:physicalquantity and shn:hasabstractpart some shn:units_ml and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 2.53))))) 3.6 Invasive investigation Coronary angiography Angiography or arteriography is a medical imaging technique used to visualize the inside of blood vessels and cavitated organs, in particular arteries, veins and the heart chambers. This is traditionally D4.2 Ontology / Information models covering the heart failure use case Page 32 of 62

33 done by injecting a radio-opaque contrast agent into the blood vessel and imaging using X-ray based techniques such as fluoroscopy. Graphical representation: OWL DL representation: We will use the pattern for past history record of a procedure done (O1) for representing the previous intervention. The test result pattern (T1) is used for representing all the test results of a coronary angiography. For representing the stenosis percentage we will use the pattern (E1). For representing the stenosis type and the finding field we will use the pattern (T1) test result record. 3.7 Assessment Final diagnosis The form allows recording the disease diagnosed, its severity, the date at onset, the age of the patient at onset and the body site affected by the disease. D4.2 Ontology / Information models covering the heart failure use case Page 33 of 62

34 Graphical representation: OWL DL representation: For the disease diagnosed we will reuse the pattern diagnosis record (D1) and we provide two additional patterns to record the severity of the disease diagnosed (D2) and the age of patient when the disease was diagnosed (D3). The severity of the disease diagnosed follow a similar pattern to the symptom severity previously presented. As previously mentioned, if we create a special information entity for the severity or we represent it directly in the diagnosis record pattern is still under consideration and we will have to further elaborate on that in the future. shn:severitydiseasediagnosedrecord subclassof shn:diagnosisrecord and shn:isaboutquality only (shn:situationseverity and btl:processqualityof some shn:clinicalsituationx and btl:qualitylocated only shn:situationseverityvaluev) (D2) With regards to the age of the patient when the disease was diagnosed, It remains to be decided whether this information requires a pattern of its own, or whether it can be captured by a refined diagnosis record pattern, in which the reference to the diagnostic procedure is made explicit and a timestamp added, from which the age of the patient at diagnosis can be computed (outside DL). shn:ageatonsetdiseasediagnosedrecord equivalentto (D3) shn:observationresult and shn:isaboutquality only (sct:age and btl:qualitylocated only shn:agevaluea and btl:inheresin some (shn:humanorganism and btl:participatesin some (shn:clinicalsiuationx and shn:situationisspecifiedas only shn:diagnosisd and btl:pointintime some shn:situationstartt))) D4.2 Ontology / Information models covering the heart failure use case Page 34 of 62

35 3.8 Plan The plan section includes several health states agreed to by the patient, to be achieved in the future; requests for laboratory tests and other healthcare services as well as for the next consultation; and a medication order Goals In this section we can find three different goals: (1) Reduce the risk of hospitalization; (2) symptom control and (3) diabetes control. Each goal comprises some objectives Goal I. Reduce risk of hospitalization We will represent the above statement by using a new pattern for describing a target procedure (G1). A target procedure record represents information about a plan, which realization is the target clinical process. shn:targetprocedurerecord equivalentto shn:informationitem and shn:isabout some (btl:plan and btl:hasrealization only shn:clinicalprocessp) (G1) Therefore, if the target is to reduce the risk of hospitalization we will define it as some information item that is about a plan to reduce the risk of hospitalization. The risk of hospitalization is a disposition which realization is the hospital admission: shn:targetreduceriskofhospitalization equivalentto shn:informationitem and shn:isabout some shn:plantoreduceriskofhospitalization shn:plantoreduceriskofhospitalization equivalentto btl:plan and shn:hasrealization only sct:hospitalizationriskmanagement shn:hospitalizationriskmanagement equivalentto sct:riskmanagement and btl:hasparticipant some (shn:humanorganism and btl:bearerof some shn:riskofhospitalization) shn:riskofhospitalization equivalentto shn:riskdisposition and btl:hasrealization only sct:hospitaladmission And the plan to reduce the risk of hospitalization comprises the following sub-objectives: and shn:hasabstractpart some shn:targetsystolicbpplan and shn:hasabstractpart some shn:targetrestinghrplan and shn:hasabstractpart some shn:targetdryweightplan Target systolic blood pressure There is a plan for the patient to have some specific blood pressure. The form provides the target measurement expected, the proposed target date to achieve it and the date in which it is achieved. D4.2 Ontology / Information models covering the heart failure use case Page 35 of 62

36 OWL DL representation: We will define a new pattern for representing some target result (G2). A record of a target result is represented as some information outcome of some clinical process (often some clinical test), which is carried out at some time and that is about some specific information item (e.g. some systolic blood pressure value). shn:targetresultoutcomerecord subclassof shn:informationitem and btl:outcomeof some (shn:clinicalprocessp and btl:temporallyrelatedto some shn:timet) and shn:isabout some shn:informationitemi G2 In this case, since the result is expected to be accomplished in the future, the time will refer to a future point in time or time interval. The concrete target measurement value here refers to systolic blood pressure and it will be represented by following the pattern E1 (MeasurementResultQualityOfHumanM). Our patient target, is to have a systolic blood pressure of 154mmHg, expressed as: Individual: TargetResult_SystolicBP_Patient06 Types: shn:targetresultoutcomerecord and InformationItem and outcomeof some sct:physicalexaminationprocess and isabout some (shn:observationresult and shn:isaboutquality only (sct:systolicbp and qualitylocated some (ValueRegion and btl:denotedby(physicalquantity and shn:hasabstractpart some shn:units_mmhg and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 154.0))))) Target resting heart rate There is a plan for the patient to have some heart rate at rest position. OWL DL representation: It will follow the same patterns as the target systolic blood pressure measurement (G2 and E1). Target dry weight There is a plan agreed by the patient to have some specific weight. OWL DL representation: It will follow the same patterns as the target systolic blood pressure measurement (G2 and E1) Goal II. Symptom control The second goal is to control the heart failure symptoms. We will use the SNOMED CT procedure Signs/Symptoms-physical case management for representing the plan to control the HF symptom by following the pattern (G1) target procedure record. D4.2 Ontology / Information models covering the heart failure use case Page 36 of 62

37 Individual: TargetProcedure_SymptomsControl_Patient06 Types: shn:targetprocedurerecord and shn:isabout some (btl:plan and btl:hasrealization only sct:signs/symptoms-physicalcasemanagement) And the plan to control the HF symptom comprises the following sub-objective: and shn:hasabstractpart some shn:targetnyhaclassplan NYHA Class There is a plan for the patient to have some specific NYHA class. OWL DL representation: It will follow the pattern G2 to represent that there is a goal to accomplish some target result (in this case some NYHA class), and the pattern S1 and S2 to express the severity of the heart failure according to the NYHA classification. Individual: TargetResultOutcome_NYHA_Patient06 Types: shn:targetresultoutcomerecord and shn:symptomrecord and isaboutsituation only (sct:heartfailure and btl:hasprocessquality some (shn:situationseverity and btl:qualitylocated only (shn:severityvalue and btl:denotedby some sct:class_iii))) Goal III. Control diabetes The third goal is to control the diabetes. Again we will use the pattern (G1) target procedure record and as process to be realized we use the SNOMED CT procedure concept diabetic monitoring. The plan to control diabetes comprises the following sub-objective: and shn:hasabstractpart some shn:targethba1cplan Target HBA1C There is a plan agreed by the patient to have some specific Haemoglobin A1c (HBA1C) level. OWL DL representation: For representing the target glucose level in blood expected we use the pattern G2 for recording a target result outcome and the pattern E4 for measuring substance concentrations. 3.9 Requests Laboratory test request a request, generally issued by a clinician, that some laboratory test should be performed. The form records the test requested and when it is requested. D4.2 Ontology / Information models covering the heart failure use case Page 37 of 62

38 Graphical representation: OWL DL representation: We will define a generic pattern for representing any kinds of requests to perform clinical processes (R1) as a plan outcome of a request and which realization is the clinical process requested. Both the request procedure and the clinical process itself can have associated a point in time or time interval, in order to record both the time of the request (instruction timing) or the time in which the procedure requested is performed. shn:requestprocessrecord equivalentto btl:plan and btl:outcomeof some sct:requestprocedure and btl:hasrealization only shn:clinicalprocessc (Q1) Then, a laboratory test request would be represented as (Q2), a kind of request: shn:laboratorytestrequest equivalentto shn:requestprocessrecord and btl:hasrealization only sct:laboratorytestl (Q2) Healthcare service request a request to perform some healthcare service (e.g. check potassium level). The form records the service requested and when it is requested. Graphical representation: OWL DL representation: We will specialise the pattern Q1, as done with Q2, to express that the request is to perform a process that is a kind healthcare service. shn:healthcareservicerequest equivalentto shn:requestprocessrecord and btl:hasrealization only shn:healthcareserviceprocessp (Q3) D4.2 Ontology / Information models covering the heart failure use case Page 38 of 62

39 3.10 Recommended Medication Medication order A medication order is also a kind of request. In this case a request for the patient, in which he has to take some medication. The form has been defined by following the epsos requirements and allows for recording the time of the order, the active ingredient, the strength (dose, e.g. 5 mg), the dose form (e.g. tablet), the start, end and duration time of the medication, a complex timing description (e.g. twice per day during a week), the route (e.g. oral), additional instructions and clinical indications. Graphical representation: OWL DL representation: a medication order is also a kind of request, a specialization of the pattern Q1, in which the goal is to perform some medication administration process. We will define a general pattern for medication administration in which we will include the instruction timing (btl:timet), the substance administered (sct:substances), its dose (shn:dosed), its dose form (shn:doseformf), route (sct:bodypartb), the start and end time of the medication (shn:starttimes, shn:endtimes) and the duration (btl:timeintervalt). D4.2 Ontology / Information models covering the heart failure use case Page 39 of 62

40 shn:requestmedicationrecord subclassof (Q4) btl:plan and btl:outcomeof some (sct:requestprocedure btl:temporallyrelatedto some btl:timet) and btl:hasrealization only (sct:medicationadministration and btl:haslocus some sct:bodypartb and btl:haspatient some (sct:pharmaceuticalproductp and btl:hascomponentpart some (sct:substances and btl:bearerof some shn:dosed and btl:beareof some (shn:doseformf and btl:qualitylocated only sct:drugdoseformf))) and btl:haspointintime some shn:starttimes and btl:haspointintime some shn:endtimes and btl:hasduration some btl:timeintevalt) We have not represented the complex timing description (e.g. each day, twice per week) in the pattern and neither the clinical indication nor additional instructions. An example of instructions is Double Carvedilol every two weeks until target achieved (see Section 1.4). This type of statements is typical for clinical guidelines and protocols (CGPs). The intertwining between CGPs, information models and clinical ontologies is still to be addressed by SemanticHealthNet, according to the workplan for year 2. With regards to the indication representation, this relates medication to some problem that should be already documented in the record and should be represented by cross-referencing. Among the medication ordered to the 68 years old patient, she should take 25mg of Spironolactone per day and we have represented it as: Individual: MedicationRequest _SpironolactonePatient06 Types: shn:requestprocessrecord and btl:hasrealization only (sct:medicationadministration and btl:haspatient some (sct:pharmaceuticalproductp and btl:hascomponentpart some (sct:spironolactone and btl:bearerof some (shn:dosed and btl:denotedby some (shn:physicalquantity and shn:hasabstractpart some shn:units_mg/day and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 25.0)))))) D4.2 Ontology / Information models covering the heart failure use case Page 40 of 62

41 4 Competency questions In the following we will show some examples of queries for retrieving clinical data of the previous fictitious patient (see Section 1.4). The next diagram shows in yellow the main data items (key information) for clinicians when they are diagnosing heart failure. Is It Heart Failure? Key information to support or refute the diagnosis John Cleland edit Suzanna Hardman Suspected Heart Failure Heart Failure Symptoms & Signs Cardiac Biomarker Cardiac Imaging Heart Failure Treatment Orthopnoea / PND (no/yes/nk if yes - mild/mod/severe/nk) NT-pro BNP - Value Echo Loop Diuretic Breathlessness at Rest (no/yes/nk if yes - mild/mod/severe/nk) Breathlessness when Walking (no/yes/can t walk NK if yes - mild/mod/severe/nk) BNP - Value MR-pro ANP - Value Other ECG CXR Thiazide Diuretic Swelling of Ankles or Legs (no/yes/nk if yes - mild/mod/severe/nk) ACE Inh. NYHA Class (I/II/III/IV/NK) Physical signs Left Ventricular Systolic Dysfunction Qualitative - (none/mild/mod/severe/ NK) or LVEF value Left Atrial Dilatation Qualitative - (none/mild/mod/severe/ NK) Or LA dimension Or LA volume Valve Disease Qualitative - (none/mild/mod/severe/nk) Other Right/Left Heart Dysfunction Qualitative - (none/mild/mod/severe/can t walk, NK) ARB Beta-Blocker MRA Warfarin Additional Information Age Sex Height / Weight Heart Rhythm SR, SR with freq ES, AF, AFl, V.Pace, Haemoglobin Serum Creatinine Current Diagnosis Heart Failure Excluded Heart Failure Confirmed Heart Failure Uncertain Clinician completing HER (name and role) D4.2 Ontology / Information models covering the heart failure use case Page 41 of 62

42 The following query examples aim to retrieve some of the yellow key information required for the clinicians. For each query we provide its formulation in natural language, as made by a clinician and how it would be expressed in DL. Always as a result, we will obtain information entities, since we only create instances of them (see Section 2). Sometimes the information entity refers to many properties such as the specific symptom, its severity, its location. All of them might be represented by the same instance of information and in order to retrieve the specific properties, it will be necessary to examine the type definition and this will require to make an specific implementation of each of the patterns. Another possibility would be to create additional instances for each of the values of the properties and that requires to use the punning approach mentioned in section 2, when referring to clinical situations. With this last option, query languages such as SPARQL could be used. These are implementation issues that we have to evaluate and in which we will further elaborate after this deliverable. We assume that we only query the data of our running patient, thus no information about the patient is added in the query, as well as no distinction is made between data from different consultations. We consider that we only have the clinical data provided in Section 2. In some examples we will introduce some new data and query examples on purpose, in order to demonstrate the advantages of using DL reasoning. Along the deliverable, the EHR standard based representation of the HFS has been done only according to openehr. This means that no examples of heterogeneously represented clinical information have been provided. However, here we will simulate some of these examples in order to show how to query them in a homogeneous way. EXAMPLE 1: Does the patient have breathlessness when doing exercise? We are looking for an information entity of the kind SymptomRecord and that refers to a situation of the patient in which he has breathlessness and he is doing physical exercise. In this case we do not specify that breathlessness is caused by physical exercise but we just check that both occurs at the same time (a clinical situation of the patient with breathlessness and doing physical exercise). DL QUERY: shn:symptomrecord and shn:isaboutsituation only (sct:breathlessness and sct:physicalexercise) Answer: SymptomPresent_BreathlessnessPhysicalExercise_PT06. However, sometimes in one EHR system clinical data are more detailed that in another one. It may happen that in another system it is only recorded that the patient has breathlessness, but it is not specified if this happens when he is lying on bed (i.e. orthopnoea) or while doing physical exercise (exertional breathlessness). However, we want to know at least if the patient has breathlessness. In order to know it we will query both systems for all patients with breathlessness as: shn:symptomrecord and shn:isaboutsituation only sct:breathlessness Answer: As answer, we will get both of them, the one that has only breathlessness, without providing more details (PT_INVENTED) and the one that specify that occurs while doing physical D4.2 Ontology / Information models covering the heart failure use case Page 42 of 62

43 exercise. (This is possible thanks to the reasoner, since a situation with breathlessness and physical exercise, is defined as including both conditions ). SymptomPresent_BreathlessnessPhysicalExercise_PT06. SymptomPresent_Breathlessness_PT_INVENTED. EXAMPLE 2: Does the patient have swelling of ankles? Again we are looking for an information entity of the kind SymptomRecord and that refers to a situation of the patient in which he has swollen ankles. However, in this case the answer is no. DL QUERY: If we ask if the patient has the symptom ankle swelling, then we will not get any instance back. This means that there is no information that expresses that. shn:symptomrecord and shn:isaboutsituation only sct:ankleswelling Answer: (empty) However, there is a difference between there is no information about something or the absence has been explicitly stated, as is the case here. This means that in order to know if the clinicians have explicitly recorded the absence, the following query has to be done: shn:symptomrecord and shn:isaboutsituation only (shn:clinicalsituation and (not (btl:hasprocessualpart some sct:ankleswelling)) Answer: SymptomAbsent_AnkleSwelling_PT06. EXAMPLE 3: What is the Left Ventricular Ejection Fraction (LVEF) value obtained in the patient echocardiogram? DL QUERY: Here we are asking for one of the results of a clinical test (echocardiogram) and we will query that as an information entity result of an echocardiogram and that is about the observation result that provides the LVEF value. shn:informationitem and btl:outcomeof some sct:echocardiography and shn:isabout some sct:lvef Answer: TestResultRecord_LVEF_PT06. In order to get the explicit numeric value obtained (see below, in red), we will need to analyse the type expression of the instance retrieved: D4.2 Ontology / Information models covering the heart failure use case Page 43 of 62

44 Individual: TestResultRecord_LVEF_PT06 Types: InformationItem and outcomeof some sct:echocardiography and isabout some (shn:observationresult and shn:isaboutquality only (sct:lvef and qualitylocated some (ValueRegion and btl:denotedby(physicalquantity and shn:hasabstractpart some shn:percentageunits and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 0.32))))) EXAMPLE 4: Has the patient been requested to be administered any loop diuretic drug? We know that the patient has been administered among others, bumetanide, that is a kind of loop diuretic, so we should get it as result. DL QUERY: We will ask for information of the type shn:requestprocessrecord and which realization is a medication administration process in which a loop diuretic substance has being requested. shn:requestprocessrecord and btl:hasrealization only (sct:medicationadministration and btl:haspatient some (sct:pharmaceuticalproduct and btl:hascomponentpart some sct:loopdiuretic)) Answer: RequestProcessRecord_Bumetanide_PT06. The answer consists of the instance of the information entity that refers to the bumetanide (see below in red). As in the previous case, the instance type definition would have to be inspected in order to get additional information such as the specific substance dose. Individual: RequestProcessRecord_Bumetanide_PT06 Types: shn:requestprocessrecord and btl:hasrealization only (sct:medicationadministration and btl:haspatient some (sct:pharmaceuticalproduct and btl:hascomponentpart some (sct:bumetanide and btl:bearerof some (shn:dosed and btl:denotedby some (shn:physicalquantity and shn:hasabstractpart some shn:units_mg/day and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 1.0)))))) EXAMPLE 5: What is the current primary diagnosis of the patient? DL QUERY: In this case the primary diagnosis of the patient is heart failure and we will query it by using the specific class created for such purpose. shn:primarydiagnosisrecord D4.2 Ontology / Information models covering the heart failure use case Page 44 of 62

45 In case that we would like to obtain all kind of diagnosis of the patient, including for instance comorbitities we will ask for the parent class of shn:primarydiagnosisrecord, that is shn:diagnosisrecord. Answer: PrimaryDiagnosisRecord_HeartFailure_PT06 Individual: PrimaryDiagnosisRecord_HeartFailure_PT06 Types: shn:primarydiagnosisrecord and shn:isaboutsituation only sct:heartfailure If we inspect the definition of the instance retrieved we will know that the diagnosis is about heart failure (see in red). EXAMPLE 6: What are the weight and height of the patient? DL QUERY: We are asking for two concrete results of the physical examination process done to the patient. That is, the information resulting from a physical examination process (of the type shn:physicalexaminationrecord) and that is about the observation results body weight and body height. shn:physicalexaminationrecord and shn:isabout some (sct:bodyweight or sct:bodyheight) Answer: In this case we will obtain two instances, one with the body weight and another one with the body height. Again, in order to retrieve the concrete value we have to inspect the definition of the instance. In case that only one of the results has been recorded we would get only that information instance. PhysicalExaminationRecord_BodyWeight_PT06 PhysicalExaminationRecord_BodyHeight_PT06 We show only the definition of the height instance here (see Section for the body weight): Individual: PhysicalExaminationRecord_BodyHeight_PT06 Types: shn:physicalexaminationrecord and shn:isabout some (shn:observationresult and btl:outcomeof some sct:bodyweightmeasurementprocedure and shn:isaboutquality only (sct:bodyheight and btl:qualitylocated only (btl:valueregion and btl:denotedby some (shn:physicalquantityentity and shn:hasabstractpart some shn:units_cm and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 160))))) D4.2 Ontology / Information models covering the heart failure use case Page 45 of 62

46 EXAMPLE 7: What is the Haemoglobin and Serum Creatinine in blood of the patient? DL QUERY: We are interested in getting two concrete results of a blood test. Then, we will ask for that information outcome of a blood test and that is about the observation results of Haemoglobin and Creatinine. As in the weight and height case, in case that both results have been recorded we will get two information instances, if only one of them has been recorded, then only an instance will be retrieved. shn:informationitem and btl:outcomeof some sct:bloodtest and shn:isabout some (sct:haemoglobin or sct:creatinine)) Answer: TestResultRecord_Haemoglobin_PT06 TestResultRecord_Creatinine_PT06 We show only the definition of the Creatinine instance here (see Section for the haemoglobin): Individual: BloodTestResult_Creatinine_Patient06 Types: shn:informationitem and btl:outcomeof some sct:bloodtest and shn:isabout some (shn:observationresult and shn:isaboutquality only (shn:concentration and btl:inheresin some (sct:creatinine and btl:componentpartof some sct:blood) and btl:qualitylocated only (btl:valueregion and btl:denotedby some (shn:physicalquantity and shn:hasabstractpart some shn:units_umol/l and shn:hasabstractpart some (shn:realentity and shn:hasdoublevalue value 137.0))))) EXAMPLE 8: Has been the heart failure of the patient caused by myocardial infarction? In this case we will assume that this information has been recorded in a different way in two EHR systems. In one system the disease (heart failure) and the cause (myocardial infarction) are recorded in two separate fields of an application form. In the other system, the SNOMED CT post-coordinated expression heart failure caused by myocardial infarction has been used, and therefore only one data field. This example shows how we can query two iso-semantic simple models in a homogeneous way. DL QUERY: We can query both systems by using the following expression in which only one information entity refers to a heart failure and its cause (i.e. post-coordinated expression in SNOMED CT): shn:primarydiagnosisrecord and shn:isaboutsituation only (sct:heartfailure and btl:causedby some sct:myocardialinfarction) D4.2 Ontology / Information models covering the heart failure use case Page 46 of 62

47 or we can query by using two information entities (i.e. two separate fields, one for the disease and another for the cause: shn:primarydiagnosisrecord and shn:isaboutsituation only sct:heartfailure and shn:primarydiagnosisrecord and shn:isaboutsituation only (shn:clinicalsituation and btl:causedby some sct:myocardialinfarction) With both cases we will obtain all the heart failure diseases caused by myocardial infarction, independently of the granularity in which the information has been recorded in each of the systems. Answer: In this case, our running patient does not provide this information, but we wanted to show the power of the approach used. EXAMPLE 9: Has the patient being administered any drug that contains acetylsalicylic acid? For this query we will simulate another example of interoperability between two systems, in which the information has been recorded in a different way. In one system, the name of the pharmaceutical product is provided (aspirin+caffeine). While in another system the information provided is the substance (acetylsalicylic acid). DL QUERY: I want to retrieve both system results if I ask for all the products that have as component acetylsalicylic acid: shn:requestprocessrecord and btl:hasrealization only (sct:medicationadministration and btl:haspatient some (sct:pharmaceuticalproduct and btl:hascomponentpart some sct:acetylsalicylic)) Answer: As answer to the query, we will get both patients data, the one in which the substance is specified (invented patient here) and the other in which the pharmaceutical product is provided. Once more we can see the advantages provided by using DL reasoning. MedicationRequest_Aspirine+Caffeine_PT06 MedicationRequest_AcetylSalicylic_INVENTED_PT D4.2 Ontology / Information models covering the heart failure use case Page 47 of 62

48 5 Overview of patterns As a result of this task a first subset of patterns has been produced and are listed in Tabla 5-1. These patterns have been developed for the HFS use case, but most of them should be generic enough to be applicable to other domain (maybe it implies to increase the detail of some of them), as the public health domain, next objective of study in the project. We have followed a bottom-up approach when modelling the heart failure summary. However, many of the patterns provided could be generalised and converted into meta-patterns. They should evolve in a later stage of the project, as well as studying how to compose them. Pattern ID R1 R2 D1 O1 O2 A1 A2 S1 S2 S3 S4 P1 E1 E2 E3 E4 T1 D2 E5 E6 D3 D4 G1 G2 Q1 Q2 Q3 M1 Pattern Name Administrative reason for encounter Clinical reason for encounter Diagnosis record Past history record No past history record Past allergies not known record Past allergy to some substance record Symptom present record Symptom severity record Symptom absent record Symptom not significant record Physical examination record Measurement result human quality record Physical examination finding record Physical examination finding severity record Measurement result substance concentration record Clinical test record Radiological diagnosis record Predicted test result record No test result record Severity of the disease diagnosed record Patient age at onset of the disease diagnosed record Target procedure record Target result record Requested process record Laboratory test request record Healthcare Service request Medication requested record Tabla 5-1 Summary of patterns proposed To test how many additional patterns are needed in order to apply the same approach to other domain is part of the feasibility study of the method proposed. This approach will fail if the catalogue of patterns is so big that their implementation and maintenance is intractable. To reach the optimal balance of generality and at the same time detail that can scale across the medical domain is the challenge we face within this project. D4.2 Ontology / Information models covering the heart failure use case Page 48 of 62

49 6 Final remarks The representational patterns we have presented thus far constitute a snapshot picture of an ongoing process. We will conclude the main body of this document with some general remarks about what we learnt from WP4, after about one and a half year of modelling and interacting with a broad range of stakeholders. 6.1 What we have reached We have developed and continuously refined a framework that allows for fine-grained semantic annotation of clinical information models. This general approach and the ensuing decisions are being shared at least in principle by all SemanticHealthNet shareholders involved, whereas discussions about technicalities and the steps to be taken next continue. Our approach of using formal ontologies under a very constrained upper-level framework has contributed to reduce the degrees of modelling freedom thus contributing to a well-organised ontology. The upper model has forced us to exactly commit on which kind of entities do exist in which kind of model, and which type of entities we are representing, exactly As a consequence, we had to make a very strict distinction between information entities (record items, plans, observation results) and other entities (procedures, clinical situations). This has not always been easy, but we are seeing it more and more as a clear and consistent picture. Another challenge has been to refer to types of entities for which it is not known whether they are instantiated in the context of the particular clinical case to be represented. We have developed a tentative approach of emulating second-order statements (statements that target an entity type (concept), but not a token entity) by OWL-DL expressions. However, this has not been sufficiently evaluated, and is currently being discussed against other proposals for which, however, the modelling syntax has not been established yet. 6.2 What is difficult It is still challenging to communicate to create a shared understanding with clinicians about all facets of interoperability and the anticipated problems of non-interoperability. It has been difficult to find out the meaning of seemingly simple universal clinical terms like "problem", "past history" or "administrative reason of encounter". This highlights the need of standardizing clinical processes. We have been in a constant dialogue with proponents of related standards, but considerable effort is needed to harmonize the different approaches. This effort goes far beyond of what the resources of SemanticHealthNet allow. We have also been confronted with high expectations regarding the representation of temporal patterns. The solutions we developed with regards to time are tentative and provisional. The difficulty is two-fold. On the one hand, the representational language (OWL-DL) is agnostic with regard to time, and the restriction to two-place predicates is a known shortcoming of all description logics currently used. On the other hand the upper ontologies at hand such as BioTop and BFO do not D4.2 Ontology / Information models covering the heart failure use case Page 49 of 62

50 provide a fine grained time model which goes beyond very general classes like temporal regions or time intervals. A socio-technical issue is that very diverging interests of different stakeholders, reflected by how negation, uncertainty, or data provenance should be accounted for, how value sets should be defined, how numerical expressions should be treated. The latter is crucial, because a large part of interoperability is directly related to numerical expressions as they occur in drug dosages and lab values. For instance, axiom of the type "an information item about a systolic blood pressure measurement datum > 150 mmhg is information about systolic arterial hypertension" are fundamental for improving interoperability. Controversies also arose around SHN's mission in general, for instance whether it should give recommendations about good / bad practice, or whether it just should accept representational formalisms as they are and make the best out of them, especially regarding the placement of the boundary between terminology and information entities. The leaders of WP 4 have taken a mostly neutral stance, arguing that the strength of SHN is exactly the possibility of creating bridges of meaning without prohibiting that many flowers bloom. This includes the acceptance that different kinds of information models will co-exist, that one and the same information model will be used in different ways, that many information models will be completely proprietary, that terminologies will incorporate elements of information models, and that information models will incorporate elements of ontologies. Throughout the examples there are (implicit) assumptions made, e.g. which entities are represented as information entities and which are not, which entities are represented as primitives and which are fully defined. The OWL DL representations necessarily make simplifications of this very complex domain leading to further computationally implicit assumptions. The implications of these assumptions, both individually and taken as a whole, is still to be determined. Ontology typically deals with the question of what is universally true, and the extension to the domain of information entities is not an issue in itself, but also typical is the local and cultural dependent nature of information structures. Proving that such a representation can be made in one domain is of course important but further research is needed to determine e.g. the reproducibility and scalability of the approach. 6.3 Success factors The study of the feasibility of the SHN approach is critically dependent on the following points: 1. Performance: here we mainly refer to the response time of an application that implements the approach proposed. Since it uses technologies as OWL DL, it implies the use of DL reasoning whose performance can be decreased with the increment in size and complexity (expressivity) of the ontology. Therefore, the technologies used for the implementation of this approach (e.g. OWL, RDF, SPARQL, SQL, etc.), and how to combine and used them, will be decisive issues to keep performance within reasonable values. 2. Scalability: this factor is directly related to performance, since the wide implementation of a system that follows the approach proposed should not result in bad performance. We refer here to the ability of the approach to be applied not only to the heart failure domain but to D4.2 Ontology / Information models covering the heart failure use case Page 50 of 62

51 the rest of the clinical domain. It would mean that we have not developed another ad-hoc solution, which will get obsolete in a few years. 3. Consensus on the model: It means that even if a total consensus of the model proposed is not reached, what has been reached is also valuable in terms of semantic interoperability. Clearly complete consensus on all details of the models is impractical across countries, specialities, etc. and infeasible across the number of different niches in medicine. Therefore, to develop a set of models of minimal information to be interchanged could at least offer a reasonable and more than acceptable degree of semantic interoperability to be achieved within this century. 4. Building and maintenance of ontology patterns: We cannot expect to develop all the ontology patterns needed to cover all the medical domain within this project and sometimes some of the existing patterns will suffer from changes. Therefore, the building and maintenance of ontology patterns should be ideally supported by a community of experts supported by specific tools, the same way as actually other organisations work such as the IHTSDO. Patterns should be well-organized, ideally in a hierarchical structure where more general patterns can be specialized by more specific ones. Additionally we may want to consider also a compositional / modular structure of patterns. For instance, in order to record the very same kind of diagnostic information, there is a preference in one setting to refer to a disease (clinical situation) as pre-coordinated codes, while in another setting the information is split between, e.g. disease, location, cause. Finally we should capitalize on pattern-like structures that already exist, first of all in the SNOMED CT context model. As we have demonstrated in D4.1, these patterns are mostly not correct in an ontological sense, but they provide useful aggregation of data elements, which are directly related to SNOMED CT concepts. 5. Implementation conformance criteria: criteria have to be formulated which need to be fulfilled for any implementations to conform to these models. They should also provide guidance for testing. Some of the previous issues, such as performance and scalability, although modestly, should be addressed before moving to another domain and using the set of patterns provided in this deliverable and the heart failure summary as a test bed. If the former issues are satisfied, the other points should be addressed at further development stages of the project. D4.2 Ontology / Information models covering the heart failure use case Page 51 of 62

52 7 Expected use of the document and way forward The set of ontology patterns presented in this document are considered as initial patterns that can be subject of further elaboration in subsequent deliverables. It should be understood as an initial version of the development of the semantic artefacts required in order to develop a semantically interoperable heart failure summary. The OWL ontologies underlying the examples in this document are available from the authors on request. As mentioned before, we have followed a bottom-up approach when defining ontology patterns. This means that many of them can be further generalized. Others can be considered as metapatterns that can be further specialised. The modularization of the patterns and how to compose them when used for annotating clinical models will be also further investigated. This document does not attempt to be a manual for implementers. Although some initial tests have been performed to evaluate whether the patterns satisfy the information retrieval need of clinicians, the patterns will require further evaluation by means of a concrete test implementation. Although large scale implementations are outside the scope of SemanticHealthNet, implementations of demonstrator examples are necessary to demonstrate the feasibility of the approach and attract interest by manufacturers. This should follow up what we have initiated with a first set of competency questions. A concrete test implementation should demonstrate how clinical information based on different standard or proprietary based representations and partly encoded with SNOMED CT, is retrieved by using a common query language. Such a prototype should give an idea of performance and scalability, as well as of the resources and artefacts required for further large-scale implementations. The conclusions of this test should guide our next steps in the project and be communicated in future deliverables. The implementation of a user-friendly query language is mostly out of scope of SHN, and we will base our developments on the use of query languages such as DL and SPARQL, possibly in combination with the recently developed SNOMED CT Query Language. However, the complexity of use of these languages could be abstracted to the user by predefining some kind of queries in the test system, based on the concrete patterns developed for the heart failure summary. This deliverable should also serve as initial material to be used within WP4 in order to promote the linkage between the EHR and clinical guidelines. Moreover, it will be used as basis in order to apply the SHN approach to the public health domain, next objective of study in the project. At this stage of the project, issues such as how to build and maintain the patterns in a collaborative framework such as the openehr Knowledge Manager have not been considered but should be subject of consideration in later project stages. D4.2 Ontology / Information models covering the heart failure use case Page 52 of 62

53 8 Annex I: Use Case 2 (data abstraction for querying) (FROM DELIVERABLE 4.1) This use case refrains from converting the data from one clinical model into another. Here, the syntactical interoperability is out of reach, even in the case that both models represent exactly the same information. Interoperability is therefore limited to an exchange of the semantic annotations in description logics. Let us assume that two systems X and Y follow information model standards S and T respectively. For the same kind of clinical content System X uses model C; whereas System Y uses model D. Each system has the clinical data stored according to these models. These clinical data are annotated with DL expressions (clinical model + values). Additional metadata (authors, time, location, etc.) are stored separately. Each system will export its clinical data to an RDF repository, thus making them available for querying. The inferred model resulting of the OWL DL annotations made to each model C and D will also be exported to RDF. It will be possible to make SPARQL queries to retrieve data from both system X and Y RDF repositories in a homogeneous way by using the inferred annotations. Clinical Information is queried and shown to the receiver system but cannot be straightforwardly integrated in it (from abstract representation to more concrete one). The following example focuses on showing how the semantic annotations added to clinical data from isosemantic models can detect that they are semantically equivalents. Figure Figure 8-1 shows three user interfaces (with appropriate value sets) from three fictitious EHR systems. Figure 8-1 Heterogeneous clinical application forms for recording the same information Each user interface allows acquiring some kind of information about a clinical case (demographics, time, and other metadata are left out for the sake of simplicity). What the three interfaces have in common is that they refer to some piece of diagnostic information, shortly diagnosis. Diagnosis here should be understood as the statement of what is known about the disease/disorder of a patient. A diagnosis Diag D does not necessarily have a referent D in the real world: if a diagnosis Diag D has a D4.2 Ontology / Information models covering the heart failure use case Page 53 of 62

54 status suspected, then we cannot infer that there is really any instance of D in the patient, as it is typical for admission diagnoses. In the following figure, each form consists of fixed and variable elements (values). Each of these elements contributes some part of the overall meaning the whole information is about. The yellow comments shown in Figure 8-2 describe in text what the information represented is about. Figure 8-2 Three different forms representing the same kind of information, with text annotations of all of its fixed and variable elements The whole picture is only given by a combination of these annotations. If we now translate the free text annotation into OWL-DL axioms, one by one (see Figure 8-3, Figure 8-4 and Figure 8-5): Figure 8-3 Example of "filled" form with DL annotations. Note the different UI paradigms, here drop-down menu vs. check boxes D4.2 Ontology / Information models covering the heart failure use case Page 54 of 62

55 Figure 8-4 Example of a filled information template in which the whole information is included in one term from a clinical terminology. The DL annotation anticipates the supposedly "correct" SNOMED CT representation of the concept "Suspected heart failure caused by physical exercise" Figure 8-5 Example of a filled information template with DL annotations. In contrast to Fig. 8.4, the element "physical exercise" is here part of a value set and not a fixed element of the information model In this example, on purpose, the filled forms are semantically equivalent, which can be shown by automated reasoning. If we consider the models without values, we clearly see the semantic differences: D4.2 Ontology / Information models covering the heart failure use case Page 55 of 62

56 Figure 8-6 Example of "empty" information templates The first one reduces the scope to organ failure diagnoses, the second one allows for whatsoever diagnoses. Different degrees of freedom apply regarding status and cause between the models. The OWL DL annotation pattern for an empty clinical information model requires placeholders. It can only be used for reasoning if all placeholders are filled by values. During the creation of the clinical models some OWL DL expressions could be specified by leaving open the specific values and only specifying the value sets:.?x Figure 8-7 Example of a empty information template with corresponding DL expressions in which the variable elements are referred to as?x,?y,?z D4.2 Ontology / Information models covering the heart failure use case Page 56 of 62

57 Figure 8-8 depicts how diagnosis instances, e.g. the real clinical data as embedded into an information model are annotated by OWL-DL (T-Box) expressions. These annotations have the form: Diagnosis_y#123 Type Diagnosis and (isaboutsituation only Situation_Y) and. Later, in order to add the clinical data instances, the 'isaboutsituation only' is filled by an atomic or composed SNOMED CT concept using OWL-EL language. Special patterns apply to negated statements. The additional conjoints further specify the diagnosis (e.g. whether confirmed or suspected). It will have to be seen in the future which additional information (time, place, author, patient, etc.) will have to be managed outside this framework. The following figure shows three instances, one for each form, defined according to the OWL DL axioms shown in the previous figures (Figure 8-3, Figure 8-4 and Figure 8-5). Figure 8-8 Diagnosis instances The check for the semantic equivalence of the information represented by each form can then be performed by a DL reasoner completely at the T-Box level. Queries could then be formulated as DL queries as follows: D4.2 Ontology / Information models covering the heart failure use case Page 57 of 62

58 All three information instances found Figure 8-9 DL classification (1) Figure 8-9 and Figure 8-10 show how the three instances of diagnosis are retrieved independently of the granularity in which the query is performed. Figure 8-10 DL classification (2) D4.2 Ontology / Information models covering the heart failure use case Page 58 of 62

59 8.1.1 Comments on Use case 2 The above use case has shown an example of an interoperability scenario in which the clinical information captured by three isosemantic models is computed as semantically equivalent if both the "empty forms" and the values are used together for reasoning. It could be summarized as consisting of the following steps: Manual semantic annotation of (empty) information model and value sets using the proposed ontology and SNOMED CT Filling of the information model with data Automated semantic annotation of the model and the clinical data A translation problem might occur in step 1, which means to correctly adding semantics to the information model. Ideally, it would make explicit all implicit assumptions contained in the information model. As humans are in the loop who have to be trained and need to provide a high quality work this might be error prone. It is a process that needs to be quality assured as it will have a major impact on the workflows and tooling. This use case could be interpreted as a variant of use case one, but it does not pursue also the syntactic interoperability, which is the integration of the clinical data in the receiver system but to provide a semantic layer to current information systems that will sit in between them and a sophisticated query system. The main roles of this layer will be to provide a consistent semantic representation of clinical data and to allow detecting equivalent semantics among them. Thus, a sophisticated query system will use the results from the semantic layer in order to build queries for retrieving data from heterogeneous medical repositories. This use case does not aim to provide reverse translation from the ontological representation in OWL back to the original representation according to a specific EHR standard and ontology. At this moment we consider this the most realistic scenario for providing SIOp. WP4 is working on looking for more practical evidences of this. However, other alternatives or combinations of the already presented might be further aim of study. D4.2 Ontology / Information models covering the heart failure use case Page 59 of 62

60 9 Annex II: Value sets The terminology classes used in the context of a clinical model comprises a value set or reference set. In SHN we focus on the use of SNOMED CT as reference terminology, and therefore we describe here how to extract a reference set of this terminology. The IHTSDO organisation is working on the definition and implementation of a standard query language for SNOMED CT (SNOMED CT Query Language Specification 8 ), which has been approved by the management board and is available at the moment as a draft standard for public consultation. Since the specification is publicly available, we provide here only an overview of its content. The specification can be used to define value sets that may be bound to fields in information models, or to define sets of SNOMED CT concepts to be included or excluded in particular use-cases. The query language support: a. Set operations union, intersection, exclusion of one set from another, etc.; b. Filter operations (for leaf nodes, primitive and fully defined concepts); c. String matching operations; d. Selection of children and descendants, based on the SNOMED CT subsumption hierarchy; e. Selection of concepts having particular relationships (of a specific relationship type, to one or more concepts in a particular domain). For instance, if we want to define a term subset with all concepts in the Immune hypersensitivity reaction hierarchy that have an explicit ungrouped causative agent relationship to any target concept, the query expression would look like as follows: Intersection( DescendantsAndSelf( Immune hypersensitivity reaction ), HasDirectRel( Causitive agent, All) ) Or we just want to get the first three levels of the Clinical findings hierarchy: ChildrenAndSelf( ChildrenAndSelf( ChildrenAndSelf( Clinical finding ))) Or include only the leaf concepts of some SNOMED CT hierarchy: FilterOnLeaf(Descendants( Finding of heart rhythm )) The SNOMED CT query language has been implemented inside the SNOMED CT Workbench 9, as an utility for allowing the creation and maintenance of reference sets. A screenshot of this tool is shown below: D4.2 Ontology / Information models covering the heart failure use case Page 60 of 62

61 Figure 9-1 SNOMED CT Reference Set Maintenance Utility screenshot As it can be observed in the application screen, the reference sets are created by using SNOMED CT query language expressions. Besides the creation of reference sets, the tool also provides the functionality for their maintenance and review process by a group of people. Following, by means of a demo application developed by John Gutai, member of IHTSDO, we demonstrate how reference sets can be used within a data capture application in which related patient heart failure data are recorded. Error! Reference source not found. depicts a screenshot of he demo application. Among others, the application allows for recording the patient symptoms, treatment, diagnosis, physical examination results, lab test results, etc. Figure 9-2 Screenshot of a related heart failure data capture application In order to specify the bindings to the SNOMED CT concepts, a file named databindings.txt is created with the following information: A binding to a reference set that contains a list of allowed SNOMED CT concepts for the data element. A reference set is identified by its SNOMED CT Concept identifier, followed by a description for the reference set within pipe characters (SnomedValueSet). A binding to a single SNOMED CT Concept, identifying the data element itself (SnomedBinding). D4.2 Ontology / Information models covering the heart failure use case Page 61 of 62