Intruduction
Speech recognition tools are one of the most exciting new technologies in healthcare. The principle behind this type of application is simple: it turns speech into text. As a result, doctors no longer have to type information – they can simply dictate their notes, and the generated text appears automatically in the system.
Studies show that these types of tools actually save time.
Doctors using medical scribes complete documentation 35-40% faster than with traditional methods. It’s no wonder that more than 60 companies are now developing these types of solutions, and that major EHR vendors are adding these capabilities to their medical systems.
Healthcare software must follow many rules, and the European Union has a complete set of requirements that vendors must follow when developing medical technology solutions.
Speech recognition tools face a double challenge: not only do they handle sensitive patient data from interviews, but they also incorporate artificial intelligence to improve speech recognition. This combination means that developers must navigate multiple regulatory frameworks when creating these solutions.
In the following article, we will try to present the legal situation of speech recognition tools from the perspective of the Medical Device Regulation. We will answer the question of whether, and if so in what situations, this type of software should apply for the famous CE mark.
The answer depends on many factors. We invite you to read on!
Table of contents:
- Functionalities of medical scribes.
- What is a medical device and what is not?
- When a medical scribe is not MDR?
- When is a medical scribe covered by MDR?
- Summary
Disclaimer: We are not a law firm. Our article only serves to help you understand the current legal situation. For comprehensive understanding, we refer you to the original texts of the regulations we discuss here. If you need professional advice, we recommend contacting a law firm specializing in these issues.
Disclaimer 2: This article is current as of its publication date. It will be updated when possible.
Functionalities of medical scribes
We need to be clear about which tools we’re discussing. The market offers many different options with varying features. For this analysis, we can identify 4 levels of speech-to-text tools for doctors: ranging from basic transcription apps to complete clinical assistants.
Level 0 – Basic medical transcription
- Conversion of speech to plain text
- No medical structuring or formatting
- Used mainly for dictating notes, not necessarily patient conversations
- Example: standard text dictation tools that differ from basic scribes by correctly recognizing specific medical terms like “ophthalmoplasty” or abbreviations like “CRP,” “X-ray.”
Level 1 – Transcription with medical structuring
- Converts speech to text
- The tool can structure text into a ready medical note; highlighting basic documentation elements (e.g., history, examination)
- Sometimes these tools have speaker recognition features
- They have interview summarization options
- Example: a tool listens to a doctor-patient conversation, transcribes everything in real-time, and then organizes the recorded text into a form ready to be added to electronic medical records.
Level 2 – Environmental listening + interpretation
- The application listens to, for example, a doctor-patient conversation, then presents a ready medical note
- It extracts key information from the conversation, rejects side threads, presenting only information relevant from a treatment perspective
- The tool creates, for example, consultation notes according to a selected template
- Example: a tool listens to a doctor-patient conversation, then creates a new note containing only relevant information, in a form ready to be added to electronic medical records.
Level 3 – Advanced clinical assistant
- Has all functions from level 2
- Tools typically integrated with EHR systems, having access to patient medical records
- Based on transcription, they suggest appropriate ICD codes and procedures
- Offer support in the diagnostic-therapeutic process, e.g., suggesting differential diagnoses, offering further diagnostic proposals, or therapeutic recommendations
- Identification of potential risks and contraindications
- Example: A doctor conducts a consultation with a patient with chest pain. The assistant not only creates a structured interview note but also suggests possible diagnoses, reminds about key tests, warns about potential drug interactions based on the patient’s history, and proposes appropriate ICD codes for the diagnosis.
It’s easy to see that the higher the tool level, the more complex the solution. The most advanced applications offer much more than simple transcription, becoming a true clinical assistant.
However, it should be added that the above categories are illustrative. The purpose of this classification was to highlight the most significant differences between these types of software and indicate the direction of these tools’ development.
This is reflected in the legal reality.
In other words: the more the tool interferes with the doctor’s competence, the more legal obligations arise from it.
What is a medical device and what is not?
To determine whether any software should be classified as a medical device, check these three key documents with specific guidance and examples:
The most important document is the MDR 2017/745 – it establishes the legal framework that manufacturers must comply with, including requirements for software qualification, classification, and certification.
The other two, MDCG 2019-11 and MEDDEV 2.1/6, are regulatory guidelines that help manufacturers determine whether their software qualifies as a medical device and how to classify it.
Ok, so what is a medical device?
Firstly, it should be noted that the fact that an application is used in health care does not automatically mean that it is a medical device. This is stated in recital (19) in the preamble of the MDR regulation:
It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device.
OK, so medical scribe can be designed to be used by doctors and still not be recognized as a medical device. So, where is the line that defines what is a medical device and what is not?
The answer to this question can be found in Article 2 of the MDR. In this passage it appears that it is the so-called “purpose” that determines whether something is a medical device or not:
[…] ‘medical device’ means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:
– diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
– diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability […]
The intended use is the official description of the designed functions of the device or software. This description is prepared by the manufacturer and is the most important part of the technical documentation of the product. In the certification process, this documentation and all descriptions are verified by the notifying body.
So if a product serves a medical purpose – such as diagnosis or monitoring – this information must be included in the description, resulting in classification as a medical device. This description is also crucial because it helps determine the device’s classification (I, IIa, IIb, or III), which affects the complexity of the certification process.
In the case of medical scribes, the classification is not easy. Take a patient interview transcript – is it just a record, or could it actually provide diagnostic insight? It’s a difficult line to draw.
Moreover, the levels of tools described above make it clear that medical scribes differ from one another, and it is actually the specific functionalities that determine classification as a medical device.
It depends on the characteristics of the tool and the reasons for its creation. This brings the discussion back to the different levels of tools mentioned earlier.
When a medical scribe is not MDR?
To properly determine when a medical scribe falls outside MDR classification, it’s essential to analyze its specific functionalities (which effectively define the ‘intended use’ of the application) alongside the detailed guidelines established in the MDCG 2019-11 and MEDDEV 2.1/6.
The MEDDEV 2.1/6 guidelines are a particularly useful document. They contain a chapter on how to classify software. There is also a handy chart there:
For transcription tools in particular, special attention must be paid to the rules governing the processing and modification of data.
In decision step 3, there is a question: Is the software performing an action on data different from storage, archival, communication or simple search?
If not, it does not have to be classified as a medical device. The answer to this question depends on the functionality available in the tool.
So, going back to our classification of tool development levels: when software is classified as fitting into level 0 and 1 (basic transcription and lossless structuring) probably does not qualify as a medical device. This is because it only performs the functions of recording, storing, and displaying information, without modifying their content.
MEDDEV 2.1/6: if the software does not perform an action on data, or performs an action limited to storage, archival, communication, ‘simple search’ or lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) it is not a medical device.
Pure transcription can be considered a form of communication or archiving without generating new medical information. It simply converts speech to text, which is a technical process with no decision-making element in a medical context.
The same applies to lossless data structuring – this functionality typically involves organizing textual information in the sense of assigning it to previously defined categories, e.g., symptoms or recommendations. Structuring understood in this way can be interpreted as an action on medical data, although this data is not modified in any way, so it can be argued that the intended purpose of the software is just organization, and not “medical”.
In summary: if a speech-to-text application offers just transcription of recordings and initial structuring consisting of text organization (not its modification or removal of fragments), then it probably should not be classified as a medical device.
When a medical scribe is MDR?
The situation changes when the structuring offered by the tool goes beyond simple organization and offers, for example, selecting the most important information from a patient interview, or a concise summary of the most important information (summarization).
These types of tools may qualify as medical software.
Arguments for this can be found in the MEDDEV 2.1.6 document:
On page 11, in the “Decision step 3” section:
Software which is intended to create or modify medical information might be qualified as a medical device. If such alterations are made to facilitate the perceptual and/or interpretative tasks performed by the healthcare professionals when reviewing medical information, (e.g. when searching the image for findings that support a clinical hypothesis as to the diagnosis or evolution of therapy) the software could be a medical device.
This fragment indicates that software creating or modifying medical information to facilitate perceptual and interpretative tasks performed by doctors may qualify as a medical device.
On page 11, in the section explaining types of data modifications:
Alterations may include reconstruction, lossy compression, filtering, pattern recognition, modelling, interpolation, transformation, classification (e.g. scoring of tumors against specific criteria), segmentation, registration (e.g. mapping a data set to a model or atlas or to another data set), calculations, quantification, qualification (e.g. comparison of data against references), rendering, visualization, interpretation, etc.
Summarizing patient data and selecting the most important information involves interpretation, classification, and transformation of data – processes mentioned in this fragment.
On page 20, in example b) regarding Decision Support Software:
In general, they are computer based tools which combine medical knowledge databases and algorithms with patient specific data. They are intended to provide healthcare professionals and/or users with recommendations for diagnosis, prognosis, monitoring and treatment of individual patients.
Software that summarizes patient data works similarly to decision support systems, as it analyzes patient data and provides doctors with information in an organized way, which supports their clinical decisions.
On page 7, in the definition of “Expert function software”:
For the purpose of this document, the ‘expert function software’ means software which is able to analyse existing information to generate new specific information according to the intended use of the software.
Summarizing patient data and selecting the most important information is a form of analyzing existing information to generate new information, which corresponds to the definition of software with an expert function.
In summary, a medical scribe that summarizes patient data or collected interview and selects the most important information may be classified as a medical device because:
- It performs actions on data beyond simple storage
- It modifies or creates new medical information
- It supports doctors’ decision-making processes
- It may have a direct impact on the diagnosis, treatment, or monitoring of a patient
Such features characterize level 2 and 3 tools according to our classification.
For Level 3 tools, the situation is clear – these are clinical AI assistants. Such applications have functionalities that directly meet the definition of medical devices and clinical decision support systems.
For example, based on patient data from the EHR, it can suggest differential diagnoses or suggest treatment plans/recommendations.
Therefore, it is clear that the intended purpose of the tool in this case is to provide information to assist in the diagnosis, treatment, monitoring, mitigation, prediction, or prognosis of a disease.
In such a situation, there is a high probability that certification would be required.
Summary
So, that’s it. Software using LLM to summarize clinical information will likely be classified as a medical device because it performs part of the work reserved for certified medical specialists, has a medical purpose, and involves risks to patients.
Key for legal classification is the degree to which the system interferes with the doctor’s decision-making process.
Manufacturers of advanced systems must meet a number of regulatory requirements, including CE certification, implementation of a quality management system, and ensuring human oversight.
However, it should be emphasized that the information presented in this article constitutes only our interpretation of the regulations. Currently, there is no clear position of regulatory authorities on this type of solution.
Nevertheless, more and more medical software providers in Europe are implementing speech-to-text solutions in their systems for doctors. If you are planning to add AI functionality to your healthcare software, ask us about our modules for software vendors, we have already done some work 😉
People who read this article also read:
