Application Developers Guide to HIPAA Compliance

Application Developers Guide to HIPAA Compliance

• 1.
  HIPAA COMPLIANCE DEVELOPER GUIDE Brought To YouBy
• 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 INeed 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 CertifiesHIPAA 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 UseCases PHI in the Application User Communication Email 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 Builtfor 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.
  1 Introduction 01 HIPAA, theHealth 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. 2013 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. Introduction
• 8.
  2 Introduction Why thisguide? 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.
• 9.
  3 Introduction Questions/Feedback Feel freeto 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 [email protected]. 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.
• 10.
  What is HIPAA?02 HIPAAis 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. 2013 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.
  5 What isHIPAA? 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.
• 12.
  6 What isHIPAA? 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 • Email 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.
• 13.
  7 What isHIPAA? 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
• 14.
  8 What isHIPAA? 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.
• 15.
  9 What isHIPAA? 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.
• 16.
  10 Do INeed to Be HIPAA Compliant? Do I Need to Be HIPAA Compliant?03 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?
• 17.
  11 HIPAA SecurityRule 04 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. The HIPAA Security Rule
• 18.
  12 HIPAA SecurityRule • Accountable -- http://accountablehq.com • Compliance Helper -- http://www.compliancehelper.com • Compliancy Group -- http://compliancy-group.com 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.
• 19.
  13 HIPAA SecurityRule 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).
• 20.
  14 HIPAA SecurityRule 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.
• 21.
  15 Becoming HIPAACompliant 05 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. Becoming HIPAA Compliant
• 22.
  16 Becoming HIPAACompliant 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.
• 23.
  17 Who CertifiesHIPAA Compliance 06 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 § 164.308(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. Who Certifies HIPAA Compliance?
• 24.
  18 Who CertifiesHIPAA Compliance 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.
• 25.
  HIPAA Fines07 HIPAA violationsare 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: 19 HIPAA Fines Source: HHS, Federal Register.gov
• 26.
  20 HIPAA Fines UnencryptedData 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.
• 27.
  21 HIPAA Fines Whatsort 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. 2014 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.
• 28.
  Developer Considerations08 As you’reevaluating 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.
  23 Developer Considerations “[Buildingour 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 email 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
• 30.
  24 Developer Considerations withthe physical safeguard requirements of the HIPAA security rule. HIPAA hosting is an important part of the requirements needed for application developers to ensure HIPAA compliance of their solutions. Does Using HIPAA Hosting Make My Application HIPAA Compliant? The short answer is no. HIPAA hosting alone does not make you HIPAA compliant. Compliance is determined by the adherence to the privacy and security rules outlined by HIPAA. HIPAA Hosting only addresses one aspect of those requirements. Hosting your application in a HIPAA compliant hosting environment such as Amazon AWS or Firehost does not make your application HIPAA compliant as they only address the physical safeguard requirements of the HIPAA security rule. You are still required to meet the administrative and technical specifications of the HIPAA Security Rule in order to be compliant. What Data Should Be Stored in HIPAA Compliant Hosting Environments? Not all of your application data needs to exist in a HIPAA hosting environment. But any PHI must be in a HIPAA compliant environment. Examples of PHI
• 31.
  25 Developer Considerations WhatMakes a Hosting Environment HIPAA Compliant? HIPAA compliant hosting providers typically provide two main aspects of HIPAA compliance: They sign a Business Associate Agreement with you, which is required by service providers managing and handling HIPAA protected information. Learn more about Business Associate Agreements. They address many of the Physical Safeguard requirements of the HIPAA Security rule. See a complete list of physical safeguards. Network and application security Ensuring your hosting environment is HIPAA compliant is only the first step. You must also implement network and application security best practices to protect your hosting environment. Health information is a popular commodity for hackers. According to a recent Information Week article, each health record could be worth as much as $20 on the black market. It’s easy to imagine hackers trying to breach your servers when your application becomes popular. You need to be sure your HIPAA hosting environment is locked down and secure from unauthorized access attempts. High-Availability and Redundancy A good infrastructure design eliminates all single-point-of-failures. While running one web server and one database server may save you money in the short run, how much would it cost your business if that one web server goes offline causing the entire hosting environment to crumble?
• 32.
  26 Developer Considerations It’sbest to design your hosting environment with at least 2 web servers behind a load balancer and 2 database servers on a active/passive failover setup. Clearly most environments are more complicated than just a 2-tier setup, so you must implement an infrastructure design best suited for your business. But the point remains, high- availability and redundancy are crucial parts of your HIPAA compliant infrastructure. Required vs. Addressable HIPAA Implementation Specifications We’ve talked about the difference between required and addressable specifications already, but most HIPAA hosting companies should implement the addressable specifications as they are best practice data security features any way.
• 33.
  Mobile Applications09 Pundits estimatethat there are more than 40,000 health-related applications in AppStores everywhere. That’s a lot of apps for an industry that by all accounts is just starting to get its bearings when it comes to consumer technology. That number is sure to grow, particularly if Apple goes full on ahead with its rumored Healthbook—which is a health-related version of its integrated Passbook application. For sure, mobile makes a ton of sense to be the platform of choice for the next generation of patient health management tools. Tablet sales are skyrocketing past PCs, more smartphones are being sold to more people, and the very notion of health management lends itself to a device that you have with you all the time. Building a health-related mobile application does have some challenges of its own, particularly as it relates to HIPAA compliance. These special cases are why we’ve added this section just about mobile application development and HIPAA compliance. Use cases As we mentioned under Developer Considerations a thorough understanding of your application use cases is essential. We won’t rehash it all here, but definitely read up on it in the link above. Needless to say, it’s important to consider whether or not your app will be used to store or transmit protected health information, regardless of how you’ve designed it or anticipate it being used. 27 Mobile Applications
• 34.
  28 Mobile Applications Evenif you’ve designed your app to collect or use anonymous data that doesn’t fall under HIPAA by itself, if a user chooses to use your app to transmit PHI to a doctor then you are subject to HIPAA compliance requirements. Edge case or not, as soon as PHI is involved your app falls under HIPAA. If your application has the chance to be used to store and transmit PHI it’s a safer bet to be HIPAA compliant to protect yourself from inadvertently violating HIPAA guidelines. PHI in the application PHI is information that could be used to identify an individual and that relates to their physical or mental health, any healthcare services they have received and any information regarding the payment for such services. The fact that an individual has received services from a covered entity is itself PHI. Likewise, the name or address of an individual, although publicly available, is also PHI when it’s on a covered entity’s computer simply because its presence suggests that the individual is or was a patient. PHI can also include what would otherwise be anonymous information. This includes a date of service i.e. anything more specific than a year. If you store, collect, manage, or transmit any protected health information to covered entities then your app needs to be HIPAA compliant. User communication This is another area where developers can get tripped up when it comes to HIPAA compliance. We’re so used to building in email and app notifications that questioning whether they can be used at all, or in a compliant manner, is a foreign concept. The very premise of the HIPAA is to protect sensitive information, so it is paramount that you consider how you will communicate with subscribers once they are using your app.
• 35.
  29 Mobile Applications Email Consideremail. Emails are usually not compliant with HIPAA as they often lack the ability to encrypt their contents. Therefore sending information that may contain PHI via email is a HIPAA violation. Because many applications use email as a communication source with users, it’s important to understand what can and can’t be included in those communications. If you are sending email communications that include or might include protected health information from your mobile app you should send those emails via a HIPAA compliant email service provider. Database/API calls If your application is relying on data from any covered entity (such as a doctor’s office) it will have to be compliant. Same goes for any integration you need to do with a business associate of a covered entity. If your app is not compliant these covered entities will not be able to grant your app access to make API or database calls, nor can you search and read anything within their database. Captain obvious says “This greatly limits the functionality of your application.” Push notifications As we have said before, mobile phones are particularly insecure devices and the native push notifications that are used by many applications to notify users of updates and changes run the risk of violating the privacy regulations outlined in HIPAA. If you’re using notifications in your mobile app, it’s critical that you do not include any PHI in any push notifications from your app as they can appear and be publicly visible even when a phone is locked.
• 36.
  30 Mobile Applications Thisgoes beyond just mobile push notifications. Any time you’re making an automated, outbound push message (whether it be mobile, email, or automated calling) the same rules apply. Make sure you evaluate all communication touch points for potential PHI/HIPAA issues. Physical phone security Phones are prone to being stolen, left in the back of cabs, on the table at restaurants, and pretty much everywhere else. Because of the natural lack of security of the phone itself you need to ensure that PHI isn’t easily accessible to unauthorized users. Unfortunately, as a mobile app developer, most of this is out of your hands. However you can take a few small steps to help users ensure their PHI is protected if they should lose their phone. Using the lock screen In order to secure data on an iPhone (for example), users must use a passcode to lock the handset when not in use. You can’t control whether a user enables this functionality, but you can recommend that users who install your app enable the feature. An easy way to do this is suggest that the user turns on the passcode lock setting in your welcome email to new account holders. Enabling remote wiping of lost phones Again, not something you can control yourself, but as in the example above you can help users make their phones more secure by taking advantage of some of the built-in functionality of their device.
• 37.
  Wearable Applications10 Wearables arepopping up left and right. From bands, to watches, to shirts, earbuds and more. All of these devices have the opportunity to collect PHI and require HIPAA compliance. While many will choose to initially collect anonymous data that doesn’t require HIPAA protection, the need to add true utility to the devices will likely push many of them down the road to compliance. As an application developer for wearables it’s important to consider whether the data you’re collecting now will remain anonymous (such as a simple pedometer report) or if you’re building something more ambitious that requires a larger set of personalized data that will be transmitted to HIPAA covered entities (PHI). If it is the latter, you’re likely better off building the software for the wearable in a HIPAA compliant environment to begin with, to protect against unforeseen use cases, unexpected PHI, etc. Considerations for wearables Today’s wearables are typically “always on” with data presentation layers that are outside of a protected lock screen or similarly private state. Therefore careful consideration needs to be taken related to how and when health data is presented on the device. Alerts and notifications Much like the push notifications on mobile devices, andy alerts generated by your application should be anonymous in nature and devoid of any PHI. 31 Wearable Applications
• 38.
  32 Wearable Applications Proactivelypushing PHI as part of an alert opens up all sorts of privacy concerns. What happens if the device is on a desk at the office, for instance? Default displays Similarly default displays should be carefully considered. A default display contain PHI is a big privacy issue. Even more mundane and typically anonymous data can be troublesome due to the fact that the device is on the person. For example, heart rate isn’t really an anonymous data point when it’s being tracked in real time on the watch face of the person wearing it, now is it? APIs and data sharing One of the most exciting aspects of wearables may be in patient health management and compliance (e.g. does the patient get their exercise in per the doctor’s orders?) In order for these apps to be used efficiently in this use case they need to talk seamlessly with the applications and software being run by covered entities. Covered entities and their business associates are required by law to be HIPAA compliant, so any application hoping to connect to one of these entities as part of patient care must be HIPAA compliant. Medical devices It is possible, based on the features and functionality that you include in your application or wearable device that it may actually be classified as a medical device. It’s important to look up FDA regulations and check whether your app will be considered to be a medical device or not. If it does fall under those definitions it may require FDA approval which brings with it a whole host of further regulations. Don’t launch your app until you’ve determined whether or not you are safely outside the
• 39.
  33 Wearable Applications FDA’smedical device classification. Data encryption Because most wearables lack a user interface to add or manage security features on the device in the event it is lost or stolen, it’s important for wearable software developers to take the appropriate precautions to encrypt the data on the device as the default. Data synching HIPAA requires that data recovery be possible in the event of a disaster or emergency. Therefore, depending on the device you are developing for, you may want to take advantage of proactive synching features instead of waiting for the user to synch the device themselves. If the device enables background synching over bluetooth or while connected to the main device it’s recommended that you take advantage of that opportunity to synch your user’s data automatically.
• 40.
  Apple HealthKit andiOS 811 Apple is reportedly set to announce iOS 8 as part of their World Wide Developers Conference (WWDC). One of the expected software elements of iOS 8 is HealthKit, a centralized location of health management information such as sleep records, emergency contact information, hydration and more. HealthKit, from early reports, appears to be similar to Passbook, an application that lets users manage things like airline boarding passes, concert tickets, and more via the app. Select apps and partners, such as United Airlines and Eventbrite, are able to push their application data into Passbook for use there. Learn more about HealthKit and Health. TrueVault iOS 8 SDK In anticipation of the new health-related features for iOS 8 and HealthKit, TrueVault is gearing up to being development on an SDK for iOS 8 in order to launch it in time with the developer release of iOS 8 this summer. If you’re planning on building a health-related app for iOS 8 and/or HealthKit, you can sign up to be notified when the TrueVault SDK launches. 34 Apple HealthKit and iOS 8
• 41.
  35 Apple HealthKitand iOS 8 iOS 8 health-related announcements Apple HealthKit announcements • Apple Announces HealthKit + Health App • HealthKit API/Fit Sample App Code - Apple Developer Library
• 42.
  About TrueVault12 TrueVault isa secure API to store health data. We make HIPAA compliance easier for healthcare applications. Built for Developers Like You Store and search protected health information (PHI) in any file format with a simple RESTful API. No pre-defined schemas to follow. HIPAA Compliant We handle all of the technical requirements mandated by the HIPAA Security Rule. Typical integration takes days and saves months of dev time. BAA + Insurance TrueVault will sign a Business Associate Agreement (BAA), and protects customers under a comprehensive Privacy/Data Breach insurance policy. 36 About TrueVault
• 43.
  37 About TrueVault TrueVaultis great for: Startups TrueVault was built to help startups simplify the complexities of HIPAA. TrueVault will save you hundreds of dev hours. Focus on building your software’s core functionality, and let TrueVault protect your data at HIPAA-security levels. Mobile Apps Store your app’s protected health data in TrueVault. We take care of HIPAA so that you can focus on creating healthcare apps on any platform. Web Apps You don’t have to worry about setting up and maintaining your own HIPAA compliant application stack. TrueVault will handle the Physical and Technical Safeguards required by HIPAA. Wearable Health Tech Devices Emerging technology dances the line between consumer health data and PHI. Sharing data with a HIPAA-defined Covered Entity (such as a doctor) makes the data PHI and it needs to be protected at HIPAA-security levels. Why people like TrueVault “Becoming HIPAA compliant as an early stage organization was a daunting task, until we found TrueVault. Their turn-key API has allowed us to check this box and get back to focusing on our core product and offering.” — Edith Elliot, Noora Health
• 44.
  38 About TrueVault TryTrueVault for free We have a free, no credit card required trial that lasts as long as you like. You can develop on it at no cost. Only pay when you activate your account by signing our business associate agreement. Once live, pricing is pay-as-you-go, just $0.001 per API call. See pricing examples here. Try TrueVault today