Just when you figured out how to negotiate the “business entity” definition, Congress hit you with the Omnibus rule. Thanks to the Health Information Trust Alliance (HITRUST), the HITRUST Framework helps HIPAA and vendor management which had suddenly become “a thing.” Managing patient health information (PHI) feels like gathering evidence from a crime scene.
Anyone who remembers the O.J. Simpson trial remembers the infamous bloody fingerprint. The sample of O.J. Simpson’s blood went missing during the police investigation. Only 6 ml of the 8 ml of the blood drawn from Simpson was accounted for, causing people to suspect evidence was planted. While HIPAA may not be as exciting as a high speed car chase, tracking your chain of evidence—or in compliance speak, chain of trust—matters.
What is PHI?
PHI incorporates multiple types of information available to health providers. When looking at the ways that the HITRUST Framework helps HIPAA and vendor management, the first thing to do is to learn the various terms under this umbrella.
“Health information” encompasses information created or received by a health care provider, health plan public health authority, employer life insurer, school or university, or healthcare clearinghouse. This information can relate to past, present, or future physical health, mental health, or condition of any individual. In easy terms, this covers all the information a patient gives to health care workers when admitted to a health care office or facility.
Individually Identifiable Health Information
“Individually identifiable health information” includes any demographic information that can be linked back to the patient. In other words, this may not be specific to the condition but is part of the history and clearly identifies the individual or can be used to identify the individual. For example, this not only includes name, address, and social security number, but may also include date of birth, zip code, or county location. If the information can be traced back to a specific individual, not just a population, then it falls under this umbrella.
Protected Health Information
“Protected health information” means any individually identifiable health information that is transmitted by electronic media, maintained in electronic media, or transmitted or maintained in any other form or media. The kicker here is that the definition of PHI excludes education records protected by the Family Educational Rights and Privacy Act, records described in 20 U.S.C. 1232g(a)(4)(B)(iv), and employment records held by a covered entity in its role as employer. In other words, when records are protected under educational or employment law, that overrides HIPAA.
What exactly does “business associate” mean?
While “business associate” may conjure up Marlon Brando in The Godfather obliquely referring to gangsters, it isn’t quite that exciting under HIPAA.
According to HIPAA, a business associate is a person or entity, other than a member of a covered entity’s workforce, who performs functions or activities on behalf of, or provides services to, a covered entity that accesses protected health information.
In regular business terms, a business associate is a vendor who somehow, by virtue of their role as a partner, comes into contact with the kind of information that needs to be protected.
For example, this could be a cloud storage vendor or a cleaning service working around files. Most likely, it won’t be a plumber.
How does a health information exchange fit into this??
Health information exchange is one of those IT terms that has a variety of meanings. Generally, it’s the back and forth digital information sharing that takes place between providers. In some places, it refers to the larger concept of general information movement between stakeholders. When it comes to the ways the HITRUST Framework helps HIPAA and vendor management, the term can also be used to refer to the organization or entity that aids in information movement.
This means that the phrase “health information exchange” can refer to the vendors handling your patient data. Ultimately, vetting these vendors is critically important because of the overall safety concerns that come with this information.
What is a chain of trust partner agreement?
Unfortunately, or maybe fortunately if you’ve had the experience of living with a toddler, the chain of trust partnership isn’t about working with Thomas and his Very Useful Crew. HIPAA and vendor management is similar to other forms of vendor monitoring but feels even more invasive, particularly if you’re the vendor.
Working with vendors under HIPAA means having to trust them with not just your own information but also the information your clients entrust to you. This means that while you may not need to be SOC compliant and complete an SSAE 18 review, you do need to understand the way in which your vendors interact with information and monitor their information security measures.
Think of a chain of trust partner agreement as a written trust fall exercise. In corporate trainings, there used to be “trust falls.” Two people stand together in a line, one falls down backward, and the second person catches them. Now, imagine this as people set up like a series of dominoes, one after another after another. The first person falls onto the second, who falls onto the third, until you get to the last person. Each person needs to be strong enough to ensure the person in front doesn’t fall, even with the added weight of the people before them.
A chain of trust agreement is the adult, contractual version of this. The business entity at the top of the chain contracts with its vendor. This relationship is covered by the contract between those two. However, that vendor may want to have vendors for itself. This means that despite having the degrees of separation from the original business entity, these vendors are also related to the business entity through their work with the other vendors.
To put it graphically:
Business Entity → Contract with Vendor A → Contract with Subvender 1 → Contract with Subsubvendor !
Now, Subsubvendor !, by virtue of its relationship with Subvendor 1, which has a relationship with Vendor A, is also related to the Business Entity. As such, even though Subsubvender ! may have nothing to do with health care, that entity is now responsible for the privacy interests of HIPAA and and the risk management involved.
How the HITRUST Framework helps HIPAA and vendor management by mitigating the impact to your business
If your organization is anywhere in the stream of a business entity, this means that you’re going to need to determine how to be HIPAA compliant.
Many of the HIPAA compliance requirements can be found in other frameworks governing information systems such as NIST, ISO, and FISMA. However, if you’re already implementing HIPAA or planning to in the future, you want to consider possible gaps.
If you really want to be HIPAA compliance, the HITRUST Cybersecurity Framework (HITRUST CSF) is your safest bet. The HIPAA Security Rule is based on administrative, technical, and physical safeguards as well as organizational requirements such as policies, procedures, and documentation.
The HITRUST CSF is based on the HIPAA Security Rule but also incorporates specific controls within a common security framework that specifically addresses information security concerns. This compliance framework incorporates 14 control categories, 49 objectives, and 149 total control specifications. The prescriptive and scalable HITRUST CSF helps create a system of access control to protect PHI.
If you’re using spreadsheets, this becomes overwhelming quickly. Trying to cross reference multiple standards takes manpower and hours. Tying up these valuable resources on a single task may seem cost inefficient.
How GRC Automation overlaps with the way the HITRUST Framework helps HIPAA and vendor management pain
HIPAA compliance can feel overwhelming. The potential for civil and criminal penalties can scare organizations away from incorporating HIPAA as part of their compliance program which, in turn, can lead to lost revenue.
With ZenGRC, you can visualize compliance gaps to determine the additional work necessary to be compliant. As you map controls to a particular standard or framework, ZenGRC allows you to map that control to other standards or frameworks that it satisfies.
The first step in the successful implementation of the HITRUST CSF is to engage in a CSF Self-Assessment with the help of a CSF assessor. CSF assessors are consulting firms that HITRUST approved to perform the assessment. Using this information, you can gauge your system and regulatory requirements to help determine your risk and scope.
Suppose that you are currently ISO 27001 compliant. One of your controls is a firewall. If you choose to incorporate PCI DSS compliance, a firewall is also an accepted control. Once you set up your controls in ZenGRC, it automatically maps current controls to new standards as you add them. This means that your ISO 27001 controls will be mapped to your new PCI DSS compliance framework. All you need to do now is determine what additional controls you need to incorporate.
If you then choose to implement the HITRUST CSF, you can run a gap analysis to determine the additional work necessary to be compliant.
Not only does this make incorporating new standards into your overall landscape easier, it also means that you can expand your business into revenue streams that seemed too onerous before.
Automation offers companies the ability to expand their business offerings more easily. When compliance offers a barrier, automation can be the battering ram.
To read more about how automation can establish better business practices, read our eBook, “Compliance Management Best Practices: When Will Excel Crush You?”