HIPAA compliance in SharePoint

Being prepared for compliance requirements applicable to your enterprise is a critical component to your SharePoint Governance.  Often, it is decided that no data that contains restricted data should be allowed in SharePoint.  This is often discarded as SharePoint's requirements are expanded.  It is best to have a plan in place before those decisions are made.

To summarize HIPAA for the IT Professional, it is four basic principles:

1. Access Control - Only those who need to have access to the patient health information (ePHI) should be able to access it.
2. Audit Controls - You must be able to audit activity pertaining to ePHI.  Auditing means you can track who accesses, adds or alters data.  You should be able to answer "why" there is access but that is difficult to perform with passive logging.
3. Data Integrity - safeguards should be in place to assure ePHI is not being destroyed or altered inappropriately.
4. Transmission Security - You must assure data in motion is reasonably secure and not able to be intercepted or altered during the transmission.

All of these things can be addressed in SharePoint quite easily.  As with most things in SharePoint, there is more than one way to accomplish the principles.

For principle one of Access control, this is fairly straight forward.  Create Active Directory security groups to control access to sites that have ePHI.  Using external groups as opposed to SharePoint groups makes cloning users permissions much simpler, auditing of group membership is easier, and these groups are reusable for multiple site collections.

Auditing is also reasonably easy to accomplish.  You must enable a site collection feature call reporting (see below):

Once you see the list of features, make sure that Reporting is enabled.

Auditing is performed at the site collection level (another reason to keep site collections small).  You view the audit data by clicking Audit Log Reports, providing a document library location, and selecting the type of audit report you require.

The Data Integrity principle can be achieved, at least in part, by enabling versions so that each time any list or library data is modified it will save a version.  Since SharePoint is not an EMR system, this typically is not a significant requirement.

The final principle of Transmission Security can be achieved by using SSL and certificates.  It is preferable to use certificates from a well-known certificate authority (CA) or have certificate services to avoid clients ignoring invalid certificate security errors in their browser.  If they get in the habit of connecting in spite of certificate errors, it leaves a potential security hole for a man-in-the-middle attack.  Further, if all your data is encrypted, the HITECH act protects your institution from embarrassing public notifications in the event of an information security breach.  Encrypting data at rest is another topic for another day, however.

If you have additional questions about compliance with SharePoint, please leave a comment.