HIPAA-compliant IT, built in rather than bolted on

The Security Rule breaks into three categories. Most of what it requires lands on IT.

Technical safeguards. Unique user identification so actions trace to a person rather than a shared login. Access controls that match roles, so the front desk cannot reach what it has no reason to reach. Encryption of PHI in transit and at rest. Automatic logoff. Audit controls that record who accessed what, and retain those records.

Physical safeguards. Controlled access to the spaces where systems live. Workstation positioning and screen privacy in areas patients can see. Device and media controls, including how equipment is wiped when it is replaced.

Administrative safeguards. A genuine risk analysis, not a downloaded template. Assigned security responsibility: a named person. Workforce training with records. Incident response procedures. Contingency planning, which includes backups that have actually been restored from.

The requirement most often missed is documentation. It is not enough to do these things; you have to be able to demonstrate you did them, with dates.

This is worth stating plainly because it is the most expensive misunderstanding in healthcare IT.

When a vendor says their product is HIPAA-compliant, they mean it is capable of being used in a compliant way: it supports the necessary controls and they will sign a business associate agreement. Whether your deployment is compliant depends on how it is configured, who has access, how it connects to everything else, and what happens around it.

An EHR with excellent access controls that every clinician logs into with the same credentials is not protecting anything. Encrypted storage on a laptop that is never locked is not protecting anything. The tool is a component. The practice is what gets audited.

Every vendor that creates, receives, maintains or transmits PHI on your behalf needs a BAA with you. That is broader than most practices assume: it typically includes your IT provider, cloud hosting, backup services, billing companies, transcription, secure messaging, and often your answering service.

Two things to get right. First, have one with each of them, signed, and know where they are. Second, understand that a BAA allocates responsibility; it does not transfer your obligations. If a vendor breaches, you are still the covered entity with notification duties.

We hold a BAA with every client whose PHI we touch, and part of our assessment work is identifying which of your existing vendors you are missing one from.

A risk analysis is explicitly required by the Security Rule, and “we have never done one” is one of the worst positions to be in if you are ever investigated.

Ours runs roughly like this: inventory every place PHI is created, received, stored or transmitted, which is always more places than expected. Identify the threats and vulnerabilities against each. Assess likelihood and impact. Review your existing controls against what is actually required. Produce a written findings document with a prioritized remediation plan.

It is a deliverable you keep, and it is the document you hand over if you are ever asked to show your work. It is also usually the first time a practice sees its whole data footprint in one place.

Most practices think about breaches in terms of the attack. The expensive part is what the law requires afterwards.

You have to notify, and there is a clock. Under the Breach Notification Rule, affected individuals must be notified without unreasonable delay and no later than 60 days from discovery. You also notify the HHS Office for Civil Rights. If the breach affects 500 or more residents of a state or jurisdiction, you notify prominent media outlets there as well, and OCR posts it publicly.

You have to prove what happened. Determining which records were exposed requires audit logs. Practices without proper logging often cannot establish scope, and when you cannot demonstrate which records were unaffected, you may have to treat far more of them as breached than were actually touched.

The investigation looks at your safeguards, not just the incident. OCR examines whether you had a current risk analysis, whether identified risks were addressed, and whether required safeguards were in place. A practice that had done the work and still got breached is in a very different position from one that never did a risk analysis.

Penalties are tiered by culpability. The structure runs from genuinely unaware, through reasonable cause, to willful neglect corrected, to willful neglect uncorrected, with escalating civil monetary penalties at each tier and annual caps. Figures are adjusted for inflation, so check current amounts. The relevant point is that the tier you land in is largely determined by what you did before the incident.

Then there is everything the rules do not cover: downtime while systems are rebuilt, patients who leave, and the time your leadership spends on it instead of running the practice.

If you are building a new practice, this is materially cheaper and more effective to get right now than at any later point.

In an existing practice, improving security means changing systems people already depend on: migrating accounts, retraining staff on workflows they know, segmenting a network that was never designed for it. Every change has to be scheduled around patient care.

In a new build, none of that applies. Network segmentation is a design decision rather than a migration. Role-based access is how the practice has always worked, not a change imposed on people. Encryption, logging and backup are configured before there is any data to lose, and your first staff training is onboarding rather than correction.

The same is true of documentation. Practices that start with a risk analysis and maintain it have a defensible record from day one. Practices that start the paperwork years later are reconstructing history.

If you are working with us on a practice buildout, this is built into the project rather than sold separately.

• Assessment: risk analysis, gap review against the Security Rule, and a prioritized plan.
• Remediation: fixing what the assessment found: access controls, encryption, logging, network segmentation, endpoint protection, identity management.
• Ongoing security: monitoring, patching, backup verification with tested restores, and periodic review as your environment changes.
• Incident readiness: a response plan that exists before you need it, and people who pick up the phone if you do.
• Documentation: maintained evidence that the safeguards are in place and operating, which is the part everyone skips and everyone regrets.

When the environment is new, all of this is cheaper to get right during the build: see practice buildouts.

We are an IT and security partner, not a law firm and not a compliance auditor. We handle the technical and operational safeguards, and the evidence that they work. For legal interpretation, formal certification, or representation in an OCR matter, you want a healthcare attorney or a dedicated compliance firm, and we will say so rather than stretch.

What we do is make sure that when those people look at your environment, it holds up.