The HIPAA Security Rule in Medical Billing

It is common to treat HIPAA as one rule. It is at least two, and they do different jobs. The HIPAA Privacy Rule governs uses and disclosures — who may see protected health information, for what purpose, and how much of it. The Security Rule governs safeguards — the administrative, physical, and technical protections that keep the electronic form of that information from being accessed, altered, or lost by someone who should not have it. Privacy is about permission; security is about protection.

The two also cover different information. The Privacy Rule reaches PHI in any form — on paper, spoken aloud, or electronic. The Security Rule reaches only the electronic subset: electronic protected health information, or ePHI, which the rules define as PHI that a covered entity or business associate creates, receives, maintains, or transmits in electronic form (45 CFR 160.103). Electronic media is defined broadly — the hard drives and removable media where data is stored, and the networks and internet connections over which it moves — so almost everything a billing operation touches is squarely inside it.

The Security Rule binds the same organizations the rest of HIPAA does, and one more group it did not always reach directly. It applies to every covered entity — a health plan, a health care clearinghouse, or a provider that transmits health information electronically in connection with a standard transaction — with respect to the ePHI it handles (45 CFR 164.302). A practice that submits claims or checks eligibility electronically is a covered entity, and its billing systems are within the rule.

Since the 2013 Omnibus Rule, the Security Rule also applies directly to business associates — the outside billing company, clearinghouse, collections agency, or software and hosting vendor that handles ePHI on a practice's behalf. Before that change, a business associate's security obligations reached it only through its contract with the covered entity; now the rule binds it as a matter of federal law as well. Both the practice and its vendors are directly responsible for safeguarding the electronic claim data they hold.

The most useful thing to understand about the Security Rule is what it does not do: it does not name the products a practice must buy or the settings it must turn on. It states objectives and then leaves the means to the entity. A covered entity or business associate must (45 CFR 164.306(a)):

• Ensure the confidentiality, integrity, and availability of all the ePHI it creates, receives, maintains, or transmits — that the information is not disclosed to the wrong people, is not altered or destroyed improperly, and is available to the right people when they need it.
• Protect against any reasonably anticipated threats or hazards to the security or integrity of that information.
• Protect against any reasonably anticipated uses or disclosures that the Privacy Rule does not permit.
• Ensure that its own workforce complies with the rule.

Those three properties — confidentiality, integrity, and availability — are the rule's own defined terms (45 CFR 164.304), and they are worth keeping distinct. Confidentiality is that the data is not made available to unauthorized people. Integrity is that it has not been altered or destroyed in an unauthorized way. Availability is that it is accessible and usable on demand by someone authorized. A safeguard that protects one can neglect another — an encrypted backup nobody can restore protects confidentiality while failing availability — which is why the rule names all three as the target rather than "security" in the abstract.

Because it sets objectives, the Security Rule can hold a solo practice and a hospital system to the same standards by different means. It says so explicitly: an entity may use any security measures that let it reasonably and appropriately implement the standards, and in choosing them it may take into account its size, complexity, and capabilities; its technical infrastructure, hardware, and software; the cost of the measures; and the probability and criticality of the potential risks to ePHI (45 CFR 164.306(b)). A five-person practice is not expected to build what an enterprise builds.

Cost is on that list, but it is a factor in choosing among reasonable measures, not a reason to leave an objective unmet. The requirement to protect the confidentiality, integrity, and availability of ePHI does not scale away; what scales is how a given practice reasonably achieves it. This is also why the specifications inside each standard carry one of two designations.

Required

A required implementation specification must be implemented. There is no discretion about whether — only about how (45 CFR 164.306(d)(2)). Conducting a risk analysis, for example, is required.

Addressable

An addressable specification is not optional. The entity must assess whether it is a reasonable and appropriate safeguard in its environment; if it is, implement it; and if it is not, document why and implement an equivalent alternative measure where that is reasonable and appropriate (45 CFR 164.306(d)(3)). The decision, and the reasoning behind it, has to be written down either way.

The Security Rule organizes its standards into three families of safeguards, and a compliant program has all three. Administrative safeguards are the policies, procedures, and workforce measures that manage security (45 CFR 164.308). Physical safeguards protect the facilities, workstations, and devices where ePHI lives (164.310). Technical safeguards are the technology and its rules of use that control access to ePHI and protect it in storage and in transit (164.312). Two further sets — organizational requirements (164.314) and documentation requirements (164.316) — sit alongside them.

Under those families sit the specific implementation specifications, marked required or addressable. The required ones include unique user identification for technical access control (45 CFR 164.312(a)(2)(i)), the disposal and media re-use protections in the physical safeguards (164.310(d)(2)(i)–(ii)), and the data backup, disaster recovery, and emergency mode operation plans within contingency planning (164.308(a)(7)(ii)(A)–(C)). The point of the map is not to memorize it but to recognize that security under HIPAA is not a single control — it is a set of coordinated ones across all three families.

One administrative safeguard makes the rest of the rule operable, and it is the one most often skipped. The security management process requires an entity to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI it holds — the risk analysis (45 CFR 164.308(a)(1)(ii)(A)) — and then to implement security measures sufficient to reduce those risks to a reasonable and appropriate level, which the rule calls risk management (164.308(a)(1)(ii)(B)).

The risk analysis is what makes the rest of the rule answerable. "Reasonable and appropriate," "addressable," and the flexibility to scale to a practice's size are all judgments that have to be made against something — and the risk analysis is that something. Without it, a practice cannot say why it implemented one safeguard and not another, because it has not identified what it is protecting the data from. This is why it is the first thing an investigation tends to ask for, and why a program built without it tends to be a collection of tools rather than a defensible set of decisions.

Most billing operations hand ePHI to at least one outside party, and the Security Rule follows the data there. A covered entity may let a business associate create, receive, maintain, or transmit ePHI on its behalf only after obtaining satisfactory assurances, documented in writing, that the vendor will appropriately safeguard it (45 CFR 164.308(b)). Those assurances live in the business associate agreement, and the Security Rule specifies the security terms it must contain (164.314(a)): the vendor will comply with the Security Rule, will bind its own subcontractors to do the same, and will report security incidents, including breaches of unsecured PHI, to the practice.

When a safeguard does fail, two ideas the rule keeps separate are worth keeping separate in practice too. A security incident is the rule's broad term — the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations (45 CFR 164.304). Many security incidents are minor and repelled, and the rule asks an entity to identify, respond to, mitigate, and document them (164.308(a)(6)(ii)). A breach is the narrower event — an impermissible acquisition, access, use, or disclosure of unsecured PHI — and it triggers a separate obligation.

For a billing operation, complying with the Security Rule is less a purchase than a set of decisions, made against a real assessment of risk and written down.

1. 01

   Name someone responsible

   The rule requires an entity to identify the security official responsible for developing and implementing its policies and procedures (45 CFR 164.308(a)(2)). In a small practice this is a role, not a department, but it has to be assigned to a person rather than left to "the software."
2. 02

   Do the risk analysis, and keep it current

   Assess the risks and vulnerabilities to the ePHI the practice holds and moves (45 CFR 164.308(a)(1)(ii)(A)), and revisit it when the environment changes — a new clearinghouse, remote staff, a new portal. Every other decision refers back to it.
3. 03

   Scale the safeguards to the risks, across all three families

   Choose administrative, physical, and technical measures that reasonably and appropriately meet the standards for a practice of this size and complexity (45 CFR 164.306(b)). For each addressable specification, implement it or document why an equivalent alternative is used instead.
4. 04

   Put the security terms in every business associate agreement

   Before any vendor handles ePHI, confirm the BAA carries the Security Rule terms (45 CFR 164.308(b), 164.314(a)) — the vendor's own compliance, subcontractor flow-down, and security-incident reporting — alongside the privacy terms the minimum necessary standard and the rest of the Privacy Rule require.
5. 05

   Write the policies down — and keep them

   The rule requires written (which may be electronic) policies and procedures, and documentation of the actions and assessments it calls for, retained for six years from the date of creation or the date it was last in effect, whichever is later (45 CFR 164.316). Undocumented good practice is, to an investigator, indistinguishable from no practice.
6. 06

   Train the workforce and act on incidents

   Provide security awareness and training (45 CFR 164.308(a)(5)) and follow the incident procedures the practice has written when something goes wrong (164.308(a)(6)). The people at the keyboards are where most safeguards succeed or fail.

The Security Rule is one piece of the wider set of regulatory duties in the Compliance and Regulations category — it works alongside the Privacy Rule's permission to use PHI for payment and the business associate agreements that extend both to a practice's vendors. Because the rules are revised and their enforcement guidance evolves, written security policies should point to the current regulation and be reviewed when it changes.