The global electronic health records market reached $35.89 billion in 2025 and is projected to grow to $53.11 billion by 2033 at a 5.10% CAGR. The broader healthcare SaaS market stood at $38.50 billion in 2025 and is on track to reach $102.98 billion by 2035. AI in healthcare reached $39.25 billion in 2025 — up from $29.01 billion in 2024. Generative AI for clinical documentation alone is projected to grow from $1.05 billion in 2026 to $10.50 billion by 2034 at a 33.3% CAGR.
These numbers reflect a sector in the middle of a fundamental infrastructure transition. Legacy clinical systems — built for compliance and record-keeping — are being replaced or supplemented by software that can exchange data in real time, integrate AI at the point of care, and surface clinically actionable insights from vast pools of patient history. For engineering teams building in healthcare, understanding the standards, constraints, and architectural patterns that make this possible is the prerequisite to delivering software that actually works in clinical environments.
The Healthcare Software Stack
Healthcare software spans several distinct categories, each with different data models, regulatory requirements, and integration obligations.
Electronic Health Records (EHR)
The EHR is the system of record for patient clinical data — diagnoses, medications, lab results, imaging orders, clinical notes, and care plans. EHR platforms (Epic, Cerner/Oracle Health, Meditech, Allscripts, athenahealth) hold the majority of structured patient data in US healthcare. Epic alone covers approximately 38% of US hospital patients.
For software teams building applications that sit beside EHRs — clinical decision support tools, patient engagement apps, population health platforms, revenue cycle applications — EHR integration is the primary technical challenge. EHR integration costs range from $50,000 to $200,000 per integration and typically take 6 to 18 months to complete, largely due to the complexity of data models, authentication requirements, and vendor-specific API implementations.
Clinical Workflow Applications
Specialised applications that operate within clinical workflows: nursing documentation tools, surgical planning software, anaesthesia management systems, radiology worklist managers, pharmacy dispensing systems. These applications sit adjacent to the EHR and must exchange data bidirectionally in real time.
Patient-Facing Applications
Patient portals, remote patient monitoring apps, chronic disease management platforms, telehealth interfaces. Patient-facing applications must meet consumer UX standards while complying with HIPAA requirements for PHI handling, consent management, and data access rights.
Population Health and Analytics
Platforms that aggregate clinical data across patients to identify cohorts, measure outcomes, flag care gaps, and support value-based care contracting. These consume large volumes of structured EHR data, claims data, and social determinants data, requiring robust data pipeline infrastructure and analytics capabilities.
Interoperability Standards: The Technical Foundation
HL7 v2: The Dominant Real-Time Messaging Standard
HL7 version 2 (HL7 v2) — a messaging format developed in the late 1980s — handles approximately 85% of real-time intra-hospital data exchange globally. Admission/discharge/transfer events (ADT messages), lab results (ORU messages), and scheduling (SIU messages) flow between clinical systems as HL7 v2 pipes-and-hats messages. Despite being decades old, HL7 v2 is deeply embedded in clinical infrastructure and will remain relevant for the foreseeable future.
Engineering teams building healthcare integrations must understand HL7 v2. The practical requirements: a message parsing library (HAPI for Java, hl7apy for Python, hl7lib for JavaScript), an integration engine or middleware layer (Mirth Connect, Azure API for Healthcare, AWS HealthLake) that can receive HL7 v2 feeds, parse and validate messages, and route or transform them to downstream consumers.
FHIR R4: The Regulatory Standard
HL7 FHIR (Fast Healthcare Interoperability Resources) R4 is the current standard for healthcare data exchange via REST API. By 2026, FHIR R4 compliance is a baseline regulatory expectation for virtually every significant healthcare IT platform operating in the United States. The CMS Interoperability and Patient Access Rule requires CMS-regulated payers to expose patient data via FHIR R4 APIs. The 21st Century Cures Act mandates that certified EHR technology support FHIR-based data access.
FHIR represents patient data as typed Resources — Patient, Observation, Condition, MedicationRequest, DiagnosticReport, Encounter — accessible via RESTful API endpoints. A FHIR server exposes endpoints like GET /Patient/{id}, GET /Observation?patient={id}&code=8480-6 (blood pressure observations for a patient), and POST /MedicationRequest (create a new prescription). FHIR’s REST/JSON API design makes it dramatically more accessible to software teams than HL7 v2’s binary messaging format.
Not all EHRs fully support FHIR. In practice, developers frequently encounter systems with partial FHIR support — some resources available via FHIR, others only via vendor-specific APIs or HL7 v2. Healthcare integration work requires supporting hybrid architectures: FHIR R4 where available, HL7 v2 or vendor API for the remainder.
SMART on FHIR
SMART on FHIR is the authorisation framework that allows third-party clinical applications to securely connect to EHRs using OAuth 2.0 and FHIR APIs. A SMART app launches within the EHR context — the EHR passes the current patient ID and access token to the app via a launch sequence — and the app queries the FHIR server for clinical data without requiring the user to log in separately or re-select the patient.
For clinical application developers, SMART on FHIR is the integration pattern that matters. Building a SMART app means: registering the application with the EHR vendor (each vendor has its own app marketplace or registration process), implementing the SMART launch sequence, requesting appropriate OAuth scopes (e.g., patient/Observation.read, user/MedicationRequest.write), and querying the FHIR server for the data the application needs.
DICOM: Imaging Data
Medical imaging data — CT scans, MRI, X-ray, ultrasound — is stored and transmitted in DICOM format. Applications that access imaging data must integrate with the PACS (Picture Archiving and Communication System) via DICOM protocols (C-STORE, C-MOVE, WADO-RS). For imaging AI applications, DICOM is the primary data format; see our medical imaging AI guide for the full DICOM integration architecture.
HIPAA Compliance in Software Architecture
HIPAA’s Security Rule defines the technical safeguards required for any system that stores, processes, or transmits Protected Health Information (PHI). For engineering teams, the non-negotiable requirements:
Access control: unique user identification (no shared accounts), automatic logoff after a defined period of inactivity, and role-based access control that limits PHI access to only the data necessary for each user’s function.
Encryption: AES-256 encryption at rest is now explicitly required following HIPAA’s 2025 update. TLS 1.2 minimum (TLS 1.3 preferred) for data in transit. Encryption keys must be managed via HSM or cloud KMS — never embedded in application code.
Audit logging: every access to, modification of, or disclosure of PHI must be logged with user identity, timestamp, and action taken. Logs must be tamper-evident and retained for a minimum of six years.
Business Associate Agreements (BAAs): any vendor or cloud provider that processes PHI on behalf of a covered entity must sign a BAA. AWS, Azure, and GCP all offer BAA-eligible service tiers (AWS HIPAA-eligible services, Azure HIPAA-aligned services, GCP Healthcare API). Deploying PHI workloads on non-BAA services is a HIPAA violation regardless of the application’s own security posture.
Minimum necessary standard: systems must be designed to limit PHI access to only what is necessary for each use case. A billing application that queries patient demographics must not also receive clinical notes that are irrelevant to billing.
Clinical AI: The 2026 Engineering Reality
The Clinical Documentation Use Case
Generative AI for clinical documentation is the highest-velocity AI use case in healthcare software in 2026. Ambient documentation systems — microphone-equipped devices or mobile apps that listen to patient-clinician conversations and generate structured clinical notes — directly address physician burnout caused by documentation burden.
The architecture: a streaming ASR (automatic speech recognition) pipeline transcribes the conversation in real time; an LLM processes the transcript to generate a SOAP note (Subjective, Objective, Assessment, Plan) or other structured note format; the output is presented to the clinician for review and one-click posting to the EHR via FHIR. In February 2026, Oracle Health expanded its Clinical AI Agent with automated order creation — enabling the AI to draft prescriptions, lab tests, and imaging orders from ambient conversation, for clinician review before submission.
The engineering requirements: low-latency ASR with medical vocabulary support; LLM fine-tuned on clinical note formats and ICD-10/CPT coding; FHIR write access to post the finalized note and orders; and a human-in-the-loop review step before any clinical data is committed to the EHR.
Clinical Decision Support
Clinical decision support (CDS) systems surface alerts, recommendations, and risk scores to clinicians at the point of care. CDS integration uses the CDS Hooks standard — a FHIR-adjacent specification that allows EHRs to call external CDS services during clinical workflow events (patient is admitted, a medication is ordered, a lab result is received) and display the CDS response as a card within the EHR interface.
CDS Hooks integration pattern:
- The EHR fires a hook event (e.g.,
medication-prescribe) with a FHIR context payload - The CDS service evaluates the context and returns one or more suggestion cards
- The EHR displays the cards within the prescribing workflow
- The clinician accepts, modifies, or dismisses the suggestion
The regulatory consideration: CDS that qualifies as Software as a Medical Device (SaMD) requires FDA clearance. CDS that functions as a reference tool — providing information for clinician review without driving automated clinical action — generally falls outside FDA device regulation. The distinction between decision support and decision automation is the critical regulatory boundary.
AI-Assisted EHR Data Integration
AI is increasingly used to automate the data engineering problem in healthcare: mapping clinical data from heterogeneous sources to standardized FHIR resources. AI-powered data mapping tools can analyse structured and unstructured source data and automatically generate FHIR resource mappings — reducing the manual effort required to onboard a new EHR data source from weeks to days. Intelligent error detection flags inconsistent or incomplete data in real time, rather than discovering mapping errors in downstream analytics.
How we approach this at Insoftex
Healthcare is one of our three core industry verticals, and the regulatory and technical constraints described in this article are the ones our healthcare builds are designed around from the start. On our AI-powered healthcare platform engagement, HIPAA compliance and FHIR integration were the first design inputs — not a compliance layer added after the data model was established. The FHIR semantic mapping work, translating the client’s existing clinical data structures into FHIR R4 resources, was done during the scoping phase because discovering a semantic mismatch during build requires data model rework that is significantly more expensive than identifying it before the architecture is set.
The EHR integration challenge — specifically the gap between HL7 v2 intra-hospital messaging and FHIR R4 external API access — is one we encounter in most healthcare platform engagements. The hybrid integration architecture (integration engine for HL7 v2, FHIR REST client for external access) is not optional; it is the architecture that matches the healthcare data landscape. Teams that plan for FHIR-only integration discover HL7 v2 requirements during implementation, when adding the integration engine requires rework to the data pipeline design.
For clinical AI specifically, we scope the FDA SaMD classification question and the human-in-the-loop design before model selection. The regulatory boundary between non-device clinical decision support and regulated SaMD is not always obvious from the product description — it depends on intended use, clinical context, and whether the clinician can meaningfully review the AI’s reasoning. We run this assessment in the Product Pilot because the classification result can eliminate model architecture options that would otherwise appear viable. Building a model architecture and discovering afterward that it fails the explainability requirement for its intended clinical use is a significantly more expensive finding than making the same discovery in discovery.
Building healthcare software — EHR integration, clinical AI, patient engagement, or population health infrastructure? Our healthcare engineering page covers the systems we build and the engineering challenges we focus on. Start with a Product Pilot for FHIR integration architecture, HIPAA compliance design, and clinical AI approach in three weeks.
Frequently Asked Questions
What is the difference between HL7 v2 and FHIR, and which does my application need?
HL7 v2 and FHIR are both healthcare interoperability standards, but they serve different integration contexts and have very different technical profiles. HL7 v2 is a message-based standard — clinical events (admissions, lab results, scheduling changes) trigger the transmission of messages in a pipe-delimited text format between systems. It is the dominant real-time integration standard inside hospitals, handling approximately 85% of intra-hospital data exchange globally. HL7 v2 requires an integration engine (Mirth Connect, Rhapsody, Azure Integration Services) to receive, parse, and route messages. FHIR R4 is a REST API standard — clinical data is exposed as typed resources (Patient, Observation, Condition, MedicationRequest) via HTTP endpoints with JSON or XML payloads. FHIR is the regulatory-mandated standard for external data access — payer-to-patient data sharing, third-party application integration, and cross-organisation data exchange. Your application likely needs both. If you are integrating real-time clinical events from a hospital's internal systems (lab results triggering an alert, admissions feeding a care management platform), you will encounter HL7 v2. If you are building a third-party application that accesses patient data from an EHR, or a patient-facing application that reads clinical history, you will use FHIR. If you are integrating with a payer for claims or eligibility data, FHIR R4 is increasingly mandated. Plan for a hybrid integration architecture that handles HL7 v2 messages and FHIR REST API calls.
What does HIPAA compliance require for a cloud-hosted healthcare application?
HIPAA compliance for a cloud-hosted healthcare application requires technical, administrative, and physical safeguards that together protect the confidentiality, integrity, and availability of Protected Health Information (PHI). On the technical side: AES-256 encryption at rest (explicitly required since HIPAA's 2025 Security Rule update), TLS 1.3 in transit, role-based access control with unique user identification (no shared credentials), automatic session timeout after inactivity, and tamper-evident audit logging of all PHI access and modification events. On the infrastructure side: you must use HIPAA-eligible cloud services and sign a Business Associate Agreement (BAA) with your cloud provider. AWS, Azure, and GCP each have specific HIPAA-eligible service lists — not all services on these platforms are BAA-eligible, and deploying PHI on non-BAA services constitutes a HIPAA violation. On the organisational side: you need written policies and procedures for access management, incident response, workforce training, and risk analysis. Risk analysis — identifying and documenting potential risks to PHI — is one of the most commonly cited gaps in HIPAA enforcement actions. The practical path for a new healthcare software application: choose a HIPAA-eligible cloud environment, design encryption and access control into the architecture from day one (retrofitting is expensive), sign BAAs with all PHI-touching vendors, and engage a HIPAA compliance specialist to review your risk analysis and policies before handling real patient data.
What is SMART on FHIR and how do I build a SMART app?
SMART on FHIR (Substitutable Medical Applications, Reusable Technologies on FHIR) is the authorisation framework that allows third-party applications to launch within an EHR context and securely access patient data via FHIR APIs. A SMART app launches within the EHR workflow — embedded as an iFrame or as a standalone launch — with the EHR passing the current patient context and an OAuth 2.0 access token to the app. The app uses that token to query the EHR's FHIR server for patient data within the scopes it was granted. Building a SMART app involves several steps: (1) Register the app with the EHR vendor or their app marketplace — each major EHR (Epic App Orchard, Cerner Code, athenahealth marketplace) has its own registration and approval process, which can take weeks to months. (2) Implement the SMART launch sequence — either EHR launch (the EHR initiates the launch with a patient context) or standalone launch (the app initiates and the user authenticates independently). This follows the OAuth 2.0 authorisation code flow with specific SMART extensions. (3) Request appropriate OAuth scopes — SMART scopes specify both the resource type and the access level (e.g., `patient/Observation.read`, `user/MedicationRequest.write`). Scopes must be declared at registration and approved by the EHR vendor. (4) Query the FHIR server using the granted token — standard FHIR REST API calls with the Bearer token in the Authorization header. The challenge: SMART implementation varies between EHR vendors. Epic's FHIR implementation differs from Cerner's in supported resources, scope naming conventions, and launch parameters. Building against multiple EHRs requires vendor-specific testing and often vendor-specific code paths.
How do I integrate AI into a clinical workflow without triggering FDA medical device regulation?
The FDA's regulatory boundary for clinical AI software is defined by the intended use and the degree to which the software drives clinical decision-making autonomously. Software that qualifies as a medical device — Software as a Medical Device (SaMD) — requires FDA clearance (510(k), De Novo, or PMA). Software that provides information for clinician review without automating clinical decisions generally falls outside device regulation. The practical distinction: a clinical decision support tool that displays a risk score with supporting evidence for clinician review is likely non-device CDS if the clinician independently reviews the information and makes the clinical decision. An AI system that automatically flags a finding, routes a case, or initiates an action based on its output without required clinician review is more likely SaMD. The FDA's 2024 and 2025 guidance updates on CDS software clarified this boundary, but gray areas remain — particularly for AI that generates recommendations that most clinicians follow in practice, even if the workflow formally requires clinician approval. The engineering implication: design human-in-the-loop review into every AI-generated clinical output. Make the review step meaningful — the clinician must be able to see the basis for the AI's output, evaluate it independently, and make an informed decision to accept, modify, or reject. Document the intended use precisely: who will use the software, in what clinical context, for what purpose, and what the human oversight mechanism is. If you are uncertain whether your intended use crosses the SaMD threshold, engage FDA regulatory counsel before building — not after.