More HIPAA/HITECH and Joint IT Environments: Multiple Account Access

I’ve had some interesting follow-up from my previous posting about HIPAA/HITECH and cloud computing. One question was about my statement that users authorized by one Covered Entity whose Protected Health Information and applications are hosted in a joint IT environment shouldn’t have access to the Protected Health Information and applications of other Covered Entities hosted by the same services provider. A question of particular interest was whether that statement also applied if the access was for purposes of treatment, payment or healthcare operations, or if the two Covered Entities were part of an organized health care arrangement (OHCA).

This is an issue I’ve gone around several times with ASPs and RHIOs, and I don’t think it would be either prudent or permitted by HIPAA for different Covered Entities to simply “leave the door open” for external users to access data. “Access” from the user’s side is “disclosure” from the Covered Entity’s side (the HIPAA/HITECH definition of “disclosure” specifically includes “access to information outside the entity holding the information”). So the Covered Entity needs to comply with HIPAA’s disclosure requirements in allowing users from different Covered Entities to access its Protected Health Information.

If the external user is a provider who needs access for treatment purposes, patient authorization is not needed and the minimum necessary rule does not apply. If the external user needs access for payment or health care operations, patient authorization is still not needed, but the minimum necessary rule does apply. That’s all good as far as it goes; you can structure policies and controls to make the appropriate information available (though minimum necessary compliance may be more of a challenge than it appears), but it begs the question, how does the Covered Entity know the purpose of the access, and that the external user is authorized to have it?

The security rule requires Covered Entities to have policies and procedures for granting access to ePHI, including documenting, review and modification of a user’s right of access. Users also have to have unique IDs and the Covered Entity has to have a method of authenticating the user. The security rule also requires security incident identification and response, while HITECH requires notification procedures for security breaches; in both cases the definition of a trigger event includes unauthorized access.

Uncontrolled access would mean that the Covered Entity would be unable to document and review an external user’s right of access, and might not be able to identify and authenticate the user. It certainly wouldn’t be able to identify unauthorized access – i.e., security incidents and breaches. So we’ve got some likely HIPAA violations, and also a lack of controls which is really inappropriate for access to sensitive information as a matter of ordinary prudence. (And I do mean that in the sense that I think it would be actionable negligence.)

When you’ve got an IT environment in which one organization is responsible for user access control, which you can have with ASPs, SaaS or cloud computing environments, that organization can be responsible for user identification and authentication and access control administration. What it probably can’t do is authorize users to have access to ePHI – it has to be told about this by the Covered Entities, who know the roles of the users, etc.

What you need then is a mechanism to make authorization transitive – to allow Covered Entity A to accept the authorization of an external user by Covered Entity B, to access ePHI owned by A on B’s behalf. This is where it often gets sticky, and RHIOs have fallen apart, because generally speaking A won’t (and probably shouldn’t) accept an authorization from B without B assuming liabilities for error and indemnifying A. This can be overcome – I’ve set up a number of arrangements which make it happen – but it can cause serious conflicts between A and B.

I don’t think an OHCA helps with this issue. The real issues are under the security rule, which does not work in those terms. But that doesn’t mean that entities within an OHCA can’t agree to manage data access appropriately under the security rule – e.g. a health system might manage identification and authentication functions on systems it supports, which allow users from associated clinics access to its systems, and in turn the clinics could use the same I&A solution to control access for hospital users accessing theirs. (There are also a few third-party I&A services which can be helpful.)

Related Posts