HIPAA COMPLIANCE DEVELOPER GUIDE

Transcription

1 HIPAA COMPLIANCE DEVELOPER GUIDE Brought To You By

2 Table of Contents 01. Introduction 2013 Final Omnibus Rule Update Why this guide? Who is this guide for? Build on our work Questions/Feedback Mandatory Disclaimer 02. What is HIPAA? Background 2013 Final Omnibus Rule Update The Four Rules of HIPAA Important Terms to Know Protected Health Information The Difference Between PHI and Consumer Health Information Covered Entity Business Associate No Safe Harbor Clause

3 03. Do I Need to Be HIPAA Compliant? Who Needs to Be HIPAA Compliant? 04. HIPAA Security Rule 3 Parts to the HIPAA Security Rule Administrative Safeguards Technical Safeguards Access Control Requirements Transmission Security Audit and Integrity Physical Safeguards Facility Access Controls Device and Media Controls Workstation Security Required vs. Addressable Specifications 05. Becoming HIPAA Compliant What Does HIPAA Require What it Means for Developers If We re Being Honest

4 06. Who Certifies HIPAA Compliance The Short Answer But Texas 07. HIPAA Fines Unencrypted Data Employee Error Data Stored on Devices Business Associates 08. Developer Considerations Build vs. Buy Unintended Use Cases HIPAA Hosting and Compliance Does Using HIPAA Hosting Make My Application HIPAA Compliant? What Data Should Be Stored in HIPAA Compliant Hosting Environments? What Makes a Hosting Environment HIPAA Compliant? Network and Application Security High-Availability and Redundancy Required vs. Addressable HIPAA Implementation Specifications

5 09. Mobile Applications Use Cases PHI in the Application User Communication Database/API Calls Push Notifications Physical Phone Security Using the Lock Screen Enabling Remote Wiping of Lost Phones 10. Wearable Applications Considerations for Wearables Alerts and Notifications Default Displays APIs and Data Sharing Medical Devices Data Encryption Data Synching 11. Apple HealthKit and ios 8 TrueVault ios 8 SDK ios 8 Health-Related Announcements Apple HealthKit Announcements

6 12. About TrueVault Built for Developers Like You HIPAA Compliant BAA + Insurance Startups Mobile Apps Web Apps Wearable Health Tech Devices Why People Like TrueVault Try TrueVault for Free

7 01 Introduction HIPAA, the Health Insurance Portability and Accountability Act, was passed in 1996, and among other things, outlines the requirements for the management of, storage and transmission of protected health information (PHI) in both physical and digital form. And while the original legislation pre-dates the rise of the commercial Internet (and the iphone by a decade) its rules govern the use of this special type of personal data by applications on the web and mobile devices. With any twenty year old piece of legislation that was written in a world without smartphones, tablets, and heck, even webmail, HIPAA is full of requirements that are confusing and challenging, particularly for software developers who have to make sense of them as they relate to their product and the underlying technologies that we all use on a regular basis to build and deliver applications to our customer bases Final Omnibus Rule Update In September of 2013, the Final Omnibus Rule Update was passed that amended HIPAA and greatly expanded the definition of who needed to be HIPAA compliant. Previously, only covered entities (such as doctors, hospitals, and insurers) were required to be HIPAA compliant. With the recent rule change however, all entities that store, manage, record or pass Protected Health Information (we ll just call it PHI from now on) to and from covered entities are also required to be HIPAA compliant. These entities, called Business Associates, who were previously exempt from HIPAA, now fall under its governance. 1 Introduction

8 Why this guide? As you can imagine, complying with federal regulations around privacy and healthcare data is no small task. That s why we ve created this guide to help you wade through what you need to know about HIPAA compliance as it relates to your application and what steps you ll need to take to ensure you don t end up in violation of the law. There is plenty to read about HIPAA guidelines, and if you want you can spend a good chunk of the rest of the year reading up on all the details. Therefore, we re not going to rewrite everything here. This guide is not meant to be comprehensive, but rather give you a framework and reference to help you understand the major portions of the law that apply directly to the software you re developing for mobile, web and wearable applications. Who is this guide for? If you re a developer building a web, mobile or wearable software application that deals in the collection, storage, or transmission of personally identifiable health information to covered entities like doctors this is for you. You ll get the ins and outs of HIPAA compliance guidelines and the steps you ll want to take to ensure you re within those guidelines in the development, hosting, and communication with your users. From a breakdown of the terms and requirements, to specific examples of HIPAA-covered activities, we ve tried to give you what you need to understand the laws in plain language so that you can make the right decisions when developing your application. Whether you decide that your application falls under HIPAA guidelines or not, this guide will give you the information you need to make that decision. Build on our Work This guide is the just the beginning. We hope you ll help us build it out further to make it the go-to source for information on HIPAA compliance and software development. 2 Introduction

9 Questions/Feedback Feel free to leave comments directly here. We ll be monitoring and responding to anything here. Rather discuss something directly? You can drop us a line any time at hello@truevault.com. We d love to hear from you. Mandatory disclaimer We re software developers just like you, but we ve spent countless hours researching, studying and learning the ins and outs of HIPAA compliance. We ve worked with industry experts and attorneys to understand the various portion of the law. In short, we think we have a solid handle on it. However, we need to be clear we re not lawyers and you should not take this as legal advice. If you need to make business decisions around HIPAA you ll probably sleep better at night knowing you paid a very expensive attorney to give their opinion on your specific question. 3 Introduction

10 02 What is HIPAA? HIPAA is short for the Health Insurance Portability and Accountability Act. HIPAA sets the standard for protecting sensitive patient data. The law states that Covered Entities and their Business Associates need to protect the privacy and security of protected health information (PHI). Background Developed in 1996 HIPAA was initially created to help the public with insurance portability. Back in the day you couldn t easily switch insurances if you didn t like the coverage or doctors that provided services under that insurance. It was a huge pain getting your medical records from one practitioner to another. Along with portability came privacy concerns, to the law makers built in a series of privacy tools and requirements to protect healthcare data Final Omnibus Rule Update In September of 2013, the Final Omnibus Rule Update was passed that amended HIPAA and greatly expanded the definition of who needed to be HIPAA compliant. Previously, only covered entities (such as doctors, hospitals, and insurers) were required to be HIPAA compliant. 4 What is HIPAA?

11 With the recent rule change however, all entities that store, manage, record or pass Protected Health Information (we ll just call it PHI from now on) to and from covered entities are also required to be HIPAA compliant. These entities, called Business Associates, who were previously exempt from HIPAA, now fall under its governance. The Four Rules of HIPAA Like the four horsemen, these are the major pieces that govern what you do and how you do it. HIPAA Privacy Rule HIPAA Security Rule HIPAA Enforcement Rule HIPAA Breach Notification Rule Developers need to focus on the Technical and Physical safeguards outlined in the Security Rule. Important terms to know Protected Health Information (PHI) You will hear this term non-stop when dealing with applications that can store health information. It s typically called PHI although some parts of the law refer to digitally-stored PHI as ephi. We ll stick with PHI for consistency. PHI is any information in a medical record that can be used to identify an individual, and that was created, used, or disclosed in the course of providing a health care service, such as a diagnosis or treatment. 5 What is HIPAA?

12 In other words, PHI is information in your medical records, including conversations between your doctors and nurses about your treatment. PHI also includes your billing information and any medical information in your health insurance company s computer system. Some examples of PHI: Billing information from your doctor to your doctor s office about a medication or prescription you need. Appointment scheduling note with your doctor s office An MRI scan Blood test results Phone records Examples of non-phi data: Number of steps in a pedometer Number of calories burned Blood sugar readings w/out personally identifiable user information (PII) (such as an account or user name) Heart rate readings w/out PII The Difference Between Protected Health Information and Consumer Health Information So how do you know if you re dealing with protected health information (PHI) or consumer health information? The test is pretty simple: if your device or application stores, records or transmits the user s personally-identifiable health data held in the app or device to a covered entity (see below) then you are dealing with protected health information and need to be HIPAA compliant. If you are building a wearable device or application that collects health information, but does not plan on sharing it with a covered entity at any point in time then you do not need to be HIPAA compliant. 6 What is HIPAA?

13 For example, the Nike Fuel Band is not HIPAA compliant because it does not track data considered protected health information because you can t transmit that data from the device to a covered entity. Covered Entity A covered entity is anyone who provides treatment, payment and operations in healthcare. According to the U.S. Department of Health & Human Services (HHS) Healthcare Providers, Health Plans, and Healthcare Clearinghouses are all Covered Entities. This one is pretty straightforward. Healthcare Providers are exactly who you might think: hospitals, doctors, clinics, psychologists, dentists, chiropractors, nursing homes, and pharmacies are considered Healthcare Providers and need to be HIPAA compliant. Examples of Health Plans include health insurance companies, HMOs, company health plans, Medicare, and Medicaid. In addition, employers and schools that handle PHI in order to enroll their employees and students in health plans fall under the definition of a Health Plan and need to be HIPAA compliant. Healthcare Clearinghouses are a little more esoteric. A Clearinghouse takes in information from a healthcare entity, puts the data into a standard format, and then spits the information back out to another healthcare entity. They need to be HIPAA compliant too. Covered Entities Include: Doctor s office, dental offices, clinics, psychologists, Nursing home, pharmacy, hospital or home healthcare agency Health plans, insurance companies, HMOs Government programs that pay for healthcare Health clearing houses 7 What is HIPAA?

14 Business Associate Simply put, a Business Associate is a vendor or subcontractor who has access to PHI. A more legalese definition of a Business Associate is any entity that uses or discloses PHI on behalf of a Covered Entity. Furthermore, a Business Associate is any person who, on behalf of a Covered Entity, performs (or assists in the performance of) a function or activity involving the use or disclosure of PHI. The vendors that we are talking about can be data storage or document storage services (doesn t matter if they can view the PHI that they maintain), providers of data transmission services, portals or other interfaces created on behalf of Covered Entities that allow patients to share their data with the Covered Entity, and electronic heath information exchanges. If a Business Associate (vendor) delegates a covered function or activity to someone, then that entity is considered a subcontractor. Some vendors avoid PHI like the plague; they don t want this information anywhere near their service. But, avoidance doesn t necessarily excuse a vendor from becoming compliant. If a Covered Entity (customer) sends PHI through a vendor, and the vendor s servers store this information, then they are considered a Business Associate and subject to the HIPAA Security Rule. No safe harbor clause Unlike other laws (DMCA anyone?) there is no safe harbor here. Just because you don t want to handle PHI doesn t opt you out of HIPAA compliance requirements. Further, just refusing to sign a Business Associate Agreement doesn t absolve you of the provisions of HIPAA compliance should your services handle PHI (intentionally or not) in any way. 8 What is HIPAA?

15 Here are some examples of potential Business Associates: Data processing firms or software companies that may be exposed to or use PHI Medical equipment service companies handling equipment that holds PHI Shredding and/or documentation storage companies Consultants hired to conduct audits, perform coding reviews, etc. Lawyers External auditors or accountants Professional translator services Answering services Accreditation agencies e-prescribing services Medical transcription services In contrast, these folks are NOT Business Associates: Covered Entity s Workforce Individuals or companies with very limited and incidental exposure to health information, such as a telephone company, electrician, etc. Companies that act as a conduit for PHI, such as the postal service, UPS, private couriers, etc. 9 What is HIPAA?

16 03 Do I Need to Be HIPAA Compliant? This is the most important question you can ask, because HIPAA violations can result in some serious penalties. If you handle, store or transmit protected health information (PHI) to or from a covered entity then you need to be HIPAA compliant. If you skipped straight here and don t know what PHI is, read this part of the guide. Who needs to be HIPAA compliant? The short answer is that the HIPAA rules apply to both Covered Entities and their Business Associates. HHS.gov What s a Covered Entity? Who is considered a Business Associate? 10 Do I Need to Be HIPAA Compliant?

17 04 The HIPAA Security Rule Outlines national security standards intended to protect health data created, received, maintained, or transmitted electronically. 3 Parts to the HIPAA Security Rule 1. Administrative Safeguards 2. Technical Safeguards 3. Physical Safeguards Administrative Safeguards The administrative components are really important when implementing a HIPAA compliance program; you are required to: Assign a privacy officer Complete a risk assessment annually Implement employee training Review policies and procedures Execute Business Associate Agreements (BAAs) with all partners who handle protected health information (PHI) Companies like Accountable can help with the administrative components of a compliance program. 11 HIPAA Security Rule

18 Accountable -- Compliance Helper -- Compliancy Group -- Technical Safeguards Technical safeguards outline what your application must do while handling PHI. While there are both required and addressable elements to these safeguards you should implement them all. Addressable elements (such as automatic logoff) are really just best practices. Access Control Requirements Unique User Identification (required): Assign a unique name and/or number for identifying and tracking user identity. Emergency Access Procedure (required): Establish (and implement as needed) procedures for obtaining necessary ephi during an emergency. Automatic Logoff (addressable): Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. Authentication (required): Implement procedures to verify that a person or entity seeking access to ephi is the one claimed. Encryption and Decryption (addressable): Implement a mechanism to encrypt and decrypt ephi. Transmission Security Integrity Controls (addressable): Implement security measures to ensure that electronically transmitted ephi is not improperly modified without detection until disposed of. Encryption (addressable): Implement a mechanism to encrypt ephi whenever deemed appropriate. 12 HIPAA Security Rule

19 Audit and Integrity Audit Controls (required): Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ephi. Mechanism to Authenticate ephi (addressable): Implement electronic mechanisms to corroborate that ephi has not been altered or destroyed in an unauthorized manner. Physical Safeguards The Physical Safeguards really have to do with who has access to PHI data and how that access is managed. Much of the Physical Safeguard requirements that developers need to worry about are handled by HIPAA compliant hosting companies (such as TrueVault, AWS, Firehost and Rackspace). Other parts of the Physical Safeguards are handled by your internal rules around who can and can t access PHI. Facility Access Controls Contingency Operations (addressable): Establish (and implement as needed) procedures that allow facility access in support of data restoration under the disaster recovery and emergency operations plan in the event of an emergency. Facility Security Plan (addressable): Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft. Access Control and Validation Procedures (addressable): Implement procedures to control and validate a person s access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision. Maintenance Records (addressable): Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (e.g. hardware, walls, doors, and locks). 13 HIPAA Security Rule

20 Device and Media Controls Disposal (required): Implement policies and procedures to address the final disposition of ephi, and/or the hardware or electronic media on which it is stored. Media Re-Use (required): Implement procedures for removal of ephi from electronic media before the media are made available for re-use. Accountability (addressable): Maintain a record of the movements of hardware and electronic media and any person responsible therefore. Data Backup and Storage (addressable): Create a retrievable, exact copy of ephi, when needed, before movement of equipment. Workstation Security Workstation Security (required): Implement physical safeguards for all workstations that access ephi, to restrict access to authorized users. Workstation Use (required): Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access ephi. Required vs. addressable specifications Some implementation specifications are required and others are addressable. Required implementation specifications must be implemented. Addressable implementation specifications must be implemented if it is reasonable and appropriate to do so; your choice must be documented. It is important to remember that an addressable implementation specification is not optional. When in doubt, you should just implement the addressable implementation specifications. Most of them are best practices anyway. 14 HIPAA Security Rule

21 05 Becoming HIPAA Compliant The HIPAA Security Rule requires having the appropriate Administrative, Physical, and Technical Safeguards in place to ensure the confidentiality, integrity, and security of protected health information (PHI). In other words, you need to cover all three bases in order to be compliant per the HIPAA guidelines. What does HIPAA require? HIPAA as a law requires that you do the following four things. 1. Put safeguards in place to protect patient health information. 2. Reasonably limit use and sharing to the minimum necessary to accomplish your intended purpose. 3. Have agreements in place with service providers that perform covered functions. These Business Associate Agreements (BAAs) ensure that service providers (Business Associates) use, safeguard and disclose patient information properly. 4. Procedures to limit who can access patient health information, and training programs about how to protect patient health information. What it means for developers If you are collecting, storing or transmitting PHI to a covered entity then you definitely should be HIPAA compliant. 15 Becoming HIPAA Compliant

22 If you re building an application that has any reasonable likelihood of collecting, storing or transmitting PHI you should probably be HIPAA compliant. Your non-technical team or (co-founder, depending on your size) should worry about the administrative compliance issues. As the developer you should focus both on the physical and technical aspects of the law. You can really go about it in one of three ways: 1. Decide that you re not going to have PHI in your system and don t need to worry about HIPAA compliance. This is the easiest choice, but remember, there s no safe harbor with HIPAA. 2. Decide that you ll build out the compliance requirements yourself. Many of the safeguards are standard parts of today s apps, login, auto-logout, etc. You can build many of these as part of your core infrastructure. Others are not so easy to build and maintain. 3. You outsource your HIPAA compliance. Using a service like TrueVault you are guaranteed compliance with the technical and physical safeguard requirements by storing any PHI in the cloud in TrueVault s secure data store. Learn more If we re being honest It s not worth taking the risk of HIPAA compliance audits and penalties if you have even a small chance of managing PHI within your application. 16 Becoming HIPAA Compliant

23 06 Who Certifies HIPAA Compliance? The short answer is no one. Unlike PCI, there is no one that can certify that an organization is HIPAA compliant. The Office for Civil Rights (OCR) from the Department of Health and Human Services (HHS) is the federal governing body that determines compliance. HHS does not endorse or recognize the certifications made by private organizations. There is an evaluation standard in the Security Rule (a)(8), and it requires you to perform a periodic technical and non-technical evaluation to make sure that your security policies and procedures meet the security requirements outlined in the rule. HHS doesn t care if the evaluation is performed internally or by an external organization just as long as it happens. That said, being evaluated by an independent, third party auditor is still a really good idea. Even though it s not official you should still do it. There are a number of great companies that can help you with this process. For example, Coalfire Systems and ComplySmart offer HIPAA Assessments that can let you know how you stack up to the requirements outlined by the legislation. This is important. Even if you get a certification from an external organization, HHS can still come in and find a security violation. Third party audits and certifications do not absolve you from your legal obligations under the Security Rule. 17 Who Certifies HIPAA Compliance

24 But Texas It is interesting to note that Texas is the first state to create a formal Covered Entity Privacy and Security Certification Program to help eliminate this ambiguity. The program was developed as part of Texas House Bill (HB) 300. The Texas Health Services Authority (THSA) and the Health Information Trust Alliance (HITRUST) partnered to implement the Certification Program. They will tell you that the Texas state law protecting patients health information is more stringent than HIPAA. So in theory, if you are certified by the THSA, then you are ipso facto HIPAA compliant. Don t hold us to that because HHS does not endorse or otherwise recognize this claim. But, considering the absence of a federal seal of approval, this is a fantastic program and a step in the right direction. 18 Who Certifies HIPAA Compliance

25 07 HIPAA Fines HIPAA violations are expensive. The penalties for noncompliance are based on the level of negligence and can range from $100 to $50,000 per violation (or per record), with a maximum penalty of $1.5 million per year for violations of an identical provision. Violations can also carry criminal charges that can result in jail time. Fines will increase with the number of patients and the amount of neglect. Starting with a breach where you didn t know and, by exercising reasonable diligence, would not have known that you violated a provision. To the other end of the spectrum where a breach is due to negligence and not corrected in 30 days. In legalese, this is known as mens rea (state of mind). So fines increase in severity from no mens rea (didn t know) to assumed mens rea (willful neglect). The fines and charges are broken down into 2 major categories: Reasonable Cause and Willful Neglect. Reasonable Cause ranges from $100 to $50,000 per incident and does not involve any jail time. Willful Neglect ranges from $10,000 to $50,000 for each incident and can result in criminal charges. HIPAA violation categories and their respective penalty amounts are outlined in the chart below: Source: HHS, Federal Register.gov 19 HIPAA Fines

26 Unencrypted Data While encryption is an addressable (rather than required) specification, it does not mean optional. The vast majority of data breaches are due to stolen or lost data that was unencrypted. When in doubt, you should implement the addressable implementation specifications of the Security Rule. Most of them are best practices. Employee Error Breaches can occur when employees lose unencrypted portable devices, mistakenly send PHI to vendors who post that information online, and disclose personally identifiable, sensitive information on social networks. These are all examples from actual cases. Employee training and adherence to security policies and procedures is extremely important. Data Stored on Devices Almost half of all data breaches are the result of theft. When laptops, smartphones, etc. are unencrypted the risk of a breach increases considerably. With TrueVault, your data is safely stored off-premise; so that stolen laptop just has a token on it, and no PHI is compromised. Business Associates Almost two-thirds of data breaches involved a business associate. Meaning that you delegated a covered function or activity to someone, and that someone messed up. So pick your partners carefully. Some of the largest breaches reported to HHS have involved business associates. As a result, the final omnibus rule expanded many of the requirements to business associates and greatly enhanced the government s ability to enforce the law. 20 HIPAA Fines

27 What sort of penalties are we talking about? Check out this chart with fines levied in years past: Source: HHS, Case Examples and Resolution Agreements Looking at this chart we can conclude that HHS does not like people storing unencrypted PHI on mobile devices. What we don t see yet are fines levied against business associates is the first year where business associates will be audited and fined. Smart money says that the first fines levied against business associates will be passed down toward the end of this year. If these fines make you nervous, then this might be a good time to revisit your decision about whether your application needs to be HIPAA compliant or not. The good news is that not every PHI breach ends in a fine. If you can show that you have made a reasonable effort to comply with HIPAA then you may not be dinged. 21 HIPAA Fines

28 08 Developer Considerations As you re evaluating how to best deal with HIPAA you ll probably have some of these questions pop-up in your deliberations. We ll continue to add more here, but these are ones that we ve heard from developers tackling HIPAA in their development process. Build vs. Buy Scanning the list of safeguards required by HIPAA it s not unreasonable to think first of building out the safeguards yourself. Functionality such as unique identifiers for users and automatic logoff are part of any application anyway, so building those is going to happen one way or another. Couple that with HIPAA compliant hosting providers, and it s easy to draw the conclusion that a combination of an AWS instance and some best practice application security wouldn t do the trick. Unfortunately, the other pieces of the security rule safeguards aren t as easy to address or maintain and can take a ton of people-power and time to build out not just the features but the audit and logging functionality as well. We think this comment from Hacker News sums up the technical debt required to roll your own HIPAA compliant infrastructure quite accurately. This was completely unsolicited and is not from a TrueVault customer. 22 Developer Considerations

29 [Building our own HIPAA compliant infrastructure] took upwards of 1,000 person-hours to figure out HIPAA-compliance issues. This will continue to be an ongoing cost for us, because HIPAA is an ongoing law and it changes sometimes. It takes substantial auditing time and money. jph Looking at it as a 1,000 hour project is one way to evaluate the true cost of rolling your own compliance infrastructure, not to mention the ongoing audit and maintenance costs associated with your in-house solution. Unintended use cases As we ve mentioned before, HIPAA isn t like the DMCA, there is no safe harbor clause for unintended transmission, storage or disclosure of PHI. Regardless of how you planned it, scoped it, envisioned it or dissuaded users from including it if PHI is in your app or on your servers you could face HIPAA fines if you re not in compliance. It s not as big of an edge case as you might think. Here s a few examples of how easily PHI can enter into your application. Your app to get doctor s advice based on anonymous symptoms could easily have PHI as soon as the patient shares an address, lab report, or last doctor visit. Your diabetes management app which tracks your blood sugar and prescription information has a note added by the user of their doctor s dosing instructions and pharmacy Rx number. You get the idea. Regardless of how you intend for the user to use your application, there is a pretty decent chance that if the application is related to personal health in any way, PHI will ultimately end up in the system. HIPAA Hosting and compliance HIPAA hosting refers to website, application or data storage and hosting services that comply 23 Developer Considerations