Healthcare Software Development: What Compliance Actually Requires

A founder says, "We just need to make it HIPAA compliant", as if compliance were a plugin you install before launch. Then the first architecture call starts, and the real question surfaces: compliant with what, exactly?

Healthcare software compliance is not one rule. It is a stack: HIPAA's Privacy, Security, and Breach Notification Rules for patient data, FDA rules if the software acts like a medical device, interoperability rules under the 21st Century Cures Act, and state laws on top. Which ones apply depends on what your software does and whose data it touches.

The stack at a glance:

• HIPAA protects patient data
• FDA rules cover software with a medical purpose
• Cures Act rules govern data access and exchange
• State and international laws add privacy duties
• Contracts called BAAs carry the rules to every vendor

This guide is general information, not legal advice. Here is how each layer works.

What Is Healthcare Software Development, and Why Is Compliance Different Here?

Healthcare software development is the design, build, and maintenance of software used in care delivery or healthcare operations, such as patient portals, telehealth, EHR integrations, scheduling, billing, and remote monitoring, with security and regulatory requirements built into the architecture from the start.

Other industries have rules too, but healthcare adds three pressures at once. The data is deeply personal and stays sensitive for life. Mistakes can affect patient safety, not just revenue. And your customers are regulated organizations that will question you about safeguards, document your answers, and audit your vendors. A vague answer on a security questionnaire can stall a contract as surely as a bug can. That is why healthcare software development rewards teams that settle compliance questions in the first architecture diagram instead of the last sprint.

Which Compliance Rules Apply to Your Healthcare Software?

Start with five questions:

1. Does the software create, receive, store, or transmit protected health information (PHI) for a covered entity or business associate?
2. Does it diagnose, treat, or drive a clinical decision?
3. Does it exchange records with EHRs or other health IT?
4. Does it handle substance use disorder treatment records?
5. Where do the users live, in which states or countries?

Your answers point to the rules below.

Three quick, hypothetical examples show how this works. A clinic's patient portal almost certainly involves HIPAA and interoperability and probably not FDA review. A symptom checker that suggests a diagnosis raises FDA questions right away, plus HIPAA if it connects to a provider. A step counter with no provider involved may sit outside HIPAA, though state and FTC rules can still apply.

Neither HIPAA nor FDA oversight applies automatically. Applicability depends on the role you play and the function you perform, which is why a short classification exercise at the start saves so much rework.

What Does HIPAA Actually Require From Software?

HIPAA is really three rules working together. The Privacy Rule limits how PHI may be used and disclosed, applies a "minimum necessary" idea, and gives patients rights of access. The HIPAA Security Rule sets safeguards for electronic PHI in three groups: administrative, physical, and technical. The Breach Notification Rule says affected individuals must be told without unreasonable delay, and no later than 60 days after discovery, with larger breaches also reported to HHS and the media.

In software terms, the Privacy Rule means supporting patient access and export requests, tracking certain disclosures, and enforcing role limits so staff see only what their job requires.

One distinction trips people up. Security rule specifications are either "required" or "addressable". Addressable does not mean optional. It means you either implement the safeguard or document why an equivalent measure is reasonable for your situation.

What Do the Technical Safeguards Mean in Code?

The Security Rule's technical standards are short. Turning them into engineering decisions is the hard part.

Encryption deserves a closer look. Encrypting the database is not enough if backups, file storage, message queues, and exports are left open. Manage keys separately from the data they protect, rotate them, and restrict who can use them. Session timeouts need judgment too: short enough to protect a shared workstation, but not so short that busy clinicians start sharing passwords to avoid constant logins.

Three habits matter more than the table suggests. First, keep PHI out of the places it leaks into, such as logs, analytics tools, error trackers, and support tickets. Second, use synthetic or de-identified data in development and testing, never a copy of production. Third, log successful access as well as failures. Audit logging is the control team's most often underfunded, and log volume grows quickly as users do, so plan retention and storage early.

Which Administrative and Physical Safeguards Touch Your Software Team?

Plenty of HIPAA work happens outside the codebase, and developers are part of it. Start with a documented risk analysis and a plan to manage the risks it finds. OCR has repeatedly pointed to risk analysis as the gap it cites most often. Add a named security officer, written policies, workforce training, and a clear process for granting and removing access as people join or leave.

Training matters for developers as well as clinicians. An engineer who understands why a stack trace full of patient details counts as a breach is less likely to ship one.

Plan for contingencies, too. That means backups you have actually restored in a test and an incident response runbook that someone has read. Keep required documentation for six years.

Physical safeguards cover facilities, workstations, and devices. With cloud hosting, responsibility is shared: the provider secures its data centers, while you secure how the service is configured and used. If you want a partner that builds these safeguards in from the first diagram, see how HIPAA-compliant development works. Engineers support your compliance officer or counsel here; they do not replace them.

Is There Such a Thing as HIPAA Certification?

No. There is no official HHS certification for software or companies. A vendor selling a "HIPAA certificate" is selling a badge, not a legal status.

What exists instead is evidence: a documented risk analysis, implemented safeguards, signed business associate agreements, and records you can produce when someone asks. Voluntary attestations such as SOC 2 and HITRUST are real, and enterprise buyers increasingly request them, but they do not confer HIPAA status. Treat a "HIPAA certified" claim the way you would treat a guaranteed search ranking: with suspicion.

What Is a BAA, and Who in Your Software Chain Needs One?

A business associate agreement (BAA) is the contract that sets how a vendor may use and protect PHI on your behalf. Any vendor that creates, receives, maintains, or transmits PHI for you generally needs one. Think beyond hosting. Email and SMS services, video tools, monitoring and error-reporting platforms, analytics, support software, and AI services all count if PHI can reach them.

The chain runs downward. Your developer needs BAAs with its own subcontractors, and they need them with theirs. A BAA typically covers permitted uses, required safeguards, breach reporting duties, subcontractor terms, and what happens to the data at the end.

It also helps to be clear about what a BAA is not. A cloud provider signing one does not make your application compliant, because you still configure and operate the service. And a BAA does not excuse sloppy habits, such as pasting patient details into a support ticket.

Ask your own developer three things: which subcontractors will touch PHI, whether each one has a BAA in place, and where the data will be hosted. Then keep a simple inventory of every service that can touch PHI, with its BAA status and an owner. Raydiant describes its wider approach on its security page, and it signs a BAA before any PHI reaches a system it builds or operates.

When Does Healthcare Software Become a Medical Device?

Intended use is the test. Software that diagnoses, treats, or drives a clinical decision may be regulated by the FDA as a device, often called software as a medical device (SaMD). Administrative tools, plain record storage, and general wellness features frequently sit outside device regulation, though the details matter.

Intended use comes from how a product is described and marketed, not only from what the code does. A feature pitched to customers as detecting a condition will be judged by that claim.

Decision support is the gray zone. In January 2026, the FDA issued final guidance on clinical decision support software and reissued it on January 29. It explains when a function can qualify for the statutory non-device exclusion. In plain language, the software must not analyze medical images or signals, must display or analyze medical information, must support a clinician rather than replace their judgment, and must let the clinician independently review the basis for any recommendation. Miss one condition and the function may be a device.

If your software is a device, expect a risk classification, a premarket route (510(k), De Novo, or PMA, depending on risk), design controls, risk management, and cybersecurity expectations. The FDA's Quality Management System Regulation took effect on February 2, 2026, aligning 21 CFR Part 820 with ISO 13485. Teams commonly use IEC 62304 for the software lifecycle and ISO 14971 for risk management.

The practical advice is simple: classify before you build. Learning in month six that a feature is SaMD is an expensive surprise, and regulatory counsel can help you settle the question early.

What Do Interoperability Rules Require?

The 21st Century Cures Act and its implementing rules push health data toward open, standards-based access. The headline concept is information blocking. Practices that interfere with the access, exchange, or use of electronic health information are prohibited for defined actors, with limited exceptions such as privacy, security, and infeasibility. Check whether you, or your customers, count as an actor, because the answer shapes what they will ask of your software.

On the technical side, three routes dominate. HL7 v2 messages are old but everywhere. The HL7 FHIR standard is the modern, API-based option and the usual target for new work. File exchange remains a fallback when the other two are closed. SMART on FHIR is commonly used to authorize apps.

Patients also have a right to access their health information, and slow or costly access can create information blocking risk. Build export and API access in from the start rather than as a favor later.

The hard part is rarely code. Vendor sandboxes, app review processes, rate limits, and licensing terms take calendar time, so ask for access during discovery. Then test against real message samples and awkward cases: a patient who changes name, a result that arrives twice, an appointment canceled after it was invoiced. Budget quietly for terminology mapping to SNOMED CT, LOINC, and ICD-10, and for parsing C-CDA documents.

Which State and International Laws Add to the Pile?

HIPAA is a floor, not a ceiling. Some state laws reach further. California's Confidentiality of Medical Information Act and Washington's My Health My Data Act are two examples, and the second covers consumer health data that HIPAA may not. Confirm which laws apply in the states you serve.

42 CFR Part 2 adds stricter consent and disclosure rules for substance use disorder treatment records. HHS aligned it more closely with HIPAA, with a compliance date of February 16, 2026, but the extra controls remain.

If you process data about people in the EU, GDPR applies, and data residency becomes a design decision rather than an afterthought. Consumer health apps outside HIPAA may fall under the FTC's Health Breach Notification Rule.

Because these laws change often, treat this list as a starting point and ask counsel to confirm the current picture for your states.

The takeaway: HIPAA compliance does not equal GDPR compliance, and FDA clearance does not settle your interoperability duties.

What Is Still Proposed? The HIPAA Security Rule Update

In January 2025, HHS published a proposed rule to overhaul the Security Rule. It is proposed, not final. The current rule stays in force, and OCR keeps enforcing it.

If adopted as proposed, it would end the split between required and addressable specifications and make safeguards such as encryption and multi-factor authentication explicit. It would also add asset inventories, regular vulnerability scanning, annual penetration testing, and faster restoration after an incident.

As of this writing, the timing is uncertain. HHS's regulatory agenda moved the target for final action from May 2026 to about July 2027, and separate Privacy Rule changes were listed for August 2026, so check the current status before relying on either date.

Waiting for certainty carries its own risk, because OCR already enforces the current rule and customers already ask for these controls in security reviews.

Should you build to the proposal now? Many teams do, because it describes what reasonable security looks like in 2026. Just do not describe it as current law, and expect to revisit your documentation when a final rule arrives.

How Do You Build Compliance Into the Development Lifecycle?

Compliance decisions made late cost the most. Retrofitting access control, audit trails, and data residency after a security review can stretch a short project into a long one. Here is what to do at each phase.

Discovery deserves special attention. The PHI data map, a diagram of where patient data enters, moves, rests, and leaves, drives almost every later decision, from the role model to which vendors need BAAs. Teams that skip it tend to find unplanned data flows during a security review, when changing them is slow and expensive.

Enforce the same safeguards in every environment, not only production. A staging server with real patient data and loose access is still a breach waiting to happen.

How Does AI Change Healthcare Software Compliance?

AI features inherit every rule above and add a few questions. If PHI can reach an AI vendor, that vendor is a business associate, so confirm its current BAA terms. Default developer tiers often do not cover PHI, and terms change, so check before you build. Keep PHI out of prompts and logs unless the vendor and your architecture support it, and prefer de-identified data where you can.

Record who reviewed AI-generated output and what changed as a result. Decision-support features also sit close to the FDA line, so revisit your classification whenever an AI feature changes what the software recommends. Plan for evaluation and change management when models update, because a model swap can alter behavior without a single line of your code changing.

Be careful with convenience tools, too. Staff pasting patient notes into a public chatbot is a very ordinary way to create an unreported disclosure, so write a clear policy and give people an approved alternative.

Finally, keep humans in the loop for anything clinical. Oversight is a safety requirement, not a courtesy.

Which Compliance Mistakes Cost Healthcare Teams the Most?

Seven mistakes show up again and again.

1. PHI in the wrong places. Logs, analytics, error trackers, and support tickets quietly collect it. Fix: scrub and test for it.
2. Real data in development. Copying production to debug is common and risky. Fix: synthetic or de-identified data only.
3. Missing BAAs. One unlisted vendor breaks the chain. Fix: keep an inventory.
4. Late audit logging. Logging only errors misses the point. Fix: design it in and log successful access.
5. Compliance as a launch gate. Rules, systems, and people change. Fix: schedule reviews and a yearly risk analysis.
6. Skipping classification. A feature turns out to be SaMD in month six. Fix: decide FDA status before building.
7. Assuming a compliant cloud makes your app compliant. The provider covers its layer, not yours. Fix: configure, document, and test your own layer.

What Does Compliance Add to Cost and Timeline?

Compliance adds senior engineering hours: access control, logging, encryption, documentation, and testing against realistic records. Scope drivers include the number of user roles, the systems you integrate with, data migration, testing depth, and hosting and residency choices. Integration access often moves the calendar more than code does.

Compliance is not a flat percentage you can add to any quote, because a simple portal and a multi-system integration carry very different review and testing loads.

Be wary of any vendor who quotes a number before understanding those drivers. For reference, Raydiant publishes a starting point of about 30,000 euros (roughly 33,000 US dollars) for a HIPAA-compliant build, with a focused first release typically taking three to five months, and its published pricing shows the full rate card.

Conclusion

Compliance is a stack, and the cheapest time to handle it is the first architecture diagram. Before you pick a vendor or a framework, write down what data your software will touch and what it is intended to do. Those two answers decide most of what follows, from the vendors you need to the rules you must plan around. Nothing in this guide replaces advice from your own compliance officer or counsel, but it should help you ask better questions of them and of any developer.

If you are planning a product in this space, the team at Raydiant Webs builds the technical safeguards into healthcare software from the start and works alongside your compliance officer or counsel. This article is general information, not legal advice.

Frequently Asked Questions