Digital health solutions are now our lives. The stats make it obvious.
71% of adults use some kind of digital health solutions. This usage also gets reflected in the funding that goes into this space.
In 2024, digital health startups in the country raised $10.1 billion across 497 deals, with AI-enabled companies capturing 42% of it.
I am talking about ambient scribing platforms, EHR vendors, medical imaging AI, remote patient monitoring tools, and telehealth platforms that are being built and deployed at a pace never seen before in the healthcare sector.
However, it is growing fast, and the compliance infrastructure just cannot keep up with it. And that gap is showing.
In January 2025, Medusind, a revenue cycle management software vendor, disclosed a breach that exposed the PHI of 701,475 individuals.
Just two years ago, another company named Cerebral, a mental health telehealth startup, had allegedly shared patient data with Snapchat, LinkedIn, and TikTok through tracking pixels. The result? Disclosure of PHI of 3.2 million users.
Neither of these was a hospital. Both were digital health business associates with direct access to large volumes of PHI. And in both cases, the breach vector was a misconfigured marketing technology stack or an inadequately secured vendor system.
These were just two instances. The millions of patient records under attack each year show that HIPAA can no longer be treated as a background compliance checkbox. It should be actively enforced with specific technical requirements for every product category in the digital health tech sector.
In this blog, we go further into the HIPAA requirement by product type and what their enforcement priorities look like.
What Are the Three Rules of HIPAA and Their Requirements?
As a digital health startup, you cannot just focus on the engineering part. Your digital health products must meet certain HIPAA requirements. Understanding how to combine compliance with engineering is how you can build a successful brand, and that journey starts here.
1. The Privacy Rule
Introduced in 1996, the Health Insurance Portability and Accountability Act (HIPAA) has set certain standards to protect medical records.
The Privacy Rule governs how PHI can be used, disclosed, and accessed. For digital health products, the practical implications are:
- Data minimization: Collect only what clinical purpose requires.
- Access limitations: This is the minimum necessary standard. RBAC will restrict users according to their authority and job function.
- Patient rights: Patients can access their records within defined timelines.
- Restrictions on disclosure: Without proper authorization, you cannot disclose PHI to other parties.
For EHR platforms specifically, the Right of Access provision is an active enforcement priority. OCR has run multiple enforcement waves on covered entities that fail to provide patients with timely access to their records. These Right of Access violations have constituted the majority of OCR’s financial penalties.
2. The Security Rule
The Security Rule governs ePHI through three safeguard categories: Administrative, physical, and technical safeguards.
The Security Rule does not mandate specific technologies but requires you to identify risks to ePHI in your environment, implement controls proportionate to those risks, and document both the risks and the rationale for your control decisions.
You have to understand that your 10-person healthtech startup and a 5,000-person health system operate under the same rule but with different risk profiles. The regulation does ask you to have the same controls but demands that you have controls appropriate to your risks. HIPAA compliance for startups in digital health explicitly acknowledges this structure.
3. The Breach Notification Rule
When a PHI breach occurs, HIPAA requires you to send notifications to HHS and the affected individuals within 60 days. If the breach affects 500 or more individuals, the media should also be alerted.
For Business Associates, the clock starts when the associate discovers the breach, and notification to the covered entity must happen on a timeline that allows the covered entity to meet its own 60-day obligation.
The Medusind case illustrates what happens when this obligation is treated loosely. The breach occurred in December 2023, but the notification was not sent out until January 2025, over a year later.
The class action suit that followed cost the company $5 million at the negotiation table. Thus, timely notification is not just law but also determines whether you will have to go through civil litigation beside OCR penalties.
What Are the Digital Health Products That Need to Meet HIPAA Compliance Requirements?
Any digital health products that touch PHI will have the same HIPAA burden. But the exposure to risk that a medical imaging AI system faces is different from a patient-facing website.
Since each carries a distinct set of compliance obligations under the Privacy Rule, Security Rule, and Breach Notification Rule, let us give you a product-by-product breakdown of the HIPAA compliance requirements.
1. EHR Platforms: The Highest PHI-Density Environment
What does an EHR not do? It aggregates diagnostic data, medication history, clinical notes, lab results, imaging references, billing records, and, in modern systems, it compiles AI-generated clinical documentation.
Every function the EHR performs, from chart access to API data exchange, is a potential PHI exposure surface.
If you’ve been in IT and compliance as long as me, you would know that HIPAA compliance in software development is the most demanding part for digital health. It is because every layer of the stack, from the database to the API gateway to the front-end, touches PHI.
The critical requirements for EHR are:
- Role-based access control (RBAC): RBAC is the minimum necessary standard. Every user’s access to PHI must be limited to what their clinical or administrative role requires. A billing administrator has no need to access diagnostic notes.
- Audit logging: Every access to a patient record must be logged with user identity, timestamp, and the data accessed. Audit logs must be stored and protected against alteration.
- API security: Each API endpoint that exposes ePHI must be authenticated, authorized, and monitored. Improperly secured FHIR APIs are a growing attack surface.
- Encryption: ePHI must be encrypted at rest and in transit, and is a non-negotiable requirement. Unencrypted ePHI on compromised servers has been the cause of some of the sector’s largest penalties.
- Business Associate chain management: Every downstream vendor receiving EHR data, be it analytics platforms or billing services, requires a signed Business Associate Agreement. Cloud provider BAAs cover infrastructure layers only, not the application layer. The EHR vendor needs its own agreement with each service it connects to.
It’s not that difficult to find that the EHR providers are already on the OCR’s list of cases investigated.
One Massachusetts-based Business Associate named Elgon Information Systems that provides cloud EHR and billing support services experienced a ransomware attack that exposed approximately 31,248 patients, resulting in an $80,000 settlement.
What did OCR find? A lack of thorough and proper risk analysis.
As of 2025, OCR has made risk analysis the centerpiece of its 2025 enforcement efforts. Seven enforcement actions in the first six months of last year were tied to failure to perform comprehensive risk analyses. This is where EHR providers should look at.
2. Medical Imaging Software: The FDA Intersection
Medical imaging, such as PACS systems, radiology AI, and diagnostic imaging platforms, presents a distinct compliance profile. These systems process highly sensitive diagnostic ePHI (DICOM files) that are large, often stored on-premises or in hybrid environments, and increasingly connected to cloud-based AI for automated analysis.
- DICOM security: DICOM, the standard format for medical images, was not designed with security as a primary consideration. Imaging platforms must implement authentication at the DICOM node level, restrict access by role, and ensure that images in transit are encrypted. DICOM data in cloud storage must meet HIPAA encryption requirements.
- Audit trails for image access: As with EHR, every access to a patient’s imaging study must be logged. In radiology workflows where multiple physicians, radiologists, and specialists access the same images, access control and audit logging become operationally complex.
- De-identification for AI training: Medical imaging AI platforms frequently require large, annotated datasets for model training. HIPAA permits use of de-identified data without a BAA, but de-identification must meet the Safe Harbor standard.
Insufficient de-identification of imaging data, where metadata embedded in DICOM files still links to an individual, is a compliance failure.
- Business Associate obligations for cloud inference: When a medical imaging platform routes images to a cloud-based AI model for analysis, the AI provider is a Business Associate. A BAA must be in place before the first image is transmitted.
The HIPAA requirements for medical imaging software intersect with a second regulatory framework, which is FDA’s cybersecurity guidance for medical devices and SaMD. It was in 2019, that the FDA first issued a major alert about medical devices having vulnerabilities.
Based on CISA and FDA’s notices, Texas Governor Greg Abbott directed the Texas Health and Human Services Commission (HHSC) in March 2026 to review cybersecurity and procurement policies around medical devices. This came from concern about Chinese-manufactured patient monitoring devices.
In direct response to that executive action, HHSC issued a directive to healthcare facilities across Texas in March 2026, requiring them to apply FDA cybersecurity guidance for all medical devices in use. This included every network-connected device as it was otherwise deemed a cybersecurity risk.
This is significant for medical imaging and connected device environments because it creates a state-level compliance obligation that runs parallel to HIPAA. Texas healthcare organizations and their vendors are now operating under both federal HIPAA requirements and this state-level medical device security directive simultaneously.
What does the Texas HHSC directive mean for imaging device vendors in the state? It means under FDA guidance under Section 524B expects ongoing vulnerability monitoring, patch management, and coordinated disclosure will become a continuous process, not a one-time audit.
3. Medical AI Scribing Tools: The Fastest-Growing Risk Category
Ambient AI scribing tools record live conversations between healthcare personnel and patients and generate clinical notes automatically. They are the fastest-growing AI tool in healthcare.
Tools like Nuance DAX, Abridge, and Suki are being deployed across the healthcare sector, and each of those are Business Associate under HIPAA. They capture patient name, condition, treatment plan, physician reasoning, and medication details in real time.
The PHI exposure is not incidental. It is the core function of these AI tools.
Beyond the BAA, AI scribing tools introduce compliance risks that standard vendor agreements were not designed to address:
- Model training on PHI: Many AI vendors retain inputs and outputs for model training unless an enterprise agreement explicitly prohibits it. Using PHI to train or fine-tune an AI model without patient authorization violates the HIPAA Privacy Rule.
If a scribing tool’s BAA does not contain an explicit written prohibition on PHI use for model training, the vendor’s default policy applies, and that policy may permit training on patient conversations.
- Data retention: Ambient AI scribes store audio recordings and generated notes before final transcription. The BAA must specify how long PHI may be retained in vendor systems, under what conditions, and the mechanism and timeline for verified deletion.
- Subprocessor chains: An AI scribing tool likely runs on a combination of cloud infrastructure, third-party compute, and in some cases third-party inference APIs. Each subprocessor that handles PHI is itself a Business Associate.
The primary vendor must obtain BAAs from all downstream subcontractors. Most standard BAA templates do not address this chain adequately.
- Shadow AI: The Netskope Threat Labs Healthcare 2025 report found that 88% of healthcare organizations have integrated cloud-based generative AI tools into their operations, and 96% use tools that employ user data for training. Many of these are adopted by clinical staff without IT or compliance awareness.
Ungoverned AI tool touching PHI is, by default, a HIPAA violation. And then there is the risk of disclosure to third parties.
4: Wearable Medical Devices and Remote Patient Monitoring
Wearable medical devices are everywhere. But do you know they present a compliance challenge as well?
In wearables, PHI is generated continuously on hardware outside the direct security perimeter of a healthcare organization and transmitted over consumer networks before it reaches clinical systems.
Devices like cardiac monitors, continuous glucose monitors, or remote patient monitoring systems are subject to FDA cybersecurity requirements in addition to HIPAA. The Texas HHSC directive requires healthcare facilities to assess every device with a network function or remote access capability for cybersecurity risk. And it applies directly to networked wearables deployed by Texas hospitals.
The key HIPAA requirements for wearable medical device programs:
- Transmission security: PHI transmitted from wearables must be encrypted end-to-end. Consumer-grade Bluetooth or Wi-Fi transmission without encryption is a Security Rule violation.
- Device authentication: The receiving clinical system must be able to authenticate that PHI is coming from the authorized patient device. Devices that can be spoofed or impersonated create both a compliance and a security risk.
- Vendor BAA scope: The wearable manufacturer, the remote monitoring platform, and any data aggregation intermediary are all Business Associates if they handle PHI. Each requires a signed BAA.
The device manufacturer’s BAA typically covers device telemetry and data transmission. However, it does not extend to third-party analytics platforms that receive the same data.
- Data at rest on device: PHI stored locally on a wearable device, whether in cache, in local memory, or in onboard storage, must meet HIPAA’s encryption and access control requirements. Devices that store unencrypted PHI locally and can be physically compromised are already breaking HIPAA compliance.
5. The Enforcement Risk You May Not Know About: Website Tracking
One of the most significant HIPAA enforcement shifts in recent years has nothing to do with EHR security or ransomware. OCR collected over $9.9 million in penalties across 22 enforcement actions in 2024, and all of them were tied to hidden data flows from website tracking technologies.
The Cerebral case established the pattern. From 2019 to 2023, the mental health startup used Meta Pixel, Google Analytics, TikTok tracking, and similar tools on its patient-facing platform without a BAA with the receiving platforms.
The data transmitted included mental health self-assessment responses, appointment information, and clinical data. The company disclosed the breach only after an internal code review flagged the issue, years after the tracking had begun. By that point, 3.1 million users have been affected.
Kaiser Foundation Health Plan reported a similar breach in 2024. Tracking tools on its websites and apps had transmitted member information to Microsoft, Google, and X. The incident affected 13.4 million individuals and represents the largest confirmed healthcare data breach involving website tracking technologies.
OCR has said the failure happened in monitoring client-side scripts and tagged the incidents as willful neglect under Tier 4, which is the most serious penalty classification. Tier 4 violations carry penalties up to $2,134,831 per violation category per year.
So, what are the practical requirements? Every tracking technology on a patient-facing web property must be audited to check whether they’re transmitting PHI transmission. And if they are, they must have a BAA or be removed.
What Measures Should Healthcare Startups Take to Be HIPAA Compliant?
For digital health startups navigating HIPAA compliance requirements for the first time or simply rehashing their processes, the challenge is not knowing where to start. The following measures reflect what OCR is actually enforcing and not going by a checklist.
1. Conduct a Documented Risk Analysis Before You Launch
A risk analysis is the single most enforced requirement in OCR’s 2025 update. It must identify every location where ePHI is created, received, maintained, or transmitted, which includes cloud infrastructure, APIs, mobile apps, and third-party integrations.
The risk analysis must assess the likelihood and impact of threats to that data. And it must document the controls selected in response.
Startups frequently skip this step or treat a penetration test report as a substitute. A pentest identifies vulnerabilities. A risk analysis is a structured, documented assessment of threats to ePHI that drives your security program. You have to understand the difference.
2. Map Every PHI Flow, Including the Ones You Didn’t Design
Most organizations can describe how PHI moves through their workflow. Far fewer can account for all the secondary places their PHIs flow.
Cerebral’s breach, for example, was not caused by a cyberattack. It was caused by tracking pixels the company itself installed. Mapping PHI flows must cover every third-party integration, every client-side script, every API integration, and every cloud service the product touches.
3. Build Your BAA Coverage Before You Build Your Vendor Stack
A Business Associate Agreement must be in place before any vendor receives PHI. For digital health startups, the BAA checklist needs to cover cloud infrastructure providers (AWS, GCP, Azure), AI model providers (if inputs include PHI), analytics platforms, session replay tools, payment processors, billing vendors, customer support platforms, and any other service that touches patient data.
A BAA that does not prohibit model training on PHI, that does not specify data retention and deletion timelines, or that does not address subprocessor notification, is insufficient according to HIPAA’s standards.
4. Implement Technical Safeguards at the Application Layer
Running on AWS or Azure with a signed BAA does not mean your application is HIPAA compliant. Cloud provider BAAs cover infrastructure. They do not cover how your application handles PHI once it arrives in that infrastructure.
HIPAA compliant software development requires access controls, audit logging, transmission encryption, and integrity controls to be implemented in the code, not just in the cloud configuration.
This distinction matters for EHR platforms that assume the compliance extends to the application. It matters for medical imaging platforms routing DICOM files through cloud AI inference and for ambient scribing tools that store audio before transcription.
In every case, the application layer is where the HIPAA software requirements must be implemented by the vendor.
5. Audit Your Patient-Facing Web Properties
Any page where a patient enters health information, selects a condition, books an appointment, or views clinical content is a regulated surface. Every tracking script, analytics pixel, and third-party tag on those pages must be reviewed. If the receiving platform does not have a signed BAA, the tool must be removed or configured to block PHI transmission before it fires.
This applies to appointment booking pages, telehealth intake forms, prescription refill workflows, patient portals, and condition-specific landing pages. The practical starting point: a full inventory of every third-party script loading on patient-facing pages, with a classification of what data each script receives and whether a BAA is in place.
6. Design Breach Response Before a Breach Occurs
The Medusind case illustrates the cost of an inadequate breach response. The breach was discovered in December 2023. Notification letters went out in January 2025. The gap exposed the company to class action litigation that settled for $5 million.
HIPAA requires notification to affected individuals and HHS within 60 days of breach discovery. Healthtechs should invest in a breach response plan and give ownership to selected individuals.
7. Training Your Workforce
Workforce training is an administrative safeguard under HIPAA and a documented requirement. For digital health startups, it extends beyond security engineers to clinical staff using AI scribing tools who may not understand PHI handling obligations.
Training must be documented and not treated as a one-time exercise.
OCR does not require perfection. It requires that you identified your risks, made reasonable decisions about controls, documented your reasoning, and can demonstrate all of this if investigated.
The organizations that face the largest penalties are those that cannot prove the above controls.
How Can KLEAP Help?
KLEAP is here to serve those venturing into the healthcare sector. We work with digital health platforms, EHR vendors, healthtech startups, and healthcare organizations to close the gap between a compliance posture that looks right on paper and one that would survive OCR scrutiny.
Our engagements are manual and evidence based. It means we do not provide you with automated scan reports repackaged as compliance deliverables.
Not to mention, our concierge model promises to stay with you every step of the way, from start to finish. Every HIPAA compliance assessment we conduct is driven by a dedicated expert who understands the specific PHI flows, architecture, and regulatory obligations of your product category. This includes HIPAA compliance for SaaS vendors.
The digital health compliance environment in 2025 is not static. OCR is running active enforcement initiatives. Texas has issued state-level medical device security directives. A revised Security Rule will soon be enforced.
The question that matters is not whether you’re compliant. It’s whether you can demonstrate compliance with documented evidence if OCR investigates. Everything from your risk analysis, BAA coverage, and website tracking stack to your response plans should be in documentation. And we can help you get there.
If you’re building or deploying in digital health and want to understand where your current posture stands, that’s where we’ll start the conversation.
