How to Build an IEC 62304 Compliant Mobile App: Medical Mobile App Development Guide

Most Healthcare Apps Are One Audit Away From Being Shut Down. Here’s Why That’s a $2,351.24 Billion Problem.

Let’s be real. Most healthcare app development companies in the USA and UK will sell you “compliant” and hand you a folder full of PDFs that nobody reads again. That’s not compliance, that’s liability management dressed up as process. And if you have come across that, I am sure you will agree how fragile it feels.

The global digital health market is on track to be USD 2,351.24 billion by 2034. And yet, another study found that fewer than 20% of mhealth and chronic disease apps meet basic clinical safety benchmarks, let alone regulatory ones. With that kind of adoption gap, teams are cutting corners on what matters most: whether the app is actually safe to put in a patient’s hands.

Tech Exactly built a cross-platform IEC 62304-compliant app for an Australian biotech company, where patients use it to interpret real diagnostic results for UTI, Pregnancy, Ferritin, and Vitamin D, and decide whether to see a doctor. The stakes were not hypothetical. Here’s everything we learned.

What Is IEC 62304, and Which Medical Mobile Apps Does It Actually Apply To?

IEC 62304 is the international standard governing how medical device software must be built, documented, tested, and maintained. If your app plays any role in diagnosing, treating, or informing a medical decision (i.e, software embedded in devices, software as a medical device (SaMD), and software used in production), IEC 62304 applies to you, whether you’ve acknowledged it or not. 

Image source.

The standard classifies software into three safety classes:

Most medical mobile app development projects land in Class B. That means full documentation, formal risk management, and verified test coverage from day one, not as a pre-launch scramble.

According to the FDA’s Digital Health Center of Excellence, software-related failures are among the leading causes of medical device recalls. The FDA also reports that between 2011 and 2022, software defects contributed to over 500 medical device recalls in the US alone. IEC 62304 exists to systematically prevent exactly that.

What Most Teams Get Wrong About  IEC 62304 Compliant Healthcare App

When teams say they’re delivering healthcare mobile app development services compliant with safety standards, they usually mean they have an SDP document and are using HTTPS. That is not what the IEC 62304 compliant meaning covers.

True compliance requires:

• Software Development Plan (SDP): Maps every development activity to the corresponding IEC 62304 clause. This governs every sprint, not just the audit prep week.
• Software Requirements Specification (SRS): Every safety-relevant feature gets a unique traceable ID that runs from requirement → architecture → code → test case. No trace, no compliance.
• Risk Management under ISO 14971: Every hazard is documented with probability, severity, and mitigation. In our test kit app, “user submits blurry image and gets wrong result” was a formal risk entry, not a UX note.
• Verification and Validation: Did we build it right? Did we build the right thing? Both need documented evidence.
• Problem Resolution Process: A formal, tracked process for every bug and anomaly. Not a Slack thread.
• Post-Market Surveillance: Compliance doesn’t end at launch. Ongoing monitoring for reported problems, near-misses, and update reviews is mandatory.

Example of IEC 62304 Medical Mobile App Development: A Diagnostic Test Kit App We Built

A biotech client came to us with an at-home diagnostic product line and a serious problem:  patients were manually interpreting multi-line test strips by eye. Misinterpretation was common, and the clinical risk was real. Research published in the Journal of Medical Internet Research found that user error in self-administered diagnostic tests can reach error rates of up to 32% without guided automation. That number was driving the brief.

They needed a medical mobile app development solution that automated interpretation, connected to their existing Shopify user base, allowed in-app test kit purchases, and achieved IEC 62304 Safety Class B compliance. The four core problems we walked into:

1. Users submitting blurry or poorly lit images that produce unreliable diagnostic results
2. Manual interpretation errors on complex test strips, even attentive users got it wrong
3. A fragmented login experience between web and mobile was killing onboarding completion
4. Zero existing compliance documentation, the entire IEC 62304 lifecycle needed to be built from scratch

Here’s the tech stack we used and why every choice mattered for compliance:

Every third-party library was formally documented as SOUP (Software of Unknown Provenance), version-locked, anomaly-reviewed, and monitored for updates. This is one of the first things a competent auditor checks and one of the most commonly skipped steps in the industry.

▶️Read the case study here: IEC 62304-Compliant Mobile App for Accurate Test Interpretation

Solutions We Built for This IEC 62304 Compliant Healthcare App

1. Enhanced User Experience and Seamless Onboarding

The client had an established Shopify web user base. Asking those users to create a new account for the mobile app would have killed adoption before it started. We integrated the Shopify API and Mobile Buy SDK to allow users to authenticate with their existing web credentials across both platforms – one identity, one login, no confusion.

We also added Google and Apple social login for new users, reducing registration friction and improving onboarding completion rates. The result was a unified user experience from first install to first test result. Meaning no duplicate accounts, no lost purchase history, no support tickets asking “why can’t I log in?”

2. Automated Test Result Interpretation With OpenCV

The core clinical problem was this: patients were guessing at their own diagnostic results. We integrated OpenCV, an industry-standard computer vision library to automate the interpretation of test strips entirely. The system detects specific markers on the strip and returns a clear, accurate diagnostic result for UTI, Pregnancy, Ferritin, and Vitamin D tests.

This eliminated the human interpretation step that was generating errors. Automated analysis also created a consistent, auditable output. Every result produced by the algorithm is generated the same way, every time, which is exactly what a Class B safety requirement for diagnostic accuracy demands.

3. Improved Image Capture Workflow With Real-Time Quality Feedback

Automated analysis only works if the input image is good enough to analyze. So we engineered the image capture workflow itself as a safety feature.

The app provides real-time feedback during capture: if an image is too dark, too blurry, or the test strip isn’t properly centered, the system rejects it before analysis runs and tells the user exactly what to fix. The app also includes in-app tutorials on how to capture a usable image. Minimum image quality thresholds were defined as documented SRS safety requirements with linked verification test cases- if your team can’t point to a requirement ID for image quality, you have a compliance gap.

💡Pro Tip: Build image quality rejection as a safety requirement, not a feature flag. The risk entry is: poor image → wrong result → wrong health decision. That chain needs to be broken at the input stage, and the break needs to be documented and tested.

4. eCommerce Integration With Shopify for In-App Test Kit Purchases

The client wanted users to be able to buy test kits without leaving the app, a seamless journey from purchase to use to result interpretation, all in one place. We integrated the Shopify eCommerce API to power a full in-app storefront with browse, cart, and secure checkout functionality.

Shopify’s payment gateway handles transactions, which keeps payment processing out of our compliance scope while giving users a purchase experience they already trusted from the web. The integration also meant order history and product catalog stayed in sync across web and mobile automatically with no duplicate inventory management or fulfillment confusion.

5. Full IEC 62304 Safety Class B Compliance Documentation and Lifecycle Management

This was the most structurally demanding deliverable of the project, and the one most agencies would have underscoped. Here’s exactly what we produced and maintained:

• Software Development Plan written before any production code, mapping every activity to the corresponding IEC 62304 clause
• Software Requirements Specification with unique traceable IDs for every safety-relevant feature
• Software Architecture Document decomposing the system into discrete units: image capture module, analysis engine, result display, eCommerce module, and authentication module. Each documented individually
• ISO 14971 Risk Register maintained as a live document throughout development, updated with every new feature
• Usability engineering under IEC 62366 where real users tested the app under real conditions to validate safe operation before launch
• Post-market surveillance procedures established pre-launch, including a named process owner, problem classification criteria, and an escalation path for safety-relevant defects

The outcome: IEC 62304 Safety Class B compliance achieved. The app met regulatory requirements, passed review, and is in active clinical use today.

What Healthcare Management Administrators Must Own in the IEC 62304 Process

If you’re a healthcare management administrator overseeing procurement or deployment of digital health tools, compliance can’t be fully delegated. And the cost of getting it wrong is not abstract. Between 2007 and 2018, Quantros, a private healthcare analytics firm, logged 18,000 EHR-related patient safety events, of which 3% resulted in direct patient harm, including seven deaths. 

Beyond patient safety, more than half of EHR systems either fail or fail to be properly utilized after deployment, and the root cause is almost always the same: clinical and governance requirements weren’t defined clearly before the build started. That’s not a developer failure. That’s a procurement and oversight failure, and it sits squarely with the people commissioning the software.

Here’s what sits on your side of the table:

• Clinical requirements in writing: your team defines what “accurate” means clinically; the dev team builds to that definition
• A formal Intended Use Statement: apps compliant with medication management or diagnostics need this before development begins; without it, regulators have nothing to evaluate against
• A named post-market surveillance owner: someone inside your organization receives reports, classifies severity, and triggers updates when safety-relevant problems are logged

How to Choose a Healthcare App Development Company in USA or UK That Actually Knows IEC 62304

When evaluating a healthcare app development company in USA or a healthcare app development company in UK, ask these questions specifically:

• Can you share a sample Software Development Plan from a past IEC 62304 project?
• How do you handle SOUP? What’s your documentation process for third-party libraries?
• Have you shipped a Safety Class B or C product with full compliance documentation?
• How do you integrate ISO 14971 risk management into an Agile sprint cycle?

A team that has done this answers with specifics and examples. 

Tech Exactly, a healthcare app development company, has delivered IEC 62304 Safety Class B medical mobile app development end-to-end: full documentation suites, ISO 14971 risk management in Agile sprints, SOUP management across complex stacks, and cross-platform apps that meet regulatory requirements without becoming unmaintainable.

If you’re building a diagnostic tool, a medication management platform, a telemedicine app or want to know how to build a IEC 62304 mobile app, talk to Tech Exactly about what a compliant build actually looks like for your specific use case.