Building Healthcare Software for HIPAA-Regulated Workflows
On this page
Healthcare software for US HIPAA-regulated workflows needs a defined data scope and clear responsibility for protection. The covered entity or business associate determines its obligations, assesses risks and documents how the system is operated. The HHS Security Rule summary describes administrative, physical and technical safeguards. This guide translates that work into engineering decisions; it is not a legal determination or certification.
Map ePHI flows and responsibilities
Before selecting infrastructure, map where electronic protected health information (ePHI) is created, received, stored, transmitted, logged, backed up, and deleted. Include support tools, analytics, email, exports, and subcontractors. Name the owner of each flow and the organisation responsible for reviewing it.
Access and identity
The Security Rule includes access control and person or entity authentication standards. Design individual user identities, role and workflow permissions, account lifecycle, emergency access, and periodic access review. Decide which actions need a second check or approval. Avoid shared accounts where individual accountability is needed.
Role-based access is one implementation pattern. A single role matrix is rarely enough when access depends on patient relationship, organisation, location, or purpose. Agree on these rules with the healthcare operator and test them with realistic scenarios.
Auditability and data integrity
The Security Rule includes audit controls and integrity requirements. Record the activity needed to investigate access and changes to ePHI. Define what is logged, retention, who may view logs, and how logs are protected from alteration. Do not put unnecessary ePHI into the logs themselves.
For critical workflows, preserve the relevant before/after state, actor, time, and reason for a change. Reconcile imported records and verify that backup restoration preserves usable data. Specific log fields and storage technology should follow the system's risk analysis and operational requirements.
Encryption and transmission
Assess encryption at rest and in transit. Under the current Security Rule, encryption is an addressable implementation specification: implement it when the risk assessment finds it reasonable and appropriate. Otherwise, document the decision and use an equivalent alternative where reasonable and appropriate. If the standard is met another way, HHS allows neither measure to be implemented, with a documented rationale. This is an assessment obligation, not permission to skip protection. See the HHS encryption FAQ.
In practice, teams should identify every network hop and storage location, choose appropriate protection, manage keys separately, and test recovery. Field-level encryption can be useful for particular threats, but it is not a blanket HIPAA requirement or a substitute for access control. Likewise, one encrypted database volume does not settle the entire risk analysis.
Vendors and integrations
List every provider that creates, receives, maintains, or transmits ePHI on the organisation's behalf. Determine which relationships require a business associate agreement and verify that the contract covers the actual service and subcontractors. A cloud product's availability or security marketing alone does not establish coverage. The HHS business associate guidance explains the contractual requirements.
For EHR and other integrations, confirm the specific vendor, API access, supported standards, data scope, test environment, and ownership of failures. HL7 FHIR support in a platform does not guarantee that a requested workflow is available or approved. Plan validation, retries, reconciliation, and a safe path when the source system is unavailable.
Continuity and incident response
Define backup frequency, recovery objectives, restoration tests, alerting, escalation, and downtime procedures with the operator. A working backup is one that has been restored and checked. Incident response also needs an owner, evidence handling, and a path to legal and privacy review.
The HHS Breach Notification Rule sets different reporting routes for a breach of unsecured PHI:
- Affected individuals: the covered entity notifies them without unreasonable delay, no later than 60 days after discovery.
- HHS: the same deadline applies to 500 or more affected individuals. For fewer than 500, report within 60 days after the end of the discovery year; this does not postpone individual notice.
- Media: a breach affecting more than 500 residents of one state or jurisdiction requires notice to prominent local media without unreasonable delay and within 60 days of discovery.
- Business associates: notify the covered entity without unreasonable delay and within 60 days of discovery; the contract may require earlier notice.
Have legal and privacy owners determine whether notification is required and identify any additional obligations.
Rehearse a fictional unauthorised export. Can the team identify the records involved, the account used, the discovery time and the evidence to preserve? Assign an owner to each evidence gap. Legal and privacy owners use the findings to assess the incident and any reporting duties.
What to include in the engineering scope
Begin with a data-flow map, access matrix, integration inventory and risk register. For each safeguard, define an owner, an implementation task and evidence for acceptance: logs that support investigation, a checked restore or a completed incident exercise. When replacing a platform, include migration and reconciliation checks for clinical and operational records.
If you are planning such a system, bring the data types, users, existing tools and operational owner to a healthcare workflow discussion. We can scope the engineering work while your compliance and legal owners determine the applicable obligations.
