A clinic adds a wearable feed and asks whether HIPAA now applies. Health data compliance depends on role and data flow: covered providers and their vendors must meet Privacy and Security Rule standards, and agreements and risk analysis come first.
This playbook sits within our wider digital health coverage. It focuses on the misunderstandings that most often leave gaps in provider and app programs.
What health data compliance covers
Health data compliance is the work of matching legal duties to everyday controls for patient information. In the United States the anchor is HIPAA. Its Privacy Rule provides federal standards to safeguard the privacy of personal health information. It also gives patients the right to examine and copy their records and to request corrections. The HHS Office for Civil Rights (OCR) oversees compliance with those privacy requirements.
The practical starting point is a risk analysis. A thorough analysis identifies where electronic protected health information (ePHI) resides and which threats and vulnerabilities affect it. The order matters because a team cannot protect, or write a contract for, data it has not located. Electronic health records, patient portals and connected apps all count as places to look.
Common misreadings of HIPAA
Most compliance gaps come from a confident but incomplete reading of the rules, not from ignoring them. The table sets four frequent assumptions against what the guidance supports.
| Common assumption | What holds | Planning use |
|---|---|---|
| HIPAA is mainly a privacy law | The Privacy Rule sets standards and patient rights. The Security Rule separately sets standards for the confidentiality, integrity and availability of ePHI. | Assign owners for both patient-rights processes and technical safeguards. |
| Addressable safeguards are optional | Addressable specifications must be implemented through an effective alternative or the decision must be documented. | Record the reasoning for every addressable item you handle differently. |
| A vendor contract can be signed after the pilot starts | Business associate agreements (BAAs) must be executed before PHI is shared. | Make the signed BAA a gate in procurement, ahead of any data feed. |
| A risk analysis is a one-off document | It should be updated after significant changes such as EHR upgrades, new telehealth platforms or mergers. | Tie reassessment to the change calendar, not only to a yearly reminder. |
Figures and requirements summarised from the American Medical Association’s HIPAA Privacy Rule overview and Accountable’s guide to HHS HIPAA rules.
Scope is the other major source of error, especially for teams building around apps and wearables:
- Coverage follows the role, not the gadget. Healthcare providers are covered if they transmit health information electronically in connection with standard transactions. A device or app is not the test. Ask what the organisation does with the data and for whom.
- The Security Rule follows the data wherever it sits. Its standards protect ePHI, so a record held in an EHR and the same information flowing through an app both fall under the same expectations once an organisation is covered or acting for one.
- Compliance is not the vendor’s job alone. A signed BAA documents shared responsibility. The provider still needs its own safeguards, analysis and records.
What HIPAA requires of providers and their vendors
Privacy Rule duties
The Privacy Rule governs how personal health information may be used and disclosed, and it builds in patient rights. Patients can examine and copy records and ask for corrections, so a provider needs a working, documented route for those requests. HHS, through OCR, is the body that oversees these obligations, which makes the patient-request process one of the first things a complaint investigation would touch.
Security Rule safeguards
The Security Rule sets standards to ensure the confidentiality, integrity and availability of ePHI. It is organised into administrative, physical and technical safeguards. Physical safeguards include facility access controls, workstation security, and device and media controls. Those matter for clinic laptops, shared workstations and any phone that holds patient data.
Teams often stall on the word “addressable”. It does not mean optional. An addressable specification still needs action: either implement it, adopt an effective alternative, or document why. For a small practice, the documentation habit is usually the cheapest control to add and the one auditors expect to see.
A playbook for wearable and app data
Connected devices add data sources faster than policies get rewritten. The sequence below keeps the work in a defensible order.
- Map each data source. List every wearable feed, app and EHR integration that carries patient information, and note who receives it. This map becomes the input for everything else.
- Run the risk analysis on that map. Identify where ePHI lives and what threatens it, then rank the gaps and assign owners.
- Sort vendors by PHI exposure. Any vendor that will receive PHI needs a BAA in place before the first record moves.
- Encrypt the endpoints. Encrypt data at rest on laptops and mobile devices and in transit across networks. Phones and tablets running health apps deserve the same attention as servers.
- Reassess after every significant change. A new platform or integration changes the map, so the analysis needs to follow it.
Teams launching video visits should read How To Do Telehealth: A Practical Step-By-Step Guide For Patients And Clinicians (2026) – Bioconnected alongside this list, because a new telehealth platform is exactly the kind of change that should trigger a fresh analysis. Product teams building consumer-facing tools can use Mental Health App Features: The 2026 Checklist For Secure, Effective Support – Bioconnected to compare their feature set against a security-minded checklist.
Handling breaches
HHS is the federal agency responsible for enforcing HIPAA. It does so through OCR, which investigates complaints and imposes penalties. HHS also maintains the Breach Notification Portal, where reported breaches are published. For a provider or app company, that public listing means an incident can carry reputational weight beyond the investigation itself.
The practical response is a written breach playbook with named owners for each step, built from the same data map used in the risk analysis. A playbook only helps if it works under pressure, so test it annually. Fold the lessons from each test, and from any real incident, back into the risk analysis so the two documents stay consistent.
Frequently asked questions
| Question | Answer |
|---|---|
| Does de-identified data fall under the Privacy Rule? | No. De-identified information is not considered PHI and is therefore not regulated under the Privacy Rule, according to RSI Security’s beginner’s guide. Confirm that data has actually been de-identified before treating it as outside scope. |
| What does the minimum necessary standard mean? | It requires limiting PHI in uses, disclosures and requests to the minimum needed for the purpose. In practice, that means sharing only the fields a task requires, not whole records. |
| Is there a tool to help small organisations assess risk? | A Security Risk Assessment tool exists for small and mid-sized organisations. It guides users through structured questions, produces risk ratings and generates reports, as described in Accountable’s HIPAA guide. |
