Medical Technology App DevelopmentPatient Monitoring, Clinical Decision Support & Digital Therapeutics

Medical technology app development in 2026 is not a mobile-app problem with a healthcare theme — it's a regulated-product discipline that happens to be delivered as software. The same engineering skills that ship a consumer app get you a working prototype quickly, but shipping a product that touches diagnosis, treatment, or patient-specific clinical decisions means engineering inside a framework of FDA risk classification, clinical evidence requirements, and federal privacy law from the very first architecture decision, not as a late-stage compliance pass.

The category has grown fast on both the regulatory and commercial sides. The FDA's Digital Health Center of Excellence has authorized roughly 1,450 AI-enabled medical devices for marketing as of mid-2026, and 2025 alone saw a record 295 new AI-enabled device clearances, evidence of just how much clinical software is now built on machine learning models rather than static rule sets. On the commercial side, multiple independent market research firms — including Fortune Business Insights and Coherent Market Insights — put the digital therapeutics market above $10 billion in 2025 with double-digit annual growth, while remote patient monitoring is one of the fastest-growing segments in healthcare IT, with the U.S. market alone projected by MarketsandMarkets to reach roughly $29 billion by 2030.

Three product categories drive most of that growth, and this guide treats each one separately because each carries a different regulatory bar, a different reimbursement model, and a different technical architecture: remote patient monitoring platforms that stream vitals data from connected devices to clinicians, clinical decision support systems that surface recommendations at the point of care, and digital therapeutics that deliver an evidence-based treatment directly through software. Building any of the three well starts with getting the regulatory classification right — which is the subject of the next section.

The single most expensive mistake in medical technology development isn't a bad architecture decision — it's building the entire product before determining which FDA device class it falls into.

Software as a Medical Device (SaMD) is the internationally adopted term — defined by the International Medical Device Regulators Forum (IMDRF) and used by the FDA's Digital Health Center of Excellence — for software intended for one or more medical purposes that performs that purpose without being part of a hardware medical device. It's distinct from software embedded inside a physical device (an infusion pump's firmware, for example), and it's distinct from unregulated general wellness software that supports a healthy lifestyle without claiming to diagnose or treat a specific condition. Getting this classification right early determines almost every downstream decision: team composition, timeline, cost, and even which cloud infrastructure choices are defensible.

The FDA sorts devices, including SaMD, into three risk-based classes, each tied to a specific regulatory pathway. Most consumer-facing remote patient monitoring tools and clinical decision support products that require clearance fall into Class II, the largest and most common category for digital health software.

A 510(k) clearance means the FDA agreed the device is "substantially equivalent" to an already-marketed predicate — it's a clearance, not a formal approval, and it's the fastest common pathway when a comparable predicate exists. When no predicate exists for a genuinely novel, moderate-risk device, the De Novo pathway creates a new classification, as happened with EndeavorRx, the FDA-authorized video-game-based digital therapeutic for pediatric ADHD, which received De Novo authorization in June 2020 based on five clinical studies covering more than 600 children. Timelines matter for planning: FDA's own performance goal for 510(k) review is 90 days, but actual 2025 review times averaged roughly 150 days, and the FDA's Breakthrough Devices Program — which had granted 1,246 designations and authorized 185 devices for commercialization as of the end of 2025 — offers an accelerated, more collaborative review track for devices treating life-threatening or irreversibly debilitating conditions.

Remote patient monitoring (RPM) platforms stream physiological data — heart rate, blood pressure, glucose, weight, oxygen saturation — from connected devices to a clinical dashboard, closing the gap between periodic in-office visits and a patient's actual day-to-day condition. The category has grown into one of the largest segments of digital health, and reimbursement is a real driver of that growth: CMS pays for RPM services under a defined set of CPT codes — 99453 for initial device setup and patient education, 99454 for the device supply and data-collection period, and 99457/99458 for the clinical staff time spent reviewing data and interacting with the patient — which gives providers a direct financial incentive to adopt RPM programs rather than treating them as an unreimbursed add-on.

Regulatory classification for RPM varies by what the software actually does with the data. A platform that simply displays and transmits vitals for informational review generally carries a lighter regulatory burden, while a platform whose algorithm performs signal processing to actively detect a medical condition — flagging atrial fibrillation from a wearable ECG waveform, for instance — is functioning as a diagnostic aid and typically requires Class II 510(k) clearance. Either way, an RPM platform destined for real clinical use needs to speak the hospital's language: pushing normalized vitals data into the patient's electronic health record via HL7 FHIR APIs, rather than living as an isolated silo the care team has to check separately, is what determines whether a platform actually gets adopted into daily clinical workflow.

A clinical decision support (CDS) system analyzes patient data — labs, vitals, medication lists, history — and surfaces a recommendation, alert, or reference at the point of care. The evidence for what good CDS can do is strong: a meta-analysis spanning 87 studies across multiple medical specialties found CDSS implementation was associated with an overall 53% reduction in medication errors, with the strongest effect in geriatrics, a population especially vulnerable to polypharmacy and dosing mistakes.

Whether a given CDS tool needs FDA clearance hinges on a distinction the FDA laid out in its Clinical Decision Support Software guidance, most recently reissued in January 2026: software that lets a clinician independently review the underlying basis for a recommendation — the specific data points and logic behind it — rather than relying on the output as the sole basis for a decision, can often qualify for a non-device CDS exemption carved out under the 21st Century Cures Act. Software that generates a specific, patient-level diagnostic or treatment recommendation the clinician can't independently evaluate — increasingly common with AI/ML-based models whose reasoning isn't fully transparent — is far more likely to be regulated as SaMD. This is precisely why AI-driven CDS is such an active area of FDA policy right now: the agency's evolving Predetermined Change Control Plan (PCCP) framework lets a company pre-specify how a model is allowed to update after clearance, avoiding a brand-new submission for every retraining cycle while still keeping FDA oversight over what the model is allowed to change.

The technical challenge that determines whether a CDS system actually gets used, regardless of its regulatory status, is alert fatigue. A rules engine or model that fires too many low-value alerts trains clinicians to dismiss warnings reflexively, which erodes the very safety benefit the system exists to provide. Effective CDS design tunes alert specificity aggressively, surfaces only actionable and clinically significant flags, and integrates directly into the clinician's existing EHR workflow — usually via a FHIR-based CDS Hooks integration — rather than requiring a separate login or a second screen to check.

A digital therapeutic (DTx) delivers an evidence-based therapeutic intervention directly to a patient through software, to prevent, manage, or treat a medical condition — not just support general wellness. Prescription digital therapeutics (PDTs) sit at the most rigorous end of the category: they're FDA-authorized, prescribed by a clinician the same way a medication would be, and typically require the kind of clinical evidence — often randomized controlled trials — that pharmaceutical products need. EndeavorRx remains the clearest real-world example: authorized via the De Novo pathway in 2020 as a videogame-based treatment to improve attention function in children with ADHD, backed by five clinical studies covering more than 600 children.

Reimbursement is where digital therapeutics most often succeed or fail commercially — and it's the sharpest lesson the industry has learned to date. CMS created a dedicated set of Remote Therapeutic Monitoring (RTM) CPT codes (98975 for setup, 98976/98977 for device supply and monitoring, and 98980/98981 for clinical time managing the data) that give some DTx products a path to reimbursement distinct from the RPM codes used for physiological vitals. But having a billing code available doesn't guarantee a payer will actually cover a product. Pear Therapeutics — an early prescription digital therapeutics company with one of the strongest clinical evidence bases in the category, including over 40 supporting studies — went public via a $1.6 billion SPAC deal in 2021 and filed for bankruptcy in April 2023, with its assets sold at auction for roughly $6 million. Industry analysis widely attributes the collapse not to a lack of clinical evidence, but to insufficient payer reimbursement uptake: Pear tried to change how payers reimbursed care at the same time it introduced a new product category, which proved to be too much disruption at once. The practical takeaway for anyone building a DTx product in 2026 is to design the reimbursement and payer strategy alongside the clinical and regulatory plan from day one, not as a problem to solve after the software is finished.

Every product discussed so far — RPM, CDS, and DTx — handles protected health information (PHI), which means HIPAA's Security Rule, Privacy Rule, and Breach Notification Rule apply regardless of whether the software itself needs FDA clearance. HIPAA compliance isn't a checklist item added before launch; the administrative, physical, and technical safeguards it requires — encryption at rest and in transit, role-based access control, audit logging of every PHI access, and a signed Business Associate Agreement (BAA) with every cloud vendor and API partner that touches patient data — are architectural decisions that are expensive and sometimes impossible to retrofit late in development.

The financial stakes for getting this wrong have risen with cost-of-living adjustments. Under the HHS Office for Civil Rights' 2025 penalty schedule, violations are graded into four tiers based on culpability.

Beyond HIPAA, interoperability is now a legal requirement, not just a technical nicety. The ONC's 21st Century Cures Act Final Rule requires certified health IT to expose patient data through standardized APIs and prohibits information blocking, with HL7 FHIR as the standard underlying that requirement. Any product that needs to exchange data with a hospital EHR — which describes nearly every serious RPM or CDS platform — needs FHIR-based integration designed in from the start, since retrofitting interoperability onto a proprietary data model is one of the most expensive rework projects in healthcare IT. For international teams, GDPR governs the handling of any EU patient data alongside HIPAA, a relevant consideration for any product with European clinical partners or patients.

Building regulated medical technology software follows a different lifecycle than a typical consumer app, structured around the quality standards FDA submissions expect: ISO 13485 for the quality management system governing the whole development process, IEC 62304 for the software development lifecycle itself, and ISO 14971 for documented risk management. In practice, that means discovery and regulatory strategy happen before a line of production code is written — determining SaMD classification, mapping the intended use statement, and choosing the pathway (510(k), De Novo, or PMA) shapes the entire engineering plan that follows.

Cost estimates for this category vary enormously because "medical app" describes wildly different scopes of work. A realistic range for a genuinely regulated product — a Class II remote patient monitoring platform or a clinician-facing decision support tool with FHIR integration, verification and validation testing, and 510(k) submission support — typically runs from roughly $400,000 to $2 million or more, driven primarily by device classification, the depth of EHR integration required, and whether clinical validation studies are needed. A prescription digital therapeutic pursuing its own randomized controlled trial sits well above that range because of clinical trial costs alone, while an unregulated general-wellness companion app with no diagnostic or treatment claims can be built for a fraction of the cost since it avoids the SaMD evidence and submission burden entirely. Timelines follow the same logic: an unregulated wellness app can ship in a few months, while a Class II product with a 510(k) submission realistically spans 12-18 months once review time and iteration on FDA feedback are factored in.

Most failed or delayed medical technology projects don't fail because of the code — they fail because of decisions made, or deferred, outside the codebase. The same handful of mistakes recur across RPM, CDS, and DTx projects alike.

• Treating regulatory strategy as a launch-week task: Determining SaMD classification after the product is built forces expensive architectural rework — encryption, audit trails, and validation documentation are far cheaper to build in than to retrofit.
• Designing for the algorithm, not the clinician's workflow: A clinically accurate CDS tool that generates too many low-value alerts trains clinicians to ignore it, erasing the safety benefit it was built to provide.
• Underinvesting in interoperability: Point-to-point custom integrations instead of HL7 FHIR APIs create a maintenance burden that compounds with every new EHR partner and often violates the ONC's information-blocking requirements.
• No reimbursement plan before development starts: As Pear Therapeutics' bankruptcy demonstrated, strong clinical evidence alone doesn't guarantee payer coverage — the reimbursement pathway needs to be mapped alongside the clinical strategy, not discovered after launch.
• Security bolted on instead of designed in: Adding encryption, RBAC, and BAAs after the data model is finalized is slower and riskier than building HIPAA safeguards into the architecture from the first sprint.
• No plan for post-market surveillance: Cleared SaMD isn't done at launch — ongoing adverse event tracking and a defined process for managing software updates (increasingly formalized via FDA's PCCP framework for AI/ML models) are expected, not optional.

Frenchy Digital builds the technology layer that medical technology products are made of — patient-facing mobile apps, clinician dashboards, and the FHIR-based data pipelines connecting them — with HIPAA-aware architecture designed in from the first sprint rather than retrofitted before launch. That engineering work is complemented by a security audit practice built for exactly the encryption, access-control, and audit-logging safeguards regulated healthcare software requires, and by startup consulting and MVP development for healthtech founders scoping their first regulated product and mapping what belongs in an initial pilot versus a full 510(k) submission.

Frenchy Digital is headquartered in Los Angeles, with international teams in Geneva, Switzerland and Paris, France — giving healthtech clients coverage across US and European working hours and familiarity with both HIPAA and GDPR considerations for products that cross those regulatory boundaries. The team works alongside your clinical and regulatory advisors throughout the FDA submission process, focused on what a development partner should own: a compliance-by-design architecture, clean FHIR interoperability, and a clinical workflow clinicians will actually use.

Ready to scope your medical technology product the right way? Schedule your free discovery call and get a clear, honest read on your SaMD classification, technical architecture, and realistic timeline before you write a single line of code.