Which computable biomedical knowledge objects will be regulated? Results of a UK workshop discussing the regulation of knowledge libraries and software as a medical device

Abstract

IntroductionTo 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.MethodsA 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.ResultsThis 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.ConclusionsIf 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.

Modelling clinical narrative as computable knowledge: The NICE computable implementation guidance project

“…We suggest that using a technology‐agnostic and commercially neutral logical model such as the WHO DAK is (a) a more achievable first step when starting from scratch in an unfunded project and (b) more stable than a technical implementation model for a particular stack, and (c) has the advantage of not being subject to regulation as it is not directly executable. 43 Having said that, we see the FHIR Clinical Guidelines implementation guide as an important area for future work. We also believe there are improvements that can be made to the DAK, which we shall report elsewhere.…”