How to build a SaMD: a step-by-step guide

Building Software as a Medical Device (SaMD) demands a wellstructured approach, from understanding the product' s purpose and user base to navigating regulatory requirements. This article will guide you through the process, covering regulatory compliance, certification, Product Design and Software Development phases.

TL;DR

Software as a Medical Device (SaMD) is an application intended for medical purposes, such as diagnosing, treating, or monitoring diseases or conditions. Building SaMD involves a strategic approach. Begin by clearly defining the software's purpose, target users, and intended level of treatment. Initiating the development process requires regulatory awareness, including certification considerations with a Notified Body. The Product Design phase involves collaborating on the application's vision and ensuring compliance with medical regulations. It’s important to estimate costs early, choose development models wisely, and be prepared for ongoing maintenance post-release. These steps ensure a successful journey in building medical software.

“I want to create a SaMD… ” and what’s next?

Let’s get the facts: for whom and for what

While taking the first step in building the medical device software, you need to know why you want to develop the particular solution, what sort of problem you would like to solve, and whether there is a real need for your product in the healthcare market. You also have to consider the product's target user – would you like to support a doctor, patient, or maybe both? Moreover, think through which level of treatment (the category that indicates the intensity of medical care based on the severity of a health condition) your solution will be useful and how it should work as an individual way of therapy or as a support for medications.

This first stage is extremely important and often boils down to verifying the idea, for example, through interviews with potential users and first simple mockups (simple Proof of Concept).

What is SaMD, and why it’s important to know the process of building it from the very beginning

You think about building a medical software device, but what exactly does it mean? Let’s explain.

Software as a Medical Device (SaMD) or software medical device (SWMD) are software applications intended for medical purposes, such as diagnosing, treating, or monitoring diseases or conditions. SaMD operates independently of any hardware medical device and can run on smartphones, tablets, or computers.

As a medical device, such software presents certain regulatory and technical requirements that need to be fulfilled to launch the product to the market. To build a successful product, you may want to get familiar with the Product Design and Software Development process with its technical requirements, but that’s not all.

Equally important is knowledge about medical regulations and the healthcare market. Also, while considering launching the SaMD to the market, it’s essential to understand the differences between certain regions and specific safety and data security regulations.

Should I develop the software on my own or hire an external company?

However, the good news is that you don’t have to do all the research and development alone.

You have two options:

• build the software with your internal team and care about certification and compliance with medical regulations on your own,

• hire an extended team or a company to design and build the product with you.
  

Both solutions have their pros and cons. When you decide to take care of the project yourself, you have complete control over the development process, enabling you to customise the software for the unique requirements. For building SaMD, you need not only a team including a Project Leader, QA Engineers and Developers but also Product Design Specialists (UX/UI). Moreover, if they don't have experience building SaMD, you'll need to train your team and make them more aware of the additional requirements for the SaMD development process.

All that you get when you decide to work with an external company. Apart from the complex team and regulatory support, when you find a reliable and skilled software development company, you decide on the progress and milestones of the project. At the same time, you don’t have to worry about the details, which allows you to focus on core activities in developing your idea.

Preparations done. Where to start?

In this article, we’ll focus on the external model of development. Supposing you’ve found a reliable and skilled company to build your product, what do you need to know for the first meeting?

First, think about your future application and its domain idea. Imagine how the app should work and in which way it can be helpful to the patients (or medical staff). Do you have any vision of potential solutions, technologies, or designs? If yes, you can discuss your idea with technical and regulatory specialists, who will help you verify the realistic opportunities to make your vision work and turn it into a plan.

If you don’t have a detailed idea yet, it’s not a problem. The project's first phase includes meetings and workshops that will clarify your concept and enable you to start the development.

The first step: medical regulations

At the beginning of your process, it’s good to be aware of its stages. We’ll discuss the next steps of Product Design and Software Development, but first, let’s focus on regulatory issues.

Why is that?

As a manufacturer, you must define the product's intended medical use and user demographics; also, think about the potential risks to the user when using the application. Importantly, you should also specify in which countries your product will be available. If the target countries are from the EU, your product should be developed according to the requirements described in the MDR Regulation 2017/745.

MDR, Notified Body and clinical trials - what about them?

MDR classification determines the device class and the need for a Notified Body for certification (for classes IIa/IIb/III). Regardless of your medical software class, consider documenting the entire product development process, starting from initial concepts, legal and technical requirements, risk analysis, development, verification and validation. Such documentation is necessary to show the traceability of product development. It will also help the manufacturer to create the Technical File, which the MDR requires.

You should also recognise if similar medical devices already exist. Why? An innovative product without equivalent devices on the market requires clinical studies to gather the clinical data necessary to demonstrate efficacy, confirm clinical safety and finally obtain certification through documented development and trial results.

Knowing these requirements before the beginning of development is better than making significant changes in the middle of the process. Moreover, the MDR emphasises the importance of ensuring the safety and performance of medical devices, including software components. Manufacturers must follow specific procedures and documentation processes during the design and development of medical devices to demonstrate compliance with the regulation.

Furthermore, in the case of Class IIa/IIb/III medical software, the certification process with the Notified Body is often a long journey which takes place after software development. Certification costs depend on whether you are building a SaMD or SiMD, its risk class, and the complexity of the software. Certification may take from a few months to over a year. For that reason, it’s worth preparing it in advance and contacting the Notified Body to set up the time of certification procedure and clinical trials (if necessary).

If you don’t start the certification process after the product is designed, verified and validated, you can do it even when the product is ready. However, bear in mind that it might take time and delay launching your product to the market.

What is a medical application and medical software?

To properly understand the meaning of medical regulations in software development, it’s worth remembering some definitions.

Is the process of certification by the Notified Body necessary?

You’re probably wondering if it’s necessary to certify your software by Notified Body. Well, it depends.

Which software must be certified?

Suppose the software is intended for medical diagnosis (including software for in vitro purposes – IVD), monitoring, treatment, or prevention and meets the definition of a medical device. Such software usually falls under Class IIa MDR or higher; in that case, a Notified Body must be involved in assessing the conformity of such a product.

You don’t need a Notified Body when software:

• has a medical purpose, and it’s classified as a low-risk medical device and poses minimal potential harm to patients or users (Class I MDR),

• is not intended for medical purposes (Note: The intended use and claims made by the manufacturer determine whether it falls under MDR),
  

• is developed solely for research purposes and not intended for clinical diagnosis or treatment and any other medical purpose listed in the definition of medical device.
  

Let’s take a look at the consequences of certification.

What does the process of certification look like?

Certification of medical software begins with gathering the knowledge. You can find the information online (for example, on our blog) or schedule a meeting with the Regulatory Specialist to get personalised advice about the process. To make such a consultation as valuable as possible, you should prepare some information: what the software will be used for, who it will be dedicated to, and what potential risks may be associated with its use. In other words, have an outline of intended use.

The final result of risk classification depends mostly on the product's intended use.

The same SaMD can have different classes, depending on how its intended purpose is defined. For example, as described in MDCG 2021-24, “MDSW intended for diagnosing depression based on a score resulting from inputted data on patient symptoms (e.g. anxiety, sleep patterns, stress, etc.)” will fall into Class IIb. However, when a specialist determines the necessary cognitive therapy based on the outcome provided by the app, it would be classified as Class IIa”.

The intended use of the software also determines if you need external certification. Clearly defining and documenting the intended use is crucial for regulatory submission and proper device or software classification. The intended use statement should be concise, accurate and reflect the device's medical purpose and indications for use.

Risk classification

After defining the intended use of the software, it’s time for initial risk analysis and determining the proper medical device risk class, as described in Rule 11 MDR.

The classification depends on factors such as intended use, potential harm, and mode of action. Higher-risk classes typically require a more rigorous certification process.

Medical device software is classified according to the four risk classes:

• CLASS I: software of the lowest level of risk that doesn’t require Notified Body certification (“self-declaration” class).
  
  Example: HelloBetter Diabetes, an online course that helps to reduce depressive symptoms and emotional burdens associated with diabetes.
  
  

• CLASS IIa: software of a moderate level of risk intended to provide information to make “low-risk” decisions with diagnosis or therapeutic purposes or monitor physiological processes.
  
  Example: ABAStroke, a digital health app for at-home neurological treatment of cognitive deficits for stroke survivors with minor motor deficits who require cognitive rehabilitation
  
  

• CLASS IIb: high-risk software for critical diagnostic or therapeutic decisions with potentially serious consequences, including surgery or immediate danger to the patient's health.
  
  Example: AblyMedical app to control the smart bed system that mobilises and monitors patients, enabling nurses to provide better patient care
  
  

• CLASS III: software of the highest level of risk intended to provide information used to make decisions with diagnosis or therapeutic purposes that have an impact that may cause death or an irreversible deterioration of the user.
  
  Example: Stylet by Dixi Medical, a specific stereotactic instrument to provide accurate electrode positioning.
  
  

Regulatory approval

The next step is regulatory approval. The Notified Body reviews the technical documentation of the product in accordance with Annex II and III of MDR, including project documentation following IEC 62304, IEC 62366 and other normative requirements applicable to the product, proper risk classification, intended use, verification and validation reports as well as information delivered to the user like user manual etc. and many others.

The second part of the Notified Body review is the quality management system of medical device manufacturer organisations, usually ISO 13485. The positive result of the conformity assessment allows you to place the CE mark on your medical device, confirming that it meets regulatory and safety requirements and is ready to be launched in the market.

The process of certification usually takes a minimum of a few months.

How do we provide regulatory compliance at Revolve?

At Revolve, we start our process by setting a meeting with our Head of Regulatory Affairs to discuss your unique challenges. Then, we oversee the entire software development process, covering design, quality assurance, risk management, documentation, and reporting. We assist with SaMD risk analysis, certification roadmaps (we can help you with the whole process of creating certification roadmaps or support your own process from the regulatory side), software audits, and documentation describing software development.

The team comprises dedicated design and development specialists led by an experienced project leader and regulatory specialists who take care of MDR compliance.

We can also provide discovery workshops, usability and technical consultations and specialist audits, including technological readiness, documentation, and UX

Important regulations to follow while building a SaMD

• MDR 2017/745 contains a set of requirements for medical devices (as well as their manufacturers) within the EU. Annex VIII of this regulation contains rules for classifying medical devices, including Rule 11, dedicated to software with medical purposes.
  
  

• MDCG 2019-11 is a guide on the qualification and classification of software. It defines the criteria for the qualification of software as a SaMD and provides guidance on the application of classification criteria described in 2017/74.
   

• ISO 13485 is the international standard containing requirements for a quality management system for medical devices. It focuses on the quality management of medical device manufacturing, maintenance, and regulatory compliance. 
  
  

• ISO 14971 is an application of risk management to medical devices. It provides guidelines for managing risks associated with medical devices. 
  
  

• IEC 62304 focuses on medical device software lifecycle processes. It addresses software development and maintenance processes for medical devices. 
  
  

• IEC 62366 is a standard focusing on usability engineering in developing medical devices to enhance user safety and satisfaction.
  

From vision to reality: the Product Design phase

The Product Design phase is necessary to begin software development and provide the development team with clues on how the software should work. And for that, you need a clear vision of your future product.

It’s like building a house. When you hire an architect, you can be sure that the project is well-thought, tailored and verified by the specialist. When you try to do it on your own (even though you have a few friends who know something about drawing), the chances of getting a reliable plan are weaker.

There’s no universal method to prepare for the product design. You may already have some drafts, materials, documentation, or just an idea, but it's a good starting point, no matter how advanced your vision is. A company like ours will use it to determine and prepare the next steps.

What does it look like?

Working on product design usually begins with a workshop, during which you’ll discuss the details of your app with the UX and development team. It’s a great moment to consider the intended use and physical condition of the patients who will use the software to adjust the interface to their needs. The workshop is also a space where you get to know the team members, their working style and the company's values, which helps you decide if you want to entrust them with the software development.

As part of software product design, we conduct preliminary medical regulatory work, including regulatory consultations to help you discover which risk class your software will fall into.

The Product Design phase's time and cost differ in every company. At Revolve, we do it within two and eight weeks, and the cost is usually around 2-5% of the software development value. It ends with providing an estimation of the development budget and time.

Why go through a decent product design instead of doing it yourself?

First and foremost, it saves time and money. The objectives are clearly defined, which means you avoid mistakes when planning the product. It’s also a chance to verify if the project can enter the market. In extreme cases, thanks to the Product Design phase, you can avoid making a bad investment if the product does not respond to consumer demand or fit your budget.

Decoding the software creation: the Software Development phase

Software development is naturally the longest and most costly part of the product development process. It can be done in the in-house model, but for this, you need experience and a well-chosen team of specialists. You can also decide on the outsourcing model, which involves hiring individuals. You can also opt for an end-to-end solution, where you hire a full set-up: software developers, QA engineers, UX/UI designers, regulatory specialists, along with a project leader who oversees the entire project. At Revolve, we prefer the third option while working with our clients.

If a software development company launches many projects in a year, the customer opting for their services is much more confident that they have a well-thought-out and coordinated process. Additionally, companies that deal with managed projects are like special forces units in the software market – when they receive a task, they know exactly where to start, how to take the next steps and organise the whole process of communication and software development.

Thanks to the experienced Project Leader, who manages the project scope by creating, organising, and maintaining the backlog, controls the percentage progress of the project and budget use and coordinates the development team, the team can deliver high-quality projects on time and within a budget.

Read more about the roles of Project Leaders and their work at Revolve Healthcare in our article.

How about methodologies?

Contemporary projects are developed based on agile methodologies such as Scrum and Kanban to ensure efficiency and flexibility throughout the development process. Scrum, a widely adopted approach, allows teams to work in iterative cycles, fostering collaboration and adaptability.

You’re probably wondering if it’s possible to combine methodologies like Scrum with regulatory requirements such as IEC 62304 when developing medical software. The answer is yes. While Scrum is focused on flexibility and adaptability, IEC 62304 provides guidelines for software lifecycle processes. In a combined approach, teams must integrate specific documentation, validation, and risk management procedures to ensure compliance, striking a balance between agility and regulatory adherence.

You can read more about the process of developing software compliant with IEC 62304 on our blog.

How long does it take?

Well, it depends if we’re speaking of MVP or the complete software ready to enter the market.

A medical software MVP is like a healthcare app's first version with only the most important features. It's made to test the functionalities and get user feedback (for example, doctors and patients). This allows developers and healthcare experts to work together to ensure the app is useful, safe and compliant with medical regulations. They keep improving it based on what users say, ensuring it follows the MDR rules and adding more features in later software versions.

The standard process of creating an MVP takes 3 to 6 months, but it is worth bearing in mind that this time depends on the specifications of the project and the number of details it contains. Software for the same purpose can be done over several months or even years. A lot also depends on the size of the team working on the project.

Usually, 3-4 developers are involved in the MVP development process, but additional people are involved in the project.

How much does it cost?

Usually, it’s hard to tell without an estimation carried out during the Product Design phase.

Estimation is necessary to arrange the development scope and determine how much of the budget will be spent on a particular software element. Without it, a project is just a blurry vision.

Let’s explain this in an example.

How is your software being developed?

The software development journey begins with meticulous planning, leading to several crucial steps.

They involve:

• analysis of software requirements,

• strategic architectural design,
  

• unit implementation and verification,
  

• integration and integration testing,
  

• system testing.
  

The final step is software release, when your software is ready to use. However, you won’t be finished with your responsibilities once the software has been released. Staying compliant with IEC 62304, you'll need to maintain the software and resolve problems as they arise. The conditions and requirements in the maintenance area depend on your capabilities and needs, the size of the project, and the certification class, and we usually determine these during software development.

Remember that the decisions made during the Product Design phase are not final – you can always adapt them to new circumstances. Returning to the metaphor of building a house, software development differs from building. Once a building is complete and finished, it is challenging to rebuild its first floor suddenly. On the other hand, programming leaves a broader scope – you can always change something during development.

Fixed price and time and materials: the differences

When considering paying for the projects, there are two accountability models: fixed price and time and materials.

Fixed Price Model: A pricing model where the cost for a project is agreed at the beginning and remains still, regardless of the time or resources invested.

Time and Materials Model: A billing method based on the time spent and resources used in a project, with costs varying according to the hours worked and materials consumed.

Let’s take a look at the benefits and drawbacks of each of them.

How can we help you in building medical software?

At Revolve Healthcare, we provide support from the beginning, guiding you through gathering knowledge of medical regulation, the process of Product Design and Software Development, and advising on technical and regulatory issues. We’ve been designing our process for 1.5 years to make it as docile and customised as possible.

It is quality, not quantity, that is important to us. For this reason, we’ve spent so much time improving our process to avoid organisational shortcomings, such as increased project duration or costs.

Every year, we launch several healthcare projects starting from scratch, and we manage the software development process on our side. Our development is performed by people who know it from the inside and can adjust it to the budget, time, quality expectations and ISO regulations. Guiding through the evolution of the project is challenging, but by our clients’ opinions, we do it well.

Let’s talk about your SaMD ideas!