Making clinical trials discoverable at the point of care (patient encounter) is one of the holy grails of connecting clinical research with clinical practice [1, 2]. Semantic interoperability standards designed for hospital systems do not interface well with clinical trials, which are predominantly unstructured/free text. In this paper, we describe our experiences of using SNOMED CT and HL7 InfoButton standards to make clinical trials from a trial registry accessible to clinicians within an Electronic Health Record (EHR) system in University College Hospitals, London. In particular we discuss the use of HL7 InfoButton standard [15] as a standardised interface for a clinical trials repository, which we believe is a first of its kind in the UK. We discuss some of the barriers to making clinical trials more accessible in EHR systems, including considerations for using standards and associated challenges & opportunities.
1.1
There is extensive literature that highlights how despite clinical research and trials
being vital to advances in clinical medicine [
In this paper (written as application notes), we describe our experience of
creating Keytrials, a clinical trials discovery platform, designed to make local clinical
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
trials accessible to physicians and patients. While Keytrials makes existing clinical
trials (either local or imported from external registries) available to users via a web
(REST1) API2, our objective was to integrate trial-matching (on-demand) into the
Electronic Health Record (EHR) system. There have been past attempts at creating
electronic solutions and novel specifications for making local registries accessible to
external consumers [
Keytrials is an open source clinical trials discovery platform, designed to make it easier for clinicians and patients to find trials that are open, with a goal to increase trial recruitment and improve visibility of clinical trial activity at University College London Hospital (UCLH), UK. Keytrials is built using modern Web 2.0 and Java enterprise technologies. There is a clean separation of its backend layer from the user interface and backend layers using REST APIs as shown in Figure 1. This makes it easy for other 3rd party applications and other apps to plugin into the RESTful service layer. 1 REST – Representational State Transfer 2 API – Application Programming Interface 3 R&D – Research and Development 4 However, since morbidity and mortality information in hospital systems has traditionally been 2 AcPoId–edApupsilnicgatIiConDPfroorgsratamtumtoinryg rIenpteorrftainceg to the World Health Organisation (WHO), aspects of the clinically relevant information (e.g. diagnosis, age, gender, interventions, etc.) tend to
For the purposes of this paper, three aspects of Keytrials are of interest – R&D3 Environment Integration, Terminology Integration and HL7 InfoButton Integration. Together, these three functionalities allow local (or remote) trials to be accessible for trial-matching within the EHR, at the point of care. 2.1
This functionality allows Keytrials to import existing trials from a clinical trials registry. Within UCLH, existing trials are held in a local trial management system (Edge), which acts as the primary source of trials. However, Keytrials also allows existing trials to be imported from remote registries like ClinicalTrials.gov. 2.2
This functionality allows Keytrials to access a centralized `terminology server` that provides search (lookup) functionality for healthcare terminologies like SNOMED CT. Keytrials uses both the terminological content (e.g. concept ids, descriptions, etc.) and the semantic relationships within SNOMED CT. For example, when users can search for disease conditions they can search for matches using the preferred terms (small cell lung cancer) or synonyms (oat cell carcinoma of lung). Both return the exact trials, since the terminology server resolves them to the same SNOMED CT concept. Keytrials also uses the underlying semantics of SNOMED CT as part of returning matches. For example, if a user searches for `Plasma Cell Neoplasm`, it will also bring back `Multiple Myeloma` even though there is no textual match between Plasma Cell Neoplasm and Multiple Myeloma. It does this because in SNOMED CT, Multiple myeloma is defined as a type of Plasma Cell Neoplasm - which makes results more intuitive to our clinician users. A longer discussion of how SNOMED CT as a standard is implemented in our workflow is discussed in section 3.4. 2.3
UCL Hospitals (UCLH) have recently implemented Epic as their EHR system across
all clinical specialties. As part of this roll out, UCLH decided to adopt SNOMED CT
as the reference terminology for their EHR, in keeping with the national requirements
in the UK. However, instead of natively using SNOMED CT to populate their
diagnosis, UCLH procured a 3rd party content provider that provides an interface
terminology system for clinicians to use. This is mapped to ICD 10 [
3.1
Trials that have been imported into Keytrials have both structured (defined) data
elements (e.g. status, open date, closing date, etc.) and unstructured elements (e.g.
eligibility criteria, description/summary of trial, etc.). In order to match suitable trials with
existing patient details (e.g. age, disease conditions, gender), it is often the eligibility
criteria of a trial that are of most relevance. However, most of this information is
provided as `free-text` in trial, which is not coded to any `standardised` medical
vocabulary/terminology. As described above, the EHR itself is coded in either ICD or
SNOMED CT – leading to situation where trial-matching will require the clinical
trials to also be `coded` using the same coding system. As part of the project, we use
Bio-YODIE [
Context-dependent `infobuttons` have been proposed & used for displaying
contextually relevant knowledge resources within EHRs [
Code systems ICD, SNOMED-CT HL7 administrative gender Not Applicable HL7 Act Code
HL7 Infobutton has been used to varying degrees of success in EHR systems
for clinical decision support, medication alerts and for allowing access to online
references [
Using the URL query parameters specified in the standard, it is possible to create a InfoButton request to a knowledge resource as below: The above request specifies that the value of `age` as `78`. A slightly more realistic query being sent to a test server for Keytrials would look like: This translates to a query for all matching trials suitable for a patient of age 78 years and an ICD-10 diagnosis of `Lung Cancer` (C34).
The workflow within ULCH, is set up such that a when a clinician is with a patient, she/he can right click on a patient’s diagnosis/disease condition to display an option for retrieving matching clinical trials.
This creates an `InfoButton` query that is sent to the `InfoButton API` in Keytrials. As shown in Figure 2, Keytrials then translates this query into its internal representation and creates a list of matching trials. In our project, we chose to conOnce we find an equivalent SNOMED CT concept for an ICD-10 code, we perform a `semantic expansion` based on the meaning of this SNOMED CT concept. For example, when the query is for `T-cell Lymphoma`, we know that in most cases the user is expecting trials for all types of `T-cell Lymphomas`. Our terminology server calculates this `semantic expansion` (transitive closure) on the fly and returns all transitive sub-types (descendants) for that concept. We refer to this `semantic expansion during search` as `semantic search`. This `semantic search` based on SNOMED CT has the added benefit of picking up concepts that would otherwise have been missed by `textbased` search alone. For example, in Figure 3, we are able to include trials for `Lennert’s Lymphoma` as part of `T-cell Lymphoma` trials, since in SNOMED CT it is declared as a sub-type of `T-cell Lymphoma`. Any `text-based` search for `T-cell Lymphomas` would have likely missed `Lennert’s Lymphoma` as it does not have the token `T-cell` in it.
Since the ability to support queries is based on the HL7 InfoButton and SNOMED CT standards, we believe our approach should be adoptable by other investigators. We believe that within the UK we are the first project to adopt InfoButton and SNOMED CT standards for accessing clinical trials from an EHR system. This approach however was not without issues given how clinical trials and clinical medicine do not often support the same standards. We share some of our experiences in this section. These challenges can be separated into trials related and EHR related issues. 4.1
We have previously mentioned how existing large registries of trials have issues in
staying up to date with trials that are on-going and open for recruitment. This
continues to be a problem even in smaller registries. In our project, we were forced to build
a batch import integration between the local trial management system and Keytrials.
This batch import is currently run weekly to ensure that Keytrials is kept in sync with
the updates to local trial registry. We however recognise that creating integrations for
multiple local trial registry systems will be expensive as every system will likely have
its own internal representation. Standards based interchange format would help
simplify this task. While CDISC-ODM [
A further issue with making clinical trials accessible to EHR systems is the
inability to explicitly specify eligibility criteria (inclusion, exclusion criteria, disease
conditions, interventions, etc.) as structured/coded entities. While FHIR seems to
allow this level of specification in the future, a vast number of existing studies are
free-text based, limiting the ability to automatically match trials to coded diagnosis,
age or other information in EHR systems. This limitation can be overcome using NLP
as adopted within our project and other initiatives [
Similar to the state of clinical trials ecosystem, the landscape in EHRs is still riddled with large amounts of un-coded and unstructured free-text information4. While having 4 However, since morbidity and mortality information in hospital systems has traditionally been coded using ICD for statutory reporting to the World Health Organisation (WHO), aspects of the clinically relevant information (e.g. diagnosis, age, gender, interventions, etc.) tend to be coded more commonly. ICD-10 used for coding diagnosis provides a slightly better starting point for integrating EHRs with clinical trials, often the level of granularity required by researchers and physicians interested in research is not provided by ICD as it was primarily designed for statistical reporting.
SNOMED CT is starting to see adoption across the globe and in the UK, but within our project we note that Epic did not support SNOMED CT natively. This meant that when we had to integrate our EHR (coded using ICD-10) with clinical trials (annotated using SNOMED CT via NLP), we were forced to use ICD codes as part of the `mainSearchCriteria` attribute in InfoButton to send diagnosis codes to Keytrials. This required a workaround within Keytrials, where all ICD codes passed via InfoButton were then processed by the `terminology server` to convert them into corresponding SNOMED CT codes. As knowledgeable readers will note, going from ICD-10 to SNOMED CT will often result in a `lossy` transform, as SNOMED CT is often more granular/specific than ICD. This `lossy transform` and incorrect use of the semantics of SNOMED CT while perhaps not immediately relevant for trial-matching is likely to become more important when automated trial-matching becomes more prevalent. We believe that with greater adoption of SNOMED CT, we will likely see native use of this standard in EHR systems in the future so these `lossy` transforms can be avoided.
While not immediately part of the EHR issues, we also noted within our project that the use of SNOMED CT presented interesting challenges. For example, in SNOMED CT searching for `adenocarcinoma` might present two exact matches – one of them being a `morphological abnormality` and the other being a `disorder` making it confusing for users as to which match to select. This can easily be addressed by ensuring that only relevant SNOMED CT hierarchies are included by default during search – in this case only including `clinical findings` hierarchy from SNOMED CT. However, it should also be noted that even within `clinical finding` hierarchy, exactly named matches could sometimes appear. For example, searching for `fatigue` might return a `symptom` and a `disorder`, both of which are part of the `clinical finding` hierarchy. Needless to say, like all clinical information systems using a terminology, a degree of clinical assurance is required to improve usability.
However, on the whole using a combination of SNOMED CT and InfoButton has provided a degree of assurance and flexibility within our project. We believe that as clinical trials registries and EHR systems continue to mature, standards based integration will continue to become more prevalent and a lot more plug-n-play. 5
In this paper we shared our experience of using existing healthcare standards SNOMED CT and HL7 InfoButton to make data in a clinical trials accessible to EHR systems. While InfoButton has been used with mixed results in other domains, it has not been previously been used to access clinical trials in the UK. One major challenge in making clinical trials discoverable and connecting them to EHRs is the lack of standardisation of trial eligibility criteria – with most being just un-coded, free-text content. This is a barrier for matching patients to eligible trials, even if relevant information (coded diagnosis, age, gender, etc.) is already available within the patient record in the EHR system. We used an NLP approach to annotate eligibility criteria (e.g. disease conditions) in SNOMED CT, thereby allowing us to use a fuller range of InfoButton query parameters to match trials to patients directly from the EHR system.
Since our approach is based on international standards, we believe it could serve as a means of creating reusable integrations between clinical trial registries with EHR systems. However, the lack of standardisation of clinical trials might mean that significant effort is required to integrate a clinical trials registry needs to a HL7 Infobutton compliant EHR system. We note that a standardised specification of clinical trials could make this integration less onerous. However, existing standards for clinical trials do not yet specify this level of detail (CDISC-ODM) and others are not yet sufficiently mature to meet this need (HL7 FHIR). A similar, albeit slightly different problem exists within EHR systems where relevant information is coded but in ICD10, which does not always provide the level of detail required for clinical research. However the increasing adoption of SNOMED CT in this space will likely solve that issue, even if SNOMED CT itself comes with its own set of challenges. We hope that as standards for clinical trials and EHRs mature and become more widely adopted, it will be possible to make clinical trials discoverable at the point of care in EHR systems using a plug-n-play model.
Acknowledgements The authors would like to acknowledge that UCLH BRC (Biomedical Research Centre) and CRIU (Clinical Research Informatics Unit) funded development of the Keytrials platform.