HIPAA matters to a product manager when a feature creates, receives, stores or transmits protected health information on behalf of a covered entity. In that case your company is likely a business associate. The practical job is to mark which features touch PHI, limit them, and plan the contracts before launch.
Who does HIPAA apply to?
HIPAA's Security Rule applies to covered entities (health plans, clearinghouses and most providers) and to their business associates, the vendors that handle electronic PHI for them. Software companies usually land in the second group. The rule text in 45 CFR 164.312 speaks to "a covered entity or business associate", so both carry technical safeguard duties.
Whether you are a business associate depends on facts and contracts, so ask counsel. A PM should still draw the boundary on the product map.
Which features are in scope?
A constructed example for a scheduling app that serves clinics:
- Appointment booking with a reason for visit: PHI, because it ties a person to care.
- Reminder emails and texts naming the clinic or provider: possibly PHI, depending on content.
- Support chat where users paste screenshots of records: PHI arrives by accident.
- Analytics events that include patient IDs: PHI flows to a third party.
- Usage dashboards with aggregated counts only: usually out of scope, but check the aggregation.
Walk each feature and ask what data it holds, where it goes and which vendors see it.
What do the technical safeguards require?
The Security Rule's technical safeguards in 164.312 cover access control with unique user IDs, emergency access, audit controls that record activity, integrity protection, person or entity authentication and transmission security. Some items are labelled "required" and others "addressable". Addressable does not mean optional: you implement it, or document an equivalent measure and why.
As a PM, those headings turn into product requirements: distinct logins per user, session timeout, an audit trail users can see, encryption in transit and at rest, and a way to reach data in an emergency.
What decisions belong to product?
- Data minimisation. Do not collect a diagnosis field if the workflow works without it.
- Defaults. Notifications should carry the least detail by default.
- Logging. Decide what the audit trail records and who can read it.
- Third parties. Every SDK or tool that receives PHI needs a business associate agreement or must be kept away from it.
- Customer controls. Admins need roles and the ability to remove access quickly.
- Retention and deletion. Define how long data stays and how a customer exports or erases it.
How do you keep the scope from growing?
Scope creeps through convenience. A developer pastes a record into a ticket, a sales engineer loads real data into a demo, an export lands in a shared drive. Add a short rule to your definition of done: no feature ships if it adds PHI to a system that is not on the approved list. Review the list whenever a new vendor or integration is proposed, and make the safe path the easy one, for example by giving support staff a redacted view of customer data so they never need the raw record.
What to do
- List features and mark each as PHI, possible PHI or none.
- Strip PHI from analytics, error reports and support tooling.
- Add acceptance criteria for access control, audit logging and encryption to relevant tickets.
- Keep a list of vendors that touch PHI and confirm agreements with legal.
- Write a short incident path: who is told, in what order, within what time.
- Review the list before every release that adds data fields.
Quick check
Is HIPAA certification a thing?
No government body certifies software as HIPAA compliant. You meet the rule's requirements and can keep evidence, and some customers ask for third party assessments such as SOC 2 or HITRUST as proof.
Are addressable safeguards optional?
No. You must implement them or document why an alternative is reasonable and put that in place.
Sources
Last reviewed: 18 October 2026.
