HIPAA compliance for a cloud-based software

As a co-founder of a Healthcare IT company, I can’t help but be worried about being HIPAA compliant. HIPAA is an evolving set of rules and guidelines. So to keep up, we engage lawyers whose job is to know legal implications of every HIPAA rule. We also engage firm(s) to audit our system for finding possible risk of breach to the Protected Health Information that we store.

I approach HIPAA compliance from two viewpoints to wrap my head around it. From the technology standpoint and from the business standpoint. To explain this, let’s use the final HIPAA omnibus rule that was finalized recently. The final omnibus rule greatly enhances a patient’s privacy protections, provides individuals new rights to their health information, and strengthens the government’s ability to enforce the law. Let’s break this statement down from technology and business standpoint.

The statement’s first part is on enhanced patient’s privacy protection which extends to cloud-based EHR solutions such as PHRQL, Inc’s product for dietitians. So from the technology standpoint, for privacy protection, PHRQL secures every individuals health information from day one. We encrypt everything on the move or at rest. However, there are times when one might have a functionality that exposes protected health information. For example. We encrypt the HCF 1500 claims form when sent electronically to comply with HIPAA laws. However, we allow medical professionals to print HCF 1500 claims forms using our software. This form can be inadvertently misplaced, lost or fall in the wrong hands. So we have to put guidelines in place for the users of the system or have the users of the system sign the End User Legal Agreement (EULA) to protect ourselves from things that we have no control over. Similarly, on the mobile technology, we encrypt the data stored on the smartphone. However, if a smartphone with our app is lost or stolen and a patient was logged into the mobile app, the protected health information might be at risk. In this case too, PHRQL mitigates the risk by using technology a certain way (requires login, has session timeouts etc) and by having EULA agreements in place to reduce risk to business.

The statement’s second part is on providing individuals new rights to their health information. It’s a no brainer for a business to know that one cannot sell identifiable health information. The product should also be able to show health information to the user and give them control over it. For example, able to share their health information with another provider (make a Blue Button + product). However, de-identified aggregate data that shows trends is valuable to an informatics based business in the form of reporting tool. We do some of the informatics for our enterprise clients. Since reporting tools are critical to decision making in an enterprise, a business needs to know the limits on how health information can be used and shown to their enterprise customers.

The statement’s third part is on strengthening the government’s ability to enforce the law. As part of the strengthening, the new rule expands the definition of business associate to entities that merely maintain patient protected health information. This is important for a cloud based EHR such as PHRQL. Any technology services we use on the cloud, such as Amazon EC2, for storing or maintaining protected health information, should also be HIPAA compliant. So we have to make sure that any third party vendor we use is HIPAA compliant. This can get a bit tricky. Read more about the tricky part here.

As a cofounder of Healthcare IT startup with access to limited funds, I can assure you of one thing on HIPAA. To achieve HIPAA compliance does not come cheap and takes major time and effort. It’s a process as one of my peer entrepreneur James likes to say. So start with baby steps and try to learn more. There are many people out there trying to figure this out, just like you are.

Leave a Reply