1 Introduction

Health technologies are vital to human health by definition. In fact, they include a wide range of typologies of products devised for health applications. According to the World Health Organization’s (WHO) definition, health technology is the application of organized knowledge and skills in the form of devices, medicines, vaccines, procedures, and systems developed to solve a health problem and improve quality of lives [1]. Thus, medical devices (MDs) and in vitro diagnostic medical devices (IVDs) can be classed as medical technologies. While MDs operate or provide support in therapeutic, diagnostic, preventive, monitoring, treatment or alleviating procedures (e.g., a defibrillator is used to restore a normal heartbeat in case of ventricular fibrillation), IVDs are a subgroup of MDs that examine specimens from the human body in vitro to provide diagnostic information (e.g., a COVID-19 self-collected antibody test system is a IVD used to detect the antibodies responsible for neutralizing SARS-CoV-2, hence they can be used to detect a past infection from this virus).

Knowing the essential role of MDs in safeguarding human life, their safety and effectiveness, as well as the safety of the users, the patients and third parties, are of crucial importance, and they must be guaranteed. In this perspective, laws and regulatory frameworks are introduced with the aim to ensure the smooth functioning of the internal market as regards MD, taking as a base a high level of protection of health for patients and users, and taking into account the small- and medium-sized enterprises that are active in this sector and at the same time to set high standards of quality and safety for MD in order to meet common safety concerns as regards such products [2]. To this purpose, European Directives and Regulations were introduced to prevent differences in provision among Member States, and to harmonize certification and conformity assessment procedures to guarantee the free movement of MDs and eliminate disparities [3].

The European MDs and IVDs market regulatory frameworks, have been going through consecutive changes since the 1970s, moving from a substantially national, subjective and prescriptive approach, towards a more international and objective approach, assigning more responsibilities to the manufacturer [4].

The evolution started with the Directive on active implantable MDs (AIMDs − 90/385/EEC), followed by the Directive on MDs (i.e., 93/42/EEC), and later the Directive on in vitro diagnostics (IVDs − 98/79/EC), and that on biocidal products (98/8/EC). These Directives were supplemented by a number of Guidance documents on MDs Classification, Vigilance and in 2007 an amending Directive was introduced, to resolve issues related to reclassification of implants, data confidentiality, clinical evaluation, post-market surveillance and software validation (i.e., 2007/47/EC). However, due to several critical points concerning ethics, definitions, supervision, transparency, standards, and inadequately managed risks, directives had to be reviewed and updated into a completely new form, i.e. the new regulations [5,6,7,8,9,10].

On the 5th of May 2017 the European Medical Device Regulation (MDR) 2017/745 and 2017/746 concerning in-vitro diagnostic MDs (IVDR) were issued. These regulations repeal directives 90/385, 93/42, 98/79 and 98/34 [11]. The MDR are currently enforceable as law in all member states since May 26, 2021, finally introducing an unified act on MDs, and guaranteeing a European regulatory framework that ensures the same level of safety, protection and efficiency of the MDs, as well as improved credibility and reputation [12]. The shift from “directives” to “regulations” is not trivial. Directives are EU instruments requiring member states to legislate accordingly and enforce them at a National level by relevant laws with a flexibility margin. Conversely, EU Regulations are simultaneously enforced, after a transitional period, in each member state, imposing clear and detailed common rules, which do not give room for divergent transpositions by member states. Furthermore, there is a derogation period in which some of the devices compliant with the former directives will be able to continue to be legitimately placed on the market (legacy devices), at the latest until May 26, 2024. From May 27, 2024, all MDs and active implantable MDs Certificates based on the previous directives will lose validity, and MDR 2017/745 will come into force for class I MD that require a Notified Body. As regards the IVDR, the transition period will end in May 27, 2028. After this date all devices placed under the previous directives will no longer be made available on the market [13]. However, in March 2023 a proposal has been accepted by the council to extend the transition period for devices that not fulfill the conditions laid down in article 120(3c) of the MDR [14]. The length of the extension is set according to the risk class of the medical device, shorter transition periods for higher risk devices (i.e. class III and class IIb implantable) and longer periods for lower risk ones (i.e. other class IIb, class IIa and class Im, Is, Ir17). The aim of the proposal is to balance the available notified body capacity and the level of manufacturers’ preparedness with high level of public health protection [14, 15].

The purpose of the transition to the novel Regulations is the forward increase of the safety and efficiency of MDs, safeguarding patients and users. This is of utter importance for the ever-evolving field of MedTech, which is witnessing the rise of more complex MDs.

The past century witnessed a major revolution of healthcare, thanks to the flourishing market of health technologies, which could increasingly rely on the progress of science and technology. That of healthcare is one of the fastest growing sectors of the economy, worldwide. The global health expenditure sharply increased from a gross domestic product (GDP) of 1% in 1900, to almost 10% in 2018 [16]. Medical technologies are, in fact, in continuous expansion because of innovations that are introduced to support and progress medicine. The fact that also software and mobile applications with a medical purpose are classed as MDs, Medical Device SoftWare (MDSW), and the information and communications technology (ICT) boom in the second half of the XX century, contributed to increasing these numbers even more. Relative to this, the number of granted patent applications in Europe can be proxy for this huge growth: from 2010 to 2020, the granted patents for medical technologies in Europe per year almost tripled reaching 10,479 in 2020 (while those related to the pharma and biotech fields almost doubled, reaching 3,588 and 3,203 in 2020, respectively) [17].

Europe is undergoing a substantial change and evolution in all areas directly and indirectly affected by the Regulation. The focal effect will be the economic and healthcare impact, but research in the laboratory and in the development of new devices will also be affected. In particular, the use of artificial intelligence (AI) in healthcare is one of major issue most subject to discussions and likely focus of updates to the Regulation. Moreover, the pandemic of COVID-19 accelerated the formation of a new vision of communication and professional activities. The remote work illustrates the combination of physical presence and longitude of some processes and of digital representation of human imagination, leading to the expansion of the Phygital [18]. Phygital is the current challenge for innovation comprehensive of Metaverse and all technologies allowing the interaction existing on the border between physical and digital world (i.e.) [19]. Phygital embraces extended reality (XR), digital twins, wearable sensors, machine learning, Human-Machine Interaction (HMI) and the Internet of Things (IoT) [20]. XR, that comprehends Virtual (VR), Augmented (AR) and Mixed Reality (MR), has seen rapid growth and the innovation will increase to the point which the Metaverse will be an everyday tool [21,22,23]. In the last decade, these technologies have found their way and applications in the medical field renovating it completely in each section (i.e. training, surgical planning, rehabilitation, imaging, monitoring). Indeed, according to the previsions of ECORYS EUROPE E.E.I.G shown in the last report about “XR and its potential in Europe”, the European XR industry is expected to reach between €35 billion and €65 billion by 2025 and its impact on the Healthcare scenario will be five times that of the market in 2020.

2 Research questions

The main question: the current European normative scenario can be considered updated and compliance to the upcoming Phygital in Medicine and Healthcare? Can MDR 2017/745 be considered innovative in the European context where the World Health Organization (WHO) introduced the Digital Health (DH)? DH was announced to expand the concept of eHealth exploring the improvement that healthcare would experience through digital technologies: artificial intelligence, big data, blockchain, health data, health information systems, the infodemic, the Internet of Things, interoperability and telemedicine. Furthermore, a Regional Digital Health Action Plan 2023–2030 was adopted by WHO with the aim of supporting Countries in leveraging and scaling up their digital transformation for better health and in line with their health needs in the DH context.

Concerning AI, several debate [24, 25] have been done to value risks, procedures and clinical evaluations according to MDR and relative guidance document, such as MEDDEV 2.1/6 and ISO/IEC JTC1 SC42, which are implementing software standards applicable to all sectors. After about 10 years of sensibilization to the issue, EU AI Act, the first European regulation on artificial intelligence, will be finally established in 2023.

What about XR applications and Metaverse in the field of medicine? Has the potential ethical, mental and physical impact been assessed? Are there guidelines to validate the implementation process and scope of the XR app and to approve the software as MDSW? VR is cited in the MEDDEV 2.1/6, although only for an example of MD relating to remoting surgery. No other official documents refer to XR. The FDA registers some software as MD that are not yet present in Europe. This is the case of the “Virtual Treatment Rooms in the Metaverse” from XRHealth, comprehensive of VR/AR apps for telehealth. According to MDR 2017/745, MDGR has introduced in the EMDN classes for software in order to provide specific allocations for each category of MDSW already present on the market or, in a future prospective, that probably will make their enter in the MD world. However, is this sufficient?.

The aim of this article is to discuss the European normative scenario, MDR 2017/745 improvements and integrations, along with lacking or challenging guidance, specifically in relation to Phygital in MD sector. Particular attention will be applied to the position of the regulatory framework in front of the inclusion of XR in medical and healthcare field. Different perspectives of the issue will be considered to provide a general summary and the consequently further experts’ opinions.

3 Background

3.1 Overview on the MDR 2017/745

The aim of the rules introduced by this regulation is guaranteeing the safety of patients and users and establishing adequate MD performances, ensuring all the fundamental requirements for affixing the CE mark, and for the consequent market placement of the product. In view of this, conformity assessment procedures for MDs, as well as the duties of all economic operators are specified. A list of harmonized standards, which can be found in the Official Journal of the European Union, complements Regulations 2017/745 and 746, supporting the manufacturers in abiding by their requirements.

The first information provided are definitions of “MD”, “accessory” and other terminologies (Article 2): “instrument, apparatus, appliance, software, implant, reagent, material” intended to be used for human beings for a specific medical purpose, such as diagnosis, prevention, monitoring, treatment, could be considered a MD. On the other hand, an accessory is not considered as a MD itself, instead, it is intended to be used in combination with one or several MDs. In the Regulation, the previous definitions of MDSW have been reaffirmed. However, the MDR 2017/745 specifies that location or type of connection of the software with the device are independent to qualification process as MDSW. Moreover, Chapter II requests repeatability, reliability and performance of the software to be ensured in line with their intended use.

In order to uniquely identify and trace MD and as well as to reinforce coordination among Member States, the implementation of the European Database on Medical Devices (EUDAMED), already introduced in the early 2000s, is reaffirmed (Article 33). The criteria to assign a Unite Device Unification code (UDI) to MDSW were also announced allowing identification and trackability. With the institution of EUDAMED, the public is adequately informed about devices placed on the market, the corresponding certificates, the economic operators, and the clinical investigations. Moreover, EUDAMED enables sponsors and manufacturer to comply with obligations and the information obligations, respectively.

A further key information provided by the MDR 2017/745 concerns the risk-based MD Classification, which is one of the essential steps towards the CE mark (Article 51). If a device and/or its software is considered to be a medical device, the manufacturer must determine the device’s risk class. MDs are divided into 4 classes of risk, i.e., Class I, IIa, IIb, and III, from the lowest to the highest level of risk. Annex VIII enlists all the rules necessary for the correct classification of the MDs, according to their invasiveness, time of use, area of application on the human body, and contact with biological substances. The criteria for the assignment of the class of risk to MDSW are described in Chap. 3, where Rule 11 states that in general software should be classified as class I. However, software intended to provide information in support to diagnosis and therapy decisions, as well as software for monitoring physiological processes, may be classified as class IIa, except for decisions causing sever impacts, which must be classified as class III or IIb. In the certification, process for MD technical documentation is fundamental and it contains extensive risk analysis, test reports, overviews of the risk management, executed calculations, data collection, clinical evaluations and information on design, manufacturing process and functioning of the software. Manufacturer of medical software should, other than ensure repeatability, reliability and performance according to the intended use, take into consideration security, verification and validation. Moreover, boundary conditions should also be validate, like hardware features, external factors, conditions of IT networks characteristics and IT-security measures.

All the conformity assessment procedures needed to be performed by the economic operators and notified bodies based on the device’s class of risk are reported in Articles 52–60. While the Post-Market Clinical Follow-up (PMCF) and the clinical evaluation are introduced in Articles 61 and 62. The clinical evaluation of MDs, explained in Annex XIV, is a systematic and planned process to continually generate, collect, analyse and evaluate clinical data on a particular device. It consists of verifying the safety and performance of the device, including the evaluation of unwanted side effects and the satisfactoriness of the benefit-risk ratio. The procedure to be followed is based on a first systematic review of the scientific literature regarding safety, performance, design characteristics and intended use of the device; a critical analysis of the results of all available clinical investigations and a study of any alternative treatment options.

3.2 Overview on the EMDN

In Chapter III, MDR 2017/745 includes obligations relating to the traceability of MD through the States. National registries are incentivized to be established and made mandatory to simplify the exchange of data between registries and the European Database of MD (EUDAMED). An internationally recognized European MD Nomenclature (EMDN) is also available free of charge to support the functioning of such database and to progress patient safety, define and name innovative technologies and classify the devices. On March 4, 2019, the EU Commission adopted the Italian Classification of Medical Devices (CND) as a base to support the activity of the future European database of MDs EUDAMED [26, 27]. As suggested and requested by the regulation, experts on each category of MD, registries, Health Institutions, surgeons, and manufacturers associations, are currently supporting the European Group to extend CND to the EU level and develop the EU nomenclature EMDN [27]. Until May 2021 when the first version of the EMDN was released, there were not a nomenclature system recognised at an EU level, so the available Registries of different MD categories established in Europe are currently based on different MD nomenclatures. However, a shared nomenclature is important to analyse MDs performances across different national databases referring to a unique definition of its characteristics [28]. These novel requirements concerning the incorporation of registry data in the data that the manufacturer must evaluate will result in their better integration in regulatory decision making, according to Melvin et al. [29]. Of similar opinion are Marquez-Peiro et al., who believe that the requirements of the new regulations will improve many areas related to the MD lifecycle, including their traceability, safety and evidence-based effectiveness [30].

3.3 Overview on guidelines for MD software

The definition of MDSW was introduced in the Directive 93/42 [3] in art.1 and in Anne IX, among the Implementing Rules the specification “Software, which drives a device or influences the use of a device, falls automatically in the same class” was also proposed as a reinforcement. In Directive 2007/47 [31] the definition of MDSW was confirmed with a specification affirming that a software for general purpose is not a medical device. Afterwards, guidelines were proposed to support manufacturer in the validation of their software as MDSW: MEDDEV 2.1/6 in 2012 [32], IEC 62,304 in 2015, IEC 82304-1 in 2016.

MEDDEV 2.1/6 introduced MDSW for telecommunication in medicine. Software specifically implemented for Telemedicine, telesurgery, Video appointment and Home-Care monitoring are discussed according to the technology in 2012. In particular, VR, software to remoting control of robot and, web modules to remotely monitor MD performance were introduced as MDSW, while video appointment software and telecommunication system were not considered MD according to the following criteria for the software. It performed actions different from storage, archival, lossless compression, communication; the action is beneficial for the patient; the action responds to the purposes defined in art.1 of MDD.

IEC 62,304 and IEC 82,304 are recommendations of international use with the aim of promoting international cooperation and standardisation. IEC 62,304 defines the life cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes from the establishing of the maintenance plan to the software release. This IEC summaries also the requirements for the software safety class considering all the relationships to the ISO involved. IEC 82304-1 includes all the steps and requirements for the complete lifecycle of the software and lists different types of health software, defined as the software intended to be used for maintaining or improving health of individual persons, or the delivery of care.

In 2017, the MDR 2017/745 [2] was published. In support of the MDR, specific guidelines were published for MDSW by the Medical Device Coordination Group (MDCG) established by Article 103 of Regulation (EU) 2017/745: MDCG 2018-5 [33], 2019-11 [34] and 2020-1 [35].

MDCG 2018-5 specifies the criteria for assigning UDI to a MDSW according to the Annex VI of the MDR 2017/745. MDCG 2019-11 regards qualification and classification of MDSW expanding the rules and directions of the MDR 2017/745. This guideline states that, for software composed by different modules, only the modules with a specific medical purpose are subjected to the MDR 2017/745 and the manufacturer has the obligation to identify them. New categories of software used in medicine are added and their evaluation as MDSW is performed. For example, Clinical Information Systems and communication systems are not qualified as MD; however, modules that provide information to diagnosis, therapy and follow-up are MD. Regarding the class of risk, this guideline presents a confrontation with the IMDRF risk categories to provide support in the analysis of the software. MDCG 2020-1 provides guidelines on determine the appropriate level of Clinical Evidence required for MDSW by the MDR 2017/745. The same principles of Clinical Evaluation apply to all MDSW individuating two macro-categories of models: (a) software for which the manufacturer claims specific clinical benefit and requires clinical evidence; (b) software intended to drive or influence a MD for which the clinical evidence is provided within the context of the driven or influenced device. The clinical evaluation includes several steps. Firstly, the manufacturer should verify that the MDSW reliably, accurately and consistently meets the intended purpose in real-world usage. For the validation of a MDSW’s Clinical Performance, the manufacturer should demonstrate that the MDSW has been tested for the intended use(s), target population(s), use condition(s), operating- and use environment(s) and with all intended user group(s). Validation of the Clinical Performance can be characterised by the demonstration of applicable Clinical Data to the MDSW in question. The clinical investigation or study should account for potential risks, should follow appropriate ethical requirements, and should be compliant with all relevant legal and regulatory requirements. The manufacturer should compile evidence, perform the benefit-risk analysis and document the Clinical or Performance Evaluation and its output in the Clinical Evaluation report.

Following the guidance of the European Commission a summary scheme to evaluate a software as a MDSW is reported in Fig. 1.

Fig. 1
figure 1

Pipeline of the process to assess if a software can be considered a MDSW according to MDR 2017/745 and MDCG2019-11.

Full size image

3.4 European artificial intelligence act

AI provides several benefits, but also risks, for individuals and sectors. However, [36] systematic review shows sufficient evidence to believe AI integration into healthcare sector is worth it because of all significant benefits it can bring. Obviously, challenges such as data integrity, patient safety and privacy issues of using AI in healthcare must be carefully evaluated according to the strict regulations that govern the healthcare sector in Europe.

In fact, some of the proprieties of AI software may be in opposition to the directive of MDR 2017/745 for putting a MD on the market, such as the pre-definition of a tolerance for changing and the assurance of no emerging risks. This may result in difficulties in comparing two applications aiming at similar clinical needs and CE mark using different performance criteria; impact of the Quality Assurance (QA) in terms of temporal changes. Subsequently, the question being rightly asked by COCIR is considering that a software changing itself is framed as a real-world experiment by the European Parliamentary Research Service [37], “under what conditions is it acceptable to experiment with AI in society?”. In addition, according to MDR 2017/745 “the qualification of software, either as a device or an accessory, is independent of the software’s location or the type of interconnection between the software and a device.”, so how is AI either interacting with different MD or processing data extrapolated from different databases, interpreted? How is a smart-structure that uses AI to better support the diagnosis of a disease considered strong of the extensive training data it has had access to? These issues are under discussion since MDR 2017/745 enhancement, although guidelines have been provided in these years. All the recommendations and discussions have finally lead to an effective intervention from the European commission which proposed, in April 2021, the first EU regulatory framework for AI and in June 2023 the first briefing of the Artificial Intelligence Act to concord a final form of law.

4 Data

Research on Scopus, PubMed and Web of Science (WoS) databases was made with the aim to evaluate the entity of publications about XR in the years since the issuing of MDR 2017/745. All articles, conference proceedings and books that presented one of the following keywords were considered “augmented reality”, “virtual reality”, “mixed reality” or “extended reality”. The distribution of publications among the Subject areas considered by Scopus and WoS was also investigated.

The version 1.2 (2021-09-29) of the EMDN available on the official site was consulted to evaluate the classes adequate for the classification of typologies of MDSW. Only the classes for MDSW were evaluated leaving out classes for accessories software. For each class EMDN identified, EUDAMED was consulted for a sample search of MDSW already classified for the EU market with particular interest for software using XR.

5 Findings

According to the criteria of filtering imposed, Fig. 2 show the results of the researches. A total of 75,771, 28,772 and 7119 publications about XR was obtained from the review respectively on Scopus, WoS and PubMed, in the last 5 years since MDR 2017/745 was issued. For both Scopus and WoS, the areas where XR is more applied, leaving out PubMed since the subject area is by the nature of the database Medicine and Health, are computer science, engineering, health & medicine and mathematics (Fig. 3). Medicine area is comprehensive of approximately the 11% of the total for Scopus and 14% for WoS.

Fig. 2
figure 2

Histogram comparing the number of publications about XR identified consulting and filtering Scopus, WoS and PubMed databases from 2017 to 2022

Full size image
Fig. 3
figure 3

Graph comparing the percentage of publications about XR in different subject areas according to Scopus and WoS since 2017

Full size image

The EMDN (version of 13/06/2023) presents 174 classes for MDSW. MDR 2017/745 was implemented starting from the CND, however these classes for MDSW were specifically integrated according to the regulations. These classes are inside the categories (Fig. 4): J for active implanted device, W devices for in-vitro diagnostic, Y devices for disabilities, Z sanitary accessories and software. However, on a total of 1074 MDSW classified in these classes as showed in the Figs. 4 and 583 MDSW are classified in the class V of various medical devices and the majority of the EMDN classes for MDSW are empty at the moment.

Fig. 4
figure 4

Graph of the number of MD registered in the EMDN classes relating to stend-alone software (consulted on 13/06/2023)

Full size image

Applications for mobile and smartwatch are also considered as MDSW for monitoring subjects vital signals, registering data and providing feedbacks through the contact selected. Software for Motion Capture systems and for rehabilitation have dedicated classes such as respectively “Z12062592 KINEMATIC MOTION CAPTURE ANALYSIS SYSTEMS – medical device software” and “Z12069092 VARIOUS PHYSIOTHERAPY AND REHABILITATION INSTRUMENTS – medical device software”. Active and passive system for rehabilitation and physiotherapy are considered in the EMDN. Software based on virtual reality and using external sensors for human acquisitions are registered in EUDAMED i.e. MindMotion GO from MindMaze is a virtual game implemented for rehabilitation based on the eternal Kinect device from Microsoft. Virtual applications for the surgical navigation are also considered in classes such as “Z12011492 SURGICAL NAVIGATION INSTRUMENTS - medical device software”, however no MD are registered.

6 Discussion

6.1 Critical aspects of MDR 2017/745 for MDSW

As Keutzer et al. [38] state, the new MDR 2017/745, introducing more requirements for software qualification and classification, is more stringent, specifically in relation to the classification of health apps and software, compared to the previous directives. For this reason, illustrative examples and recommendations on how to qualify software as a MD are essential [39]. When it comes to MDSW, the new MDR 2017/745 features increased cybersecurity requirements, including those for the device’s operational environment (e.g., IT network characteristic) [40]. Also the UDI on software is particularly relevant, due to both its nature (i.e., non-hardware) and the specific lifecycle of this kind of MD [41].

Regulatory bodies like FDA or the EU are not sufficient for a responsible AI system because they focus on epistemic concerns instead of practical concerns [42] and other documentations are provided to discuss the need for implementing sufficiently good machine learning practices.

Although MDCG has provided specific classes for MDSW in the version of the EMDN with a look to the future technologies that will be applied in healthcare and medicine, the category with the large number of devices registered is V of the various medical devices. Probably this fact is due to EMDN and EUDAMED being still new and subjected to other updated, but the lack of clear guides and normative can be an incentive to cause doubts and misunderstandings for manufacturers on how to consider their software.

What needs to be specifically regulated?

6.2 XR applications

As stated by the ECORYS report corporate-controlled metaverse environments will proliferate over the next decade and considering the increase of publications about XR in medical subject areas (Fig. 3) this phenomenon will interest also health applications. Therefore, potential dangers of the metaverse, whether virtual or augmented, first and foremost for the growth of society should be considered and restricted with sensible regulations [23]. The range of software applications for the health sector has increased significantly in the past years. Differences among apps for health, fitness and MDSW are still not clear for manufacturers. This is also demonstrated by [43], a review of the mobile apps is presented to determine whether they can be classified as MD and to evaluate their CE marking. Among all apps, 64% of the apps filtered were considered as MD based have not be CE-marked. So, more instruction for qualifying an app as a MDSW are necessary and this statement can be applied also for XR apps. Manufacturer determines if the criteria for the software to be a MDSW are respected. However, even if the documentation and clinical evaluations is delivered considering the efficiency of the software in healthcare or medicine, is it enough to state that the software has been implemented for medical purposes to make it a MDSW? For example, in rehabilitation and physiotherapy, how a XR software for medical application [44, 45] is different from a general exergame [46]? Considering the several medical areas in which VR [47] and MR [48] is provided, can all categories of apps be regulated?

In USA, according to the last US FDA Update, the FDA in 2021 authorised marketing of digital therapeutic TV or VR system for chronic pain reduction and improving vision [49] and, in 2022, US FDA PEAC Executive Summary [50] provides special guidelines for regulating AR and VR as hardware and software MD. Special considerations on benefits and risks of AR/VR devices are listed to be included in the information provided by the manufacturer with a set of robust testing data to show safety and efficiency. The integration in Europe mandates of more specific guidance on VR/AR apps for medical purposes would be crucial and desirable a greater monitoring from the authority about registered MDSW on the market.

Furthermore, Head-Mounted Display (HMD) indispensable for experiencing XR software should be discussed. Currently in EU, HMD are not considered MD because they were not developed especially for health applications, unlike XR apps implemented for patients or surgeons, which can be considered MDSW. However, FDA are considering HMD as MD other than the software exergame proposed as MDSW. While non-HMD-based VR systems are already legally marketed in the US for at-home therapy, [51] HMD-based VR introduces associated risks requesting appropriate demonstration that HMD can be safe for home use and remote patient monitoring.

Several considerations should be done for developing a HMD specifically for medical use which could be consequently classifiable as MD, considering risks and pertinence of the device because the resulting XR experience depends on the technical performance of the HMD i.e. spatial resolution and contrast, temporal error of synchronisation and depth perception. Current ISO standards have gaps around evaluation methods for binocular performance, latency, comprehensive visual guidelines, and new HMD technologies [52]. These proprieties can be fundamental in apps where the patient safety is at risk such as in navigation and surgical procedures. In addition, fully immersive HMD can lead to visual fatigue, motion sickness, ergonomics concerns, or cognitive overload [53]. Moreover, 3D segmentation, rendering medical images and hand/object tracking introduces limits to accuracy invalidating the sensitive procedures. All these considerations should be taken into account while evaluate the class of risks of this devices.

7 Conclusions

Undoubtedly, the entry into the phygital world is already underway and will continue to develop in the medical field in ever-greater depth, becoming indispensable and intrinsic in everyday medical procedures and guidelines. But with regard to the use of the new phygital technologies in medical procedures, such as surgery or diagnosis, can MDR 2017/745 contemplate and protect the new medical protocols complemented by such innovations? In a future European context projected towards interaction, exchange and communication, how will the immense possibility of Phygital application be seen?

On the basis of the information gathered and discussed, the Authors agree that the competent authorities should consider intervening in the European Regulation as it is borderline obsolete and inadequate to cope with the revolution we are witnessing. The lack of protocols to regulate procedures involving the use of XR in medicine may be conduct to future misunderstanding and criticalities especially for high risk situations such as surgical planning, real-time surgical navigation and telesurgery. In the section d.1.1 of MEDDEV and MDCG2019-11 VR is for the first time nominated in relation to remote surgery device, stipulating that the virtual device and software for this procedure is to be considered a MD according to the MDR 2017/745. How should the risks and critical situations been specifically assessed such as a lack of connection or hologram accuracy?

The growth of technology is increasingly rapid and official normative must be able to keep up with the times to be a precursor in studying the issue. Demonstrations of this need are the integration of specific classes in the EMDN for MDSW; the establishment of the IEEE Virtual Reality and Augmented Reality Working Group (VRARWG) which is developing 12 standards for XR design that could be useful to apply to improve safety, usability, and standardization [54]; the new ISO/IEC TR 23,844: 2023, that specifies potential directions for using immersive technologies (AR, VR and MR) in learning, education, and training and provides suggestions on what can be standardized for this purpose. However, these documents do not considered technologies such as metaverse, digital twin and extended reality (XR) and the date on which the standards by VRARWG will be made available is not declared.

The Authors believe that the time gap that existed from the last Directive to the Regulation is for today’s times too large and dispersive, leaving a phase of misunderstanding and uncontrollability in market management and activity. A fundamental and representative example of this was the great interest that arose with regard to AI in the medical field, which then led to scientific discussions to the point of issuing official guidelines in this regard. The same should be expected for all main areas of innovative technology making their way into the MD world. Therefore, more systematic and specific interventions should be expected to address the needs of market regulation and protection of patients and health care providers at the appropriate time.

Phygital hardware and software in medicine is a new frontier to be explored and to be regulated without limiting future development and innovations that can be obtained in healthcare.