When does software become a medical device?

Not every healthcare application is a medical device. But understanding where the line is can completely change how you build and validate your software.

Photo by National Cancer Institute on Unsplash

You build a web application.

It connects to a hospital’s systems.

It displays patient information.

It stores medical records.

Everything seems straightforward.

Then you add a new feature.

The software analyzes a CT scan and tells a doctor that a patient might have a tumor.

Technically, it’s still software.

But from a regulatory perspective, something may have changed.

This is where things get interesting.

Because not every piece of healthcare software is considered a medical device.

But some software can become one.

And understanding where that line is matters a lot if you’re a developer building applications for healthcare.

Healthcare software is not automatically a medical device

Let’s start with a common misconception.

If your application is used in a hospital, does that automatically make it a medical device?

No.

A hospital might use software for:

• Scheduling appointments
• Managing employees
• Billing
• Managing inventory
• Sending emails
• Managing administrative tasks

These applications are used in healthcare.

But they don’t necessarily perform a medical function.

Now imagine a different application.

It analyzes a patient’s CT scan.

It detects suspicious lesions.

It calculates a risk score.

It recommends a diagnosis.

The situation is very different.

The intended purpose of the software becomes extremely important.

The question is: what is the software supposed to do?

This is one of the most important questions.

Not:

“Is it an app?”

Not:

“Is it running in the cloud?”

Not even:

“Does it use AI?”

The question is:

What is the intended purpose of the software?

Imagine two applications.

The first one:

Medical Imaging Viewer
Purpose:
Display DICOM images

The second:

Medical Imaging AI
Purpose:
Analyze CT images
Detect suspicious lesions
Support diagnosis

Both applications work with medical images.

But their intended purposes are very different.

This distinction can have significant regulatory consequences.

Software as a Medical Device

You may have heard the term:

SaMD

It stands for:

Software as a Medical Device.

The basic idea is that software can have a medical purpose even when it isn’t physically part of a traditional medical device.

For example, imagine software that:

• Analyzes medical images
• Detects abnormalities
• Helps diagnose diseases
• Monitors patients
• Provides clinical recommendations

The software itself may be performing a medical function.

It doesn’t need to be connected to a physical machine to be important.

The software is the product.

What about a DICOM viewer?

This is where things can get interesting.

A DICOM viewer displays medical images.

For example:

CT Scanner
     |
     ↓
DICOM
     |
     ↓
PACS
     |
     ↓
DICOM Viewer
     |
     ↓
Doctor

The viewer helps the doctor visualize the images.

But what exactly does it do?

Does it simply display the image?

Or does it perform advanced analysis?

For example:

• Automatic segmentation
• Tumor detection
• Quantitative measurements
• Diagnostic recommendations
• AI-based classification

The more the software moves from displaying information toward analyzing or influencing medical decisions, the more important the regulatory considerations become.

This is one reason medical imaging software can be a fascinating area for developers.

The technology and the clinical context are closely connected.

What happens when you add AI?

This is where things become even more interesting.

Imagine you have a DICOM viewer.

It displays CT scans.

Everything is straightforward.

Then you add an AI feature:

Upload CT Scan
      |
      ↓
AI Model
      |
      ↓
Possible Pulmonary Nodule
      |
      ↓
Displayed to Radiologist

The application is no longer simply displaying images.

It is generating information that could influence a clinical decision.

The question becomes:

What is the software actually intended to do?

Is it:

“A research tool that helps developers experiment with image analysis?”

Or:

“A clinical tool designed to help radiologists detect abnormalities?”

Those are very different use cases.

Intended use matters

Imagine two products using the same AI model.

Product A says:

“This tool is for research purposes only.”

Product B says:

“This tool assists radiologists in detecting pulmonary nodules.”

The underlying technology might be identical.

But the intended use is different.

This is why developers working in healthcare need to understand that technical functionality isn’t the entire story.

How you describe the product.

How you market it.

How users are expected to use it.

And what decisions it is intended to support can all matter.

A healthcare application can evolve

This is something developers should think about early.

Imagine you build an application.

Version 1:

Store patient information

Version 2:

Display medical images

Version 3:

Calculate measurements

Version 4:

Analyze images

Version 5:

Suggest a diagnosis

Technically, you might still have the same application.

But the purpose and risk profile can change significantly as new capabilities are added.

Get Najm F.’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This is why regulatory considerations shouldn’t always be treated as something to think about at the very end.

If you know from the beginning that your software will eventually support clinical decision-making, your architecture and development process may need to account for that.

Developers usually think about features

When building software, developers often think in terms of:

• Features
• APIs
• Databases
• Microservices
• Cloud infrastructure
• Performance

These are all important.

But healthcare software introduces another dimension:

Risk.

What happens if the software makes a mistake?

What happens if the system displays the wrong information?

What happens if an AI model misses an abnormality?

What happens if the wrong patient is selected?

In a normal application, a bug might be frustrating.

In healthcare, the consequences can be much more serious.

Verification and validation

This is where software development in healthcare can become different from traditional web development.

You don’t just want to know:

“Does the software work?”

You may also need to know:

“Does the software work as intended?”

And:

“Does it perform reliably in the context where it will be used?”

Imagine an AI model designed to detect lung nodules.

It works perfectly on your development dataset.

Great.

But what happens when:

• The scanner model changes?
• The image quality changes?
• The patient population changes?
• The hospital uses a different imaging protocol?

A model that performs well in development may not perform identically everywhere.

This is why validation matters.

The software development lifecycle can change

In a typical web application, the process might look like:

Idea
 ↓
Development
 ↓
Testing
 ↓
Deployment
 ↓
Updates

For software with a medical purpose, the process may need much more structure.

You may need to consider:

Requirements
     ↓
Risk Analysis
     ↓
Design
     ↓
Implementation
     ↓
Verification
     ↓
Validation
     ↓
Documentation
     ↓
Release
     ↓
Post-market monitoring

The exact process depends on the product and applicable regulations.

But the general principle is important:

The development process itself becomes part of the product’s safety story.

What about Europe?

If you’re developing healthcare software in Europe, you’ve probably heard about:

CE marking

and the

Medical Device Regulation (MDR).

The regulatory landscape can be complex, and the classification of software depends on factors such as its intended purpose and risk.

This means that a developer working on healthcare software shouldn’t assume:

“It’s just an application.”

The regulatory status needs to be assessed based on what the software actually does and how it is intended to be used.

This is especially important for software involved in:

• Diagnosis
• Monitoring
• Prediction
• Prevention
• Treatment decisions

The details can be complex, which is why organizations often involve regulatory and quality specialists early in the process.

And what about the United States?

The same general idea exists in the United States.

The FDA regulates certain medical devices and medical device software.

Again, the important point is not simply whether the software runs on a computer.

The intended use and functionality matter.

A piece of software that helps manage hospital appointments is very different from software that analyzes an MRI and provides diagnostic information.

For developers building products internationally, understanding these differences early can save a lot of time later.

Why developers should care

You might be thinking:

“I’m a developer. Isn’t this something for the legal or regulatory team?”

Yes, regulatory specialists are extremely important.

But developers are also part of the process.

The architecture you choose affects:

• Data integrity
• Traceability
• Security
• Version control
• Reproducibility
• Testing
• Monitoring

Imagine an AI model that changes every week.

Can you determine which model generated a specific result six months ago?

Imagine a clinical algorithm is updated.

Can you reproduce the previous behavior?

Imagine a doctor receives an AI-generated result.

Can you explain how it was produced?

These questions aren’t just technical questions.

They can become important questions about safety and accountability.

A small example

Imagine a medical imaging platform.

A radiologist uploads a CT scan.

The system runs an AI model.

The model returns:

Possible pulmonary nodule detected
Confidence: 87%

The result is displayed in the viewer.

Now imagine someone asks:

“Why did the system produce this result?”

You might need to know:

Patient:
12345
Study:
CT Chest
Model:
Version 3.2.1
Model deployed:
2026-05-12
Input:
DICOM Study
Output:
Possible nodule
Timestamp:
2026-07-20 14:32

Suddenly, concepts like versioning, logging, traceability, and reproducibility become very important.

This is where software engineering and medical device development start to overlap.

The biggest mistake

I think one of the biggest mistakes a software team can make is waiting too long to ask:

“Are we building a medical device?”

By the time the question is asked, the product may already be in development.

The architecture is already built.

The AI model is already trained.

The database is already designed.

The development process is already established.

Changing everything at that point can be expensive.

It’s much better to ask the question early.

Before writing thousands of lines of code.

Final thoughts

Healthcare software is a fascinating space because it sits at the intersection of technology and real-world consequences.

A scheduling application is software.

A hospital management system is software.

A DICOM viewer is software.

An AI system that analyzes medical images is also software.

But they don’t all have the same purpose.

And they don’t all carry the same risks.

The moment software starts playing a role in diagnosis, monitoring, prediction, or treatment, the questions become much bigger than:

“Does the application work?”

You also have to ask:

“Is it safe?”

“Can we validate it?”

“Can we trace its behavior?”

“Can we prove that it performs as intended?”

That’s the point where software engineering starts meeting medical device development.

And for developers entering healthcare, understanding where that line sits can be just as important as understanding the technology itself.

In the next article, we’ll look at one of the most interesting areas where healthcare software, medical imaging, and AI meet: what actually happens before an AI system can analyze a CT scan?