Medical Devices & Surgical Tech Archives - OZOP Surgical

Healthcare Quality Measurement in 2026: The Complete Guide for Medtech and Health IT Companies

Ozopsurgical — Sat, 04 Apr 2026 11:14:56 +0000

Digital Health · Regulatory & Market Access

Healthcare Quality Measurement in 2026: The Complete Guide for Medtech and Health IT Companies

How quality metrics translate into reimbursement, which measure sets matter, and why health technology companies that ignore the mechanics of quality measurement are leaving money — and clinical credibility — on the table.

OZOP Surgical Editorial · April 2026 · 20 min read

45%

National Spend Driven by Federal/State Programmes

$750B

Potential Annual Savings from Quality Improvement

Max Penalty for Lowest-Performing Providers

38%

Americans Covered by Federal Programmes

Why Quality Measurement Should Be on Every Medtech Company’s Radar

Quality metrics are not an abstraction reserved for hospital administrators and insurance executives. They are the financial architecture that determines how healthcare providers get paid, how health plans retain revenue, and — critically for the medtech and health IT industry — how your customers justify the purchase of your product. If your technology improves clinical outcomes but those improvements do not register in the specific quality measures embedded in your customers’ reimbursement contracts, you have a value proposition problem that no sales deck can solve.

The US healthcare system has historically delivered worse outcomes than peer nations despite higher spending. The gap between what the system spends and what it achieves in patient outcomes represents an estimated $750 billion in annual waste — and quality measurement programmes are the primary mechanism through which payers, regulators, and providers are attempting to close it. Federal and state programmes now drive approximately 45 percent of national healthcare expenditure, and the quality measurement frameworks they use cascade into commercial insurance contracts, provider negotiations, and health plan accreditation requirements.

Quality measurement is not an afterthought for health technology companies — it is the mechanism through which clinical value is converted into financial value for your customers.

For health technology companies — whether you build surgical robotics platforms, AI-powered diagnostic tools, clinical decision support systems, or EHR modules — understanding how quality metrics work is essential to positioning your product effectively, pricing it credibly, and demonstrating ROI in the language your buyers actually use. This guide covers the full landscape: who develops the measures, how they are structured, how they translate into payment, and where the opportunities are for medtech and health IT companies to build quality measurement into their products from day one.

Two Ways Health Technology Affects Quality Performance

Health technology products improve quality measure performance through two distinct pathways, and understanding which pathway your product addresses is fundamental to how you position it commercially.

Pathway 1

Changing Clinical Care

The product facilitates changes in how clinical care is delivered — directly affecting the measured processes or outcomes. An AI diagnostic tool that identifies at-risk patients earlier, a surgical navigation system that reduces complication rates, or a clinical decision support module that increases guideline-concordant treatment.

Pathway 2

Improving Documentation

The product improves the capture and coding of data elements required by the measure specification. An EHR module that ensures correct coding of clinical encounters, a data integration layer that surfaces demographic information required for population stratification, or automated reporting tools that reduce documentation gaps.

Both pathways create genuine financial value for customers. Improved performance on quality measures — whether through better care delivery or more accurate capture of care that is already being delivered — translates into quality incentive payments, higher ratings in performance systems that feed into reimbursement, and stronger positioning for future contracts. For many widely-used quality measures, these financial benefits accrue even when the product improves measured processes rather than ultimate health outcomes. That is not a loophole — it is how the system is designed.

The Precision Problem: Why Broad Clinical Improvement Does Not Always Move the Measure

This is where most health technology companies make their first — and most expensive — strategic error. A product may deliver genuine clinical improvement across a broad patient population, but if that improvement does not cross the specific thresholds defined in the relevant quality measure specification, it will not register as improved performance in the customer’s reimbursement programme.

Consider a concrete example. A health technology company develops a chronic disease management platform and can demonstrate that 20 percent of patients respond to its intervention, achieving a measurable clinical improvement. Impressive on its face. However, the relevant quality measure only counts patients who cross a specific clinical threshold — for instance, moving from above a particular biomarker level to below it. Patients who start well above the threshold and improve but remain above it are not counted. Patients who start below the threshold and improve further are also not counted. Only the patients in the narrow band around the threshold — who improve enough to cross it — register as improved performance.

Example: How Measure Thresholds Filter Clinical Improvement

Hypothetical: 1,000 patients. Product affects 20% (200 patients). Measure only reimburses for patients crossing a specific clinical threshold.

400

Far above threshold

Improve but still above → Not counted

200

Near threshold

20% respond = 40 cross → 40 counted

400

Already below threshold

Improve further → Not counted

Product improves health for 200 patients

→

Measure recognises improvement for 40 patients

The implication is clear: health technology companies that want to make a credible quality measurement argument need to understand the exact specification of the measures their customers use — including the numerator and denominator definitions, the threshold values, the eligible population criteria, and the exclusion rules. Broad statements about clinical improvement are insufficient. The value proposition must be articulated in the precise terms of the measure specification.

The Landscape: Who Develops the Measures, and Which Ones Matter

The quality measurement ecosystem involves multiple overlapping entities that develop, maintain, and implement measure sets. Most health technology companies only need to understand a handful of specific measures — but they need to understand those measures deeply. The key players operate in a layered system where federal agencies fund and mandate measurement, independent organisations develop and maintain the specifications, and payers and providers implement them in contracts and workflows.

🏛️

Federal Healthcare Agency (CMS)

The dominant funder of measure development and the largest single user of quality measures. Directly covers 38 percent of Americans through federal insurance programmes and regulates coverage for an additional 4 percent through insurance exchanges. Contracts with independent organisations to oversee measure development and maintenance.

🔬

Consensus-Based Entity (CBE)

The federally designated body that assesses quality measures and oversees the process of maintaining key measure sets used in fee-for-service programmes. Reviews measures for validity, reliability, and feasibility. Assigns identification numbers that are referenced across payment programmes.

📊

Quality Assurance Bodies (e.g., HEDIS Maintainers)

Private organisations that develop and maintain widely-used clinical quality measure sets. These measures are embedded in federal, state, and commercial contracts. The transition toward digital quality measures — relying on standardised coding systems beyond traditional claims data — is being driven by these organisations.

Major Quality Measure Sets and Where They Appear

Measure Set	Used In	Maintained By
HEDIS	Federal, state, and commercial payment programmes	Private quality assurance body (annual review)
Core Sets (Adult, Child, Behavioural Health)	State-level reporting for public insurance programmes	Federal agency via expert workgroup
Star Ratings	Managed federal insurance plan performance assessment	Consensus body advisory process; federal rulemaking
Fee-for-Service Measure Sets	Various federal payment programmes (hospital, physician, specialty)	Consensus body; annual federal rulemaking
Exchange Quality Rating System	Qualified health plans on insurance exchanges	Federal agency via rulemaking
Universal Foundation	Reference tool for convergence across measure sets	Federal agency (no defined update schedule)

Measure sets overlap significantly in topic areas — preventive care, chronic disease management (diabetes, hypertension), and behavioural health are common across all major sets.

Anatomy of a Quality Metric: Numerators, Denominators, and Why the Details Are Everything

Every quality measure is a precisely defined specification describing who is being measured (the denominator), what counts as successful performance (the numerator), over what time period, and with what exclusions. These specifications are developed through resource-intensive processes designed to ensure the measure is valid, reliable, feasible, and comparable across different entities and time periods. Understanding the structure of these specifications is not optional for health technology companies — it is the difference between a credible quality claim and a misleading one.

Component	Definition	Why It Matters for Health Tech
Denominator	The eligible population where the process or outcome could occur	Defines who your product needs to reach. If your user base does not overlap with the denominator population, the measure is irrelevant to your value proposition.
Numerator	The subset of the denominator for whom the desired process or outcome occurred	Defines what success looks like. Your product must demonstrably move patients into the numerator to claim quality improvement.
Exclusions	Patients removed from the denominator due to clinical circumstances (e.g., hospice, death)	Reduces the measurable population. If your product disproportionately serves excluded populations, the measurable impact shrinks.
Measurement Period	The calendar period during which performance is assessed (typically one year)	Timing matters. Providers are most focused on closing performance gaps in Q3 and Q4 of the measurement year — a sales cycle insight.
Data Source	Claims, encounter data, EHR data, surveys, or digital sources	Determines how your product’s impact will be captured. The industry is transitioning toward digital quality measures using standardised coding (LOINC, SNOMED) beyond traditional claims-based measurement.

The shift toward digital quality measures is particularly significant for health technology companies. Historically, quality measurement relied on claims and encounter data — billing records that capture what was done and coded, not necessarily what was clinically relevant. Digital measures draw on EHR data, using standardised terminology systems, which opens the door for technology companies whose products capture structured clinical data to contribute directly to quality measurement infrastructure. Companies that design their data capture to align with the coding systems used in quality specifications — matching the specific fields, value sets, and definitions — add measurable value to their customers’ quality reporting workflows.

How Quality Measures Translate Into Actual Reimbursement

Quality measures become financially consequential through value-based payment programmes — structured arrangements where providers or payers receive financial rewards for high performance and face penalties for low performance. The design of these programmes is complex, and the financial impact of any single measure depends on three critical variables: the total weight assigned to quality within the programme, the number of measures sharing that weight, and the mechanism by which performance translates into payment (direct performance payment versus quality gates that unlock access to other savings).

Programme	Population	Measures	Financial Mechanism
Merit-Based Incentive	Fee-for-service patients served by eligible physicians	~200 (select 6+)	Quality = 30% of final score → payment adjustment; budget-neutral (penalties fund bonuses)
Advanced Alternative Models	Patients in accountable care organisations	6–12	Quality = 50% of final score; not budget-neutral → higher potential upside for strong performers
Managed Plan Star Ratings	Beneficiaries in managed insurance plans	30 (Part C) + 12 (Part D)	4–5 star rating → 5% benchmark increase + higher rebate retention; avg. rebate value >$2,300/enrollee
Hospital Inpatient Quality	Fee-for-service hospital patients	19 + eCQMs	Pay-for-reporting + value-based purchasing; up to 2% payment adjustment
Renal Disease Quality	Dialysis facility patients	18	Up to 2% payment reduction based on performance
State Managed Care	State-insured beneficiaries in managed care	Varies by state	Withheld payments returned based on quality; plan-level public reporting planned by 2028

The lowest-performing participants face penalties as high as 9 percent of their covered service payments. That makes quality improvement not a luxury but a risk management imperative — and a compelling sales argument for technology that demonstrably moves the needle.

A critical nuance for health technology companies: the entity participating in the payment programme may not be the entity that directly uses your product. Health plans frequently delegate quality performance requirements to providers through their contracts. To identify your actual buyers, you need to understand both which entities are accountable for performance and which entities have the operational ability to affect it. A product that helps a specialist practice improve documentation of a specific procedure may ultimately generate financial value for the managed care plan that contracts with that practice — but the purchase decision may sit with the practice, the plan, or a health system that employs the specialist.

The Annual Cycle: When Measures Change and When Customers Buy

Quality measure sets are re-evaluated annually, with new measures added and outdated measures retired on a regular schedule. This cycle creates both risk and opportunity for health technology companies. If your value proposition depends on a measure that is at risk of being retired, you have a commercial vulnerability. If you can demonstrate impact on a newly added measure before competitors do, you have a first-mover advantage. Understanding the timeline lets you anticipate customer needs and align product development accordingly.

Illustrative Annual Cycle for Major Federal Quality Programmes

Autumn (Yr 1)

Pre-rulemaking review begins. Measures under consideration list published. Workgroups convene to discuss proposed changes.

Spring (Yr 2)

Proposed rules released. Comment periods open. Star rating measure changes proposed. State programmes begin parallel review processes.

Summer–Autumn (Yr 2)

Final rules published. Measure sets confirmed. Performance data from prior year released — triggering customer interest in improvement tools.

Q3–Q4 (Yr 2)

Providers focus on closing care gaps before year-end. Peak purchasing window for quality improvement technology. Claims lag period follows.

Note: Timing is approximate and subject to change. Some programmes may forgo notice-and-comment rulemaking under current administrative policy.

The practical implication for sales and product teams: the period when prior-year performance data is released — typically mid-year — is when customers are most acutely aware of their quality gaps and most receptive to purchasing improvement solutions. The period from Q3 through year-end is when providers are most focused on closing care gaps before the measurement period closes. Aligning your marketing, sales outreach, and product release cycles to this annual rhythm can meaningfully improve conversion.

Five Strategic Actions for Health Technology Companies

Start with the measure specification, not the clinical claim

Before positioning your product around quality improvement, identify the exact measures your customers use and read the full specifications. Understand the numerator, denominator, exclusions, and data sources. Build your value story in the language of the measure, not in generalised clinical outcomes.

Design data capture around quality specifications from day one

Configure your product to track processes and outcomes using the same code definitions, value sets, and field structures used in relevant quality measures. Even if your product cannot calculate formal performance results, aligning data capture with measure parameters adds material value for customers.

Monitor the annual measure set cycle for risks and opportunities

Track the annual rulemaking and measure review processes. If a measure your product addresses is being considered for retirement, you have a commercial vulnerability to manage. If a new measure is being added in your clinical area, you have a first-mover opportunity to capture.

Engage the regulatory process — comments can make a difference

Proposed rules are open for public comment, and regulators are sometimes willing to make technical adjustments — adding a specific code to an eligible services list, adjusting implementation timelines — when presented with data-driven arguments. This is a low-cost, high-optionality channel for health technology companies.

Map the accountability chain to identify your actual buyer

The entity accountable for quality performance in a payment programme may not be the entity that uses your product. Health plans delegate requirements to providers. Providers delegate to specialists. Understanding this chain — and where your product creates measurable impact — determines your go-to-market strategy.

Frequently Asked Questions

What is a quality measure in healthcare?

A quality measure is a precisely defined specification that assesses whether participants in the healthcare system — payers, hospitals, physician practices — are delivering effective care. It captures a snapshot of performance or quantifies change over time by looking for the presence or absence of specific clinical or administrative indicators in patient records. These measures are used in reimbursement programmes to adjust payments based on performance.

Why should medical device and health IT companies care about quality measurement?

Quality measurement directly affects your customers’ revenue. Improved performance on quality measures can generate incentive payments, higher plan ratings that increase reimbursement benchmarks, stronger positioning for contract renewals, and avoidance of financial penalties. If your product improves clinical care or documentation in ways that align with specific quality measures, that alignment is a measurable part of your ROI story. If it does not align, your clinical impact may not translate into financial value for your buyer.

What is the difference between a numerator and a denominator in a quality measure?

The denominator defines the eligible population — the group of patients where a specific process or outcome could occur. The numerator defines the subset of that population for whom the desired process or outcome actually occurred. Performance is calculated as the proportion of the denominator that appears in the numerator. Your product needs to demonstrably move patients from the denominator into the numerator to claim quality improvement.

What are digital quality measures and why do they matter for health tech?

Digital quality measures draw on structured clinical data from electronic health records and other digital sources, using standardised coding systems like LOINC and SNOMED in addition to traditional claims codes. This transition opens opportunities for health technology products that capture structured clinical data to contribute directly to quality measurement — provided their data fields and definitions align with the measure specifications.

How often do quality measure sets change?

Most major measure sets are reviewed annually, with new measures added and existing measures retired through a structured process that typically spans from late autumn through the following spring or summer. Changes are proposed in advance and open for public comment, giving companies that monitor the cycle time to prepare. Final changes are published in annual payment rules or through programme-specific guidance documents.

Can a health tech product improve quality measure performance without improving health outcomes?

Yes, in specific circumstances. Quality measures assess both care processes and outcomes. A product that improves documentation of care processes — ensuring that guideline-concordant actions are properly coded and captured in the clinical record — can improve measured performance even if the underlying clinical care has not changed. This is not gaming the system; it is closing the gap between care delivered and care documented, which is a recognised problem in quality measurement.

What is a value-based payment programme?

A value-based payment programme is a reimbursement arrangement that adjusts provider or plan payments based on quality performance rather than volume of services delivered. These programmes may offer financial bonuses for high performance, impose penalties for low performance, or use quality metrics as gates that determine access to shared savings from reduced total cost of care. They are the primary mechanism through which quality measures become financially consequential.

What is the financial penalty for poor quality performance?

Penalties vary by programme. In the merit-based incentive programme for physicians, the lowest-performing participants can face penalties of up to 9 percent of their covered service payments. Hospital programmes can impose payment reductions of up to 2 percent. Managed care plans that fail to achieve four- or five-star ratings miss out on benchmark increases and higher rebate retention — a loss that can represent thousands of dollars per enrolled beneficiary.

What if my product targets a condition that does not have a quality measure?

If your product serves a population too small or specialised to be covered by major payment programme measures — such as rare diseases — you can look for validated measures in dedicated databases that catalogue measures beyond the major payment sets. While measures not linked to payment incentives may be less commercially compelling, they provide a validated benchmark for demonstrating impact. Building a product and assuming a quality measure will be developed later is a high-risk strategy — measure development is slow, resource-intensive, and not guaranteed to result in inclusion in payment programmes.

How can health tech companies influence quality measure development?

Each quality measure has a designated steward responsible for maintaining its specifications. Companies that identify potential improvements to an existing measure can contact the steward with a data-driven proposal. Simple changes — like adding a code for a newly approved treatment in an established category — can sometimes be adopted with minimal process. Companies can also submit comments on proposed rules when measures are being considered for addition to or removal from major programmes. While individual comments rarely prompt sweeping changes, they can influence technical details that matter for health technology adoption.

OZOP Surgical is an independent healthcare technology publication. This analysis is editorial commentary and does not constitute medical, legal, or regulatory advice. Quality measurement policies are subject to change — always consult current programme guidance for the most recent specifications and requirements. For the full technical specifications referenced in this guide, consult the relevant federal programme documentation at cms.gov. © 2026 OZOP Surgical. All rights reserved.

The post Healthcare Quality Measurement in 2026: The Complete Guide for Medtech and Health IT Companies appeared first on OZOP Surgical.

The Complete Guide to Healthcare Software Development in 2026: What Hospital IT Leaders, Medtech Executives, and Clinical Engineers Need to Know

Ozopsurgical — Sat, 04 Apr 2026 11:14:01 +0000

Healthcare IT spending crossed the trillion-dollar threshold in 2026. That figure represents one of the largest capital allocation decisions the industry has ever made — and much of it is flowing into software systems that determine how clinical workflows operate, how patient data moves between institutions, and how regulatory compliance is maintained at scale. For hospital CIOs, biomedical engineers, and medtech executives evaluating build-or-buy decisions, understanding the architecture of healthcare software development is no longer optional. It is foundational to every technology strategy conversation happening in healthcare leadership today.

This guide examines what healthcare software development actually involves in practice — not from a vendor marketing perspective, but from the operational reality of institutions that must deploy, integrate, and maintain these systems in clinical environments where downtime is not an inconvenience but a patient safety risk. We cover the major categories of healthcare software, the development lifecycle as it applies to regulated environments, the cost factors that determine whether a project stays on budget, and the technology trends that are reshaping what is possible in 2026.

What Healthcare Software Development Actually Means in a Clinical Context

Healthcare software development is the discipline of designing, building, and maintaining digital systems that support clinical, administrative, and operational functions within healthcare organisations. That definition sounds straightforward, but the execution is anything but. Unlike consumer software — where a bug might cause inconvenience — healthcare software operates in an environment where data integrity failures can affect treatment decisions, where downtime can delay critical procedures, and where regulatory non-compliance can result in seven-figure penalties and criminal prosecution.

The scope of healthcare software has expanded dramatically over the past decade. What began as electronic record-keeping has grown into an interconnected ecosystem spanning real-time patient monitoring, AI-assisted diagnostics, robotic surgery coordination, pharmacy automation, revenue cycle management, and population health analytics. Each of these systems must interoperate with existing clinical infrastructure, comply with jurisdiction-specific regulations, and — critically — be usable by clinicians who are under time pressure and have limited tolerance for poorly designed interfaces.

The Core Categories of Healthcare Software in 2026

Healthcare software is not a single product category — it is an ecosystem of interconnected systems, each with distinct regulatory requirements, user constituencies, and integration challenges. Understanding these categories is essential for any technology leader evaluating where custom development adds value versus where off-the-shelf solutions are sufficient.

Electronic Health Records and EMR Systems

EHR and EMR systems remain the gravitational centre of healthcare IT. Every other clinical system — from radiology PACS to pharmacy dispensing — ultimately connects back to the patient record. Custom development in this space typically focuses on interoperability (ensuring records flow seamlessly between departments and institutions), usability improvements (reducing the documentation burden that drives physician burnout), regulatory compliance automation (meeting evolving CMS and ONC requirements), and integration with emerging data sources like wearable devices and genomic platforms. The distinction between EMR (electronic medical record, used within a single organisation) and EHR (electronic health record, designed for cross-institutional data sharing) matters less in practice than in regulatory definitions — most modern systems are converging toward the EHR model as interoperability mandates expand.

Telemedicine and Virtual Care Platforms

The pandemic-era surge in telemedicine adoption forced healthcare organisations to deploy virtual care platforms at speed — and many are now facing the consequences of those rapid implementations. The first wave solved the immediate problem of remote consultations, but left significant gaps in clinical integration, billing workflow alignment, and patient experience consistency. The current generation of telemedicine platforms is focused on hybrid care models that blend in-person and virtual visits within a unified clinical workflow, multi-device accessibility that accommodates patients with limited broadband or older hardware, and asynchronous care delivery models that reduce the dependency on real-time video consultations for routine follow-ups. The development challenge is not building a video call feature — that technology is mature. It is integrating virtual care into the operational fabric of a healthcare organisation so that it enhances rather than fragments clinical workflows.

AI and Machine Learning Modules

AI modules in healthcare software fall into two distinct categories: clinical AI (diagnostic imaging analysis, predictive deterioration models, drug interaction checking, pathology screening) and operational AI (scheduling optimisation, resource allocation, billing code suggestion, staffing prediction). Clinical AI faces the most rigorous regulatory pathway — the FDA has cleared over 900 AI-enabled medical devices as of early 2026, and the EU’s AI Act classifies healthcare AI as high-risk, requiring conformity assessments, post-market monitoring, and explainability provisions. Operational AI faces lighter regulatory scrutiny but has arguably a larger near-term impact on institutional economics — automating administrative workflows that consume an estimated 30 percent of total healthcare spending in the United States.

Medical Device Software and IoMT Integration

The Internet of Medical Things (IoMT) represents one of the fastest-growing segments of healthcare software development. Connected devices — patient monitors, infusion pumps, surgical robots, wearable sensors, implantable devices — generate continuous data streams that require real-time processing, secure transmission, and clinical integration. Software that connects to medical devices operates under the most demanding regulatory requirements: it may be classified as Software as a Medical Device (SaMD) under FDA and EU MDR frameworks, requiring the same rigorous clinical validation and post-market surveillance as physical medical devices. More than 80 percent of life sciences CEOs view IoMT as critical to their organisation’s future, but the implementation reality involves navigating device interoperability standards, cybersecurity requirements for connected medical equipment, and the challenge of integrating data from dozens of device manufacturers into a coherent clinical picture.

Practice Management, Billing, and Operational Software

The operational backbone of healthcare organisations — scheduling, staffing, resource planning, billing, claims processing, and revenue cycle management — runs on software that is often decades old and built on assumptions that no longer hold. CMS’s recent finalisation of electronic claims documentation standards (requiring structured digital submission from providers, insurers, and clearinghouses) is accelerating the modernisation timeline for billing systems that were designed around paper-era workflows. Custom development in this space targets real-time capacity dashboards, automated claims error detection, payer integration APIs, and the elimination of manual rework that inflates administrative costs. Pharmacy management systems — handling inventory tracking, dispensing verification, lot tracking, and integration with prescribing and payer systems — represent a specialised subset with particularly unforgiving accuracy requirements.

Healthcare software development is not a technology problem with a clinical context — it is a clinical problem that requires technology solutions. The distinction determines whether a system survives contact with real-world hospital operations.

— OZOP Surgical editorial perspective

The Development Lifecycle in Regulated Healthcare Environments

Healthcare software development follows a lifecycle that mirrors general software engineering but with additional stages and constraints imposed by the regulatory environment. Each phase carries requirements that do not exist — or carry far less weight — in commercial software development.

Discovery and functional specification is where the product vision meets clinical reality. Development teams must collaborate with clinicians, compliance officers, and IT operations to define not just what the software should do, but how it fits into existing clinical workflows without introducing friction that degrades patient care. Regulatory constraints — HIPAA data handling requirements for U.S. markets, GDPR consent frameworks for European deployments, local healthcare data laws in other jurisdictions — must be mapped at this stage, not retrofitted later. Risk evaluation is not a formality: healthcare regulators expect documented evidence that risks were identified, assessed, and mitigated by design.

UI/UX design in healthcare carries stakes that consumer app designers rarely encounter. A confusing interface on a food delivery app costs a user time; a confusing interface on a medication dispensing system can cost a patient their health. Healthcare UX must accommodate multiple user roles with fundamentally different needs — clinicians who need speed and information density, administrators who need reporting and workflow oversight, patients who need simplicity and accessibility. The design must also account for environmental constraints: clinicians wearing gloves, working in sterile fields, operating under time pressure, and switching between multiple systems during a single patient encounter.

Development and integration is where interoperability becomes the defining challenge. Healthcare systems must communicate through standardised protocols — HL7 (Health Level Seven) and FHIR (Fast Healthcare Interoperability Resources) are the dominant standards for clinical data exchange. FHIR has gained particular momentum because it uses modern web APIs (RESTful interfaces) that are more accessible to contemporary development teams than HL7 v2’s legacy messaging format. The integration layer — connecting the new system with existing EHRs, laboratory information systems, radiology PACS, billing platforms, and medical devices — typically consumes 40 to 60 percent of total development effort in healthcare projects. Underestimating integration complexity is the single most common cause of healthcare software project failures.

QA, security, and compliance testing in healthcare goes far beyond functional testing. It includes penetration testing against healthcare-specific threat models, validation against HIPAA security rule requirements (encryption, access controls, audit logging, breach notification procedures), stress testing under realistic clinical load conditions, and — for software that qualifies as SaMD — clinical validation that the software performs as intended with real patient data under real clinical conditions. The U.S. alone recorded 628 healthcare data breaches in 2025, and the average time to identify a breach was approximately 241 days. Security by design — embedding protection into the architecture from the first line of code rather than bolting it on afterward — is not a best practice in healthcare. It is a survival requirement.

Launch and ongoing maintenance is where many organisations underestimate costs. Healthcare software is never “done” — regulatory requirements evolve, clinical standards change, security vulnerabilities emerge, integration points shift as connected systems are updated, and user feedback reveals workflow issues that testing did not surface. The maintenance phase typically costs 15 to 25 percent of initial development annually, and organisations that fail to budget for it face a compounding technical debt problem that eventually forces a costly replacement cycle.

Reference Table

Healthcare Software Categories and Key Development Considerations

Category	Primary Users	Key Development Challenge	Regulatory Intensity
EHR / EMR Systems	Clinicians, administrators	Interoperability & usability	Very High
Telemedicine Platforms	Clinicians, patients	Clinical workflow integration	High
Clinical AI / ML	Clinicians, radiologists	Validation & explainability	Very High (SaMD)
IoMT / Device Software	Biomedical engineers, clinicians	Real-time data & cybersecurity	Very High (SaMD)
Practice Management	Administrators, staff	Legacy system migration	High
Medical Billing / RCM	Revenue cycle teams	Payer integration & accuracy	High
Patient Portals	Patients, care teams	Accessibility & engagement	Moderate
mHealth / Consumer Apps	Consumers, patients	Engagement & data accuracy	Moderate–High

Source: OZOP Surgical analysis. Regulatory intensity reflects U.S. (FDA/HIPAA) and EU (MDR/AI Act) frameworks as of 2026.

What Drives the Cost of Healthcare Software Development

There is no standard price for healthcare software development, and anyone who quotes one without understanding the specific requirements is selling a template, not a solution. The cost is determined by a constellation of factors that interact in ways that are difficult to estimate without deep domain expertise.

Functional scope and complexity is the most obvious cost driver. A patient portal with appointment booking and results viewing is a fundamentally different project than a clinical decision support system that processes real-time physiological data and generates treatment recommendations. The number of user roles, the depth of workflow automation, the requirement for real-time data processing, and the inclusion of AI or ML modules all multiply development effort. System integration adds cost proportionally to the number and complexity of connections — each integration with an EHR, laboratory system, billing platform, or medical device requires development, testing, and ongoing maintenance. Regulatory compliance adds both direct costs (compliance testing, documentation, audit preparation) and indirect costs (slower development velocity due to mandatory validation checkpoints). Team composition affects hourly rates, but the more consequential cost variable is whether the team has healthcare domain expertise — developers who understand clinical workflows, regulatory requirements, and healthcare data standards deliver faster and produce fewer rework cycles than technically capable teams without domain knowledge.

The costs that catch organisations off guard are typically infrastructure-related: cloud hosting for healthcare data (which requires HIPAA-compliant or GDPR-compliant environments that cost significantly more than standard cloud services), third-party API licensing fees for integrations with external data sources, ongoing monitoring and logging tools required for security compliance, and the maintenance burden of keeping the system current as regulatory requirements and connected systems evolve. Organisations that plan only for the initial development budget — without provisioning for 3–5 years of maintenance, compliance updates, and integration maintenance — consistently underestimate total cost of ownership by 40 to 60 percent.

Technology Trends Reshaping Healthcare Software in 2026

Several technology trends are converging to reshape what is possible — and what is expected — in healthcare software development this year. These are not speculative horizons; they are active deployment priorities for institutions making technology investment decisions now.

AI-powered clinical automation is moving beyond decision support into autonomous workflow execution. Predictive models are flagging patient deterioration before clinical symptoms manifest. Natural language processing is drafting clinical notes from physician-patient conversations, reducing documentation burden. Computer vision models are screening radiological and pathological images with accuracy that rivals specialist clinicians in narrow diagnostic tasks. The regulatory framework for deploying these systems — particularly the EU AI Act’s high-risk classification for healthcare AI — is creating a new compliance layer that development teams must navigate alongside existing medical device regulations.

Remote patient monitoring and IoMT are shifting care delivery from episodic facility-based encounters to continuous data-driven management. Wearable devices, connected implants, and home-based monitoring equipment generate streams of physiological data that must be ingested, processed, and acted upon in real time. The software layer that connects these devices to clinical workflows — handling data normalisation, alert management, clinician notification, and integration with the patient record — is one of the most technically demanding segments of healthcare software development. The AR/VR healthcare market, projected to reach $3.81 billion by the end of 2026, is adding another dimension: immersive surgical planning, training simulations, and emerging care delivery models that require entirely new software architectures.

Interoperability-first architecture is becoming a non-negotiable design principle rather than a feature to be added later. As approximately 70 percent of U.S. hospitals have engaged in interoperable data exchange at least once, the expectation is shifting from “can your system share data” to “how efficiently and completely does it share data.” FHIR-based APIs are becoming the baseline, and development teams that do not architect for interoperability from the first sprint are building systems that will be obsolete before they are deployed. Digital therapeutics (DTx) — regulated software that delivers evidence-based therapeutic interventions — represents a category that barely existed five years ago and is now attracting significant clinical validation investment, particularly in mental health, chronic disease management, and rehabilitation.

Cloud migration and modular architecture are enabling healthcare organisations to replace monolithic legacy systems incrementally rather than through risky big-bang replacements. Microservices architecture allows institutions to modernise individual components — patient scheduling, clinical documentation, pharmacy management — without disrupting the entire technology stack. Cloud-native platforms provide the scalability to handle demand spikes (emergency surge scenarios, seasonal volume increases) without the capital expenditure of over-provisioning on-premises infrastructure. The regulatory landscape for healthcare cloud deployment has matured significantly, with major cloud providers now offering compliance-certified environments and shared responsibility models that simplify the path to regulatory acceptance.

$999B+

Healthcare IT Market 2026

15.8%

Projected CAGR to 2030

900+

FDA-Cleared AI Devices

70%

U.S. Hospitals in Interop Exchange

Frequently Asked Questions

Healthcare Software Development — Common Questions

What is the difference between HL7 and FHIR?

Both are standards for healthcare data exchange, but they represent different generations of technology. HL7 v2, developed in the late 1980s, uses a pipe-delimited messaging format that was designed for point-to-point data transfers between hospital systems. It works but is difficult to implement, hard to extend, and poorly suited to modern web-based architectures. FHIR (Fast Healthcare Interoperability Resources), developed by HL7 International as a next-generation standard, uses RESTful APIs and JSON/XML data formats that contemporary developers find far more familiar. FHIR is modular — it defines individual “resources” (Patient, Observation, MedicationRequest, etc.) that can be combined as needed, rather than requiring implementation of a monolithic specification. Most new healthcare software development uses FHIR, and CMS regulations increasingly mandate FHIR-based APIs for data access, but HL7 v2 remains deeply embedded in legacy hospital systems and will not disappear for many years.

What is Software as a Medical Device (SaMD) and when does it apply?

SaMD is software that is intended to be used for one or more medical purposes without being part of a physical medical device. The key distinction is intent: if software is designed to diagnose, treat, cure, mitigate, or prevent disease — or to inform clinical decisions — it may be classified as SaMD and subject to medical device regulation. An AI model that analyses chest X-rays to detect pneumonia is SaMD. A scheduling app that helps patients book appointments is not. The regulatory pathway depends on the risk classification: software that informs clinical management (like a clinical decision support tool) faces different requirements than software that drives clinical management (like an automated diagnostic system). Under the EU MDR and FDA’s digital health guidance, SaMD classification triggers requirements for quality management systems, clinical evidence, post-market surveillance, and regulatory submission — requirements that significantly affect development cost, timeline, and ongoing operational obligations.

How much does custom healthcare software development cost?

Costs vary enormously depending on scope, complexity, regulatory requirements, and integration depth. A patient-facing mobile app with basic appointment booking and health tracking might cost $150,000–$400,000. A clinical decision support system with AI/ML capabilities, EHR integration, and SaMD regulatory compliance could range from $500,000 to several million dollars. Enterprise-scale systems — core EHR replacements, hospital-wide IoMT platforms, or multi-facility practice management systems — routinely exceed $5–10 million in development costs alone. The critical cost variable that most organisations underestimate is ongoing maintenance: expect to spend 15–25 percent of initial development cost annually on regulatory updates, security patches, integration maintenance, and feature improvements. A $1 million development project typically costs $3–4 million over a five-year lifecycle when maintenance, infrastructure, and compliance costs are included.

What does HIPAA compliance require for healthcare software?

HIPAA (Health Insurance Portability and Accountability Act) compliance for software involves three primary rule sets. The Privacy Rule governs how protected health information (PHI) can be used and disclosed. The Security Rule requires administrative, physical, and technical safeguards to protect electronic PHI — including encryption at rest and in transit, access controls, audit logging, and breach notification procedures. The Breach Notification Rule mandates reporting of data breaches to affected individuals, HHS, and in some cases the media. For software developers, compliance means encrypting all PHI, implementing role-based access controls, maintaining comprehensive audit trails, establishing data backup and disaster recovery procedures, conducting regular security risk assessments, and executing Business Associate Agreements (BAAs) with any third-party service (including cloud providers) that handles PHI. HIPAA violations carry penalties ranging from $100 to $50,000 per violation, with a maximum of $1.5 million per violation category per year.

How does the EU AI Act affect healthcare software development?

The EU AI Act, which began entering into force in 2024 with phased implementation through 2026, classifies most healthcare AI as “high-risk.” This classification triggers mandatory requirements for conformity assessment (demonstrating the system meets essential requirements before deployment), risk management (documented identification and mitigation of risks throughout the system lifecycle), data governance (ensuring training data is relevant, representative, and free from bias), transparency (providing users with clear information about the system’s capabilities and limitations), human oversight (maintaining meaningful human control over high-risk AI decisions), and post-market monitoring (continuously monitoring the system’s performance after deployment). For healthcare software developers, the EU AI Act creates a new compliance layer that sits alongside — and interacts with — existing medical device regulations (EU MDR) and data protection requirements (GDPR). Development teams building AI-powered healthcare software for European markets must architect their systems for compliance from the design phase, as retrofitting these requirements is prohibitively expensive.

When should a healthcare organisation build custom software versus buying off-the-shelf?

The build-versus-buy decision hinges on whether the software represents a competitive differentiator or an operational commodity. For core clinical systems like EHRs, where the market is dominated by mature platforms (Epic, Cerner/Oracle Health, MEDITECH) with decades of regulatory compliance investment, most organisations are better served by configuring an existing platform. Custom development makes strategic sense when the organisation has a unique clinical workflow that off-the-shelf systems cannot accommodate, when the software will be integrated into a novel medical device or clinical process, when the organisation wants to build proprietary intellectual property (as with many digital therapeutics and clinical AI companies), or when existing platforms cannot provide the interoperability, performance, or user experience required for a specific use case. The hybrid approach — using an established platform for core functions while developing custom modules for differentiating capabilities — is increasingly common and often the most pragmatic path.

OZOP Surgical is an independent publication covering healthcare technology, medical devices, and digital health infrastructure. We are not affiliated with any software vendor, healthcare system, or development company mentioned or referenced in this article. This content represents our editorial analysis and should not be construed as procurement, legal, or regulatory advice.

The post The Complete Guide to Healthcare Software Development in 2026: What Hospital IT Leaders, Medtech Executives, and Clinical Engineers Need to Know appeared first on OZOP Surgical.

WHO Flags Generative AI as a Public Mental Health Concern — and the Governance Gap Is Growing

Ozopsurgical — Thu, 26 Mar 2026 19:18:26 +0000

A workshop convened by the World Health Organization and TU Delft in January 2026 produced a set of recommendations that should concern anyone building or deploying AI tools in healthcare: generative AI use should be formally recognised as a public mental health concern, with coordinated responses across government, health systems, and industry.

The statement is notable not because it is surprising, but because it marks the point at which the world’s leading public health authority moved from cautious observation to explicit policy positioning on the mental health implications of generative AI — and not just for tools designed for mental health, but for all generative AI systems that people interact with in moments of emotional vulnerability.

The Problem Is Not Hypothetical

The core concern is straightforward. Generative AI tools — chatbots, conversational agents, AI companions — are increasingly being used for emotional support, particularly by young people. These tools were not designed for that purpose, have not been clinically tested for it, and operate without the safeguards that would be expected of any regulated mental health intervention.

The gap between how these tools are being used and how they were intended to be used is widening rapidly. The pace of consumer AI adoption has dramatically outstripped investment in understanding its psychological impact. People are forming habits of emotional dependence on systems that have no clinical accountability, no crisis referral protocols, and no mechanism for monitoring long-term outcomes.

For healthcare organisations, the implications are practical rather than theoretical. Patients are arriving at clinical encounters having already engaged with AI tools for emotional support — sometimes in ways that have reinforced unhealthy patterns or delayed appropriate care. Clinicians need frameworks for understanding and addressing this reality, and health systems need policies for how AI-assisted mental health support fits into their care models.

Three Recommendations Worth Tracking

The WHO workshop produced three principal recommendations that are likely to shape regulatory and policy conversations over the next several years.

First, generative AI use should be treated as a public mental health issue. This is the broadest and most consequential recommendation. It means that mental health impact should be considered not just for AI tools explicitly marketed as mental health interventions, but for any generative AI system that interacts with users in emotional or vulnerable contexts. The scope of what falls under health governance scrutiny expands considerably under this framing.

Second, mental health should be integrated into impact assessments for AI systems. Workshop participants called for independent investment in testing the effects of AI tools on mental health determinants, short-term clinical measures, and long-term outcomes such as emotional dependence. The emphasis on independent evaluation is significant — it signals a recognition that self-reported assessments from AI developers are insufficient for understanding clinical impact.

Third, AI tools used for mental health support should be co-designed with mental health professionals and people with lived experience, including young people. This recommendation pushes back against the technology-first approach that has dominated the market, where tools are built by engineers and marketed to consumers without meaningful clinical input during the design phase.

What This Means for Healthcare Technology

For medtech companies and health systems, the WHO positioning creates a trajectory that will eventually intersect with regulatory requirements. The pattern is familiar from other areas of health technology — advisory guidance precedes formal standards, which precede compliance mandates.

Organisations developing AI tools that interact with patients or consumers in any emotionally sensitive context should be preparing now for a regulatory environment in which mental health impact assessment is expected, not optional. This includes conversational AI for patient engagement, AI-powered triage systems, virtual health assistants, and any tool that provides information or support in contexts where users may be emotionally vulnerable.

The governance infrastructure is already being built. WHO is establishing a Consortium of Collaborating Centres on AI for Health, bringing together leading academic institutions across all six WHO regions to support evidence-based AI governance. TU Delft, which hosted the workshop as the first WHO Collaborating Centre on AI for health governance, is coordinating initial collaboration mechanisms with candidate institutions.

The Larger Question

The deeper issue that the WHO workshop highlights is one of accountability. When a patient uses a clinically validated mental health intervention and experiences an adverse outcome, there are clear pathways for reporting, investigation, and accountability. When a person uses a generative AI chatbot for emotional support and develops patterns of dependency or receives harmful guidance during a crisis, those pathways do not exist.

Building them will require collaboration between AI developers, mental health professionals, regulators, and the people most affected by these tools. The WHO recommendations provide a framework for that collaboration. Whether the industry moves fast enough to implement it before the harm becomes systemic is the question that matters most.

The post WHO Flags Generative AI as a Public Mental Health Concern — and the Governance Gap Is Growing appeared first on OZOP Surgical.

CMS Finalises Standards for Electronic Claims Documentation: What It Means for Hospital IT

Ozopsurgical — Mon, 10 Nov 2025 19:10:30 +0000

The Centers for Medicare & Medicaid Services has finalised a regulation that will require healthcare providers, insurers, and clearinghouses to adopt standardised electronic formats for exchanging claims documentation by May 2028. The rule targets one of the most persistent inefficiencies in healthcare administration — the continued reliance on fax machines and physical mail to transmit medical records, lab results, and imaging data between providers and payers.
For anyone who has worked in hospital IT or healthcare operations, the fact that this is still a problem in 2026 will not come as a surprise. Despite decades of digitisation in clinical systems, the administrative layer connecting providers to payers has remained stubbornly analogue in many workflows. Claims attachments — the supporting documents payers request to process or adjudicate a claim — have been a particular bottleneck, with providers often printing, faxing, or mailing records that already exist in digital form within their EHR systems.
What the Rule Actually Requires
The regulation formalises two sets of standards for electronic claims attachment exchange. X12 standards will govern the administrative transaction layer — the structured data that identifies which documents are being requested and transmitted. HL7 standards will handle the clinical content itself — the actual medical records, lab reports, and imaging data that support the claim.
The rule also mandates electronic signatures for authentication, ensuring that exchanged documents meet federal privacy requirements under HIPAA. All HIPAA-covered entities — providers, health plans, and clearinghouses — must comply by the May 2028 deadline.
Notably, CMS did not finalise provisions for electronic prior authorisation documentation, which had been included in earlier proposals. Industry stakeholders raised concerns about conflicts with existing standards and implementation complexity. CMS has indicated it will address prior authorisation data exchange in future rulemaking.
The Scale of the Problem
CMS estimates that adopting electronic claims attachment standards could save the healthcare sector roughly $782 million annually. That figure reflects the cumulative cost of manual document handling — printing, faxing, mailing, tracking, and re-requesting records that get lost or arrive incomplete.
But the financial estimate likely understates the operational impact. Every manual claims attachment exchange involves time from clinical staff who could be engaged in patient care, introduces delay into the revenue cycle, and creates opportunities for errors that trigger additional rounds of correspondence. For hospitals operating on thin margins, the administrative drag from manual documentation exchange is a meaningful operational burden.
What This Means for Hospital IT Teams
For hospital CIOs and IT directors, the 2028 compliance deadline creates a concrete implementation timeline. The key questions are practical rather than strategic.
First, how well does the current EHR system support automated generation of claims attachments in the required X12 and HL7 formats? Most major EHR platforms already support HL7 for clinical data exchange, but the specific implementation for claims attachments may require configuration work, vendor coordination, or middleware integration.
Second, what is the connectivity path to payers? The rule standardises the format but does not mandate a single transmission channel. Clearinghouses will likely play a central role in routing electronic attachments, but providers need to assess whether their existing clearinghouse relationships support the new standards or whether additional integration work is needed.
Third, how will electronic signature requirements be implemented? Authentication workflows for outbound clinical documents may need to be built or adapted, particularly for organisations that currently rely on manual sign-off processes for records released to payers.
The Bigger Picture
This regulation is part of a broader CMS push to modernise healthcare data infrastructure. The agency has also launched initiatives like the Health Technology Ecosystem to accelerate digital health adoption and data sharing across the sector.
The direction of travel is clear — healthcare administration is moving toward fully electronic, standards-based data exchange. But the pace of that transition has been slower than almost anyone predicted, and the persistence of fax-based workflows in a sector that has spent billions on digital transformation is a reminder that technology adoption in healthcare is as much an operational and organisational challenge as it is a technical one.
For hospital IT teams, the May 2028 deadline is far enough away to plan properly but close enough to start scoping the work now. The organisations that treat this as a compliance checkbox will get it done. The ones that treat it as an opportunity to streamline their entire claims attachment workflow will get significantly more value from the effort.

The post CMS Finalises Standards for Electronic Claims Documentation: What It Means for Hospital IT appeared first on OZOP Surgical.

Samsung’s Xealth Acquisition Signals a Shift in How Digital Health Tools Reach Clinicians

Ozopsurgical — Mon, 12 May 2025 19:16:14 +0000

Samsung Electronics’ acquisition of Xealth, finalised in late 2025, is not the kind of healthcare deal that generates front-page attention. There were no billion-dollar figures, no flashy product launches, and no promises to revolutionise medicine overnight. But for anyone tracking how digital health tools actually reach clinicians and patients at scale, it may be one of the more consequential moves in the space.

Xealth built something deceptively simple: a platform that lets physicians prescribe digital health tools directly from the electronic health record. Not as a workaround, not through a separate portal, and not by asking patients to download an app on their own — but as a native part of the clinical charting workflow, with decision support that matches patients to relevant digital interventions automatically.

That distinction matters more than it might appear.

The Prescribing Problem in Digital Health

The healthcare industry has no shortage of digital health applications. Remote patient monitoring, digital therapeutics, clinical nutrition platforms, virtual care tools, patient education content — the supply side of the market is well developed and growing. The bottleneck is not technology. It is clinical adoption.

Most digital health tools exist outside the clinical workflow. A physician who wants to recommend a remote monitoring programme or a digital assessment to a patient typically has to leave the EHR, navigate to a separate system, manually enrol the patient, and hope the patient follows through on their end. In a clinical environment where appointment slots are measured in minutes, that friction is enough to prevent adoption for all but the most motivated providers.

Xealth addressed this by building a SMART on FHIR application that sits inside the EHR itself. Physicians can order digital health tools the same way they order a lab test or a medication — from within their normal charting workflow. The platform handles delivery, patient enrolment, and monitoring, and feeds outcomes data back into the clinical record.

The practical effect is that digital health tools become part of the care plan rather than an afterthought. For health systems trying to scale digital programmes across thousands of patients, the difference between “available if you go looking for it” and “integrated into every relevant clinical encounter” is the difference between a pilot project and an operational capability.

Why Samsung Is Interested

Samsung’s interest in Xealth makes sense when viewed alongside the company’s broader healthcare strategy. Samsung already manufactures medical imaging hardware — digital X-ray systems, ultrasound devices — and has integrated AI diagnostic capabilities from partners like Lunit and VUNO into its premium imaging lines.

But hardware and imaging AI address only part of the clinical picture. The larger opportunity is in connecting what happens inside the hospital — diagnostics, treatment decisions, care planning — with what happens outside it. Remote monitoring, home health management, patient education, and ongoing digital engagement between appointments are where the next wave of healthcare value is being created.

Xealth provides the integration layer that makes that connection possible. By sitting inside the EHR and enabling physicians to prescribe and monitor digital health tools as part of standard care, the platform creates a channel through which Samsung can potentially connect its consumer health devices and monitoring capabilities back to clinical workflows.

The company has been explicit about this ambition, framing the acquisition as a step toward building a bridge between home health monitoring and clinical decision-making — with provider workflows and the patient-provider relationship at the centre rather than the periphery.

What This Means for Health Systems

For hospital IT leaders and digital health programme managers, the Samsung-Xealth combination is worth watching for two reasons.

First, it validates the “formulary” model for digital health — the idea that health systems should manage digital tools the way they manage pharmaceuticals, with a curated catalogue of approved interventions that can be prescribed, tracked, and evaluated within clinical workflows. Xealth has been building this capability with health systems like Froedtert and The Medical College of Wisconsin, where the platform is used to deploy clinical nutrition services to diabetic patient populations at scale.

Second, it raises questions about consolidation in the digital health integration layer. If the platform that connects digital health tools to clinical workflows is owned by a device manufacturer with its own hardware and AI ecosystem, health systems will need to evaluate how that ownership affects neutrality, interoperability, and the ability to integrate competing tools.

The Broader Trajectory

The pattern across healthcare technology is consistent: the most valuable infrastructure is not the individual tools but the integration layers that connect them to clinical workflows. An AI diagnostic algorithm is useful. An AI diagnostic algorithm that is embedded in the imaging device, connected to the EHR, and linked to automated care pathways is transformative.

Samsung appears to be assembling these layers — imaging hardware, AI diagnostics, clinical workflow integration, and consumer health connectivity — into a more cohesive ecosystem. Whether that ecosystem remains open enough for health systems to use it flexibly, or becomes another walled garden in an already fragmented landscape, will determine how much value it ultimately delivers.

For now, the Xealth acquisition is a signal that the competition in digital health is shifting from building better apps to controlling how those apps reach the people who prescribe them.

The post Samsung’s Xealth Acquisition Signals a Shift in How Digital Health Tools Reach Clinicians appeared first on OZOP Surgical.