Search

Introduction: To understand when knowledge objects in a computable biomedical knowledge library are likely to be subject to regulation as a medical device in the United Kingdom. Methods: A briefing paper was circulated to a multi‐disciplinary group of 25 including regulators, lawyers and others with insights into device regulation. A 1‐day workshop was convened to discuss questions relating to our aim. A discussion paper was drafted by lead authors and circulated to other authors for their comments and contributions. Results: This article reports on those deliberations and describes how UK device regulators are likely to treat the different kinds of knowledge objects that may be stored in computable biomedical knowledge libraries. While our focus is the likely approach of UK regulators, our analogies and analysis will also be relevant to the approaches taken by regulators elsewhere. We include a table examining the implications for each of the four knowledge levels described by Boxwala in 2011 and propose an additional level. Conclusions: If a knowledge object is described as directly executable for a medical purpose to provide decision support, it will generally be in scope of UK regulation as "software as a medical device." However, if the knowledge object consists of an algorithm, a ruleset, pseudocode or some other representation that is not directly executable and whose developers make no claim that it can be used for a medical purpose, it is not likely to be subject to regulation. We expect similar reasoning to be applied by regulators in other countries. [ABSTRACT FROM AUTHOR]

Introduction: Translating narrative clinical guidelines to computable knowledge is a long‐standing challenge that has seen a diverse range of approaches. The UK National Institute for Health and Care Excellence (NICE) Content Advisory Board (CAB) aims ultimately to (1) guide clinical decision support and other software developers to increase traceability, fidelity and consistency in supporting clinical use of NICE recommendations, (2) guide local practice audit and intervention to reduce unwarranted variation, (3) provide feedback to NICE on how future recommendations should be developed. Objectives: The first phase of work was to explore a range of technical approaches to transition NICE toward the production of natively digital content. Methods: Following an initial 'collaborathon' in November 2022, the NICE Computable Implementation Guidance project (NCIG) was established. We held a series of workstream calls approximately fortnightly, focusing on (1) user stories and trigger events, (2) information model and definitions, (3) horizon‐scanning and output format. A second collaborathon was held in March 2023 to consolidate progress across the workstreams and agree residual actions to complete. Results: While we initially focussed on technical implementation standards, we decided that an intermediate logical model was a more achievable first step in the journey from narrative to fully computable representation. NCIG adopted the WHO Digital Adaptation Kit (DAK) as a technology‐agnostic method to model user scenarios, personae, processes and workflow, core data elements and decision‐support logic. Further work will address indicators, such as prescribing compliance, and implementation in document templates for primary care patient record systems. Conclusions: The project has shown that the WHO DAK, with some modification, is a promising approach to build technology‐neutral logical specifications of NICE recommendations. Implementation of concurrent computable modelling by multidisciplinary teams during guideline development poses methodological and cultural questions that are complex but tractable given suitable will and leadership. [ABSTRACT FROM AUTHOR]

Inputs and Outputs: The Strike‐a‐Match Function, written in JavaScript version ES6+, accepts the input of two datasets (one dataset defining eligibility criteria for research studies or clinical decision support, and one dataset defining characteristics for an individual patient). It returns an output signaling whether the patient characteristics are a match for the eligibility criteria. Purpose: Ultimately, such a system will play a "matchmaker" role in facilitating point‐of‐care recognition of patient‐specific clinical decision support. Specifications: The eligibility criteria are defined in HL7 FHIR (version R5) EvidenceVariable Resource JSON structure. The patient characteristics are provided in an FHIR Bundle Resource JSON including one Patient Resource and one or more Observation and Condition Resources which could be obtained from the patient's electronic health record. Application: The Strike‐a‐Match Function determines whether or not the patient is a match to the eligibility criteria and an Eligibility Criteria Matching Software Demonstration interface provides a human‐readable display of matching results by criteria for the clinician or patient to consider. This is the first software application, serving as proof of principle, that compares patient characteristics and eligibility criteria with all data exchanged using HL7 FHIR JSON. An Eligibility Criteria Matching Software Library at https://fevir.net/110192 provides a method for sharing functions using the same information model. [ABSTRACT FROM AUTHOR]

Abstract Introduction Translating narrative clinical guidelines to computable knowledge is a long‐standing challenge that has seen a diverse range of approaches. The UK National Institute for Health and Care Excellence (NICE) Content Advisory Board (CAB) aims ultimately to (1) guide clinical decision support and other software developers to increase traceability, fidelity and consistency in supporting clinical use of NICE recommendations, (2) guide local practice audit and intervention to reduce unwarranted variation, (3) provide feedback to NICE on how future recommendations should be developed. Objectives The first phase of work was to explore a range of technical approaches to transition NICE toward the production of natively digital content. Methods Following an initial ‘collaborathon’ in November 2022, the NICE Computable Implementation Guidance project (NCIG) was established. We held a series of workstream calls approximately fortnightly, focusing on (1) user stories and trigger events, (2) information model and definitions, (3) horizon‐scanning and output format. A second collaborathon was held in March 2023 to consolidate progress across the workstreams and agree residual actions to complete. Results While we initially focussed on technical implementation standards, we decided that an intermediate logical model was a more achievable first step in the journey from narrative to fully computable representation. NCIG adopted the WHO Digital Adaptation Kit (DAK) as a technology‐agnostic method to model user scenarios, personae, processes and workflow, core data elements and decision‐support logic. Further work will address indicators, such as prescribing compliance, and implementation in document templates for primary care patient record systems. Conclusions The project has shown that the WHO DAK, with some modification, is a promising approach to build technology‐neutral logical specifications of NICE recommendations. Implementation of concurrent computable modelling by multidisciplinary teams during guideline development poses methodological and cultural questions that are complex but tractable given suitable will and leadership.

Abstract Inputs and Outputs The Strike‐a‐Match Function, written in JavaScript version ES6+, accepts the input of two datasets (one dataset defining eligibility criteria for research studies or clinical decision support, and one dataset defining characteristics for an individual patient). It returns an output signaling whether the patient characteristics are a match for the eligibility criteria. Purpose Ultimately, such a system will play a “matchmaker” role in facilitating point‐of‐care recognition of patient‐specific clinical decision support. Specifications The eligibility criteria are defined in HL7 FHIR (version R5) EvidenceVariable Resource JSON structure. The patient characteristics are provided in an FHIR Bundle Resource JSON including one Patient Resource and one or more Observation and Condition Resources which could be obtained from the patient's electronic health record. Application The Strike‐a‐Match Function determines whether or not the patient is a match to the eligibility criteria and an Eligibility Criteria Matching Software Demonstration interface provides a human‐readable display of matching results by criteria for the clinician or patient to consider. This is the first software application, serving as proof of principle, that compares patient characteristics and eligibility criteria with all data exchanged using HL7 FHIR JSON. An Eligibility Criteria Matching Software Library at https://fevir.net/110192 provides a method for sharing functions using the same information model.

Abstract Introduction To understand when knowledge objects in a computable biomedical knowledge library are likely to be subject to regulation as a medical device in the United Kingdom. Methods A briefing paper was circulated to a multi‐disciplinary group of 25 including regulators, lawyers and others with insights into device regulation. A 1‐day workshop was convened to discuss questions relating to our aim. A discussion paper was drafted by lead authors and circulated to other authors for their comments and contributions. Results This article reports on those deliberations and describes how UK device regulators are likely to treat the different kinds of knowledge objects that may be stored in computable biomedical knowledge libraries. While our focus is the likely approach of UK regulators, our analogies and analysis will also be relevant to the approaches taken by regulators elsewhere. We include a table examining the implications for each of the four knowledge levels described by Boxwala in 2011 and propose an additional level. Conclusions If a knowledge object is described as directly executable for a medical purpose to provide decision support, it will generally be in scope of UK regulation as “software as a medical device.” However, if the knowledge object consists of an algorithm, a ruleset, pseudocode or some other representation that is not directly executable and whose developers make no claim that it can be used for a medical purpose, it is not likely to be subject to regulation. We expect similar reasoning to be applied by regulators in other countries.

The use and shareability of Clinical Quality Language (CQL) artefacts is an important aspect in enabling the exchange and interoperability of clinical data to support both clinical decisions and research in the medical informatics field. This paper, while basing on use cases and synthetic data, developed purposeful CQL reusable libraries to showcase the possibilities of multidisciplinary teams and how CQLs could be best used to support clinical decision making. [ABSTRACT FROM AUTHOR]

Computable knowledge artefact development is challenging and often culminates in the development of unique single usage solutions. Libraries of computable knowledge artefacts have the possibility to enhance the Learning Health System in order to improve the benefits of innovation and the decision making of clinicians. This paper aims to discuss the process of creating the use cases and the tutorial material that would enable students to both understand how the interaction between the dataset and the outcome occurs as well as how HL7 Clinical Quality Language can be used to create artefacts of re-usable code. [ABSTRACT FROM AUTHOR]

Background: Guideline-directed medical therapy (GDMT) optimization can improve outcomes in heart failure with reduced ejection fraction., Objectives: The objective of this study was to determine if a novel computable algorithm appropriately recommended GDMT., Methods: Clinical trial data from the GUIDE-IT (Guiding Evidence-Based Therapy Using Biomarker Intensified Treatment in Heart Failure) and HF-ACTION (Heart Failure: A Controlled Trial Investigating Outcomes of Exercise Training) trials were evaluated with a computable medication optimization algorithm that outputs GDMT recommendations and a medication optimization score (MOS). Algorithm-based recommendations were compared to medication changes. A Cox proportional-hazards model was used to estimate the associations between MOS and the composite primary end point for both trials., Results: The algorithm recommended initiation of angiotensin-converting enzyme inhibitor/angiotensin receptor blocker, beta-blockers, and mineralocorticoid receptor antagonists in 52.8%, 34.9%, and 68.1% of GUIDE-IT visits, respectively, when not prescribed the drug. Initiation only occurred in 20.8%, 56.9%, and 15.8% of subsequent visits. The algorithm also identified dose titration in 48.8% of visits for angiotensin-converting enzyme inhibitor/angiotensin receptor blockers and 39.4% of visits for beta-blockers. Those increases only occurred in 24.3% and 36.8% of subsequent visits. A higher baseline MOS was associated with a lower risk of cardiovascular death or heart failure hospitalization (HR: 0.41; 95% CI: 0.21-0.80; P  = 0.009) in GUIDE-IT and all-cause death and hospitalization (HR: 0.61; 95% CI: 0.44-0.84; P  = 0.003) in HF-ACTION., Conclusions: The algorithm accurately identified patients for GDMT optimization. Even in a clinical trial with robust protocols, GDMT could have been further optimized in a meaningful number of visits. The algorithm-generated MOS was associated with a lower risk of clinical outcomes. Implementation into clinical care may identify and address suboptimal GDMT in patients with heart failure with reduced ejection fraction., Competing Interests: Dr Dorsch is supported by R18 HS026874 from the Agency for Health Research and Quality, R01 AG062582 and R61 HL155498 from the 10.13039/100000002National Institutes of Health, and the American Health Association Health IT Strategically Focused Research Network. Dr Hummel is supported by a grant from 10.13039/100000738Veterans Affairs CARA-009-16F9050 and R01 AG062582 and R61 HL155498 from the 10.13039/100000002National Institutes of Health. Dr Koelling is supported by R01 AG062582 from the 10.13039/100000002National Institutes of Health. All other authors have reported that they have no relationships relevant to the contents of this paper to disclose., (© 2023 The Authors.)