When developing medical device software, the natural temptation is to focus first on the product.
Build the algorithm. Develop the application. Connect the data. Test whether the concept works.
For regulated medical software, however, development cannot be separated from the evidence that will eventually be needed to demonstrate that the software is safe, performs as intended, and is suitable for its clinical purpose.
If requirements, testing and verification documentation are treated as something to reconstruct once the software is already finished, development becomes more difficult than it needs to be.
A better approach is to develop the product and the regulatory evidence together.
That starts before the first major development decisions are made.
Start with what the software is intended to do
Before deciding how to build a medical software product, there needs to be a clear understanding of what is actually being developed.
What is its intended use? What claims will be made? What role does the software have in the clinical workflow? What regulatory classification and pathway are likely to apply?
These questions are not separate from software development. They can directly affect what needs to be built and what ultimately needs to be demonstrated.
This is why our software development approach begins by considering the intended use, classification and claims against the expected regulatory route before development progresses too far.
For example, an algorithm that supports the organisation or visualisation of information may have very different evidence requirements from software that analyses patient data and provides information used for diagnosis or treatment decisions.
Defining that role early helps establish a clearer foundation for requirements, architecture, testing and verification.
It also reduces the risk of reaching a technically successful product only to discover that the evidence package does not adequately support its intended medical purpose.
Requirements and verification should grow with the software
In conventional software projects, documentation can sometimes be produced after development to describe what has already been built.
That approach becomes problematic in medical device software.
Requirements, design decisions, testing and verification need to maintain a clear connection throughout development. The evidence should therefore emerge from the development process itself rather than being recreated afterwards.
This is also where development and regulatory requirements begin to overlap.
MDS supports medical device software projects in alignment with frameworks such as IEC 62304, while connecting software development with technical documentation, risk management, usability engineering, clinical evaluation and preparation for EU and US regulatory pathways.
The objective is not to create documentation for its own sake. It is to make sure that the development process produces evidence showing what was intended, how it was implemented, how it was tested and whether the results support the defined requirements.
When this happens continuously, the resulting documentation reflects the actual software rather than an interpretation reconstructed months later.
Algorithm development starts before the final algorithm
Medical device software increasingly relies on algorithms, signal processing, statistical methods and, in some applications, machine learning or AI.
But algorithm development is not simply about choosing a model and optimising its performance.
It may begin much earlier with equipment testing, benchmarking, feasibility work and prototyping. From there, the project can move through algorithm development, testing and ultimately the evidence needed for regulatory submission.
This early work can be particularly valuable when the development team is still determining what can realistically be extracted from a signal or dataset.
Can the available data answer the clinical question? Is the signal quality sufficient? Which measurements are meaningful? How does the proposed method compare with existing approaches?
Answering these questions early can help prevent significant development effort from being invested in an approach that later proves unsuitable.
Good medical software depends on good data
For data-driven medical software, the algorithm is only part of the system.
The way data are collected, structured, labelled, analysed and validated can be just as important as the model itself.
Software development may therefore include building data handling platforms, annotation and labelling tools, and statistical workflows for analysing clinical and device data.
This becomes particularly important for AI and machine-learning applications.
The quality of the development and validation datasets, the way relevant events are labelled, and the relationship between the data and the intended clinical use all influence the evidence that can eventually be generated around the software.
MDS also works with medical data processing, algorithm development and preparation of training and validation datasets as part of its medical software development offering.
The regulatory question therefore should not only be whether an algorithm performs well technically.
It should also be whether the data, methods and resulting performance evidence support what the software is intended to do in practice.
From algorithms to applications
Medical device software projects can take many forms.
Some are standalone Software as a Medical Device (SaMD) products. Others are software components connected to physical devices, sensors or other medical hardware. MDS supports both types of development.
The development work may extend from algorithms and data handling into complete applications for web, iOS or Android platforms.
In other projects, the software may need to collect information from sensors, process physiological data and present clinically useful outputs to the user.
Regardless of the architecture, the same underlying principle applies: the technical solution, its intended medical purpose and the evidence needed to support it should remain aligned.
This becomes increasingly important as a project grows. A prototype may initially demonstrate that an idea works, but transforming that concept into regulated medical software requires a more controlled development structure.
Development should happen inside the quality system
Another important question is where the development process sits in relation to the manufacturer’s quality management system.
Outsourcing software development does not remove the manufacturer’s regulatory responsibilities.
For this reason, external software development should not operate as a completely separate process that eventually hands over finished code and a collection of documents.
The development work needs to fit into the manufacturer’s processes.
The approach described by our development partner is to work within the client’s quality system and produce software and documentation that can be used directly as part of the regulatory submission.
This allows responsibilities, requirements, reviews, testing and evidence generation to remain connected to the manufacturer’s own regulatory framework.
It also makes the eventual handover much more useful.
The manufacturer receives not only functioning software, but the development records and verification evidence needed to understand, maintain and support that software throughout its regulatory lifecycle.
Bringing software development and regulatory expertise together
Medical device software projects sit at the intersection of several disciplines.
There is software engineering, but also quality management, regulatory strategy, risk management, clinical evidence, usability and often complex data analysis.
Treating these as completely separate activities can create gaps between what is being built and what ultimately needs to be demonstrated.
Through MDS and our software development partnership, we bring these areas together.
Our development capabilities include early testing and prototyping, algorithm development including ML and AI, web and mobile application development, and platforms for handling, labelling and analysing medical data.
MDS complements this with regulatory and quality expertise, including technical documentation, clinical evaluation, software validation, risk management, usability engineering, and preparation for CE marking and FDA market entry.
The aim is to make regulatory thinking part of development rather than something introduced once the development work is already complete.
Build once, document as you go
Good medical device software development is not simply about producing working code.
It is about building a product whose requirements, design decisions, performance and verification can be understood and demonstrated throughout its development.
Starting with the intended use and regulatory route helps establish what needs to be built. Producing requirements and verification evidence alongside development creates traceability. Working within the manufacturer’s quality system ensures that the resulting software and documentation can support the wider regulatory process.
And for algorithm and data-driven products, considering the evidence strategy early helps connect technical performance with the clinical purpose the software is ultimately expected to serve.
At MDS, we support medical device software projects from early concept and regulatory planning through algorithm and application development, verification, documentation and preparation for market entry.
If you are developing a SaMD product, medical algorithm, data-driven application or software integrated with a medical device, we would be happy to discuss how development and regulatory planning can be approached together.
You can contact us at sales@mdsfinland.com or via Book a Meeting.
