The global digital health market reached $387.8–$427 billion in 2025 and is projected to grow to $2.19 trillion by 2034 at a 21.2% compound annual growth rate. Over 1.4 billion people used digital health tools in 2025. The FDA has cleared 295 AI/ML-based medical devices to date, with a median clearance time of 142 days — and 24% cleared in under 90 days.
Digital medicine has crossed from innovation category to clinical infrastructure. The question is no longer whether AI and connected devices will be part of healthcare — 82% of healthcare organisations have adopted telemedicine, up from 23% in 2020; telehealth now represents 23% of all healthcare encounters in the US. The question is how to build digital medicine systems that are safe, regulatorily sound, and clinically effective at the engineering level.
This is a technically honest breakdown of the current landscape and what it takes to build in it.
The Five Technology Domains of Digital Medicine
1. AI-Powered Diagnostics
AI diagnostic systems — computer vision models that interpret medical imaging, NLP models that extract findings from clinical notes, and multimodal systems that combine imaging with structured patient data — represent the highest-stakes and highest-potential category in digital medicine.
The clinical performance data is significant. AI systems for radiology and pathology imaging achieve 76–90% diagnostic accuracy, compared to physician-only performance of 73–78% in equivalent benchmark studies. Specialised systems have reached 94% accuracy for lung nodule detection, compared to 65% for radiologists working without AI assistance. In dermatology, AI classification of skin lesions has matched board-certified dermatologist performance in multiple prospective studies.
The engineering requirements for diagnostic AI:
Training data quality is the binding constraint. Diagnostic AI models are only as good as their training data — the quality of annotations (who labelled the images, what criteria were used), the diversity of the dataset (institutions, imaging equipment, patient demographics), and the volume required for the target performance level. A rule of thumb: classification models for common pathologies (diabetic retinopathy, pneumonia on chest X-ray) can be developed with 10,000–50,000 labelled examples; rare pathology detection requires substantially more and often requires multi-institution data sharing agreements.
Uncertainty quantification is not optional. A diagnostic AI that outputs a binary classification (finding present / absent) without a confidence estimate is not safe for clinical deployment. Clinicians need to know when the model is uncertain so they can apply additional scrutiny. Bayesian deep learning and Monte Carlo dropout provide calibrated uncertainty estimates; temperature scaling provides a post-hoc calibration approach for models that are not inherently calibrated.
Distribution shift monitoring is a production requirement. A model trained on CT images from three academic medical centres may perform differently on CT images from community hospitals with different scanners, protocols, and patient populations. Monitoring for distribution shift — where incoming data diverges from training data — and triggering re-evaluation when it occurs is a production MLOps requirement for diagnostic AI, not an optional enhancement.
2. Remote Patient Monitoring (RPM)
Remote patient monitoring involves collecting physiological data from patients outside clinical settings — at home, during daily life — and transmitting it to clinicians for review and action. The RPM market reached $26.2–$40 billion in 2025, growing at 11–13% annually.
The device categories:
Wearables — continuous physiological monitoring devices worn on the body. Apple Watch, Fitbit, and Garmin devices provide heart rate, SpO2, skin temperature, and ECG capabilities cleared by the FDA for specific clinical uses. Specialised medical-grade wearables (Biobeat, Withings, iRhythm Zio patch) provide continuous monitoring for specific clinical applications (hypertension management, cardiac arrhythmia detection).
Implantables — continuous monitoring devices implanted in the body. Cardiac implantable devices (ICDs, pacemakers) with remote monitoring capability transmit data to clinician portals via home base stations. Abbott, Medtronic, and Boston Scientific have large installed bases; their remote monitoring platforms transmit alert events and trend data that inform clinic visit timing and intervention decisions.
Point-of-care devices — clinical-grade measurement devices used at home by patients: smart blood pressure monitors, connected glucometers, spirometers for COPD management, and weight scales for heart failure monitoring.
The engineering architecture for RPM platforms:
Device connectivity: consumer wearables connect via Bluetooth LE to a companion app (iOS/Android) that transmits data to the cloud. Medical-grade devices may use proprietary protocols, cellular radios, or dedicated home base stations. The integration surface is device-specific; standardised device APIs do not exist at scale.
Data pipeline: device data → companion app or cellular radio → cloud ingestion (FHIR Observation resources) → alert processing → clinician-facing dashboard. The alert processing layer is the highest-stakes component: which values trigger what alerts, routed to whom, with what escalation if unacknowledged?
FHIR integration: RPM platforms that transmit data to EHR systems should write data as FHIR Observation resources — the standard structure for measurement data in FHIR R4. 71% of countries are now actively using FHIR, and 70% of US hospitals have enabled FHIR patient access. FHIR R4 is the interoperability standard; build to it from the start.
3. Telehealth and Virtual Care
82% of healthcare organisations have adopted telemedicine as of 2025. 54% of Americans had at least one telehealth visit in 2025; 1 in 6 had four or more. Telehealth now accounts for 23% of all healthcare encounters nationally and is projected to grow at 23.8% annually through 2030.
Telehealth has moved from pandemic-era stopgap to structural component of the care model. The engineering platforms that underpin it:
Video visit platforms: Zoom for Healthcare, Doxy.me, and proprietary platforms embedded in Epic, Oracle Health, and athenahealth. HIPAA compliance (BAA in place, encryption in transit, no recording without consent) is the baseline requirement. Quality of service requirements: video resolution of at least 720p at 30fps for clinical examination; adaptive bitrate for variable home internet conditions.
Asynchronous care: store-and-forward telehealth where the patient submits information (photos, questionnaire responses, device readings) and the clinician reviews and responds without a synchronous visit. Lower cost per encounter than video visits; appropriate for dermatology second opinions, medication management, and chronic condition monitoring. Requires a structured clinical review workflow and clear SLA for clinician response time.
Digital front door: the patient-facing scheduling, intake, and communication layer that routes patients to the appropriate care modality (in-person, video, asynchronous). AI-powered intake triage — collecting symptom information and suggesting appropriate care routing — is a growing application, but one that requires careful FDA consideration (is the routing recommendation a clinical decision?).
4. Digital Therapeutics (DTx)
Digital therapeutics are software-based interventions that deliver clinically validated therapeutic effects — treating, managing, or preventing medical conditions. FDA-cleared examples include:
- Somryst (Pear Therapeutics) — cognitive behavioural therapy for insomnia, delivered via app
- EndeavorRx (Akili Interactive) — attention training for paediatric ADHD, delivered as a video game
- reSET — substance use disorder treatment
The engineering distinction from wellness apps: digital therapeutics must demonstrate clinical efficacy in randomised controlled trials and obtain FDA clearance or approval as a medical device (Software as a Medical Device). The regulatory pathway is the same as a pharmaceutical — clinical evidence is required, not just safety review.
The engineering requirements for DTx: adaptive treatment algorithms that personalise the intervention based on patient engagement and progress; engagement and adherence monitoring; clinical outcome measurement that aligns with the trial endpoints used for FDA clearance; and integration with clinical workflows for the condition being treated.
5. Clinical AI and Decision Support
Beyond diagnostic imaging AI, clinical AI includes: NLP for clinical documentation (ambient documentation — AI that listens to a patient encounter and generates a structured clinical note), AI-powered prior authorisation (reducing the 40-hour weekly administrative burden on clinicians), and clinical decision support (surfacing relevant clinical guidelines, drug interaction alerts, and care gap notifications).
88% of health systems report integrating generative AI into workflows in some form. The most impactful deployment is ambient documentation — AI that reduces physician documentation time by 40–70%, the largest single driver of the physician burnout crisis. The engineering stack for ambient documentation is covered in detail in our healthcare SaaS architecture guide.
The Regulatory Framework: FDA and Beyond
Digital medicine software faces regulatory requirements that do not apply to most software categories. Understanding the framework is prerequisite to any serious product development in this space.
Software as a Medical Device (SaMD): FDA regulates software that meets the definition of a medical device — software intended to diagnose, cure, treat, prevent, or mitigate a disease or condition, or affect the structure or function of the body. The classification (Class I, II, or III) depends on the intended use and the risk level of the software’s output.
As of 2025, 295 AI/ML medical devices have been cleared by FDA, with a median clearance time of 142 days. 24% are cleared in under 90 days — typically straightforward 510(k) submissions with close predicates. Complex novel devices or Class III devices requiring PMA (Premarket Approval) have much longer timelines.
The clinical decision support carve-out: not all clinical software is regulated as SaMD. FDA’s guidance identifies four characteristics that together define regulated clinical decision support: (1) intended for use by healthcare professionals; (2) intended to acquire, process, or analyse medical images or signals; (3) displays, analyses, or prints medical information; and (4) the clinician is not expected to independently review the basis for the recommendation. Software where the clinician can review the AI’s reasoning and make an independent decision is generally not regulated as SaMD.
The AI/ML Software Action Plan: FDA’s ongoing framework for AI/ML-based SaMD addresses the unique challenge of continuously learning AI — models that update based on real-world performance after clearance. Pre-determined change control plans (PCCPs) allow manufacturers to define in advance the types of model updates that can be made without a new submission.
FHIR mandates: the 21st Century Cures Act Final Rule requires health systems and payers to enable FHIR R4 patient access APIs. 73% of countries now mandate or recommend FHIR for health data exchange. Software that integrates with health system data needs to handle FHIR R4 as its primary data exchange format.
How we approach this at Insoftex
Healthcare is one of our three core industry verticals, and the regulatory and technical architecture described in this article is the context in which we do that work. Our AI-powered healthcare platform was designed around HIPAA compliance and FHIR integration as first-class architectural constraints — not compliance layers added after the data model was set. The FHIR semantic mapping work — translating the client’s existing clinical data structures into FHIR R4 resources — was done during discovery rather than during build, because discovering a semantic mismatch mid-build requires data model changes that are significantly more expensive than the same discovery made in a scoping phase.
The FDA SaMD classification question is one we scope earliest in any digital medicine engagement that involves AI. The distinction between clinical decision support software that is outside FDA’s regulation and software that meets all four criteria for regulated SaMD is often not obvious from the product description — it depends on the intended use statement, whether the clinician can independently review the AI’s reasoning, and what specific clinical action the software output is designed to support. We run this classification assessment in the Product Pilot, before architecture decisions are made, because the classification result determines the regulatory pathway, the clinical validation requirements, and whether certain model architectures are viable at all.
The HIPAA compliance architecture for digital medicine follows the same principles as our other regulated-industry builds: full data flow mapping before vendor selection, BAA review covering every system that touches PHI (including analytics tools that capture request payloads), and audit log design built for an OCR investigation rather than for a compliance checkbox. The difference in healthcare is that audio and imaging data add categories of PHI that are often missed in initial architecture reviews — a clinical AI system that processes patient conversations or medical images requires explicit data handling design for those modalities, not just for the structured EHR data.
Building a digital medicine product — diagnostic AI, RPM platform, telehealth infrastructure, or clinical decision support? Our Product Pilot covers FDA SaMD classification, HIPAA compliance architecture, and FHIR integration in three weeks.
Frequently Asked Questions
What is the difference between a wellness app and a digital therapeutic?
A wellness app makes no clinical claims — it does not diagnose, treat, or manage a medical condition. A calorie tracker, a meditation app, a step counter: these are wellness software and are not regulated by FDA as medical devices. A digital therapeutic (DTx) is a software-based intervention that delivers clinically validated therapeutic effects for a specific medical condition — cognitive behavioural therapy for insomnia, attention training for ADHD, substance use disorder treatment. Digital therapeutics must demonstrate clinical efficacy in randomised controlled trials and obtain FDA clearance or approval as a Software as a Medical Device. The regulatory distinction is the intended use: if the software claims to treat, manage, or diagnose a condition, it is a medical device. If it only claims to support wellness or healthy habits, it is not. The practical implication for product development: if you are building an app that you want healthcare providers to prescribe or payers to reimburse for a specific condition, you are building a digital therapeutic and need an FDA regulatory strategy from day one. Building the clinical evidence and navigating FDA clearance typically takes 3–5 years and $5–$15 million in clinical trial and regulatory costs.
How does AI diagnostic software get FDA cleared?
Most AI diagnostic software seeks 510(k) clearance by demonstrating substantial equivalence to a predicate device — a device that was previously cleared for the same intended use. The submission includes: (1) intended use statement — precisely defined, because this determines both the regulatory pathway and the scope of clinical claims the cleared device can make; (2) performance testing — analytical validation (does the algorithm perform as designed?) and clinical validation (does it perform as intended in the clinical setting, measured against a reference standard?); (3) software documentation — design controls, software development lifecycle documentation, risk management (ISO 14971), and cybersecurity assessment; (4) description of the algorithm — training data, model architecture, training process, and performance metrics on test sets withheld from training. The FDA has issued guidance on predetermined change control plans (PCCPs) that allow manufacturers to update AI/ML models after clearance without a new 510(k) submission, provided the changes fall within the PCCP's defined scope. Devices with no predicate or with intended uses that pose higher risk (autonomous decision-making, life-sustaining functions) typically require De Novo classification or PMA, with much longer timelines.
What FHIR resources are most commonly used in digital medicine applications?
The core FHIR R4 resources for digital medicine are: Patient — the central demographics resource; linked to by all clinical resources. Observation — measurements and simple assertions (lab results, vital signs, device readings from RPM, survey responses). This is the highest-volume resource in most digital medicine platforms. Condition — diagnoses and health concerns. Medication/MedicationRequest — medication records and prescriptions. DiagnosticReport — the structured output of a diagnostic study, such as a radiology report or lab panel. AllergyIntolerance — allergy and intolerance records. Immunization — vaccination records. CarePlan — care plans and goal tracking. Encounter — visits and care episodes (in-person or telehealth). DocumentReference — for clinical documents such as clinical notes, discharge summaries, and consent forms. For RPM specifically: Observation with appropriate LOINC codes for the measurement type (blood pressure, SpO2, heart rate, blood glucose) and Device to represent the monitoring device. For AI diagnostic output: DiagnosticReport with DiagnosticReport.result linking to Observations representing individual findings, and DiagnosticReport.conclusionCode for coded conclusions. 70% of US hospitals now have FHIR patient access enabled; building to FHIR R4 from the start is the right long-term approach.
What is the reimbursement landscape for remote patient monitoring?
Medicare reimbursement for RPM is the most mature payer coverage available and sets the template for commercial payer policies. Current Medicare CPT codes for RPM (as of 2025): CPT 99453 (initial device setup and patient education, billed once per episode); CPT 99454 (device supply and daily transmission, billed monthly — requires at least 16 days of data per month); CPT 99457 (minimum 20 minutes monthly clinical staff time for review and management); CPT 99458 (additional 20-minute increments). Combined, these codes support approximately $120–$200 per patient per month in Medicare reimbursement for ongoing RPM programmes. The clinical requirements: the monitoring must be physician-ordered, the data must be reviewed by clinical staff, and the patient must have at least one in-person visit in the past year. Most commercial payers have adopted similar coverage, but policy details vary by payer and state. The reimbursement landscape makes RPM commercially viable for chronic conditions (hypertension, diabetes, COPD, heart failure) where ongoing monitoring has demonstrated clinical impact — these are the conditions where RPM programme development makes business sense.