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.

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. 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.

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.

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.