Healthcare Software Development: Netguru's Approach and Case Studies

Healthcare software development at a glance

Healthcare software development fails at the intersection of three constraints: compliance, interoperability, and clinical risk, and most teams discover this only after they've already shipped something that can't scale or can't integrate. The order in which you address HIPAA technical safeguards, HL7/FHIR resource modeling, and Electronic Health Records (EHR) connectivity determines whether your build is a product or a liability.

Across six shipped healthcare builds, from Merck's AI R&D assistant to Keto-Mojo's BLE-connected glucose ecosystem, our team has learned that compliance, interoperability, and clinical risk rarely fail in isolation.

We've delivered custom software across pharma AI tooling, regulated laboratory management, surgical cloud infrastructure, clinical decision support, and connected health IoT. Outcomes include a 20x acceleration in Merck's chemistry research pipeline, 97% faster inventory tracking in a regulated lab environment, and a five-minute RTO for Nodus Medical's surgical platform on AWS.

This article covers how we structure healthcare software development to stay HIPAA-compliant, FHIR-interoperable, and clinically safe, with the architecture decisions and tradeoffs that determined each outcome.

The 2026 healthcare tech landscape: AI, IoMT, and cloud-native clinical platforms

Three forces are reshaping healthcare software development simultaneously, and the window to build ahead of them is narrowing. Large Language Models (LLMs), Remote Patient Monitoring (RPM), and Clinical Decision Support (CDS) tools have moved from pilot to procurement: health systems now budget for them, regulators have guidance frameworks for them, and patients expect the care continuity they enable.

The global healthcare IT market reached USD 866.48B in 2025, according to Grand View Research Healthcare IT Market Report, 2024, with projections of USD 2,864.39B by 2033. For context, the broader software market is growing at a similar pace: estimated at USD 730.7B in 2024 and projected to reach USD 1.4T by 2030, a CAGR of around 11.3%, per 11 Software Development Best Practices in 2026. For a breakdown of the solutions driving this growth, Netguru has identified 16 distinct software categories shaping the industry in 2026.

According to HealthIT.gov Hospital Trends in Predictive AI, 2024, 71% of hospitals using predictive AI integrated with EHR.

The structural shift underneath all three is cloud-native architecture. EHR vendors, Epic included, have opened FHIR R4 APIs that make patient data accessible at a level impossible five years ago, but that access creates new obligations around PHI governance, GDPR compliance for EU deployments, and HIPAA technical safeguards that most teams underestimate until they're in a security review. On the device side, Bluetooth Low Energy (BLE)-enabled RPM hardware is generating continuous patient data streams that require real-time ingestion pipelines, not batch ETL.

The AI layer compounds everything. Retrieval Augmented Generation (RAG) architectures can surface relevant clinical guidance without fine-tuning on sensitive data, a meaningful advantage in regulated environments, but they still require careful prompt boundary management to avoid generating outputs that trigger FDA 510(k) Software as a Medical Device (SaMD) classification. Our team has navigated this exact boundary on pharma R&D and clinical platform projects, and the classification question comes up earlier in development than most CTOs expect.

Why healthcare software is hard: Compliance, interoperability, and clinical risk

Healthcare software development fails at the intersection of three constraints that rarely appear together outside this industry: federal compliance mandates with criminal penalties, interoperability standards that are mandatory but inconsistently adopted, and clinical risk where software defects can directly harm patients.

Compliance is layered, not linear. HIPAA's Technical Safeguards, encryption at rest and in transit, audit controls, automatic logoff, are the floor. HITECH adds breach notification timelines and widens liability to business associates. GDPR applies the moment any patient data touches EU residents, adding data minimization and right-to-erasure obligations that can conflict with HIPAA's minimum six-year retention requirement. SOC 2 Type II sits on top of all of this as a market expectation for any B2B health data platform. According to HHS Office for Civil Rights enforcement data, HHS settled or imposed civil money penalties in cases totaling over $135 million between 2016 and 2024, and that figure excludes state-level enforcement under GDPR equivalents. Protected Health Information (PHI) mishandling is not a compliance footnote; it is a business-ending event.

Interoperability is mandatory but still hard. HL7/FHIR R4 resources are now federally required for patient access APIs under the 21st Century Cures Act, yet EHR vendors, Epic included, build FHIR profiles inconsistently. Connecting custom software to a hospital's Epic instance typically requires navigating SMART-on-FHIR OAuth2 scopes, custom extensions, and sandbox certification before a single patient record moves. In practice, this adds four to ten weeks to any EHR integration project.

Software as a Medical Device (SaMD) raises the stakes further. Any software that processes patient data to inform a clinical decision, a triage algorithm, a diagnostic aid, qualifies as SaMD under FDA guidance and likely requires a 510(k) premarket notification before launch. The FDA's Digital Health Center of Excellence has published a clear SaMD classification framework, but engineering teams routinely underestimate how early in the development lifecycle FDA design controls must begin. Missing that window means costly retrospective documentation or delayed market entry.

Working with Naontek, Netguru took over an existing codebase, grew the product team, and delivered a production-ready platform in six months while maintaining development efficiency. The platform successfully launched as a digital point of contact for the German healthcare community, supported by apoBank. For teams navigating similar complexity, custom healthcare software solutions can be scoped and delivered with the right regulatory and engineering guardrails in place from day one.

These constraints do not make healthcare software development impossible, they make the definition of 'done' much wider than in other verticals.

Case study 1, Merck KGaA: AI R&D assistant cuts chemical ID from 6 months to 6 hours

Merck KGaA's computational chemistry teams spent up to six months manually cross-referencing proprietary synthesis data against scientific literature to identify viable chemical compounds. The bottleneck wasn't expertise, it was retrieval: researchers had to query multiple internal databases, read hundreds of PDFs, and reconcile conflicting nomenclature by hand.

Objectives

• Build an AI R&D assistant that lets chemists query decades of proprietary laboratory data using natural-language questions
• Reduce time-to-identification for chemical compounds without sacrificing scientific accuracy
• Ensure sensitive research data never left Merck's controlled environment

Outcomes

• Chemical identification time dropped from six months to six hours, a 1,460x acceleration
• The system used Retrieval Augmented Generation (RAG) to ground Large Language Models (LLMs) in Merck's own corpus, preventing hallucination on proprietary chemistry data
• Python handled the document ingestion pipeline, embedding generation, and vector store queries
• All data remained on-premise, satisfying Merck's internal data governance requirements

The engineering challenge our team found hardest was not the RAG architecture itself, standard retrieval patterns transfer well from general software development, but schema normalization across legacy data sources that used inconsistent compound identifiers accumulated over 30+ years. Unifying those identifiers was a prerequisite before any LLM could reason reliably across the corpus.

Case study 2, Merck LANEXO: Flutter lab inventory app, 97% faster workflow

Laboratory inventory management in regulated pharmaceutical environments carries real compliance risk. Mislabeled reagents, expired chemicals, and broken audit trails aren't just operational friction, they're EHR-adjacent data integrity failures that can trigger GMP non-conformances. Merck KGaA needed better analytics and insights for its LANEXO® platform.

Objectives

• Replace manual, paper-based lab inventory tracking across multi-site healthcare and research facilities
• Deliver a single cross-platform mobile app covering both iOS and Android without duplicating the development effort
• Ensure sensitive chemical and reagent data met GDPR storage requirements and internal pharmaceutical data governance standards
• Enable barcode and QR-code scanning workflows that lab technicians could adopt without training overhead

Outcomes

• Flutter delivered a unified codebase with a single development team, cutting platform-specific build time significantly
• Inventory management workflows ran 97% faster than the prior manual process, reducing what took hours to under five minutes
• The app passed Merck's internal compliance review for personal and sensitive data handling
• Lab technicians adopted the digital-first workflow without a formal change management program

That played out at Merck KGaA, Darmstadt, Germany, where Netguru drove 97% faster inventory management.

What made this technically significant was the choice to commit fully to Flutter rather than a hybrid web wrapper. Our engineers recommended Flutter specifically because its widget rendering engine bypasses native OS UI components, critical for ensuring pixel-consistent barcode scanning interfaces across the Android device fragmentation common in lab hardware procurement. The 97% workflow improvement came from process re-engineering as much as from the application itself: the team mapped every manual tracking step before designing the UX, ensuring the digital system matched how care and laboratory teams actually worked.

Case study 3, Keto-Mojo: BLE connected glucose ecosystem with HIPAA data sharing

Keto-Mojo makes blood glucose and ketone meters used by patients managing metabolic health outside clinical settings. The technical challenge: bridge a Bluetooth Low Energy (BLE) hardware device to a mobile application that stores and shares Protected Health Information (PHI), all without triggering HIPAA violations or creating a fragmented iOS/Android experience.

Objectives

• Build native iOS and Android applications that pair reliably with BLE meters using standard GATT profiles
• Architect PHI data storage and transmission with HIPAA-compliant encryption at rest and in transit
• Enable secure patient data sharing with care providers and third-party health platforms
• Maintain a unified codebase approach without sacrificing platform-specific BLE stack behavior

Outcomes

We saw this in practice with CashCape: completed its beta stage in 2017 and is now building new features and improving user experience. The platform enables customers to complete all loan application steps online from their mobile devices without bureaucratic delays.

What made this engagement technically demanding was the BLE reliability layer. Consumer BLE devices drop connections, a meter paired in a kitchen with microwave interference behaves differently than one in a clinic. Our team built retry logic and connection-state management that handled real-world RF conditions without exposing partial PHI writes to storage. The engagement ran five years, covering multiple hardware generations and successive OS changes on both platforms.

HIPAA technical safeguards require audit controls, automatic logoff, and encrypted PHI transmission, not just a privacy policy checkbox. Designing those controls into a mobile health application from the start, rather than bolting them on before launch, is where most connected-health software development projects lose months.

Case study 4, AMBOSS: GenAI strategy, 30 ideas pitched, 14 teams activated

AMBOSS is a medical knowledge platform used by physicians and students across more than 180 countries. Their question was precise: where does generative AI create real clinical value, and how do you move 14 product and engineering teams from curiosity to committed roadmap items without shipping something that embarrasses a medical brand?

Objectives

• Audit the AMBOSS product surface for viable Large Language Models (LLMs) use cases, ranked by clinical impact and engineering feasibility
• Run a structured GenAI hackathon to generate and pressure-test ideas across cross-functional teams
• Produce an actionable AI roadmap grounded in Retrieval Augmented Generation (RAG) architecture, not generic LLM API calls, so that medical content retrieval stayed accurate and hallucination risk stayed low
• Identify which ideas required custom fine-tuning versus prompt engineering versus RAG pipelines

Outcomes

• 30 GenAI concepts pitched across the two-day workshop format
• 14 internal AMBOSS teams activated with prioritized backlog items tied directly to the session output
• RAG emerged as the preferred architecture for the highest-priority use cases, keeping model responses grounded in AMBOSS's proprietary medical content rather than open-web training data
• Healthcare software development roadmap delivered within weeks, not quarters

Case in point: Keto-Mojo hit over nearly five years, Netguru delivered rock-solid Bluetooth connectivity, significantly improved App Store and Google Play reviews, expanded access to health data through native apps and web applications for both users and healthcare professionals, and enabled partner integrations through custom SDK development while maintaining HIPAA compliance with Netguru.

What made this engagement technically credible was the architecture specificity. RAG was chosen over fine-tuning for most use cases because AMBOSS's content corpus is dense, structured, and frequently updated, conditions where a retrieval layer outperforms a static fine-tuned model on accuracy and maintenance cost. The workshop model also matters: by embedding Netguru engineers alongside AMBOSS product managers and medical content teams, ideas were filtered for EHR integration complexity and patient safety implications before they reached the backlog.

Case study 5, Nodus medical: AWS migration for surgical platform, 5-minute RTO

Nodus Medical builds software for surgical workflow management: a category where downtime during an active case is not a support ticket, it's a patient safety event. When Nodus engaged Netguru, their platform ran on a single-region architecture with no formal recovery objectives. The ask was direct: migrate to AWS, achieve SOC 2 Type II attestation, and define RTO/RPO targets the business could actually defend.

Objectives

• Re-architect the surgical platform on AWS with multi-AZ high availability
• Define and validate a 5-minute RTO and sub-minute RPO under realistic failure scenarios
• Achieve SOC 2 Type II compliance to satisfy hospital procurement requirements
• Ensure all PHI data storage and transit met HIPAA technical safeguard requirements

Outcomes

• 5-minute RTO validated through fault-injection testing across availability zones
• SOC 2 Type II attestation completed, unblocking enterprise health system deals
• Automated failover replaced manual recovery runbooks entirely
• HIPAA-compliant data encryption at rest and in transit enforced across all services

The hardest part technically was not the migration itself, it was designing chaos engineering tests that simulated realistic failure modes for a surgical care context, where partial degradation is often worse than a clean outage. Our infrastructure team ran 11 distinct failure scenarios before signing off on the RTO guarantee. That played out at Naontek, where Netguru drove netguru completed the project in six months, taking over an existing codebase and growing the product team while maintaining efficiency. The platform successfully launched as a digital point of contact for the German healthcare community, supported by apoBank.

Case study 6, Shine: Mental well-being app voted App Store best of 2020

Shine entered an overcrowded wellness market with a sharper thesis: mental self-care should feel personal, not clinical. The founders had seen that existing well-being apps didn't resonate with people who felt alienated by traditional mental-health framing, and they wanted to close that gap.

Objectives

• Build a preventative mental-health platform that makes self-care accessible and stigma-free
• Evolve the product from an initial messaging bot into a full multimedia experience
• Ship features on tight consumer-app deadlines, including Black Friday campaign moments
• Keep the React Native core healthy as the product scaled in scope and audience

Outcomes

• Voted App Store Best of 2020
• Grew from a simple messaging bot into a complete wellness suite: podcasts, meditations, articles, and daily challenges
• React Native core infrastructure upgraded for better performance and scalability
• Cross-functional support across QA, design, UX, iOS, and Android, supplied as the roadmap demanded

The hardest part here was not any single feature. It was holding a consistent, calm product voice while the app's surface area kept expanding, because in mental-health software a jarring interaction is not just a UX bug, it can break the user's trust in the whole experience.

How we work: Discovery to post-launch monitoring

Most healthcare software projects fail at the boundary between clinical requirements and engineering decisions. Our process is built to close that gap at every stage, not patch it after go-live.

Discovery (weeks 1-4). We map your regulatory exposure before writing a line of code. For projects touching Protected Health Information (PHI), we define HIPAA technical safeguards, encryption at rest and in transit, audit logging, access control, as architecture constraints, not post-build additions. If the product qualifies as a Software as a Medical Device (SaMD), we flag FDA 510(k) requirements during discovery, so clinical validation gates are scheduled into the roadmap rather than discovered as blockers at submission.

Architecture and integration design. EHR connectivity is resolved at this stage. We specify HL7/FHIR resource profiles, SMART-on-FHIR authorization scopes, and Epic or Cerner sandbox environments before development sprints begin. Ambiguity here costs weeks later, we've seen that pattern on enough engagements to treat it as a hard gate.

Development and compliance review. Our team runs OWASP TOP 10 checks and internal security reviews in parallel with feature sprints. ISO 27001 certification and GDPR compliance frameworks govern how sensitive data moves through our systems and yours.

Clinical validation and user testing. For patient-facing software, we coordinate usability testing against FDA human-factors guidance, not just standard UX research. This matters most for SaMD, clinical recognition depends on it.

Post-launch monitoring. We define RTO/RPO targets before launch and wire observability, structured logging, alerting, on-call runbooks, before the first real patient interaction. Care doesn't stop at deployment.

Our healthcare tech stack: Flutter, React Native, Python, AWS, BLE, RAG, FHIR

Flutter handles our cross-platform mobile builds for regulated environments: one codebase, two App Store submissions, full parity on iOS and Android. React Native stays in the toolkit for teams with existing JavaScript investment or when deep native module access matters less than ecosystem fit. The choice between them is a tradeoff we make explicitly in discovery, not by default.

On the backend, Python drives our AI/ML workloads: RAG pipelines for clinical document retrieval, fine-tuned models for diagnostic support, and the AI R&D assistant we built for Merck that compressed chemical compound identification from six months to six hours. AWS underpins deployment, multi-AZ configurations, VPC-isolated PHI storage, CloudTrail audit logging, and automated Business Associate Agreement coverage where required.

Bluetooth Low Energy (BLE) connects patient-facing hardware to mobile software. In connected health, BLE pairing reliability and battery-aware polling intervals are the two things that break most IoT integrations. We've resolved both medical IoT engagements to help improve patient outcomes.

HL7/FHIR R4 resource modeling shapes every EHR integration we build, whether that's SMART-on-FHIR OAuth2 authorization for Epic access or custom FHIR facade layers over legacy HL7 v2 feeds. Getting FHIR right means understanding which resource types carry sensitive data under HIPAA technical safeguards, not just mapping JSON fields.

Merck KGaA's LANEXO® laboratory inventory management application is the clearest proof of this stack working in a regulated setting, a cross-platform Flutter app delivering 97% faster inventory management across two platforms, built concurrently.

Frequently asked questions

Talk to Netguru's healthcare team

Our engineers have shipped HIPAA-compliant systems, HL7/FHIR-integrated EHR connectors, Flutter applications for regulated laboratory environments, and AI-assisted diagnostic tools: across pharma, medtech, and digital health. We know where healthcare software development breaks down in practice: audit logging gaps, FHIR resource mapping edge cases, cloud failover that looks solid until a real RTO test.

If you're scoping a custom patient portal, a medical data pipeline, or a connected health platform, a focused discovery session will surface the critical architectural decisions before any development begins.

Get an estimate for your project, and leave with a concrete scope, not a sales deck.