An ontology driven clinical evidence service providing diagnostic decision support in family practice.

Formulation of a working diagnostic hypothesis in family practice requires consideration of many differential diagnoses associated with any presenting patient complaint. There follows a process of refinement of the differentials to consider, through ruling in or out each candidate differential based on the confirmed presence or absence of diagnostic cues elicited during patient consultation. The patient safety implications of diagnostic error are potentially severe for patient and clinician. This paper describes a clinical evidence service supporting this diagnostic process. It allows decision support consumers to provide coded evidence-based recommendations to assist with diagnostic hypothesis formulation, integrated with an EHR in primary care. The solution implements ontology models of evidence accessible to consumers as a web service using open source components and standards. An implementation example is described that consumes the service to drive a diagnostic decision support tool developed for the TRANSFoRm project.

Introduction and Background

The nature of family practice requires familiarity with a wider range of clinical conditions than specialists working in secondary care. The diagnostic process in family practice requires formulation of a working diagnosis based on the primary presenting patient complaint or reason for encounter (RFE) (1). Consideration is given to each candidate differential diagnosis with a view to ruling it in or out based on the confirmed patient diagnostic cues identified through consultation (2). This process can fail and diagnostic error has been shown to be a major threat to patient safety in the family practice setting (3–4). The knowledge base available to any clinician may be limited by their own case experience or, in the case of rare or unfamiliar conditions, distorted through cognitive bias. This may distort the initial formulation of differentials to consider which has been shown to be a crucial first step in the diagnostic process (5). This paper describes the design, development and implementation of a clinical evidence service for the TRANSFoRm project (6). The service supports the diagnostic process in family practice by allowing querying and refinement of coded clinical evidence supporting candidate differentials to consider based on submission of the patient presenting RFE and consultation diagnostic cues.

Methods

Evidence Service Design

The clinical concepts to support a diagnostic process have been modelled as an ontology of clinical evidence (figure 1). This allows representation of the relationships between a presenting patient reason for encounter and the associated candidate differential diagnoses to consider. The evidence relating to any particular diagnosis is captured as associated diagnostic cues, of which there are cue sub-concepts to represent clinician observed signs, patient reported symptoms, risk factors and clinical tests. The ontology design methodology used is based on the design practices advocated by the work of Gruninger and Fox (7). Semantic interoperability support is provided for by the ‘code binding’ concept, separate and independent of the clinical concepts. This is used to associate potentially many different clinical terminology codes for any single ontology RFE, cue or diagnosis.

Figure 1:

Core evidence ontology concepts.

Specifically we have supported interoperability with a single EHR vendor in the UK using NHS read codes version 3 (8). Localisation support to allow easier searching by a third party consumer for ontology terms using locally defined synonyms is provided for by the ‘synonym’ concept. An example of concepts and associated instances (in red) of the diagnostic cue concept for a patient history of irritable bowel syndrome, with an associated NHS read ‘14CF.00’ and local synonym ‘HO IBS’ is shown in figure 2. The ontology can support other coding schemes including ICP2, ICD10, SNOMED and UMLS (9–11).

Figure 2:

Example of cue ontology concept instance for ‘history of irritable bowel syndrome’.

Evidence Service Implementation

The clinical evidence service consists of three implementation layers. The ontology is implemented as an OWL ontology using Protégé version 4.3 and hosted on a Sesame triple store (12–14).

The implementation technologies for the three layers are summarised in figure 3. The persistence layer provides a data store for ontology hosting upon which the evidence service is constructed. This provides a platform for multi-user access and dynamic update of ontology clinical content through a programmable API. The service layer provides a fully functional Jersey REST based web interface with defined endpoints to allow parameterised querying of diagnostic questions based on patient data supplied from a third party consumer (15).

Figure 3:

Evidence service implementation technologies.

Using structured evidence service endpoints we can access any ontology content with results returned as XML (default), JSON or RDF formats (16–18). The REST query to access the differentials to consider for a patient presenting with abdominal pain for example is:

http://phaedrus.scss.tcd.ie/munnellg/ClinicalEvidenceRESTService/interfaces/query/rfes/differentials/AbdominalPainRFE

To access the cues supporting diagnosis of urinary tract infection (output shown in figure 4) the query is:

Figure 4:

An evidence service reply describing a symptom collection for Urinary Tract Infection including Frequency and Haematuria.

http://phaedrus.scss.tcd.ie/munnellg/ClinicalEvidenceRESTService/interfaces/query/differentials/cues/UrinaryTractInfection

Sesame also provides flexibility beyond the defined endpoints by providing functionality to process custom ad-hoc SPARQL queries executed directly against its own accessible web service interface.

The client layer provides a client side library used to handle exchange of patient data between the third party consumer with appropriate calls sent to the backend evidence service. The client accepts patient data in the form of a XML patient evidence set describing the patient RFE, demographics and the underlying cues confirmed through consultation with the patient (figure 5). The evidence service returns recommendations in the form of a dynamically updated ranked list of differentials to consider by keeping a cue count for each differential under consideration. This list is based on the presenting RFE and ordered in descending cue count based on the number of patient cues confirmed present for each differential along with the supporting underlying evidence cues for each diagnosis. An interactive and iterative diagnostic conversation can take place between the third party consumer as presence or absence of patient cues are confirmed, appropriate patient contextualised REST queries are executed and the re-ranked diagnosis list is supplied to the consumer tool.

Figure 5:

An XML patient evidence set submitted to the evidence service for a female patient presenting with chest pain and symptoms including fatigue.

Results

The evidence service implements diagnostic content from systematic review of evidence based sources that identified appropriate diagnostic cues for seventy eight diagnostic conditions relating to three presenting patient complaints: abdominal pain, chest pain and dyspnoea. The TRANSFoRm project has used this to provide ontology driven prompting and recording of coded patient diagnostic cues from a separately developed diagnostic decision support tool embedded and interoperable with an EHR in family practice (the Vision 3 EHR). This allows bottom-up input of observed patient cues independent of associated diagnosis (left window) or top-down drilling into and selection of evidence cues supporting specific diagnoses (right window). A dynamically updated cue count is maintained for each differential diagnosis indicating the number of evidence cues that are confirmed as present based on the patient cues elicited. As each patient cue is selected the cue counts are recalculated. The differentials are re-ranked in descending order based on the cue count. In addition each diagnosis has a prevalence category assigned to it (common, uncommon and rare). Where differentials have the same number of cues present they are ordered by highest prevalence first. These are used to dynamically rank potential differential diagnoses to consider (most likely at top) based on the patient presenting RFE along with the evidence supporting each diagnosis under consideration (figure 6). Upon exiting the tool a working diagnosis can be confirmed and the coded evidence cues and current working diagnosis can be saved back and recorded for future reference in the patient EHR.

Figure 6:

The diagnostic decision support window accessible from the patient EHR record shown in the background

The tool is separately undergoing evaluation of diagnostic accuracy and ease of use by researchers at Kings College London. A sample of 32 UK family practitioners has been trained to use the tool prior to use. Diagnostic performance is compared between family practitioners with and without access to the tool. Performance is tested against predefined diagnostic scenarios represented by actors in simulated family practice encounters. Ease of use is assessed using a tool usability questionnaire.

Discussion

The implementation of the clinical evidence service can be contrasted with other comparable approaches (19). The unique features of this work include the provision of an evidence base provided through an open service-oriented architecture combined with an ontology model that is independent of any specific diagnostic condition. The provision of an ontology model driven by the concept of the RFE allows for a combination of top-down or bottom-up diagnostic reasoning making it particularly suited to the requirements of the diagnostic process in family practice. The hosting of the ontology on a triple-store platform is flexible enough to provide for future population of content programmatically from dynamically generated clinical content using identification of diagnostic associations from aggregated sources of coded EHR data. The TRANSFoRm project has already developed a data mining tool to allow for generation of quantified empirical evidence based on association rules that can be imported into the evidence service. Future work will assess the feasibility of using data mined evidence to rank differentials under consideration using Bayesian methods.