Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

FormalPara Key Statements
  1. 1.

    Medical consultants face increasing challenges in keeping up-to-date with the rapid development of new treatments and medications, particularly for rare and complex cases.

  2. 2.

    Personalised medicine offers substantial benefits for patients and clinicians, but requires capturing, integrating and interpreting huge volumes of data.

  3. 3.

    Information providers offer evidence-based medical information services , continuously taking into account new publications and medical developments. The use of such medical information services in today’s clinical day-to-day routine is, however, still limited. Due to high workload, consultants simply find no time for researching those knowledge bases. The knowledge bases themselves can also provide contradictory information.

  4. 4.

    To allow effective clinical decision support, personalized medical information must be available at the point-of-care: useful information on diagnosis or treatment, tailored to each particular patient, without placing the burden of research on the consultant.

  5. 5.

    Personalized clinical decision support requires electronic health records to be semantically linked with evidence-based medical knowledge services.

10.1 Introduction

Personalised medicine , also known as precision or stratified medicine , is the practice of tailoring of patient care based on their predicted response or risk of disease [18, 19]. For example, patients with the same broad diagnosis, such as breast cancer, can have varying forms of the disease, such as ‘Papillary Carcinoma of the Breast’ or ‘Ductal Carcinoma In Situ’, and will have major differences in their treatment plans. When the myriad potential comorbidities, medications, symptoms, environmental factors and demographics of patients are considered, there are even more differences in optimal care paths for patients. Furthermore, since a genetic component is present in most diseases, the use of genome sequencing will allow an even more personalised approach to treatment.

There are substantial benefits for patients and clinicians in using a personalised approach as it will provide a more accurate diagnosis and specific treatment plan, offer better care outcomes for patients, will improve efficiency for the healthcare providers and will allow drug and diagnostics designers more effective methods to target disease ([18, 19]).

For example, breast cancer patients are tested for certain genetic biomarker mutations in the BRCA1 and BRCA2 genes if they have a family history of breast cancer or ovarian cancer. Patients who have pathogenic variants of BRCA1 or BRCA2 genes are at high risk for breast and ovarian cancer and prophylactic surgery if often carried out to protect their long-term health [1]. The level of BRCA1 gene expression is also an important guide for tailoring chemotherapy [2]. Note, however, that not all genetic variants are pathogenic, so the he challenge here is the appropriate clinical classification of variants and keeping this classification up-to-date, along with smooth integration of this knowledge into precision medicine.

Another example of information used in personalised medicine is the HER2 gene which contains the genetic instructions on how to make HER2 proteins, which are receptors on breast cells. HER2 proteins control how a breast tissue cell grows, divides, and repairs itself, however, in some patients, an error in the HER2 gene causes it to replicate itself leading to uncontrolled growth in the breast tissue [3]. Such information can be combined with other clinical data such as tumour size, lymph node status, comorbidities, lifestyle and to a lesser extent age and socioeconomic status to produce a more accurate diagnosis, prognosis and treatment [4].

To quote Hippocrates, “It is more important to know what sort of person has a disease, than to know what sort of disease a person has” [5].

However major challenges exist for enabling personalised medicine in front line patient care. For example a position paper by the European Society for Medical Oncology (ESMO) states that there is “the daunting task of integrating and interpreting the ever-increasing volume of data and the associated information communication technology (ICT) needs, and the multiple dimensions of, and changing perspectives on, value and cost-effectiveness in personalised cancer medicine” [6].

Indeed, medical consultants already face enormous challenges in keeping up-to-date with the rapid development of new treatments and medications, particularly for rare cases. Healthcare systems have undergone significant transformation over the last decade, so that clinicians are now burdened with rapidly growing medical knowledge bases, taxing regulatory requirements, increased clerical burden with paper records, the roll out of fragmented electronic health systems and intense scrutiny of quality performance indicators.

Moreover the introduction of electronic health records (EHR) appear to have increased clerical burden for clinicians and can distract some clinicians from meaningful interactions with patients. A recent study involving observation of 57 clinicians over many weeks indicated that clinicians spend about half of their time completing administrative tasks and interfacing with the EHR [7].

A recent study discovered that usability issues, lack of interoperability, and poor quality of documentation were sources of frustration for physicians who engage with EHR systems and it has been suggested that dissatisfaction with EHR is a major factor in physician burnout. Dissatisfaction is also trending upwards with a growing percentage of clinicians becoming frustrated with current implementations of EHRs.

Moreover, the complexity of patient data is growing and physicians are now tasked with interpreting vast volumes of patient data in the form of EHRs that aggregate documents related to a given patient. Due to the heterogeneity and volume, such data is considered as one of the most complex in the information processing industry. Biomedical big data, in the form of EHRs and digital image archiving is rapidly growing, with an estimated annual growth rate of 48% and it is estimated that health data will 2,000 exabytes or 2 zetta bytes by 2020 [8]. Consequently the management and analysis of EHR data increasingly needs big data software management tools.

Information providers offer evidence-based medical information services, continuously taking into account new publications and medical developments. Prominent examples are up-to-date (www.uptodate.com) and DynaMed Plus (www.dynamed.com).

The use of such medical information services in today’s clinical day-to-day routine is, however, still limited. Due to high workload, consultants simply find no time for researching those knowledge bases. To allow effective clinical decision support, personalized medical information must be available at the point-of-care: useful information on diagnosis or treatment, tailored to each particular patient, without any research effort by the consultant.

In this chapter we describe a Clinical Decision Support System (CDSS) for cancer care [20]. The CDSS semantically links EHRs with external evidence-based medical information services, which enables the consultant to use those services without any research effort.

10.2 User Interaction Concept

We illustrate the user interaction concept of the CDSS by means of an example in melanoma treatment. Figure 10.1 shows anonymised summary data of a fictitious melanoma patient from an EHR.

Fig. 10.1
figure 1

Fictitious patient-related issue data

Full size image

In this example, the patient suffers from melanoma in situ at stage IB, with a Breslow thickness of 0.8 mm. Based on the EHR data, without interaction by the consultant, relevant information can be retrieved and displayed.

In order to provide an intuitive way for physicians and other health professionals to access this information, the CDSS leverages several information services that each try to satisfy different information needs. Those information services are organized in web page panels that the users can customize and fit to their needs by deciding which service panels should be displayed and which should be hidden. Additionally the order and size of the panels can be adapted to the user’s individual needs while the resulting layout is persisted over different sessions for the specific user.

In the following sections, we briefly describe the individual information services.

10.2.1 Drug Information Service

One important piece of information in patient care is material on drugs and their interactions “at the point of drug prescribing” [9]. A drug information service provides information normally available in medication package leaflet inserts and secondary decision support services in a more accessible and structured way (Fig. 10.2, left). The provided information includes dosage data for different age groups and pre-filled calculators to suggest dosage based on relatively static information like the age and weight of the patient. For dosages dependant on more dynamic data such as renal function, it is important to acquire recent readings if the latest data is not available in the EHR. Other information available from drug information services consists of warnings, adverse effects, pharmacology, administration guidelines, material for patient education and pill images and prices. Selecting a drug to display can be done in an autosuggest-supported field that ranks already prescribed medication higher, but allows also searching for medication not yet prescribed.

Fig. 10.2
figure 2

Drug information service [20]

Full size image

As physicians indicated they wanted to see automatically generated alerts for severe drug interactions and adverse effects [9], an alert is displayed prominently (Fig. 10.2, top). For more information on how to manage the interaction or alternative drugs, an appropriate link is provided. Drug interactions as well as drug-food interactions are displayed in an another panel where the users have the possibility to check interaction with other, not yet prescribed drugs (Fig. 10.2, right).

10.2.2 Literature Service

The literature service displays relevant primary medical literature and review results that are related to the patient at hand (Fig. 10.3).

Fig. 10.3
figure 3

Literature service [20]

Full size image

Automatically generated filters allow to quickly navigate the literature search results. The filters are displayed on the left whereas the medical literature is shown on the right. For each medical publication, its title, journal and publication date is displayed. In the context of evidence-based medicine (EBM) , publications with a high degree of evidence are to be preferred in patient care [10]. As such, publications that are reviews or clinical trials are shown with a marker indicating their publication type. This also aligns with a study from 2013 that logged and analysed data queries in a hospital and found that almost a third of the articles accessed were reviews [11, 12]. For quick orientation and relevance assessment, terms that appear in the patient’s EHR are highlighted in the literature service. To help the literature relevance assessment process, a teaser text is displayed when hovering the mouse pointer over the eye icon after each publication title. In order to give the users a way to provide feedback on the relevance of a publication and improve the literature search, icons with a thumbs-up and a thumbs-down are provided.

10.2.3 EBM Recommendations

In this service, evidence-based medical (EBM) recommendations are displayed which are relevant for the patient currently being treated. In the example from Fig. 10.1, the patient suffers from melanoma in situ at stage IB, with a Breslow thickness of 0.8 mm. Based on the EHR data, without interaction by the consultant, the relevant page of the NCCN EBM guideline [21] for melanoma treatment is retrieved. In this example the NCCN guidelines are used, but the source of these guidelines may be configured to comply with the regulations used in a particular medical practice.

The guideline is structured as a decision tree with the relevant path (Stage IB, Breslow thickness 0.67–1.0 mm) displayed. Appropriate diagnosis and treatment procedures are recommended. Terms matching the EHR, e.g., interferon, are highlighted. If interested, the consultant may read footnotes and follow hyperlinks for more details.

10.3 Information Providers in Medicine

There is a large number of information providers in medicine. Some are public institutions such as the US National Institute of Health which provide information for free. Others are commercial, such as Wolters Kluwer. The volume and quality of information provided varies. Some information providers offer application programming interfaces (API) for accessing data from an EHR applications, but others provide only web access.

The following Tables 10.1, 10.2, and 10.3 give an overview of some prominent information providers.

Table 10.1 Drug information sources. (Adapted from [20])
Full size table
Table 10.2 Literature information sources. (Adapted from [20])
Full size table
Table 10.3 EBM information sources. (Adapted from [20])
Full size table

10.4 Ontology-Based Electronic Health Record

Personalized clinical decision support requires EHRs to be semantically linked with evidence-based medical knowledge services. A large amount of EHR data is stored in free-text, providing the maximum flexibility for consultants to express case-specific issues. However, using free-text has a downside for mining EHR data, as medical terminology is used in diverse ways by various medical professionals and across different regions. For example, synonyms are in widespread use in the medical community, along with abbreviations, and even misspellings. While this usually poses no problem for the human expert, it is difficult for software modules to deal with those kinds of ambiguities in a reliable way.

To cope with these issues, text mining approaches have been proposed to disambiguate texts in EHRs [14]. While such an analytic approach is unavoidable when dealing with existing legacy EHR data, we use a constructive approach for new EHR applications: a semantic auto-suggest service (see Fig. 10.4).

Fig. 10.4
figure 4

Semantic auto-suggest [15]

Full size image

While typing input into a free text field, suggestions of medical terms of various categories (anatomy, symptom, disease, etc.) are being presented. For example: “ipilimumab (medication)” is suggested to the user while typing “ip”. While moving the mouse over an entry, an explanatory text is shown. These terms are based on merged ontologies from multiple sources, which are stored in CSV format and can be configured to suit the clinical use case.

Semantic auto-suggest not only improves usability by reducing typing effort for the consultant, but, just as importantly, it normalises the usage of medical terminology: instead of using synonyms, abbreviations or even misspelling terms, the same preferred term is always used for a concrete medical concept.

We identified six distinct semantic categories for a melanoma application: medication, activity, symptom, disease, gene, and anatomy. Some free-text fields require words from one category only, e.g., “medication used by the patient”. Others can be filled with terms from multiple categories, e.g., “other relevant health issues”. See Fig. 10.5.

Fig. 10.5
figure 5

Semantic categories [15]

Full size image

Grounding terms used in the EHR in an ontology is the basis for semantically matching an EHR with information sources like EBM guidelines, see Fig. 10.6. The ontologies used are discussed in more detail below.

Fig. 10.6
figure 6

Semantically matching EHRs with medical information sources

Full size image

Medical terms entered into an EHR are linked to the ontology. Such terms as well as numerical data are extracted from the EHR of a particular patient. The extracted information can be used for semantically retrieving information sources like EBM guidelines which match the conditions of this patient. The relevant information is then displayed to the consultant who is making decisions on patient treatment.

10.5 Ontologies in Medicine

In the medical domain, numerous controlled vocabularies , thesauri and ontologies exist. They contain medical terms and, potentially, additional information such as explanations, synonyms, hyperonyms (broader terms), and domain-specific term relationships. Following Liu and Özsu’s Encyclopedia of Database Systems [16], we use the term “ontology” within this article to refer to all kinds of classified terminology in the medical domain.

Whereas some medical ontologies are commercial (e.g., Unified Medical Language System® Metathesaurus®, SNOMED-CT, etc.), there are many open source ontologies available (for an overview see, e.g., www.ontobee.org).

A challenge that needs to be addressed is how to select an ontology or a set of ontologies as the base vocabulary for the EHR application and map these ontologies to the knowledge requirements of the EHR. In analyzing the melanoma use case, we observed that no single ontology contains all relevant terms, i.e., necessary for the semantic auto-suggest feature. Therefore, we had to integrate several ontologies in order to get a sufficiently comprehensive ontology. For an overview of the ontologies selected, see Table 10.4 for a selection of medical ontologies and their use for different semantic categories.

Table 10.4 Medical ontologies for various semantic categories
Full size table

10.6 Software Architecture

10.6.1 Overview

Figure 10.7 gives an overview of the CDSS software architecture.

Fig. 10.7
figure 7

CDSS software architecture

Full size image

The architecture is separated into an online subsystem and an offline subsystem. The offline subsystem is a batch process for integrating various source ontologies into an application-specific ontology. It is implemented as a semantic extract, transform, load (ETL) process. The online subsystem is organized as a three-layer-architecture consisting of client, business logic and data store. See also ([17]; [22]).

Components with semantic logic are the semantic ETL , ontology services and decision support services. In the following sections, we describe some aspects of the semantic components. For more details see ([13, 15, 20]).

10.6.2 Semantic ETL

For integrating various ontologies into an application-specific ontology, e.g., used for semantic auto-suggest, data needs to be extracted from the source ontologies, transformed, and loaded into a data store (ETL). The following issues need to be addressed:

  1. 1.

    Transformation of technical data formats: Ontologies have different technical formats, e.g., XML, XLS, CSV, RDF. A transformation from the specific to the common format is required.

  2. 2.

    Semantic field mapping: Even if the technical formats are identical, e.g., XML, the individual field names and structure of the ontologies may differ. For example, broader terms in MeSH are encoded as tree id whereas in other ontologies, the ids of the broader terms are listed.

  3. 3.

    Semantic cleansing/filtering: Some terms are “polluted” (have unwanted parts) or are not meaningful for the semantic application. For example, the general term “Non-physical anatomical entity” from the Foundational Model of Anatomy does not denote a concrete body part. Those terms need to be filtered out.

  4. 4.

    Duplicate handling: Duplicate terms occur because some terms are covered in various ontologies (e.g., “Warfarin” is covered in The Drug Ontology and in MeSH), and even in various versions within the same ontology. Duplicates need to be removed.

  5. 5.

    Target data format and storage: The target ontology data format as well as the data store technology used should be targeted towards the intended application. E.g., for semantic auto-suggest a simple data format consisting of term, semantic category, definition, hyponyms, and synonyms suffices. A search index, such as Apache Solr, provides optimal performance and allows semantic search of terms, their category, hierarchy of hyponyms as well as synonyms.

10.6.3 Literature Service

For selecting literature relevant for the patient’s treatment, relevant data needs to be extracted from the EHR and used for querying literature data sources such as PubMed. The semantic matching logic is application-specific; specific to the medical specialty, specific to the EHR management application, and specific to the literature data source.

See Fig. 10.8 for a query generation example from a melanoma EHR for PubMed.

Fig. 10.8
figure 8

Sample query generation from an EHR for PubMed [20]

Full size image

From the ca. 100 attributes that are used in the EHR application, not all are helpful for personalized literature suggestions. Fields with no relevance, such as the patient’s name, are omitted in query generation, whereas relevant fields like the issue, medications or comorbidities are included. The query to be generated must conform to the query language of the data source selected, here, PubMed. The query itself is generated by a rule-based template engine. For example, one rule to search for publications that address the safety or efficacy aspects of the medications prescribed, combines all medications with an “OR” and adds “(safety OR efficacy)” to the subquery. Another rule combines the comorbidities field with the medication to search for drug-related adverse effects and their treatment. To ensure data quality and only search for recent literature, restrictions are added to the query, such as the “hasabstract[text]” to only show publications that contain an abstract.

10.6.4 EBM Recommendation Service

Identifying sections of EBM guidelines which are relevant for a particular patient under treatment requires more than full text search. Consider the patient example above (patient data in Fig. 10.1). The EBM data source chosen are NCCN guidelines, here for melanoma, which are provided as a PDF document. The task is to identify the one section in a 150 page document which exactly matches the patient’s condition. In the example above, the patient’s Breslow thickness is 0.8. Searching for the string “0.8” in the text of the NCCN guidelines will not match the relevant page (ME-3), since on this page, the condition is formulated as “0.67–1.0 mm thick”. Therefore, some explicit decision logic is required for matching extracted EHR data to sections of the EBM guidelines. See Fig. 10.9 for an example rule.

Fig. 10.9
figure 9

Example rule (MS Biztalk Server) [13]

Full size image

Here, the following rule is shown: “If clinical stage is IB and Breslow thickness is between 0.76 and 1.0 mm, then section ME-3 on page 8 is relevant”. This rule is edited using a business rule composer, here MS BizTalk [23].

Applying the rules in a business rule engine with the extracted EHR data as input will match the relevant section of the EBM guidelines which can then be displayed to the consultant in the clinical decision support system. Using a business rule composer may have advantages over coding the decision logic in a conventional programming language. It allows adding or modifying business rules by trained medical administrators whenever new or modified EBM guidelines are published. Where possible metadata such as author, reputation, affiliations, version and time of publication can be used to provide confidence to the users on the accuracy of the presented guidelines.

10.6.5 Implementation

We have successfully implemented the personalised clinical decision support system for melanoma care. The offline subsystem and the business logic has been implemented in C# using Microsoft .Net technology. We use Microsoft SQL server for storing EHRs and Apache Solr for storing and querying the ontology for the semantic auto-suggest service. The client accesses the server via a REST interface. The client is implemented in HTML5/CSS/JavaScript respectively Type Script, using Google’s AngularJS framework. See Fig. 10.7.

10.7 Recommendations

We summarize our main learnings from implementing the personalised clinical decision support system in the following recommendations.

  1. 1.

    When developing a semantic application, carefully look at at regulatory compliance to check what are the constraints on selecting a particular ontology, then check for existing ontologies which suit the application use case. Pay more attention to regulatory compliance and the quality and completeness of data than to technical data formats used. In the medical domain, there are numerous ontologies available.

  2. 2.

    Carefully analyze the quality of ontologies with respect to the application use case. It is most common that no single existing ontology meets the quality requirements of an application use case and can be used without modification.

  3. 3.

    Use Semantic ETL for preprocessing existing ontologies for an application use case. It includes the process steps extraction, transformation, semantic cleansing/filtering, and loading.

  4. 4.

    Ontologies provide a common terminology within a semantic application and may be used for mapping to the terminology of an information provider service.

  5. 5.

    When including services of information providers in semantic applications, carefully check suitability for the application use case, technical constraints, and license details.

  6. 6.

    Semantically mapping EHRs with clinical information sources requires application-specific code, taking into account the specifics of the medical specialty, the EHR application, and the information source.

10.8 Conclusion

Personalised medicine promises many benefits. However, it is not yet in widespread use in clinical practise. We believe that personalised medicine must seamlessly integrate into the consultant’s workflow, posing no additional workload for searching relevant medical information. In this article we have presented a personalised clinical decision support system for cancer care, which provides the consultant treating a patient with relevant medical information based on the patient’s EHR.

We have successfully implemented the clinical decision support system. After successful tests it is planned to be integrated into a commercial EHR application.