In practice, regulated software development isn’t ordinary delivery followed by a documentation sprint. Intended use informs requirements, hazards shape controls, controls influence design, and verification evidence has to match the software version that reaches users. Production data then feeds back into maintenance and risk review.
This guide provides practical engineering and product guidance; it isn’t a substitute for legal or regulatory advice. The route depends on the specific product, its intended purpose, functions, risk, market, and classification. A qualified regulatory professional should determine that route, while engineering creates the controls and evidence to support it.
TL;DR
- Start by defining the intended use, users, clinical context, and target markets. Those decisions are going to drive much of the work that follows, including qualification, classification, evidence, and the engineering controls the product needs.
- Rather than treating each area in isolation, consider requirements, risk controls, architecture, verification, cybersecurity, and release evidence as parts of one system. They're connected, and a decision in one area often changes the work in another.
- Use the latest standards and regulator guidance that are relevant to the product and market. Standards can help with compliance, but that doesn't make every standard a legal requirement in every jurisdiction.
- Plan for maintenance from the start. That means deciding how the team will handle complaints, vulnerabilities, supplier notices, field performance, and model drift, any of which can reopen the risk analysis after launch.
What is medical device software?
Not everything that handles health information is medical device software. A scheduling portal, claims workflow, staff collaboration tool, or general wellness app may process health data without meeting the legal definition of a device. Software intended to diagnose, prevent, monitor, predict, prognose, treat, or alleviate disease may be considered a medical device, depending on its claims and where it is offered.
Three categories are helpful when discussing the scope:
- Software as a Medical Device (SaMD): software that performs a medical purpose without being part of hardware, such as an application that analyzes an image for a clinical finding.
- Software in a Medical Device: embedded or integral software required for a physical device to perform its intended function.
- Non-device health software: administrative, educational, wellness, communication, or data-management functions that sit outside the relevant device definition.
The FDA’s SaMD overview distinguishes software that is itself a device from software integral to a device and software used in manufacture or maintenance. In the EU, MDCG 2019-11 rev.1 addresses qualification and classification under the MDR and IVDR. For Great Britain, the MHRA software and AI guidance collection begins with the same practical questions about intended purpose and qualification.
A label such as “decision aid,” “wellness tool,” or “AI assistant” doesn’t settle the question. The team still has to examine the users, inputs, outputs, clinical context, level of influence, claims, and foreseeable use. Those details are usually more informative than the label on the feature.
Step 1: Fix intended use, users, and target markets
The first controlled deliverable needs to be an intended-use statement detailed enough to set real boundaries. It should identify:
- the medical or non-medical purpose;
- the target population and relevant exclusions;
- the intended user, such as a clinician, technician, patient, or caregiver;
- the use environment, including home, clinic, hospital, or laboratory;
- the input data and the output produced;
- the decision or action influenced by that output;
- whether the software informs, drives, or performs the action;
- the markets where the product will be offered.
Claims need the same discipline as requirements. A landing page that promises to detect or diagnose a condition creates a different regulatory question from one that discusses secure storage or workflow coordination. Product, clinical, regulatory, sales, and marketing teams need to agree on one claims baseline. Otherwise, engineering may build a product that doesn’t match the commercial materials.
Market selection needs to happen during discovery too. The United States, European Union, and Great Britain use related concepts, but their definitions, classification logic, routes to market, and post-market duties differ. A US team may need to evaluate 510(k), De Novo, or PMA pathways, while an EU product falls under the MDR or IVDR. Great Britain has its own framework, and Northern Ireland can involve EU rules. One evidence architecture can support several markets, but a classification conclusion can’t simply be copied from one to another.
A practical regulatory and standards map
The references involved here do different jobs. Regulations establish legal obligations, consensus standards provide widely accepted working frameworks, and regulator guidance explains an authority’s recommendations or interpretation. The product scope, market, and classification determine which combination applies.
For software lifecycle work, the current consolidated publication is IEC 62304:2006+AMD1:2015, edition 1.1, and IEC lists a stability date of 2028. ISO records ISO 14971:2019 and ISO 13485:2016 as current after their 2025 reviews. A medical device software development standards matrix should record the edition, market recognition, product relevance, and the evidence each reference changes.
In the United States, the FDA Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. This alignment does not make every clause, record, or market expectation identical worldwide. The regulatory strategy and standards-applicability assessment still need to be market specific.
| Layer | Main reference | What it governs | Engineering implication |
|---|---|---|---|
| Market authorization | US FD&C Act and FDA regulations; EU MDR/IVDR; UK medical-device rules | Qualification, classification, route to market, and post-market obligations | Set target markets and document classification assumptions before evidence is baselined |
| Quality management | ISO 13485:2016; US QMSR | Organization-wide controls for design, suppliers, records, corrective action, and product realization | Run development through controlled procedures, roles, reviews, records, and change control |
| Software lifecycle | IEC 62304:2006+A1:2015, edition 1.1 | Development, maintenance, safety-related classification, configuration, and problem resolution | Define lifecycle work and evidence in proportion to software safety class |
| Risk management | ISO 14971:2019 | Hazard identification, risk evaluation, control, and production/post-production information | Link hazards and hazardous situations to implemented and verified controls |
| Usability engineering | IEC 62366-1:2015+A1:2020 | Safety-related usability and use-error risk | Treat the interface and use environment as possible contributors to harm |
| Cybersecurity | Market-specific requirements and current regulator guidance | Secure design, vulnerability management, evidence, labeling, and post-market response | Maintain threat models, security requirements, SBOM evidence, testing, and response processes |
Figure 1. Regulatory and standards map: intended use and classification connect to the market framework, while QMS, software lifecycle, risk, usability, and cybersecurity references produce the engineering evidence. Applicability varies by product, market, and classification. Custom visual by Intelisoft.
The medical device software development life cycle
A well-controlled medical device software development life cycle can be iterative. What counts isn’t a strict waterfall process, but planned activities, regular reviews, clear baselines, and evidence that builds with each significant change.
01
Planning
Planning lays the foundation. It establishes:
- Roles
- Software safety classification
- Expected deliverables
- Review points
- Configuration management
- Problem resolution
- Supplier controls
- Cybersecurity work
- Evidence tools
It should also explain how iterative development will work without disrupting approved baselines instead of leaving each team to figure that out later.
Requirements
Take the intended use, user needs, risk controls, interfaces, performance targets, security objectives, and market expectations, then turn them into requirements that can actually be tested.
Not acceptance criteria
Terms such as “fast,” “intuitive,” or “secure”
Specify instead
The operating conditions, expected behavior, measurable limit, and what the system does when that limit is exceeded
03
Architecture and Detailed Design
Architecture needs to show the boundaries that matter: components, interfaces, data flows, trust zones, external dependencies, failure modes, segregation mechanisms, and ownership. Detailed design then goes far enough for the work to be implemented and reviewed.
Decisions that reduce risk belong in the design record, not only in meeting notes.
Implementation and Unit Verification
Coding practices, review depth, static analysis, unit tests, dependency policies, and build controls should all follow the risk involved. A passing unit test doesn’t prove clinical suitability, but it does provide local evidence that a component behaves as expected.
Reproducible builds and controlled environments make it possible to see what was actually tested and released.
05
Integration and System Verification
Integration testing looks at how components, devices, networks, and external systems interact. System verification asks whether the agreed requirements were met.
Useful evidence records the configuration, input, expected and actual results, anomalies, the reviewer’s decision, and the requirement or control being tested.
06
Release
Release isn’t simply a deployment date. It’s the point where the team confirms:
Approved baselines, unresolved anomalies, and residual-risk decisions
Cybersecurity status and required documentation
Version identity, installation or deployment instructions, and recovery provisions
The released binary and supporting records have to describe the same product.
07
Maintenance and Problem Resolution
Once teams start using the product, complaints, incidents, support cases, vulnerabilities, telemetry, supplier notices, and field performance may trigger an investigation. Every change needs a critical review: has the team checked safety, security, intended use, validation, and market impact?
How long the lifecycle lasts
The medical device software lifecycle lasts for as long as the product is supported.
Requirements and end-to-end traceability
Medical device software requirements need to cover what should happen when everything goes right and what happens when things go wrong. For a dose-calculation function, that means valid ranges, units, rounding, incomplete or contradictory inputs, stale data, unavailable services, user confirmation, audit events, and the response when the system can’t produce a safe output.
Give each requirement a stable ID, along with its source, rationale, acceptance method, and status. Higher-level needs break down into system and software requirements; hazards create risk controls. The medical device software requirements baseline should make four questions easy to answer:
- Why does this function or control exist?
- Where is it implemented?
- How was it verified?
- What else must be reviewed if it changes?
Traceability isn’t about creating a spreadsheet after the work is done. It’s about maintaining the relationships between requirements, controls, design, code, and evidence throughout the medical device software lifecycle. A simple example looks like this:
User need → system requirement → software requirement → risk control → architecture/design/code → verification evidence → approved release
The relationships aren’t always one-to-one. A single hazard might need several controls, while one system test can cover several requirements. The tool matters less than the integrity of the links: identifiers need to stay stable, changes need review, access needs control, and reports need to be reproducible.
Figure 2. End-to-end traceability chain from user need to approved release, with example identifiers, accountable roles, and backward impact analysis when a requirement, risk control, component, or test changes. Custom visual by Intelisoft.
Risk management changes the workload, not the principles
Risk management starts with the product and the way people will use it, rather than with a list of bugs found during testing. Teams identify hazards, sequences of events, hazardous situations, potential harms, and the people affected. They evaluate risk against an agreed policy, choose controls in a logical order, check whether those controls work, assess what remains, and keep watching production and post-production information.
Software may return the wrong information, suppress an alert, delay an action, misidentify a patient, lose data, or control hardware incorrectly. A cybersecurity event can become a safety issue too if it affects availability, integrity, or clinical behavior.
More rigor doesn’t mean producing pages for their own sake. It means deeper analysis, more independent review, broader testing, and better evidence where failure could cause serious harm. The medical device software development process should direct effort toward the areas with the highest risk instead of applying the same routine everywhere.
Rigor by risk level
Requirements
Area 1 of 6
Lower safety or regulatory risk
Focused functional and operational baseline
Higher safety or regulatory risk
Formal decomposition, hazard-derived controls, edge cases, and stronger review evidence
Architecture
Area 2 of 6
Lower safety or regulatory risk
Standard component and interface documentation
Higher safety or regulatory risk
Segregation, fault handling, independence, defensive design, and documented rationale
Verification
Area 3 of 6
Lower safety or regulatory risk
Representative functional and integration coverage
Higher safety or regulatory risk
Boundary, failure, stress, negative, recovery, and control-effectiveness testing
Change control
Area 4 of 6
Lower safety or regulatory risk
Product and technical impact review
Higher safety or regulatory risk
Explicit safety, cybersecurity, traceability, validation, and regulatory impact analysis
Suppliers and components
Area 5 of 6
Lower safety or regulatory risk
Basic fit, license, and maintenance review
Higher safety or regulatory risk
Criticality, provenance, known-anomaly review, monitoring, and fallback decisions
Release
Area 6 of 6
Lower safety or regulatory risk
Product acceptance and operational readiness
Higher safety or regulatory risk
Formal anomaly disposition, residual-risk review, configuration evidence, and authorization
Software safety classification and process rigor
IEC 62304 assigns software safety classes according to what could happen if the software fails after controls outside the software system are considered. The class affects which lifecycle activities are needed, but it isn’t the same as the overall device class used by a regulator. They serve different purposes, and the labels aren’t interchangeable.
The classification needs solid reasoning behind it. Architecture can change the outcome when an external or independent control stops a software failure from contributing to unacceptable risk. Independence has to be real, though. A safeguard that relies on the same failing component, data source, or control path may add very little protection.
Document the assumed software safety class.
Record the reasoning behind it.
List the external controls considered.
Name the components covered by the conclusion.
Confirm that any independent control is really independent of the failing component, data source, or control path.
Revisit the decision whenever intended use, architecture, or risk controls change.
Medical device software development standards provide a framework, but the manufacturer is ultimately responsible for applying it correctly.
SOUP, open source, and third-party components
Most products rely on software that wasn’t written for the current device. IEC 62304 uses the term SOUP, commonly expanded as “software of unknown provenance” or “software of unknown pedigree,” for relevant items without adequate development records or not developed for incorporation into the device. Open source can be SOUP, but the two concepts aren’t identical. Commercial SDKs, drivers, databases, and cloud components may need the same kind of scrutiny.
Keep an inventory for every component, including its version, source, license, purpose, interfaces, known anomalies, security status, and locations in the product. Then assess the questions that affect the decision:
Need and alternatives
Why is the component needed, and were safer or better-supported alternatives considered?
01
Failure effect
What could its failure cause in the product’s intended context?
02
Known issues
Which known defects, limitations, and security advisories are relevant?
03
Architectural limits
Which architectural controls limit the effect of a failure?
04
Integrated verification
How will the component be verified in the integrated system?
05
Monitoring and response
Who monitors updates and vulnerabilities, and how quickly must the team respond?
06
Support and end of life
What is the support, replacement, or end-of-life plan?
07
An SBOM is useful, but it doesn’t replace the work. A package list can’t show whether a vulnerability is reachable, whether a known defect affects a safety function, or whether an upgrade changes validated behavior. “Not exploitable” should be a documented technical conclusion with supporting context, not a status copied from one release to the next.
Figure 3. SOUP and vulnerability control loop: from intake and version capture through assessment, integration verification, and release inventory to monitoring, impact analysis, remediation, and re-verification. The SBOM is an input and output of the loop, not the complete process. Custom visual by Intelisoft.
Building software that may be a medical device?
Tell us about the intended use, users, and target markets. We will help plan the engineering controls and evidence the product needs.
Cybersecurity belongs inside design control
Cybersecurity needs to sit inside design control from the beginning. A final penetration test can only cover part of the security case. Threat modeling should start while the architecture and data flows are being defined so security requirements enter the same baseline as functional and safety requirements.
For connected software, take a close look at identity, authorization, cryptographic boundaries, secrets, update mechanisms, logging, data integrity, availability, separation, interfaces, recovery, and secure defaults. Model plausible attack paths, including compromised accounts, manipulated inputs, dependency compromise, denial of service, unauthorized updates, and lost connectivity.
Where does the security work sit?
Threat modeling in the design baseline
What it involves
Threat modeling should start while the architecture and data flows are being defined so security requirements enter the same baseline as functional and safety requirements.
Main caution
A final penetration test can only cover part of the security case.
FDA premarket cybersecurity guidance
What it involves
The FDA’s current premarket cybersecurity guidance is dated February 2026 and supersedes the June 2025 version. It connects cybersecurity design and documentation to the quality system and addresses devices covered by section 524B.
Main caution
Product teams still need to determine which statutory and guidance provisions apply rather than assuming every connected application carries the same submission obligations.
Post-market capability
What it involves
Define how vulnerability reports enter the organization, which monitoring sources the team will use, how issues will be triaged, and when remediation, disclosure, customer communication, rollback, or regulatory escalation is required.
Main caution
A secure release without a maintainable update path leaves the control incomplete.
Verification and validation answer different questions
Verification asks whether the specified requirements were implemented correctly. Validation asks whether the product meets user needs and intended uses in the environment where it’s expected to operate. Both need planned evidence that another qualified person can review.
Testing should follow the product’s architecture and risk profile rather than the number of screens. Depending on the product, the strategy may include unit, integration, system, interface, performance, installation, upgrade, recovery, interoperability, security, usability, and regression testing. Tests for risk controls need to challenge the assumptions behind the control, including invalid data and borderline cases.
Usability validation is especially important when user action or inaction can contribute to harm. Representative users, critical tasks, realistic environments, labels, alerts, and foreseeable use errors all matter.
A polished interface, by itself, isn’t evidence that safety-critical tasks can be completed correctly.
| Activity | Question it answers | Evidence it needs |
|---|---|---|
| Verification | Were the specified requirements implemented correctly? | Planned evidence that another qualified person can review |
| Validation | Does the product meet user needs and intended uses in the environment where it is expected to operate? | Planned evidence that another qualified person can review |
| Risk-control tests | Does the control hold when its assumptions are challenged? | Results with invalid data and borderline cases |
| Usability validation | Can safety-critical tasks be completed correctly when user action or inaction can contribute to harm? | Representative users, critical tasks, realistic environments, labels, alerts, and foreseeable use errors |
The FDA’s 2023 guidance on device software submission content describes recommended documentation for premarket review and uses risk-based Basic and Enhanced documentation levels. Those levels should not be confused with IEC 62304 software safety classes; they answer different questions.
Agile delivery can work under regulated controls
“A sprint doesn’t need to produce a formal submission package, but it should leave requirements, risk items, design decisions, code, reviews, tests, and anomalies in a coherent state.”
Intelisoft engineering team
Agile and regulated delivery can work together when the team controls the right objects. One workable pattern keeps discovery flexible while protecting approved baselines. Teams can refine backlog items, prototype an interface, and test assumptions, then baseline requirements before the affected implementation is accepted. The definition of done includes traceability, required reviews, automated evidence, risk-control updates, and anomaly handling. Release reviews assemble that evidence from completed increments instead of reconstructing it months later.
Automation only helps when its output can be trusted. Versioned pipelines can retain build identity, test results, analysis reports, approvals, and deployment records. The organization still has to define each evidence tool’s intended use, the risk of incorrect output, and the controls needed to rely on it.
“A well-run medical device software development process becomes faster because evidence is produced alongside the work.”
Intelisoft engineering team
Figure 4. Medical device SDLC with continuous risk overlay: eight iterative stages, risk management, cybersecurity, configuration management, and problem resolution across every stage, risk-control verification before release, and production feedback returning to risk analysis. Custom visual by Intelisoft.
| Element | How it works under regulated controls |
|---|---|
| Discovery | Teams refine backlog items, prototype an interface, and test assumptions. |
| Baselines | Requirements are baselined before the affected implementation is accepted. |
| Definition of done | Traceability, required reviews, automated evidence, risk-control updates, and anomaly handling. |
| Release reviews | Evidence is assembled from completed increments instead of being reconstructed months later. |
| Versioned pipelines | Build identity, test results, analysis reports, approvals, and deployment records are retained. |
| Evidence tools | Each tool's intended use, the risk of incorrect output, and the controls needed to rely on it are defined. |
Intelisoft’s engineering approach
A device function rarely operates alone. Intelisoft has delivered EHR-connected workflows, remote patient monitoring, telemedicine, patient-facing products, and clinical analytics. In one remote-monitoring engagement, a seven-month implementation supported more than 3,000 patients with 99.9% data-pipeline uptime. The result shows experience with continuous health-data processing and operational reliability; it isn’t presented as evidence of device clearance or certification.
Remote patient monitoring
Source: Intelisoft project data, seven-month implementation. The result isn’t presented as evidence of device clearance or certification.
Intelisoft starts by understanding the client’s clinical and operational workflow before proposing an architecture. For device software, discovery maps intended users, decisions, data sources, integrations, failure consequences, and operating ownership. Only then does the team select an implementation pattern.
Understand the workflow
Clinical and operational
Map discovery
Users, decisions, data, integrations
Select a pattern
Only then, the implementation
Delivery runs across five engineering tracks: requirements and traceability, architecture, risk controls, verification, and release operations. Senior engineers can work inside the client’s established quality system, create technical evidence in the required tools, and coordinate with clinical and regulatory specialists.
What Intelisoft does
What it does not do
Engineering scope
Builds software and technical evidence
Classification, submission strategy, regulatory representations, or market authorization
Quality system
Works inside the client’s established quality system and coordinates with clinical and regulatory specialists
Legal or regulatory advice, or a replacement for the manufacturer’s decision-makers
Project results
Experience with continuous health-data processing and operational reliability
Evidence of device clearance or certification
Case example: ambient clinical documentation
Healthcare
Ambient clinical documentation
Epic and Cerner
It shows relevant workflow and integration experience, while any new product still needs its own intended-use assessment.
AI and machine learning need additional controls
AI-enabled device functions raise questions that a purely deterministic feature may not answer.
01
Define the model in the development record
The record has to define the model’s role, data provenance, reference standard, population coverage, performance metrics, subgroup analysis, uncertainty handling, human interaction, change policy, and monitoring plan.
02
Don’t mistake training performance for clinical validation
A model may perform well on a retrospective dataset and still fail after deployment because prevalence, equipment, workflow, patient mix, or human response is different.
03
Test the intended population and use conditions
Analyze relevant subgroups, and specify what the product does when inputs fall outside the supported range.
04
Plan changes with a PCCP
The FDA issued final PCCP guidance for AI-enabled device software functions in August 2025. A predetermined change control plan can describe planned modifications, the methods used to develop, validate, and implement them, and an impact assessment. It is not blanket permission to change a model without control.
05
Label draft guidance as draft
Broader FDA lifecycle guidance for AI-enabled device software functions remained draft guidance on the agency’s current digital-health list at the time of review and should be identified as draft when cited.
06
Review the EU AI Act overlap per product
For EU products, the AI Act and medical-device obligations may overlap depending on the system and conformity-assessment context. That intersection is still developing, so it warrants a product-specific review.
07
Preserve lineage and a working rollback path
Regardless of market, engineering should preserve data lineage, dataset versions, code and model identity, evaluation results, deployment conditions, monitoring thresholds, and a rollback path that works.
Release, maintenance, and post-market learning
Before release, the team should be able to identify what belongs to the version being shipped. After launch, collect signals that could change the benefit-risk understanding.
Area
What to review
Control
Shipped version
Which requirements, risks, components, test results, known anomalies, and configurations belong to the version being shipped
Identify them before release
Unresolved anomalies
The impact of each anomaly still open at release
Document the impact and the disposition
Release notes
Relevant changes and limitations
Communicate them in release notes; release notes don’t replace product labeling or regulated documentation
Post-market signals
Complaints, incidents, near misses, security reports, field performance, model drift, integration failures, and supplier notices
For each signal, define the question it answers, the privacy basis for collecting it, the investigation threshold, and who is accountable
Problem resolution
A support workaround may restore service while a deeper safety, security, or systemic issue remains open
Separate symptom containment from root-cause correction
Follow-up actions
Corrective and preventive action, design change, field action, reporting, and communication
Keep them connected rather than running them as unrelated queues
What clients say about Intelisoft
Frequently asked questions
No. A healthcare context alone doesn’t make software a medical device. Intended purpose, functionality, claims, users, and influence on diagnosis, treatment, monitoring, or another medical action determine whether a device framework may apply. Administrative and general-wellness functions often sit outside the definition, although privacy, security, consumer, and other obligations can still apply.
Classification work should begin during discovery, before architecture and commercial claims become expensive to change. The team needs a preliminary view of intended use, target users, medical purpose, markets, and risk. That view can be refined, but waiting until validation may expose missing controls, unsuitable evidence, or claims the product was never designed to support.
Device classification belongs to a market’s regulatory framework and helps determine the route and applicable controls. IEC 62304 software safety classification concerns the possible effects of software failure and the lifecycle rigor that follows. They support different decisions and aren’t substitutes for each other.
There isn’t one universal list for every product and market. IEC 62304, ISO 14971, ISO 13485, and IEC 62366-1 are common references, but applicability, recognized editions, national adoptions, and expected evidence vary. Build the standards matrix around intended use, classification, target markets, and the selected conformity or submission route.
Yes. IEC 62304 defines lifecycle processes and expected activities; it doesn’t require a single-pass waterfall project. Agile teams still need controlled requirements, risk links, architecture, reviews, configuration, verification, anomaly management, and release evidence. Frequent increments help when changes stay traceable and approved baselines remain clear.
No. An SBOM identifies components and supports monitoring, but the team still has to assess failure impact, known defects, vulnerabilities, licenses, architectural controls, verification, updates, and end-of-life risk. The same component may be reasonable in an administrative module and unsuitable in a safety-critical path.
Feature count and code size aren’t good proxies. Testing scope follows intended use, architecture, hazards, security exposure, software safety classification, interfaces, and market expectations. The test set should cover requirements, risk-control effectiveness, failure behavior, usability of critical tasks, interoperability, recovery, and regression with reproducible evidence.
The core lifecycle remains, but AI adds controls for data provenance, reference standards, population and subgroup performance, model identity, uncertainty, human factors, drift, monitoring, and managed modification. A model update is a product change, so it needs impact analysis, verification, validation, and a market-appropriate regulatory assessment.
Bring the best available intended-use statement, target markets, users, workflow, clinical rationale, product claims, data sources, integration constraints, known hazards, and regulatory assumptions. The team doesn’t need every answer on day one, but uncertainty should be explicit. That lets the engineering partner expose technical choices and evidence needs without quietly making regulatory judgments for the founder.
How Intelisoft can help
Intelisoft supports the engineering scope of medical device software development, from product discovery and requirements engineering to architecture, implementation, interoperability, cybersecurity engineering, test automation, verification, traceability, release infrastructure, and post-market technical operations.
For an early product, the team can turn intended-use and workflow inputs from the client’s clinical and regulatory leaders into an implementable system model and evidence plan. For an existing product, Intelisoft can assess architecture, requirements, code, dependencies, tests, build controls, and operational gaps, then prioritize remediation according to product risk.
The team can also collaborate with the manufacturer’s regulatory consultants, quality group, clinical experts, and test laboratories. The boundary is deliberate: Intelisoft builds software and technical evidence; the manufacturer and its qualified advisers own classification, submission strategy, regulatory representations, and market authorization.
Sources
- FDA, Software as a Medical Device (SaMD)
- European Commission, MDCG 2019-11 rev.1
- MHRA, Software and AI as a medical device
- IEC 62304:2006+AMD1:2015
- ISO 14971:2019
- ISO 13485:2016
- FDA, Quality Management System Regulation
- IEC 62366-1:2015+A1:2020
- FDA, Cybersecurity in Medical Devices (premarket guidance)
- FDA, Content of Premarket Submissions for Device Software Functions
- FDA, PCCP guidance for AI-enabled device software functions
Standards and regulator sources as cited in the article. This guide is not legal or regulatory advice.
