Digitalization in Health Care Industry :

The digital revolution in healthcare represents a transformative shift in how healthcare services
are delivered, managed, and experienced. It is a comprehensive integration of digital
technologies, data-driven solutions, and innovative approaches that are reshaping the entire
healthcare landscape.

EHRs have replaced traditional paper records, enabling healthcare providers to store and access
patient data electronically. This streamlines information sharing among clinicians, enhances
patient care coordination, and reduces the risk of errors. Telemedicine has emerged as a
prominent aspect of the digital revolution, allowing patients to receive medical consultations,
diagnoses, and even treatment from the comfort of their homes. This remote healthcare delivery
has become especially important during health crises like the COVID-19 pandemic. What has
impacted much here is Rise in technology based devices led by the eminent software
functionality . 1

SaMD and wearable devices

SaMD can be termed as “software intended to be used for one or more medical purposes that
2
perform these purposes without being part of a hardware medical device.” whereas wearable
devices can be termed as another medical/non-medical product through an electronic user
interface. Medical Device Data System (MDDS) -software (or hardware) used to transport and
store data, convert data formats, and display data from a medical device without affecting the
parameters of any other medical devices that are linked.

SaMD Basic Programming Model Premarket was discovered to be a critical component of

medical device regulation. There are several medical items on the market that are not actual
medical equipment, such as laboratory glassware and reagents, eyeglasses, lenses, and so on. The
mechanism for recognising and classifying generic devices is critical for successful product
regulation.3

1
https://health.economictimes.indiatimes.com/news/health-it/how-india-can-benefit-from-digitalization-in-healthcare-delivery/
98524762
2
https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-131209-samd-key-definitions-140901.pdf
3
https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
Several opportunities associated with software driven medical sciences are :

1) Advance Analytics : Techniques of advanced analytics can be used to analyze datasets

which normally cannot be analyzed by humans. These include big and complex data sets that
can only be analyzed by specialized software . Advanced analytics can discover new patterns
in data.

For eg. A patient's melanoma can be analyzed by an imaging system through comparison with
a repository of past melanoma data such as images, diagnosis and treatment plans. And
technology is so far developed , the software can use it’s algorithm providing diagnostic
information about diseases .

2) Wearable devices embedded with Software can be driven by Data Collected by it , for eg.
Fitbit a wearable SaMD uses Pulse-oximeter , hereby Data of patients from a pulse oximeter
can be used by a designed infusion pump to change the settings of another infusion pump as
per requirement .

Examples of software that are not SaMD:

 The SaMD definition states “SaMD is defined as software intended to be used for one or
more medical purposes that perform these purposes without being part of a hardware
medical device”. Examples of software that are considered “part of” include software
used to “drive or control” the motors and the pumping of medication in an infusion
pump; or software used in closed loop control in an implantable pacemaker or other
types of hardware medical devices. These types of software, sometimes referred to as
“embedded software”, “firmware”, or “micro-code” are, not SaMD”.

 Software required by a hardware medical device to perform the hardware’s medical

device intended use is not SaMD even if/when sold separately from the hardware medical
device.

 Software that relies on data from a medical device, but does not have a medical purpose,
e.g., software that encrypts data for transmission from a medical device is not SaMD.
  Software that enables clinical communication and workflow including patient
registration, scheduling visits, voice calling, video calling is not SaMD.

 Software that monitors performance or proper functioning of a device for the purpose of
servicing the device, e.g., software that monitors X-Ray tube performance to anticipate
the need for replacement; or software that integrates and analyzes laboratory quality
control data to identify increased random errors or trends in calibration on IVDs is not
SaMD.

 Software that provides parameters that become the input for SaMD is not SaMD if it does
not have a medical purpose. For example, a database including search and query
functions by itself or when used by SaMD is not SaMD.4

The Software as a Medical Device (SaMD) to be marketed in India is subjected to and must
comply with the following regulations:

 S.O. 648(E), February 11, 2020, Medical Device Definition

 Medical Device Rules, 2017
 ISO 13485:2016 - Quality Management Systems
 ISO 14971:2019 - Application of Risk Management to Medical Devices
Additionally, the SaMD shall also comply with the applicable global harmonized standards that
include:

 IEC 62304; it deals with the software lifecycle, i.e., almost everything about what
software engineers do.
 IEC 60601-1 applies to embedded software in a hardware medical device
 IEC 82304-1 applies standalone software also known as Software as a Medical Device
(SaMD)
 IEC 81001-5-1 adds requirements for cybersecurity

4
“Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations”
https://www.imdrf.org/documents/software-medical-device-possible-framework-risk-categorization-and-corresponding-
considerations
  IEC 62366-1 adds requirements about man-machine interface ergonomics
 IEC 62304 is the standard for software in medical devices

Despite the rapid innovation in AI-based medical devices, current medical device regulatory
pathways such as those pertaining to software as a medical device (SaMD) do not account for
technologies that change in real-time as is the case with some software-based medical devices
that utilize AI.5

Regulating Ai in SaMD

It should be considered that interoperability has an impact on a lot of specification and testing
activities. Starting with device description and the interconnectivity to other devices, it is
important to have documented evidence for testing with related devices. A signifcant challenge in
the post-market lifecycle of interoperable software is to stay informed about changes of
interoperable devices when amended by their manufacturers.

Although AI/ML-based SaMD exists on a spectrum from locked to continuously adaptive

algorithms, a common set of considerations for data management, re-training, and performance
evaluation can be applied to the entire spectrum of SaMD. For example, the rigor of performance
evaluation for both locked and continuously adaptive algorithms depend on the test methods,
quality and applicability of dataset used for testing, and the algorithm's training methods. Robust
algorithms typically require the availability of large, high-quality, and well-labeled training data
sets. Likewise, a common set of principles can be applied to considerations about how to provide
confidence in function and performance to users through appropriate validation, transparency,
and claims after the modification.6

When we look down in Case of US, The traditional paradigm of medical device regulation was
not designed for adaptive AI/ML technologies, which have the potential to adapt and optimize
device performance in real-time to continuously improve healthcare for patients. The highly

5
WHAT IS ARTIFICIAL INTELLIGENCE? By John McCarthy , can be accessed through
http://jmc.stanford.edu/articles/whatisai/whatisai.pdf
6
US FDA Artificial Intelligence and Machine Learning Discussion Paper
https://www.fda.gov/media/122535/download?attachment
iterative, autonomous, and adaptive nature of these tools requires a new, total product lifecycle
(TPLC) regulatory approach that facilitates a rapid cycle of product improvement and allows
these devices to continually improve while providing effective safeguards.7

To fully adopt a TPLC approach in the regulation of AI/ML-based SaMD, manufacturers can
work to assure the safety and effectiveness of their software products by implementing
appropriate mechanisms that support transparency and real-world performance monitoring.
Transparency about the function and modifications of medical devices is a key aspect of their
safety.8 This is especially important for devices, like SaMD that incorporate AI/ML, which
change over time. Further, many of the modifications to AI/ML-based SaMD may be supported
by collection and monitoring of real-world data. Gathering performance data on the real-world
use of the SaMD may allow manufacturers to understand how their products are being used,
identify opportunities for improvements, and respond proactively to safety or usability concerns.
Real-world data collection and monitoring is an important mechanism that manufacturers can
leverage to mitigate the risk involved with AI/ML-based SaMD modifications, in support of the
benefit-risk profile in the assessment of a particular AI/ML-based SaMD.9

The European framework around medical device and AI regulation is governed by the EU MDR
and In Vitro Diagnostic Regulations (IVDR), that, came into force on 26 May 2021. Further,
with the notification of the Artificial Intelligence Act, clarity will be sought on its alignment with
the existing regulatory frameworks, which may create duplicate quality control mechanisms,
testing protocols for the use of AI/ ML solutions in medical devices .10

Singapore has co-developed a set of recommendations, in association with state regulators, to

encourage the safe development and implementation of AI centric medical devices . In addition,
the document also provides better clarity to industry stakeholders on the regulatory requirements

7
Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based
Software as a Medical Device (SaMD) https://www.fda.gov/media/122535/download?attachment
8
https://www.mondaq.com/canada/healthcare/1129652/regulating-artificial-intelligence-in-medical-devices-a-
global-perspective#_ftn6
9
Transparency and real-world performance monitoring of AI/ML-based SaMD:
10
https://www.arcondis.com/en/stories/software-as-medical-device/?
utm_source=mondaq&utm_medium=syndication&utm_content=inarticlelink&utm_campaign=article
for AI centric medical devices. The exclusive aim is to support patient safety and to improve
trust in the ecosystem.11

IP licensing and Ownership

Growth through software necessitates that stakeholders recognize the value of their intellectual
property (IP), which includes patents, copyright, trade secrets, and data rights in protocols, data
sets, study results, etc. IP owners must readily leverage their assets in the context of co-
development to ensure that value is maximized but also protected. SaMD frequently involve
multiple stakeholders, each with varying interests and concerns regarding the current and future
deployment of the technology.

Competing Stakeholder Interests in the Use and Deployment of AI

Consider a hypothetical (albeit common) scenario in which the interests and concerns of these
stakeholders collide: the use and deployment of an AI model. AI may involve computer-
implemented technology that attempts to mimic some aspect of human intelligence. Training
data is used to teach an underlying model so that the resulting software can make reliable and
accurate inferences with respect to newly-acquired data.

In the example shown above, there are three stakeholders that collaborate to deploy and use an
AI model in a piece of SaMD:

 Company A, a software development firm that created the AI model using certain data;
 Company B, a research institute or hospital providing additional data that will be used for
training the AI model; and
 Company C, a customer (e.g., a commercialization entity, a pharmaceutical manufacturer,
insurance company, end users, etc.) making use of the AI model, either as part of a
software as a service architecture or for use in connection with a medical device.

11
https://www.mondaq.com/india/healthcare/1198896/software-as-a-medical-device-samd--blurred-lines-for-
regulation
While one company may have in fact written the code to initially build the AI model, it is the
collaboration among these companies that helped drive the AI model to fruition, ultimately
generating value and improving the quality of care. The research institute, with the provision of
data to train and refine the model, plays a critical role in the overall development, as does the
customer, who often shapes development based on user input. Against this backdrop, there are a
number of ownership and licensing questions to consider:

1. Who owns which data?

2. Who owns the initial and trained AI models?
3. How are the various data, AI model, and any associated IP (e.g., patents, copyrights,
know-how, and trade secrets) to be licensed among the parties?

How to Address Intellectual Property Challenges in SaMD

Protecting existing IP and recognizing value for development contributions require that answers
to these questions to be sorted out, upfront, via intercompany development, clinical trial,
manufacturing, or other agreements. These agreements must include highly-technical definitions.
Those definitions must interface with sophisticated IP ownership and licensing provisions to
establish, among other agreement elements, (a) the type of technology involved (e.g., what the
AI model is to be used for), (b) ownership and use of data to be shared (e.g., what data is
inputted into, used to train the AI model, outputted from the model, etc.), (c) risk based on which
specific employees or labs will be contributing to the collaboration (e.g., individual scientists or
research group names), (d) duration of the license, if any, for use of the project results (e.g., term
or perpetual), and (e) compliance with privacy laws with respect to potentially sensitive data
(e.g., medical records, personally identifiable information, etc.). In conjunction, each stakeholder
must evaluate these agreements to ensure that their current and future uses are protected and that
their contributions are recognized.

The licensing agreement should address each type of IP that each party is bringing to the table.
First, background IP may be owned by each stakeholder but licensed (using the defined terms)
narrowly as needed for collaboration or broadly. Second, independent IP may be owned by each
stakeholder but deployed during the course of collaboration, and may be licensed as needed for
the collaboration. It should be noted that IP developed using other parties' IP is not
"independent" in nature. Third, the new (foreground) IP should be owned by the appropriate
party and licensed to others as needed for the collaboration. When possible, joint ownership
should be avoided, because joint ownership may cause a myriad of problems down the line (e.g.,
who will handle prosecution and can enforce a patent).12

In addition, all stakeholders should understand the basis for ongoing royalty payments under the
license agreement, if any. One option for royalties is to make them payable for use of AI model
and any associated data, including the training and output data in the scenario outlined above.
Another potential option is to define royalties as being payable for products that are covered by
IP, including trade secrets as well as pending and issued patents. There may also be additional
considerations for royalties in the use of proprietary data.13

These and other considerations should be factored when formulating IP licensing strategies in
developing SaMD.

Exemption for imports for personal use

Under an existing regulatory exemption, an individual in Australia may lawfully import a

medical device not on the Australian Register of Therapeutic Goods (ARTG) for personal use.
If a device is not on the ARTG, there is no local Sponsor for the device and the TGA does not
have the same powers to monitor the safety, quality and performance of the device over time, or
to enforce product recalls for public health and safety reasons.

Under this regulatory exemption, SaMD products are being freely downloaded by millions of
Australians for personal use without regulatory oversight. The consultation paper states this does
not reflect the original intention of the exemption.

12
https://www.mondaq.com/unitedstates/healthcare/1335606/ip-contracting-considerations-for-software-as-a-
medical-device-samd
13
https://www.mondaq.com/unitedstates/healthcare/1335580/protecting-innovations-in-samd--biomedical-
applications
Under the proposed reforms, the personal use importation exemption will no longer apply to
SaMD products. All SaMD products will need to be included on the ARTG and have a local
Sponsor (with responsibilities to the TGA in relation to the product). It may be possible for
overseas developers to enter into developments with certain App stores (or similar), for example,
to potentially satisfy the requirement of having a local Sponsor.

"Essential principles" for SaMD products

The term "essential principles" refers to the regulatory requirements for the assessment of safety
and performance of medical devices. Sometimes international standards are used to demonstrate
that a medical device complies with the applicable essential principles. The existing regulatory
problem in this area is that the "essential principles" do not refer to software. This means it may
be unclear to SaMD developers what the applicable requirements are under Australian law.

The TGA proposes to add further details to the essential principles reflecting good software
development and security, including requiring the features, capabilities and risks of the relevant
computing platform to be taken into account during design and to require developers to adopt
best practice cyber security principles.14

General Intellectual Property (IP) Considerations for SaMD

This edition will discuss the sophisticated IP strategies that can be used to protect innovations for
the three categories of software for biomedical applications: SaMD, software in a medical
device, and software used in the manufacture or maintenance of a medical device, including
clinical trial collaboration and sponsored research agreements, filing patent applications, and
pursuing other forms of protection, such as trade secrets.

Licensing and Contracting with Third Parties for SaMD

This edition will unpack engaging with third parties practically and comprehensively, whether in
the context of (i) developing new SaMD or (ii) refining or testing existing SaMD. Data and IP
can be effectively either owned or licensed, provided such licenses protect the future interests of

14
https://www.mondaq.com/australia/healthcare/791862/software-as-a-medical-device-samd-tga-proposes-
regulatory-reform
the licensee. Such ownership and licensing are particularly important in the AI and machine
learning space, which is one area of focus for this edition.

FDA Considerations for SaMD

This edition will explore how FDA is regulating SaMD, which will include a discussion of what
constitutes a regulated device, legislative actions to spur innovation, and how FDA is
approaching regulation of specific categories of SaMD such as clinical decision support
software, general wellness applications, and other mobile medical devices. It will also examine
the different regulatory pathways for SaMD and FDA's current focus on Cybersecurity issues for
software.

Health Care Regulatory and Reimbursement Considerations for SAMD

This edition will discuss the intersection of remote monitoring services and SaMD, prescription
digital therapeutics and how they intersect with SaMD, licensure and distributor considerations
associated with commercializing SaMD, and the growing trend to seek out device specific codes
for SaMD.

Our hope is that this series will be a starting point for digital health companies, investors,
innovators, and clinicians as each approaches development and use of SaMD as part of their
business and clinical offerings.15

15
https://www.mondaq.com/unitedstates/healthcare/1318582/software-as-a-medical-device-challenges-facing-
the-industry-