Digital health companies often begin by developing an app, software platform or algorithm as a technology product. Medical device requirements may only enter the conversation later, when a customer requests regulatory evidence, an investor questions the product’s status, an NHS organisation asks for compliance information or the company prepares for market entry. By that point, important development decisions may already have been made without the controls, documentation or traceability expected for medical device software. The company may then face unexpected testing, certification, regulatory review and redevelopment costs at a commercially sensitive stage. A SaMD regulatory consultant should help the organisation answer two immediate questions: whether the software is a medical device and, if it is, what must be completed next, in which order and for which target market.
Not every health-related app, platform or digital tool is a medical device. The decision depends primarily on the software’s intended purpose and what it does with information, rather than the fact that it is used within healthcare. A product may operate in a clinical environment without performing a medical function, while another product presented as a general software platform may meet the definition of a medical device because its output supports diagnosis, monitoring, prediction, prognosis, treatment or another medical purpose.
The assessment should begin with the company’s stated intended purpose, but it should not stop there. The consultant should review the product’s functionality, intended users, outputs and actual use. It is important to consider whether the software analyses patient-specific information, whether its output influences a clinical decision and whether the product is limited to storage, communication, administration or general wellbeing. Claims made on the company website, in sales materials, during demonstrations and within the Instructions for Use should also be reviewed because inconsistent or overly broad claims can affect the regulatory position.
How customers and healthcare professionals use the software may also be relevant. A company may describe its product in cautious or general terms while its demonstrations, commercial discussions or user behaviour indicate that the software is being relied upon for a medical purpose. Changing the wording alone will not make medical functionality non-medical where the product is still intended to support diagnosis, treatment, monitoring or another medical activity. A sound regulatory assessment therefore requires a complete view of what the software does, how it is presented and how its output is used.
Once the company has established that the software is a medical device, the next step is to determine its classification and the regulatory pathway required for market entry. This should be addressed before the organisation commits to a submission plan, promises a customer a launch date or bases investment projections on an assumed route to market.
The strategy should begin with the company’s priority market because requirements, review routes, registration obligations and local representation needs can differ. The assessment should consider the software’s intended purpose, the significance of the information it provides and the seriousness of the healthcare situation it supports. These factors can influence classification and determine whether third-party conformity assessment or another form of regulatory review is required.
Classification can affect the level of evidence expected, the amount of external review involved, the cost of compliance and the overall time required to reach the market. Proposed claims should therefore be reviewed against the available evidence at an early stage. Where the claims go beyond what the company can support, the organisation may need to adjust the intended purpose, generate further evidence or change its regulatory strategy. A SaMD consultant should explain these implications clearly so that commercial, technical and regulatory decisions remain aligned.
The company should also identify the registrations, representatives and local requirements that apply in each intended market. Attempting to enter several markets without a defined sequence can create duplicated work and conflicting priorities. A practical strategy should show which market will be addressed first, what evidence can support more than one market and where additional local requirements will need to be managed separately.
Many digital health companies already use structured development tools and practices, including agile development, issue tracking, software testing, release controls and version management. These systems can provide valuable evidence, but they do not automatically meet all regulatory expectations for medical device software. The organisation must be able to show that development has been planned, controlled and documented in a way that supports the safety and performance of the product.
This may require controlled software requirements and architecture, software safety classification and lifecycle planning. The company should be able to trace requirements through identified risks, implemented controls and completed testing. Verification and validation activities must be documented, and the resulting evidence should show that the software performs as intended and that safety-related requirements have been addressed.
Third-party software and software of unknown provenance, often referred to as SOUP, also need appropriate control. The company should understand which external software components, libraries, hosting services or dependencies are used, what risks they introduce and how updates or vulnerabilities will be managed. Cybersecurity, vulnerability management and software updates should be integrated into the development and maintenance process rather than treated as activities that begin immediately before submission.
Usability engineering may also be required where user interaction can affect safety. The company should consider whether users can understand the output correctly, complete important actions and respond appropriately to alerts, recommendations or other information presented by the software. Release, deployment, maintenance and change management should also be controlled so that each version can be identified and supported by the appropriate documentation.
A SaMD regulatory consultant should map the organisation’s existing development process against the applicable requirements. The objective is not to replace every software practice with a separate regulatory system. It is to identify evidence that can already be used, strengthen areas that do not meet expectations and close genuine gaps. Creating a second development process that the technical team will not follow is unlikely to produce sustainable compliance.
Regulatory compliance is not limited to producing a software file or preparing a submission. The company must also explain how it will demonstrate the safety, performance and ongoing control of the product. This may include clinical evaluation and other performance evidence, depending on the software’s intended purpose and claims. The evidence strategy should be planned early enough to influence product development rather than being assembled retrospectively after the software is complete.
Risk management should address software hazards and the clinical context in which the product is used. The organisation should consider what could happen if the software produces an incorrect output, fails to provide information, presents information late or is misunderstood by the user. These risks should be linked to software requirements, design controls, testing and post-market activities so that the company can demonstrate how identified hazards are being managed.
The company may also require a quality management system and, where applicable, ISO 13485 certification. Supplier controls should cover cloud providers, hosting companies, external developers and other outsourced services that can affect the safety, performance or availability of the product. Complaint handling, vigilance, corrective action and post-market surveillance processes must also be planned before launch.
These activities should be integrated with the product roadmap. A software change that appears minor to the development team may affect the intended purpose, risk profile, clinical evidence, cybersecurity position or existing regulatory approval. The change process should therefore include regulatory assessment before updates or new releases are implemented.
Medical device software continues to change after market entry. New versions, bug fixes, infrastructure changes and cybersecurity updates may be necessary throughout the product lifecycle. The company should have defined processes for evaluating, approving and documenting these changes.
Post-market surveillance should collect information about how the product performs in use. This may include complaints, user feedback, incidents, corrective actions and other real-world information. The purpose is to identify whether the assumptions made during development remain valid and whether new risks, performance concerns or usability issues have emerged.
For digital health companies accustomed to frequent releases, this can require a change in approach. Regulatory control does not necessarily prevent regular updates, but it does require the company to understand the impact of each change. Updates should be assessed against the intended purpose, risk management documentation, verification and validation evidence, clinical claims and regulatory status. Without this assessment, the organisation may unintentionally introduce changes that affect classification, safety or the basis of an existing approval.
The most expensive time to discover that software is a medical device is usually after development is complete or when a commercial agreement depends on regulatory compliance. At this stage, the company may find that essential design and development records are missing, testing does not demonstrate the required safety or performance or the claims being made are not supported by suitable evidence.
Late identification may also reveal that the software falls within a classification requiring more external review than expected. This can delay customer contracts, investment discussions and market launch. The organisation may need to reconstruct development documentation, repeat testing, revise product claims, introduce a quality management system or rework parts of the software.
These issues can be especially disruptive where launch dates and commercial commitments have already been communicated. Costs that might have been planned and spread throughout development become urgent, unbudgeted requirements. The company may also need to divert developers and senior leaders away from planned product work to support retrospective compliance activities.
Early regulatory input allows the organisation to make informed decisions before those commitments are made. The company can decide which markets to prioritise, which claims to support, what evidence to generate and how regulatory controls will fit within the existing development process. It is generally more efficient to create suitable records and evidence as work is completed than to reconstruct them after the product has been built.
A SaMD regulatory consultant should provide more than a list of regulations or standards. The company needs a practical route forward that reflects the product, current stage of development, target market and commercial objectives.
The support should clarify whether the software is a medical device, its likely classification and the regulatory route required for the intended market. They should identify available evidence, documentation gaps, quality management system needs and outline the responsibilities of the company and any external providers. The consultant should also explain dependencies and the realistic sequence of work.
For a company that has already completed much of its development, the consultant should assess which existing records can be used and where retrospective work is genuinely necessary. For an earlier-stage business, the focus may be on integrating regulatory requirements into product planning, development, testing and release processes.
The advice should be understandable to technical, commercial and leadership teams. Regulatory decisions influence product features, claims, timelines, contracts and investment planning, so the implications must be communicated clearly across the organisation.
Digital health companies sometimes treat regulatory compliance as a separate workstream that begins once the product is ready. For medical device software, this can create avoidable delays because regulatory requirements influence the product throughout its lifecycle.
Intended purpose affects classification and evidence. Risk management affects requirements and testing. Clinical claims affect the type of performance evidence needed. Cybersecurity and supplier controls affect the development and maintenance process. Post-market obligations affect how the product is supported after launch.
A stronger approach is to include regulatory requirements within product strategy from the beginning. This allows the company to make informed decisions about features, claims, architecture, suppliers, evidence and market sequencing. It also gives investors, customers and healthcare organisations greater confidence that the product has been developed under appropriate controls.
LFH supports software and digital health companies in determining whether their products qualify as medical devices and establishing a practical route to market. Our team can help with SaMD classification, intended purpose, regulatory strategy, quality management systems, software lifecycle documentation, risk management, clinical evidence and post-market planning. We focus on identifying what is already in place, addressing genuine gaps and creating a sequence of work that supports both compliance and commercial progress.
A SaMD regulatory consultant helps software and digital health companies understand whether their product qualifies as a medical device and what regulatory requirements apply. This may include classification, market access strategy, software lifecycle documentation, risk management, clinical evidence, quality systems and post-market activities.
No. The decision depends primarily on the intended purpose and what the software does with information. Software limited to administration, storage, communication or general wellbeing may not be a medical device, while software used for diagnosis, monitoring, prediction, prognosis or treatment may fall within medical device requirements.
Regulatory input should be sought as early as possible, particularly before intended purpose, clinical claims, development processes and target markets have been finalised. Early support can reduce retrospective documentation, repeated testing and delays to customer contracts or market launch.
Agile development practices can be used, but the company must still demonstrate controlled requirements, risk management, traceability, verification, validation, release management and other applicable regulatory activities. Existing tools and processes should be mapped against these requirements.
A quality management system may be required depending on the product, classification and target market. The company should assess whether ISO 13485 certification or other quality system requirements apply and build the necessary processes around development, suppliers, complaints, corrective action and post-market surveillance.
Classification can influence the evidence required, whether external review is needed, the amount of documentation expected and the time required to reach the market. An incorrect early assumption can therefore lead to additional review, testing, certification and redevelopment costs.
Software changes should be assessed before release to determine whether they affect the intended purpose, risk profile, clinical evidence, cybersecurity position, classification or existing regulatory approval. Even changes considered minor may have regulatory implications.
