Requirements and validation of a prototype learning health system for clinical diagnosis

Abstract

Introduction: Diagnostic error is a major threat to patient safety in the context of family practice. The patient safety implications are severe for both patient and clinician. Traditional approaches to diagnostic decision support have lacked broad acceptance for a number of well-documented reasons: poor integration with electronic health records and clinician workflow, static evidence that lacks transparency and trust, and use of proprietary technical standards hindering wider interoperability. The learning health system (LHS) provides a suitable infrastructure for development of a new breed of learning decision support tools. These tools exploit the potential for appropriate use of the growing volumes of aggregated sources of electronic health records.

Methods: We describe the experiences of the TRANSFoRm project developing a diagnostic decision support infrastructure consistent with the wider goals of the LHS. We describe an architecture that is model driven, service oriented, constructed using open standards, and supports evidence derived from electronic sources of patient data. We describe the architecture and implementation of 2 critical aspects for a successful LHS: the model representation and translation of clinical evidence into effective practice and the generation of curated clinical evidence that can be used to populate those models, thus closing the LHS loop.

Results/conclusions: Six core design requirements for implementing a diagnostic LHS are identified and successfully implemented as part of this research work. A number of significant technical and policy challenges are identified for the LHS community to consider, and these are discussed in the context of evaluating this work: medico-legal responsibility for generated diagnostic evidence, developing trust in the LHS (particularly important from the perspective of decision support), and constraints imposed by clinical terminologies on evidence generation.

Keywords: diagnostic decision support systems; knowledge discovery; knowledge representation; learning health systems.

Figure 1

Component architecture of the TRANSFoRm decision support system. EHR indicates electronic health record

Figure 2

Core ontology concepts and relationships for knowledge representation. RfE indicates reason for encounter

Figure 3

Example of cue ontology concept instance for “history of irritable bowel syndrome.” RfE indicates reason for encounter

Figure 4

The steps of the knowledge derivation process using data mining. KNIME indicates Konstanz Information Miner

Figure 5

Filters available in the web tool for clinical evidence review. RfE indicates reason for encounter

Figure 6

The rule detail selection window showing textual descriptions of dysuria as a presenting complaint indicating urinary tract infection for the Netherlands population

Figure 7

Generation of urinary tract infection association rules export Extensible Markup Language from the web rule sender

Figure 8

Association rule available evidence made available as a quantified value through the clinical evidence service

Figure 9

Evidence service implementation technologies. API indicates Application Programmable Interface; OWL, Web Ontology Language; RDF, Resource Description Framework; SPARQL, Sesame triple store query language

Figure 10

An evidence service reply describing the symptoms of urinary tract infection including frequency and haematuria with associated code bindings

Figure 11

An Extensible Markup Language patient evidence case submitted to the evidence service for a female patient presenting with chest pain and symptoms including fatigue

Figure 12

The integrated diagnostic decision support window accessible from the patient electronic health record shown in the background (the data presented are of a simulated patient)