Service
HIPAA IT compliance
The Security Rule is less prescriptive than most people expect and more demanding than most practices realise. It does not name products. It requires that you assess your own risks, implement safeguards proportionate to them, and be able to demonstrate both. That last part is where most practices are exposed.
The requirement everything traces to
Risk analysis
repeated, not completed once
An analysis describing an environment you no longer run is evidence against you rather than for you.
The safeguards, and which are which
The Security Rule splits specifications into required and addressable. Both carry obligations. Only one of them can be satisfied by an alternative measure, and only with documentation explaining the decision.
| Safeguard | Status |
|---|---|
| Risk analysisThe foundation. Every other decision has to trace back to it, and it must be repeated, not done once | Required |
| Access controlUnique user identification, automatic logoff, emergency access procedure | Required |
| Audit controlsRecording and examining activity in systems holding protected health information | Required |
| Integrity controlsConfirming records have not been improperly altered or destroyed | Addressable |
| Transmission securityProtecting information moving across networks, in practice encryption | Addressable |
| Encryption at restNot mandatory, but declining it requires documented justification | Addressable |
| Workforce trainingDocumented, with records of who completed it and when | Required |
| Contingency planData backup, disaster recovery and emergency mode operation | Required |
| Business associate agreementsWith every vendor touching protected health information, including your IT provider | Required |
General information about the Security Rule, not legal advice. Confirm your obligations with counsel or a qualified compliance adviser.
Six gaps we find repeatedly
None of these are exotic. All of them appear in practices that believe they are compliant, usually because a vendor once said the software was.
- A risk analysis that was completed once, years ago, and never repeated after the environment changed
- Shared logins on a front desk or operatory workstation, which makes audit controls meaningless
- Imaging or practice management servers running an operating system past end of support
- Backups running but never restore tested, which fails the contingency plan requirement
- No business associate agreement with an IT provider who plainly has access to patient data
- Text messages and personal email used for anything containing patient information
Why shared logins matter more than they seem
A single front desk account used by four people is the most common finding in small practices, and it is understandable. It is faster, and the workstation is behind the desk anyway.
The problem is that it disables the audit control requirement entirely. If every record access is attributed to one account, you cannot demonstrate who viewed what, which means you cannot investigate a suspected inappropriate access and cannot answer the question a regulator will ask first after an incident.
Unique user identification is a required specification, not an addressable one. Fixing it is mostly a workflow and licensing exercise rather than a technical one, and it is usually the highest value single change available in a practice environment.
Common questions
Answered before you ask.
Does addressable mean optional?
No, and this is the most common misreading of the Security Rule. Addressable means you must assess whether the safeguard is reasonable and appropriate for your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure. What is not permitted is skipping it silently. In practice, for a business of typical size, most addressable specifications are reasonable and appropriate, and encryption in particular is very difficult to justify declining.
How often does the risk analysis need repeating?
There is no fixed interval in the rule itself, but the analysis has to reflect your current environment, which means it needs repeating whenever something material changes and periodically regardless. Annually is the common practice and is defensible. A risk analysis describing a server you retired two years ago is not evidence of compliance, it is evidence of the opposite.
Is our IT provider a business associate?
If they can access systems containing protected health information, then yes, and a signed business associate agreement is required before that access begins. This applies even where the provider never intentionally looks at patient data, because the standard is access rather than use. Any IT provider working with healthcare clients who is unfamiliar with this requirement is telling you something important about their experience in the sector.
Can an IT provider make our practice HIPAA compliant?
No provider can, and treat any claim otherwise with caution. HIPAA covers workforce training, physical security, policies, patient rights and business process alongside technology. What an IT provider covers is the technical safeguards and a substantial portion of the administrative ones, plus the evidence to demonstrate them. The rest needs an owner inside the practice, and the rule expects a designated security official to exist.
Related
What sits alongside this.
Healthcare
HIPAA, EHR uptime, device segmentation
Dental practices
Imaging servers, practice management, HIPAA
Backup and disaster recovery
Immutable backups with tested restores and a defined recovery window.
Cybersecurity services
Endpoint detection, email security, monitoring and user training.
Cybersecurity risk assessment
Vulnerability scanning, penetration testing and a prioritised findings register.
Find out where the gaps are before an auditor does.
The assessment includes a Security Rule gap review across the technical safeguards, with a findings register you can act on with or without us.