Does every healthcare software need to be HIPAA compliant?

Only software that creates, receives, maintains, or transmits Protected Health Information (PHI) on behalf of a covered entity or business associate is subject to HIPAA. If your software handles patient names, diagnoses, appointment data, prescription history, or any information that could identify a patient alongside their health data, HIPAA applies. When in doubt, assume it applies — the cost of compliance is far lower than the cost of a breach.

What is a Business Associate Agreement (BAA) and why does it matter?

A BAA is a contract between a healthcare organization (covered entity) and any vendor that handles PHI on their behalf. If you're building software for a hospital, clinic, or health plan, you are a business associate and must sign a BAA. Without one, both parties are in violation of HIPAA. Every cloud service you use that touches PHI — AWS, Google Cloud, Twilio, SendGrid — must also sign a BAA with you.

How difficult is HL7 FHIR integration compared to standard REST APIs?

FHIR is a standard, not a single API. Every EHR implements it differently, with different resource support, different authentication mechanisms, and different quirks. Budget 2–4 weeks for a first FHIR integration with a specific EHR system, and expect ongoing maintenance as the EHR vendor updates their implementation. The standard helps, but it doesn't eliminate the integration complexity.

Building Healthcare Software: HIPAA, EHR Integrations, and What Most Dev Teams Get Wrong

Healthcare software is not just another vertical. The compliance requirements are real, the consequences of failure are serious, and the integration landscape is among the most complex in any industry. This guide is for engineering teams building healthtech products — what you must get right from day one, and what can be deferred.

Healthcare software breaks in ways other software doesn't. A billing bug is expensive. A healthcare billing bug violates federal law. A data breach exposes your users' most sensitive information. An integration failure with an EHR system can affect patient care decisions.

This isn't meant to scare you — it's meant to make sure you're building with the right understanding of the stakes. For a broader, less code-heavy look at the application types and compliance basics involved, see our guide on software development for healthcare.

HIPAA: what engineers actually need to know

HIPAA is a US federal regulation. It governs how Protected Health Information (PHI) is handled. If your software touches PHI, you need to understand:

What counts as PHI

PHI is any information that can identify a patient connected to their health data. This includes:

Names combined with diagnoses, appointments, or treatment history
Dates (birth dates, admission dates, procedure dates)
Geographic identifiers below state level (ZIP codes, addresses)
Phone numbers, email addresses, social security numbers
Medical record numbers, health plan beneficiary numbers
Photos, voice recordings, biometric identifiers

Practical rule: If you can answer "whose health information is this?" — it's PHI.

The Technical Safeguards requirement

HIPAA's Technical Safeguards rule requires:

Requirement	What it means in practice
Access controls	Role-based access to PHI — minimum necessary access
Audit controls	Log who accessed, created, modified, or deleted PHI and when
Integrity controls	Protect PHI from improper alteration or destruction
Transmission security	Encrypt PHI in transit (TLS 1.2+)
Authentication	Unique user identification, automatic logoff

None of these are optional. None can be "we'll add this later."

Encryption requirements

In transit: TLS 1.2 minimum, TLS 1.3 recommended
At rest: AES-256 encryption for databases and file storage containing PHI
In backups: Backups must be encrypted — an unencrypted backup of an encrypted database is a HIPAA violation
In logs: Ensure audit logs don't inadvertently contain unencrypted PHI

Business Associate Agreements

Every vendor that touches your PHI must sign a BAA. This includes:

AWS, GCP, Azure (all offer BAA-covered service tiers)
Twilio (SMS/voice with health content)
SendGrid / Mailgun (if sending PHI in emails)
Analytics platforms that receive PHI
Your own contractors and employees

Do not use the free tier of any cloud service for PHI. Free tiers typically don't offer BAAs.

Audit logging: the requirement most teams underestimate

HIPAA requires audit trails. But the requirement is broader than most teams implement.

What must be logged:

Every access to a patient record (read, not just write)
Every modification — what changed, who changed it, when
Login attempts (successful and failed)
Admin actions — permission changes, user creation, data exports
Failed access attempts

What the logs must contain:

User identifier
Action performed
Resource accessed (which patient record)
Timestamp (UTC)
Source IP or session identifier

What logs must NOT be:

Deletable by admins
Modifiable by anyone
Stored in the same database as the data they're auditing (separate, immutable log store)

Implement audit logging from day one. Retrofitting it into an existing system is expensive and error-prone.

EHR integration: HL7, FHIR, and the reality

Electronic Health Record integrations are the core of most clinical healthtech products. Much like the integration challenges in logistics and supply chain software, these connections are where most of the engineering complexity hides. The two standards you'll encounter:

HL7 v2 (the old standard, still everywhere)

HL7 v2 is a 1980s-era messaging standard still used by most hospitals. It looks like this:

MSH|^~\&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20260312||ADT^A01|MSG00001|P|2.3
EVN|A01|20260312
PID|1||12345^^^Hospital^MR||Smith^John^A||19800101|M

Reality of HL7 v2 integrations:

Every hospital implements it differently, despite the standard
Interfaces are typically managed through integration engines (Mirth Connect, Rhapsody, Azure Integration Services)
Messages arrive via MLLP (a TCP-based protocol), not HTTP
Budget for an integration engine if you're doing serious HL7 v2 work

FHIR R4 (the modern standard)

FHIR (Fast Healthcare Interoperability Resources) is REST-based, JSON/XML, and the direction the industry is moving. US federal regulations now require most EHRs to offer FHIR R4 APIs.

FHIR key resources to know:

Patient — demographic information
Observation — clinical data (vitals, lab results)
Condition — diagnoses
MedicationRequest — prescriptions
Appointment — scheduling
DiagnosticReport — lab and imaging results

What FHIR doesn't solve:

Each EHR vendor's FHIR implementation has gaps — not all resources are supported everywhere
Authentication varies (SMART on FHIR is the standard, but implementations differ)
You'll need to handle the quirks of each EHR system separately

Budget realistically: A first FHIR integration with a specific EHR typically takes 2–6 weeks, including testing in a sandbox environment.

Hunchbite Service

Custom Software Development

Production-grade software built around how your business actually works — not forced into a generic template.

Scope your build

Architecture decisions specific to healthcare

Single-tenant vs. multi-tenant

Healthcare organizations are sensitive about data co-mingling. Many enterprise health systems will require or strongly prefer single-tenant deployments (their own database, their own infrastructure). Plan your architecture to support both:

Schema-per-tenant or database-per-tenant for maximum isolation
The ability to deploy a dedicated instance for large customers
Clear data isolation guarantees you can show to a customer's security team

De-identification for analytics

If you want to use patient data for analytics, ML training, or population health insights, you need to de-identify it properly. HIPAA's Safe Harbor method requires removing 18 specific identifiers. The Expert Determination method uses statistical analysis to verify re-identification risk is sufficiently low.

Do not use raw PHI for analytics. De-identify first, then analyze.

Telehealth considerations

If your product includes video or messaging between clinicians and patients:

Video must be end-to-end encrypted
Messages containing PHI must be encrypted at rest
Recordings (if any) must be treated as PHI
Session metadata may also constitute PHI (who spoke to whom, when)

Zoom for Healthcare and similar HIPAA-compliant video platforms have BAAs available. Consumer-grade WebRTC implementations used without a BAA are not acceptable.

Testing in healthcare software

Healthcare software requires more rigorous testing than typical web applications because errors can have clinical consequences.

Never use real patient data in development or staging environments. Use FHIR test servers (HAPI FHIR) or synthetic patient generators (Synthea).
Test failure scenarios explicitly: What happens when an EHR integration fails? Does the application degrade gracefully?
Clinical logic needs unit tests. Any calculation, recommendation, or alert logic must have comprehensive test coverage.
Pen testing before launch. A security audit from a firm experienced in healthcare applications is worth the cost.

The teams that get healthtech wrong almost always treat compliance as a launch-week task instead of an architecture decision. If you want a second opinion on your design before you commit to it,

talk to a team that has shipped HIPAA-compliant products →

What to prioritize vs. defer

Non-negotiable from day one:

HTTPS everywhere
Encryption at rest for any PHI storage
Audit logging
BAA with every cloud provider touching PHI
Role-based access control

Can be iterative:

SOC 2 certification (plan for it, but Type II takes 12 months)
Full EHR integration breadth (start with one EHR, expand)
Advanced analytics (de-identify before you build)

Building a healthcare software product and want to get the compliance and architecture right from the start? Contact us — we've built HIPAA-compliant systems across telehealth, clinical operations, and patient engagement. We can help you architect it correctly the first time.