Healthcare software has a different risk profile from most business apps. A booking bug is an annoyance. A leak of patient information is a legal and reputational event. If you are a clinic, a health-tech founder or a company hiring an outside team to build custom healthcare software for the US market, you need to know early how HIPAA shapes the project. This guide summarises what the US Department of Health and Human Services (HHS) says in its public pages on the Security, Privacy and Breach Notification rules, then turns it into questions to settle before you write a line of code. It is general information, not legal advice.
Software that touches patient information starts with the question of who is responsible for protecting it. Photo: Vitaly Gariev on Unsplash
The short answer
HHS describes three rules that matter most to software that handles health information:
- The Security Rule establishes national standards to protect individuals' electronic protected health information created, received, used or maintained by a covered entity or its business associate. It requires appropriate administrative, physical and technical safeguards to ensure confidentiality, integrity and availability.
- The Privacy Rule protects medical records and other individually identifiable health information, sets limits on how it can be used and disclosed without authorisation, and gives individuals rights such as obtaining a copy of their records.
- The Breach Notification Rule requires covered entities and their business associates to notify affected parties after a breach of unsecured protected health information, generally no later than 60 days after discovery.
So the practical order is: work out whether HIPAA applies to you, design safeguards into the software, and have a tested breach process before launch.
Step 1: Work out whether HIPAA applies
HHS says the Privacy Rule applies to health plans, health care clearinghouses and those health care providers that conduct certain health care transactions electronically. The Security Rule covers electronic protected health information handled by a covered entity or its business associate. HHS also notes that the FTC enforces similar breach notification provisions for vendors of personal health records and their service providers.
For a software project, that raises questions you should answer in writing:
- Are you a covered entity, a business associate of one, or neither?
- Will the software create, receive, store or send identifiable health information?
- Will an outside development team, hosting provider or support vendor have access to that information?
If a vendor will handle protected health information on your behalf, HHS's wording about business associates suggests they fall within the rules, so ask a qualified adviser how that affects your contracts. We cannot decide this for you, and the answer differs between a clinic, a wellness app and a software vendor.
Step 2: Design safeguards into the build
The Security Rule's three safeguard types translate into design decisions. HHS describes the categories and not a fixed technical checklist, so the examples below are our reading of what each category typically means in software, not requirements quoted from HHS.
Administrative safeguards are about people and process: who can see data, how staff are trained, how incidents are handled and how risk is assessed. For a development project, this means defined roles, access reviews and a written incident plan.
Physical safeguards cover the places and devices where data lives. For cloud-hosted software, this mostly means choosing a hosting provider carefully and controlling the devices your team and vendors use.
Technical safeguards are the controls in the system itself. Typical examples are individual logins, role-based access, audit logs of who viewed what, encrypted storage and transmission, and automatic sign-out. HHS's breach guidance names encryption and destruction as the methods that render information unusable, unreadable or indecipherable to unauthorised persons.
HHS also points small and medium-sized practices and business associates to its Security Risk Assessment Tool, developed by ASTP/ONC and the Office for Civil Rights, which is a sensible free starting point for a first risk assessment.
Step 3: Respect the Privacy Rule in your features
The Privacy Rule sets limits and conditions on how protected health information may be used and disclosed without an individual's authorisation, and gives people rights to examine and obtain copies of their records, to have copies sent to a third party and to request corrections. For software, that shapes real features:
- Which staff roles can see which records, and why.
- How a patient requests a copy of their data and how you deliver it.
- How corrections are requested and recorded.
- What data your analytics, marketing or support tools can see. Sending identifiable health information to a third-party tool needs an explicit decision.
Build these in at design time. Retrofitting access rules and export features after launch is slower and riskier.
Step 4: Plan for a breach before you launch
The Breach Notification Rule, at 45 CFR 164.400-414, is specific about timing. According to HHS:
- Notice to affected individuals must be given without unreasonable delay and no later than 60 days after discovery of a breach, normally by first-class mail or by email if the person has agreed.
- If a breach affects more than 500 residents of a State or jurisdiction, covered entities must also notify prominent media outlets.
- If a breach affects 500 or more individuals, the Secretary must be notified within the same 60-day limit. Smaller breaches may be reported annually, no later than 60 days after the end of the calendar year in which they were discovered.
- A business associate that discovers a breach must notify the covered entity without unreasonable delay and no later than 60 days.
- Covered entities and business associates bear the burden of showing that required notifications were made or that a breach did not occur, so documentation matters. HHS also says covered entities must have written breach notification policies, train staff and apply sanctions for non-compliance.
These are only the headline points. Have a qualified adviser review the full rule for your situation. For software teams, the useful takeaway is that logs, backups and incident procedures are not optional extras: you will need to know what data was involved, who accessed it and when.
Choosing and managing a development partner
If an outside team builds or maintains your software, discuss HIPAA on the first call, not after the contract. Ask:
- Have you built software for healthcare clients, and can I speak to one?
- Who on your team will have access to protected health information, and how is that access granted and removed?
- How do you separate development, testing and production, and do you ever use real patient data for testing?
- What logging, encryption and backup practices do you follow?
- How will you tell me quickly if something goes wrong, given the 60-day business associate deadline?
- What happens to data and access when the contract ends?
Our guide to hiring Indian developers from the US covers contracts and time zones, and our mobile app security checklist covers the technical basics for app builds. If your project is a patient-facing app, see our telemedicine app guide. For the general process, read what custom software development is, or talk to us about our custom software development service.
Checklist before you commission healthcare software
- Decide in writing whether you are a covered entity, a business associate or neither, with advice from a qualified adviser.
- List every type of patient information the software will create, store or send.
- Complete a first security risk assessment, for example with the HHS Security Risk Assessment Tool.
- Define who can see which records, and build role-based access and audit logs into the design.
- Plan encryption for data in storage and in transit.
- Decide how patients will request copies of their data and corrections.
- Keep identifiable data out of analytics, marketing and support tools unless you have approved it.
- Never use real patient data in test environments unless your adviser has approved it.
- Write an incident and breach plan that fits the 60-day deadlines, and test it.
- Put data handling, access removal and breach notification duties into the development contract.
- Train staff and vendors who will touch the system.
Common mistakes to avoid
Treating HIPAA as a launch-week task. Safeguards and access rules are easier to design in than to retrofit.
Assuming the vendor handles compliance. Responsibilities sit with covered entities and business associates, so agree who does what in the contract.
Using real patient data for testing. It widens who can see sensitive information and creates avoidable risk.
Sending health data to third-party tools by default. Analytics and chat widgets can quietly receive identifiable information.
No breach drill. The 60-day clock starts at discovery, so you need to know how you would discover and respond.
Key takeaways
- HIPAA's Security Rule requires administrative, physical and technical safeguards for electronic protected health information.
- The Privacy Rule limits uses and disclosures and gives individuals rights to their records.
- Breach notices are generally due no later than 60 days after discovery, and business associates must notify covered entities within the same limit.
- Encryption and destruction are the methods HHS names for rendering information unusable, which affects whether notification is required.
- Decide early whether HIPAA applies, design safeguards in and put responsibilities in your contract.
If you are planning a healthcare product and want a development partner who will talk through safeguards from day one, see our custom software development service or talk to our team.
Sources
Last reviewed 30 October 2026. This article is general information and not legal advice or a statement that any software is HIPAA compliant. Rules change, and your obligations depend on your circumstances, so consult a qualified adviser.
