Software Development
Security Services
Cloud Services
AI Services
Other Services
TechMagic Academy
HIPAA Compliance Checklist for Healthcare Software: A Founder's Guide to Getting It Right
Last updated:15 June 2026
If you build or scale a healthcare product, HIPAA affects your decisions long before launch. It runs through your architecture, your choice of vendors, and the healthcare software developers you hire to write the code. Founders who treat it as a final legal review tend to pay for that later.
Healthcare companies that missed this faced serious financial consequences. In 2025, the largest HIPAA settlement reached $3 million, paid by a national medical supplier after a phishing attack exposed patient data. What OCR penalized was not the breach alone. The company had never run a proper risk analysis, so it had no way to catch the weakness attackers used. They paid millions for work they failed to do in advance.
Most founders never write a line of HIPAA-compliant code themselves. They hire a team and trust the result. The job, then, is knowing what to verify. This guide gives you that. It covers what to check in your dev partner and what to audit in your own product, so HIPAA compliance for software development becomes something you confirm rather than assume.
Key Takeaways
- HIPAA affects your product from the first design decision, long before launch.
- Founders rarely build compliance themselves, so a software HIPAA compliance checklist helps you check your dev partner's work.
- A signed BAA should be in place before any partner handles patient data.
- Encryption, access controls, and MFA are the minimum, and the proposed Security Rule update would make them mandatory.
- A risk assessment is ongoing work that needs repeating as the product changes.
- AI can handle patient data only under a signed BAA, which puts consumer tools like the ChatGPT app off limits.
What Is HIPAA Compliance?
HIPAA compliance means following the Health Insurance Portability and Accountability Act (HIPAA), the federal law that protects patient health information, known as PHI. PHI is individually identifiable health information, meaning any health data that can identify a person. That includes names, diagnoses, treatment records, billing details, and anything else tied to an individual's care. The HIPAA rules set requirements across privacy, security, and breach response.
For a healthcare product, compliance is ongoing work that continues well past launch day. It covers security measures like data encryption, access controls, risk assessments, employee training, data breach reporting, and the documentation that proves all of it.
What is included in PHI
That makes maintaining HIPAA compliance software development a continuous responsibility rather than a one-time setup. A specialist healthcare cybersecurity services partner can help you build these safeguards and maintain compliance over time.
The penalties for HIPAA violations are real and recurring. In 2023, L.A. Care Health Plan was fined $1.3 million after weak safeguards and poor activity monitoring exposed patient records. OCR, the HHS Office for Civil Rights, hands out penalties like this every year.
Who Has to Be HIPAA-Compliant?
HIPAA applies to two groups, defined by the U.S. Department of Health and Human Services: covered entities and business associates. Knowing whether you are a covered entity or business associate tells you exactly what you are responsible for. If you build healthcare software, you almost always fall into the second group.
Covered entities are the organizations that deliver care, insure it, or process its data. They create and hold PHI directly. Under HIPAA, covered entities are divided into three types:
- Healthcare providers: doctors, clinics, dentists, psychologists, nursing homes, pharmacies
- Health plans: insurers, HMOs, employer-sponsored plans, government programs like Medicare
- Healthcare clearinghouses: the intermediaries that route billing and claims data between healthcare organizations and plans
A HIPAA business associate is a vendor or partner that handles PHI on a covered entity's behalf. You never treat a patient, but you touch their data, so HIPAA binds you all the same. Most software vendors in healthcare sit here:
- Software and SaaS providers
- EHR and EMR platforms
- Cloud and data storage providers
- Analytics, billing, and IT service vendors
- Legal, accounting, and consulting firms
If you sell a product or service that processes PHI, you are a business associate. Every entity or business associate that handles PHI carries this duty, and it starts the moment a covered entity shares data with you.
Learn about our expertise in the industry and what we have to offer
HIPAA Compliance Checklist for Healthcare Software Founders
You will not write HIPAA-compliant code yourself. You will hire a team and inherit the result, including the liability. So your real job is verification. No agency hands out a badge for certified HIPAA compliance, so the proof sits in your controls and documentation. This full HIPAA compliance checklist for software development gives you a practical set of questions to bring into any conversation with a dev partner, or to audit a product already in production.
Healthcare has been the costliest sector for data breaches for 14 years running, at an average of $7.42 million per incident in 2025, so getting these wrong carries a real price.
Ask your dev partner the following questions, and treat anything vague or evasive as a warning sign.
Does your dev partner understand BAA obligations?
A Business Associate Agreement is a legal contract, not a formality you sign to feel covered. It binds your dev partner to the same HIPAA standards you carry and defines how they protect, use, and report on PHI. You need a signed BAA before the partner touches a single patient record, as a core part of your due diligence process. A solid one spells out the permitted uses of PHI, requires breach notification within set timelines, mandates safeguards like encryption, requires the partner to implement procedures for incidents, and says what happens to the data when the contract ends. If a partner hesitates, or asks what a BAA is, stop there. They are not ready to handle sensitive data.
Is PHI encrypted at rest and in transit?
Encryption protects data in two states: when it sits in storage, and when it moves between systems. You do not need to follow the cryptography. You need clear answers to two questions. Ask your team whether all patient data is encrypted at rest, and which standard they use. Then ask whether data is encrypted in transit everywhere, including between internal services. A confident answer sounds like "AES-256 at rest, TLS 1.2 or higher in transit." A vague answer, or "we'll get to it," points to a gap you should not ship with.
Are access controls and MFA in place?
Multi-factor authentication is not yet federally required, but OCR already expects it, and the proposed Security Rule update would make it firm. Treat it as the baseline. Role-based access controls limit access so each person sees only the data their role requires, and nothing more. Ask your team three things. How many people can reach PHI, and why does each one need to? Is MFA enforced on every account that touches patient data? Do audit logs record who viewed or changed what, and when? Broad access or thin logging is a problem worth closing before launch.
Has your team conducted a HIPAA risk assessment?
A HIPAA risk assessment is not a form you sign once a year. It is risk management in practice: an ongoing process of finding weaknesses in how your product handles PHI, fixing them, and documenting both as part of your compliance efforts. This carries weight because a missing or stale risk analysis is the most common finding in OCR enforcement actions. Ask when the last assessment ran, who performed it, what it found, and what got fixed as a result. "We did one at launch" does not pass. Your product changes and the threats change, so the assessment has to keep pace.
Do you have a breach notification plan?
If patient data is exposed, the clock starts at once, and the rules are specific. The HIPAA Breach Notification Rule requires you to notify affected individuals without unreasonable delay and no later than 60 days after discovery. If a breach affects 500 or more people, you also notify HHS and alert prominent media in the affected area inside that same 60-day window. Smaller breaches can be reported to HHS annually. The business question is ownership. Know exactly who, on your team or your partner's, owns detection, who must report security incidents, and who handles notification and documentation, and confirm a written plan exists before you ever need it.
Is your cloud infrastructure HIPAA-eligible?
A HIPAA-compliant cloud provider does not make every one of its services safe for PHI. AWS, Microsoft Azure, and Google Cloud each publish a specific list of HIPAA-eligible services, and only those fall under the provider's BAA. A team can build on AWS and still place patient data in a service that was never approved for it. Confirm two things: that your partner has signed a BAA with the cloud provider, and that every service touching PHI appears on that provider's eligible list. For a closer look at building on one major platform, see our guide to AWS for healthcare.
Are third-party integrations vetted for HIPAA compliance?
This is the gap teams miss most often. Analytics scripts, marketing pixels, chat widgets, and third-party APIs can quietly send patient data to companies that never signed a BAA. Tracking pixels on patient-facing pages have already triggered major settlements and class actions across the industry. Every tool is a potential leak. Ask your team for a complete list of every third-party integration in the product. For each one, you need a clear answer: either it never touches PHI, or a signed BAA covers it. Anything that fails both tests has to go.
Is AI used in your product, and is it HIPAA-compliant?
AI raises one specific question: does the model ever see patient data? Consumer tools like the ChatGPT app or personal Gemini are off-limits for PHI, with no exceptions. The good news is that the major providers offer compliant paths. OpenAI will sign a BAA for its API on zero-retention endpoints, Microsoft offers Azure OpenAI under a BAA, and Google covers Gemini through Vertex AI. Self-hosted models are another route. There is also a cleaner design: build the product so AI never touches PHI in the first place. That is the approach we took with Tiro.Health, where the AI does its work without interacting with patient data. For the full set of options, see our guide to HIPAA-compliant LLMs.
HIPAA Compliance in Our Projects: Two TechMagic Builds
The checklist above describes what good looks like. Here is how HIPAA compliant software development plays out in two products we built, each with its own compliance challenges.
Early cancer detection platform. We built this preventive care product on Medplum, a FHIR-native backend that ships with the compliance primitives the checklist calls for: audit logging, role-based access, and secure data access patterns. Patients book screenings, view their records, and meet doctors over Zoom, while role-based dashboards keep each user inside their own data. Multi-factor authentication was part of the build from day one. During development, the team worked with synthetic and anonymized data, so real PHI was never exposed in non-production environments.
EMR portal for MHC HealthCare. MHC treats personal injury patients and shares records with attorneys, so a clean audit trail was non-negotiable. We isolated the audit process from core services and logged every change: who modified what, and when. The platform runs on AWS using HIPAA-eligible services under a signed BAA, with encryption and role-based access delivering the kind of data security the rules demand.
Both products answer the same questions we just told you to ask: who can reach PHI, how it is encrypted, whether access is logged, and whether the infrastructure is genuinely eligible to hold patient data. That is the line between a product that claims compliance and one that can prove it.
HIPAA-compliant portal for secure medical data records and exchange
HIPAA Privacy Rule
The Privacy Rule controls who may access, use, and share PHI, so any entity seeking access needs a permitted reason, and it gives patients real rights over their own data: the right to see it, get a copy, and learn who it has been shared with. For a founder, this lands as a product requirement. Your software has to enforce those limits in code, backed by HIPAA-compliant policies, log disclosures, and let patients access or export their records on request. Many teams name a HIPAA privacy officer to own these obligations. One point teams miss is scope. The Privacy Rule covers PHI in every form, not only electronic data, so paper printouts and spoken disclosures count too.
The Privacy Rule break example:
After a theft of a laptop containing ePHI of 1,391 individuals from an employee vehicle, a wireless health service provider had to pay $2.5 million to address suspected HIPAA Privacy Rules breaches. At the time of the theft, there was an insufficient risk analysis procedure and inadequate management systems, according to the inquiry. Furthermore, the HIPAA Privacy Rule policies and procedures were in a draft form. The organization failed to develop clear and effective policies and procedures for safeguarding ePHI.
HIPAA Security Rule
The Security Rule is the one that matters most while you build software. It governs ePHI, or electronic protected health information, meaning patient data in electronic form, and requires you to implement safeguards that protect its confidentiality, integrity, and availability: the right people can reach the data, no one else can, it cannot be tampered with, and it is there when needed.
The rule sorts its requirements into three types of safeguards:
Administrative safeguards cover policies and people. Verify there is a named HIPAA security officer responsible for the program, documented policies and procedures, a current risk analysis, regular workforce training, and a clear process for granting and removing access as people join or leave.
Physical safeguards cover the hardware and facilities that hold PHI. For a software product that mostly means your partner's cloud regions and company devices. Verify where PHI lives and that access to those systems is controlled.
Technical safeguards are the security controls inside the software: access controls, unique user IDs, encryption, and audit controls that log who touched what. Verify each one is active, not just named in a design doc.
The HIPAA Security Rule update founders should watch
In January 2025, OCR proposed the first major overhaul of the HIPAA Security Rule since 2013. It is still only a proposal and has not become law. As of mid-2026 there is no final version, and the timeline could shift. Even so, the direction is clear, and strong teams are building toward it now.
The key change is structural. The rule would erase the line between "required" and "addressable" safeguards, which for years let teams skip a control if they documented a reason. The proposal makes almost every safeguard mandatory, and turns multi-factor authentication and encryption of patient data, at rest and in transit, into firm requirements.
The business read is simple. If your product is live, close MFA and encryption gaps now, since OCR expects both even today. If it is in development, build them in from the start. And if a dev partner treats "addressable" specs as optional, take it as a warning sign. OCR also weighs whether you had recognized security practices in place when it sets civil monetary penalties, so building toward the proposal can work in your favor.
The Security Rule break example:
The OCR examined a health insurance company after hackers accessed the PHI of roughly 10.5 million people. The hackers accessed the provider computer system with a phishing email containing malware. The malware provided the organization with access to ePHI and stayed undiscovered for 9 months.
The corporation was penalized $6.85 million by the OCR for breaching the HIPAA Security Rule.
A multi-state case was also resolved for $10 million, as was a class action lawsuit for $74 million.
HIPAA Omnibus Rule
The Omnibus Rule closed a gap. Before it, business associates sat largely outside direct HIPAA enforcement. The 2013 update made them, and their subcontractors, directly liable for protecting PHI. For a founder, the effect is that liability flows down the chain. You answer for your own handling of patient data and for every partner and subcontractor who touches it. That is exactly why vetting your dev partner, and asking who they work with, is your responsibility.
The Omnibus Rule break example:
The city of New Haven reported a patient data breach after a terminated employee used their login credentials to access a work computer and transfer ePHI data onto a USB drive.
According to OCR, the city failed to protect HIPAA omnibus rule in various ways. At the time of their termination, the city had not deactivated the former employee login credentials. Employees were also not provided individual login passwords to track their system activities and contacts with ePHI.
In addition, the company failed to conduct a risk assessment to identify possible risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. As a result, the city committed to a remedial action plan and paid over $200,000 in financial penalties.
The lesson is concrete. Offboarding is a compliance control. The moment someone leaves your team or your partner's, their access to patient data has to end with them.
HIPAA Breach Notification Rule
The Breach Notification Rule assumes no system is fully secure, so it sets the steps you must take once patient data is exposed. The Breach Notification requirements define what counts as a breach and what you owe affected patients when one happens.
The Breach Notification Rule break example:
A specialist clinic had to pay $150,000 to address suspected HIPAA breaches. An unencrypted thumb drive containing the ePHI of around 2,200 people was taken from the car of a clinic employee.
The inquiry discovered that, as part of its security management approach, the clinic had not properly or completely examined the possible threats and vulnerabilities to the confidentiality of ePHI.
In addition, the clinic failed to meet the Breach Notification Rule requirements for documented rules and procedures and personnel training.
Here is what the rule requires. You must notify affected individuals in writing without unreasonable delay and no later than 60 days after discovering a breach. If the breach affects 500 or more people, you must also notify HHS and alert prominent media in the affected area within that same 60 days. Breaches under 500 people are logged and reported to HHS once a year. Know in advance who owns each step, because the 60-day clock does not wait for you to assign responsibility.
We'll be pleased to assits
Summing Up: What to Do Next
If you are choosing a dev partner, take this HIPAA compliance requirements checklist into the conversation and start with the BAA, encryption, and access questions. The answers tell you quickly whether the team works to current standards.
If your product is already live, run a quick HIPAA audit of two things first: who can reach PHI, and whether every third-party tool and AI service has a BAA behind it.
And when you want a partner experienced in HIPAA software development who builds compliance into the architecture from day one, talk to us. We will answer your questions and help you find the gaps before they become problems.
HIPAA compliance resources
As HIPAA regulations evolve, it helps to track them at the source. These are reliable references for monitoring HIPAA compliance updates in 2026:
- Official HHS CSC HIPAA Website
- Calculated HIPAA
- Center for Disease Control
- FAQs about the Disposal of Protected Health Information
- Business Associate Contracts and Business Associates FAQs
- Privacy, Security, and HIPAA
- Security Rule Guidance Material
- Special Topics in Health Information Privacy
FAQ
Make each item a question for your team or dev partner, and ask for evidence, not assurances. Every "yes" should be backed by something you can see, like a signed BAA or an audit log.
Your software needs to be HIPAA compliant if it stores, processes, or transmits PHI for a healthcare provider, health plan, or their vendors. If patient data passes through your product, HIPAA applies.
Ask whether they will sign a BAA, how they encrypt PHI, and how they manage access and MFA. A clear HIPAA compliance software checklist turns each answer into something you can verify.
Yes, if the AI processes patient data without a BAA. Consumer tools like the ChatGPT app cannot handle PHI, but OpenAI, Azure OpenAI, and Google offer HIPAA-eligible options under a signed BAA.
