What a Company Has to Write Down About Protecting Your Records

Answer first: the rule ends in two documents you will never see

The federal security standards for electronic health records finish with paperwork rather than with technology.

One document is a contract between the company you signed up with and whoever else handles the records. The other is a file of the company's own policies, procedures and assessments.

Both are internal. Neither is published, and neither is something a reader can request under these particular sections.

That is still worth understanding, because the contract fixes what one company can require of another, and the file is what an enforcement question would eventually be answered from.

None of it applies to everyone. The subpart's applicability section fixes who carries the duty. A covered entity or business associate must comply with the applicable standards, implementation specifications, and requirements of the subpart, with respect to electronic protected health information of a covered entity.

The chain, and the sentence that stops one link in it

Records rarely sit in one company. The rule builds a chain for that, and the chain is made of assurances.

A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on its behalf. It may do so only on satisfactory assurances that the business associate will appropriately safeguard the information.

The same structure repeats one step down. A business associate may permit a subcontractor to handle the information only if it obtains satisfactory assurances from that subcontractor.

⭐ Then comes a sentence most summaries drop. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.

So the duty runs link by link rather than end to end. The company at the top is not told to reach past its own vendor to that vendor's vendor; the vendor is the one told to do that.

Assurances alone are not enough either. A required implementation specification says to document them through a written contract or other arrangement meeting the organizational requirements section.

Three things the contract has to say

The organizational requirements section fixes the contents, and its implementation specifications are marked required rather than addressable.

The contract must provide that the business associate will comply with the applicable requirements of the security subpart.

It must provide that the business associate will ensure that any subcontractors handling the information on its behalf agree to comply with those requirements. That agreement takes the form of a contract or other arrangement complying with the same section.

And it must provide that the business associate will report to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as the breach subpart requires.

⭐ Read that third term slowly, because it is wider than it looks. A security incident is defined in this subpart to include an attempted unauthorized access, and interference with system operations. So the reporting duty reaches events the breach rules would never require anyone to disclose to you. The breach half of that sentence is a companion article's subject.

A cross-reference that points at a paragraph that is not there

One clause in that section is worth flagging, because anyone checking this themselves will hit it.

The paragraph applying the contract requirements to a subcontractor arrangement describes that arrangement as the one required by paragraph (b)(4) of the administrative safeguards section.

That section's paragraph (b) runs to three numbered paragraphs and stops. As served today there is no fourth.

The other two cross-references in the same section both land, and the duty this one describes is carried anyway. The administrative safeguards section already tells a business associate to obtain assurances from a subcontractor, and the contract terms already require the flow-down.

⚖ So the substance is not in question and the address is. This is stated here as a reading of two published texts, and no conclusion is drawn from it about what anyone must do.

The other arrangement, and the employer version

A contract is not the only route. An organization is treated as compliant if it has another arrangement in place meeting a standard set out elsewhere in the privacy subpart. That is how public agencies and similar bodies satisfy the same requirement without a commercial contract.

There is a second half to the section that reaches employer coverage rather than vendors.

A group health plan must ensure that its plan documents provide for the sponsor to safeguard the information reasonably and appropriately. That covers electronic protected health information created, received, maintained or transmitted to or by the sponsor on the plan's behalf.

The plan documents must be amended to require four things of the sponsor. Implement administrative, physical and technical safeguards that reasonably and appropriately protect the confidentiality, integrity and availability of that information. Ensure that a required separation is supported by reasonable and appropriate security measures. Ensure that any agent it gives the information to agrees to implement reasonable and appropriate measures. And report to the group health plan any security incident of which it becomes aware.

That last one is the same reporting term as the vendor version, pointed in a different direction.

What has to be written down

The final section of the subpart is about the file itself, and it opens with a standard on policies and procedures.

An organization must implement reasonable and appropriate policies and procedures to comply with the subpart. It must take into account the same four factors the general rules use. Those are its size and capabilities, its technical infrastructure, the costs of security measures, and the probability and criticality of potential risks.

The section then closes an obvious gap. That standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification or requirement of the subpart.

Policies may be changed at any time, provided the changes are documented and implemented in accordance with the subpart.

The documentation standard has two limbs. Maintain the policies and procedures in written form, which may be electronic. And where the subpart requires an action, activity or assessment to be documented, maintain a written record of it.

⭐ That second limb is what turns the addressable branch into evidence. Wherever an organization decides a specification is not reasonable and appropriate, the explanation it is required to write is a record this standard tells it to keep.

Three required things about the file

The documentation standard carries three implementation specifications and all three are marked required.

A time limit. Retain the documentation for six years from the date of its creation or the date when it last was in effect, whichever is later.

Availability. Make the documentation available to those persons responsible for implementing the procedures to which it pertains.

Updates. Review the documentation periodically, and update it as needed, in response to environmental or operational changes affecting the security of the information.

⛔ The word availability is doing double duty in one subpart, and it is worth catching. As a defined term it means the property that data or information is accessible and useable upon demand by an authorized person. As the title of this specification it means giving a policy to the staff who have to follow it. Same word, two jobs, a few pages apart.

Six years is about the company's paperwork, not your record

This is the correction worth carrying away, because the six-year figure travels a long way from where it belongs.

The retention period above applies to the documentation the subpart requires: the policies, the procedures, and the written records of actions, activities and assessments.

It says nothing about how long a medical record is kept. The claim that a federal health privacy law keeps your records for six years is common, and this is not the sentence behind it.

How long a clinical record is retained is a matter of state law and professional requirements, which vary and which are not described here.

⚖ Those are two different filing cabinets. Asking a company how long it keeps your record is a reasonable question, and the answer will not come from this rule.

What a reader can actually look at

Whether a privacy document names the entity that holds the record, since the contract chain runs between organizations rather than between brands.

Whether it says anything about vendors, service providers or partners handling health information, because that is the population the contract requirement is built for.

Whether a company states its own record-retention period anywhere, and whether it distinguishes the medical record from the account.

Whether the documents describe review and updating rather than a single past build, since two of the three required items in the final section are about keeping a file current.

And whether a company describes reporting arrangements with the businesses it works with. The contract term above reaches attempted access, not only successful loss.

What this does not decide

It does not say whether any particular company is inside the category the applicability sentence names, or whether it holds a contract of the kind described. Both are questions about a specific business.

It does not say that any company has documented, retained or reported anything. No such claim is made and none is implied.

It does not say how long anyone keeps a medical record, which is not what the retention period quoted here is about.

It does not describe the breach subpart's own notice duties, which companion articles cover, and it describes no state statute.

And it is not legal advice. It reports what three sections of one federal subpart say.