Over the last couple of years the interest in using AI technologies to support clinical processes has increased massively. The combination of the AI technology improving, and becoming more accessible, with general awareness of available technologies increasing has led to a drive to use AI.
As this is an area which I am increasingly asked to support from both a regulatory and strategic perspective I thought it would be worth putting some reflections down.
All the hype in this area got me thinking about the basics of system or process design. It is often said that one issue that technology companies have when is approaching healthcare that they develop solutions which are looking for a problem, rather than responding to a problem by developing a solution. In my experience it is not just the technology providers who fall into this trap when faced with the lure of available AI products. There sometimes seems to be a drive to use AI as the primary goal rather than as the most appropriate tool to achieve the best outcomes.
This is where the importance of a use case comes in. A use case is a story about how a set of behaviours achieves a goal (or meets a need) of a user of the system. It essentially defines the purpose of a product. A product without a well-defined use case is unlikely to deliver. The use case should lead to the definition of the requirements for any system, which in turn leads to the appropriate technological solution.
Unsurprisingly a use case is often not a simple interaction between a behaviour or input and the goal or output. Requirements are likely to interact with each other and may even conflict. Interactions may be driven by system interfaces or other aspects of system design, or by the clinical environment a product will be used in. System interactions are likely to affect the user and patient experience, and may influence how a user themselves interacts with a system.
When thinking about a use case it makes sense to start with the simplest possible requirements. By capturing user requirements or needs, developing these into clear systems requirements, followed by breaking these down into defined, executable, and testable subsystem requirements we have a process that can be followed and tested – the product development lifecycle. These steps can apparently be easily forgotten in the excitement of bringing AI into clinical practice. I have recently seen products being suggested or developed that for example promote using a LLM to interrogate a clinical record to identify particular terms, where in fact a LLM provides no advantage over basic search functionality.
The use case also has very important implications in terms of the regulatory requirements for healthcare IT. The use case drives the intended purpose of a product and the intended purpose will be how a product is judged in terms of regulatory need. In terms of the UK Medical Device Regulations there are a set of well-defined medical purposes which if a product fulfils any of these it becomes a medical device and needs to be registered as such.
Figure 1: Medical Purpose as set out in the UK MDR
The definition of the intended purpose as per the UK MDR is:
Intended Purpose: the use for which the device is intended according to the data supplied by the manufacturer on the labelling, in the instructions and/or in promotional materials.
This is distinct from the:
Indications for use: the clinical condition that is to be diagnosed, prevented, monitored, treated, alleviated, compensated for, replaced, modified or controlled by the medical device. It should be distinguished from ‘intended purpose/intended use’, which describes the effect of a device.
Failure to adequately define the intended purpose of a medical device will impair any subsequent efforts to comply with medical device regulation. MHRA consider an inadequately defined intended purpose as a potential serious failure to meet key medical device requirements.
There is overlap between the intended purpose and the use case, but they are not quite the same thing. In terms of how we capture a use case, this has been laid out by Cockburn as follows:
1. Name the system scope and boundaries.
2. Brainstorm and list the primary actors.
3. Brainstorm and exhaustively list user goals for the system.
4. Capture the outermost summary use cases to see who really cares.
5. Reconsider and revise the summary use cases. Add, subtract, or merge goals.
6. Select one use case to expand.
7. Capture stakeholders and interests, preconditions and guarantees.
8. Write the main success scenario (MSS).
9. Brainstorm and exhaustively list the extension conditions.
10. Write the extension-handling steps.
11. Extract complex flows to sub use cases; merge trivial sub use cases.
12. Readjust the set: add, subtract, merge, as needed.
Whereas the suggested approach to defining an intended purpose as per the UK MDR includes the following steps:
1. Structure and Function of the device
2. Intended population
3. Intended user
4. Intended use environment
Figure 2: Further detail of how the intended purpose can be developed and aligns with the MDR
There are many issues of a poorly defined use case and or intended purpose as already alluded to. A further issue that can cause difficulty is function creep. In this instance over time, additional functionality is added to the product and the intended purpose becomes vague with a mismatched evidence base. This issue doesn’t relate to the initial creation of the intended purpose but to expanding the intended purpose, it is useful to consider these risks. This is especially for software products which do not qualify as SaMD but where additional functionality leads to product claims that fall within the scope of medical device regulations.
Hopefully I have what I have described highlights how the use case has particular importance when initiating the product development process as it enables appropriate technology tools to be chosen to solve the identified problems, rather than taking the approach of seeing how a particular technology can be used in a clinical area or to address an undefined need.
References:
- MHRA Software Flowchart: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/548313/Software_flow_chart_Master.pdf
- Guidance: Crafting an Intended Purpose In the Context of Software as a Medical Device: https://www.gov.uk/government/publications/crafting-an-intended-purpose-in-the-context-of-software-as-a-medical-device-samd/crafting-an-intended-purpose-in-the-context-of-software-as-a-medical-device-samd
- Writing Effective Use Cases, by Alistair Cockburn, Addison-Wesley Professional; 1st edition (2000)