Master the complexities of cloud compliance with expert resources and relevant insights.
HIPAA Compliance at the Application Level
What’s your responsibility for HIPAA?
When a digital health product stores, processes, or transmits PHI, HIPAA asserts rules for how it should handle a multitude of security, privacy, and policy procedures, called “controls”. Demonstrating that your company and your digital health product meet all those controls is how you can call yourself compliant.
HIPAA controls can be conceptually organized into three levels: infrastructure, application, and company. At the infrastructure level, compliance is very heavy on technology. Your organization needs to meet certain controls around encryption, backup and disaster recovery, OS hardening, and so on. It’s a robust list. At the company level, it’s about implementing administrative policies.
At the application level, compliance is more of a blend of technology and policy. Your organization needs to adhere to basic security and privacy best practices. Some products exist to help with these controls, but for the most part, it’s up to the organization to do the right things and to coordinate an external audit to prove compliance at this level. There is also the broad concept of “access” that fits into this level: Does the product ensure that only authorized people have access to only certain sets of data? Oftentimes this is implemented using Access Control Lists (ACLs). It’s a broad topic but is also an important component to HIPAA compliance. Often a health organization— like a hospital trying to buy a digital health product—will do their own security audit to assess this level.
This guide dives into all the under-the-hood considerations you must manage at the application level to ensure your application meets the security requirements required for healthcare data. Following this guidance will help you to get through an audit process and help you engage with healthcare customers.
At the application level compliance is more of a blend of technology and policy. Your organization needs to adhere to basic security and privacy best practices
Understand your App Usage
The concept of access or availability to an application can be taken for granted in today’s technology climate, yet, healthcare has more quirks than other industries. It’s not as simple as listing an application in the Apple App Store, or one-click installs on Google Play. The interface isn’t necessarily commodity hardware like an iPhone, Sony PlayStation, or Windows home PC. It’s likely legacy, locked-down PCs or specialty consoles. If you are a mobile app, chances are iOS or Android won’t be available; instead, you’ll be dealing with old Java-based middleware, obsolete Blackberries, or Symbian.
How will your application be accessible to users from hospital systems? Understand the environment of the health system you’re hoping to work with. Are you providing your own hardware like Vocera or iPads for waiting rooms with your app installed? Or, will you instead need to support VPNs, firewalls, and virtualization as a way to tunnel access to your app? Does Clinical Care Object Workgroup matter to you?
How will your application manage access? Depending on the form factor supporting the application, additional access protocols might be required to support compliant administration of the product. For example, if you are a telehealth solution providing iPads pre-installed with your app, do you have a plan to work with each hospital’s IT staff to manage inventory, installation, and ownership of the devices?
Credentials and Provisioning
The value of a digital health product is the personal experience bestowed upon each user. That can’t happen without authentication and authorization.
Authentication is one of the primary threat vectors from malicious network actors, so getting it right is a major part of compliance. Often an existing healthcare enterprise already has an LDAP or Single Sign-on (SSO) mechanism in place, so your digital health application will need to integrate with those on a customer-by-customer basis.
Don’t forget, with onboarding new users all communication must be com- pliant and secure. For example, don’t share passwords or PHI via email, and understand how email is one of the most exploitable threat vectors that exist in today’s enterprise technology climate. Rotating passwords is a compliance requirement, so implementing a plan which helps users reset their password regularly and securely is a requirement.
How will you onboard new users?
Will you send an email? Is that email noncompliant or a security threat vector?
Will you need to integrate with existing LDAP/SSO systems?
How often will you require password updates and other changes?
Will everything be self-service or will you need to work with hospital IT?
Access Control Lists
Access Control Lists (ACLs) manage what data can be seen by which users. ACLs are enormously complicated because there are many variables: People, roles, geography, employment, BAAs, and more factor into who should see what when. It’s such a tricky thing to manage that is also disastrous when uncalibrated by even the smallest degree either way: On one side, you might get people who are upset they are blocked from seeing some data they should see. On the other side, if too much data is exposed, you violate HIPAA compliance.
ACLs are an application-level concern and a central part of both the design of the app and HIPAA compliance.
Who can see what data? Figure out the right balance of ease of use and compliance.
Does it change situationally by user role or location?
Ensure future scenarios are planned out today. It is hard to undo ACLs once the decided approach is set in motion.
Continuous auditing at the infrastructure and application levels is a require- ment for compliance. At the infrastructure level, it’s things like process logging. At the application level, it’s things like tracking which authenticated user saw what data when.
Keep in mind that these audit logs need to be stored in a compliant way as well since it’s probable the logs have PHI in them.
Track who saw what and when.
Are there situations in which you should let someone “break the glass” and access sensitive PHI? If so, indicate these.
If sensitive information is involved, consider writing reports to track for known unusual behavior.
Alignment with Customer Processes and Needs
Never forget the customers of digital health are most often behemoth organizations, like hospital systems, who have instituted endless processes, work- flows, and controls for every anticipated
scenario—the definition of bureaucracy.
Your digital health application will be more successful if you understand how to align with basic processes put upon its users.
We spend most of our time thinking about what happens when users use our digital health application. But what happens when they don’t or can’t use it?
It’s a provocative thought and one that enterprises think about. Those processes all wrap up into a contingency plan or, more formally, what’s called Business Continuity, which is a way of summarizing what happens when the application is unavailable and the path to make it available again. One important consideration with digital health, in particular, is how to deal with data loss.
What should users do in the event of downtime?
How can data be backloaded into the system when systems are available again?
User Training and Support
Training and onboarding are so fundamental, an entire industry exists with billion-dollar consultancies focused on managing the process. Your product will be no different: You must have a plan to train new users of the application.
How will you train users on your application? Online? In Person?
How will users get support if they are having difficulties? What is your SLA on providing that assistance?
Data Onboarding and Backload
Starting with a blank slate with an application is difficult, especially for com- plex patients or situations where longitudinal data matters (e.g. Pediatrics). Backloading past patient data is typically a requirement to adoption of the product. Without it, users won’t find value.
Consider onboarding data through interfaces, flat files, or manual transcription to reduce the burdens on the most complicated patients.
Run a basic cost-benefit analysis on using automated technology vs. humans.
Collecting User and Outcomes Data
“Lock-in” doesn’t happen as much as one would guess with healthcare soft- ware. Because of the complexity of landing a deal with a hospital or similar enterprise, the assumption is that once you’re in, you’re in. The truth is software turnover in those settings is quite common. Even EHRs, which can take years to implement and cost upwards of $20 million, have been known to be ripped out and replaced if they expose a critical failure or are deemed too cost inefficient.
A similar metaphor is sports teams. A common practice is once a new coach is hired, he or she prefers to bring in players that are “his or her” players, often cutting existing athletes from the team. A very common similar scenario exists within healthcare: When a new CIO or CTO is hired at, say, a hospital, it’s common that all old technology is “on watch” since it’s not his or her preferred choice.
Thus, this step of the application strategy is important for continued plan use: collect user data and outcomes data on a continuous basis so the successful impact on patient care and successful reduction in costs the product is delivering can be demonstrated. If the digital health application is not collecting this data to help tell that story then it is at risk of being replaced, which happens more often than you might think: The average tenure of a CIO at a hospital is around three years.
Upgrading the Application after Initial Deployment
If your digital health product is a Software-as-a-Service (SaaS) application where the delivery and access model is wholly owned, then upgrading is simple. In fact, it’s one of the main selling points of SaaS, and a reason SaaS as a paradigm has taken the world by storm.
The bigger concern is if the digital health product is deployed on-premises (on-prem) on technology where you, as the owner of the digital health application, don’t have control over its delivery or access. Upgrade cycles become an ongoing issue.
Hardware-based digital health products are another story altogether. Repairs, returns, replacements are all a thing software-only products don’t have to consider. It’s an ongoing concern that is also a cost center: shipping, new parts, and labor for repairs are all unpredictable costs software doesn’t have.
The point is to understand how updates and fixes to your digital health product will be administered as the key last step of an application strategy before you are off and running towards market adoption.
How to Prove Compliance
At the infrastructure level, it’s easy—and common—to find a partner who does most the work. Maybe you are deployed directly on AWS and handle most of the compliance obligations yourself. Maybe you utilize Datica’s platform to satisfy the entirety of HIPAA compliance at the infrastructure level. The point is it’s possible and common to let someone else take care of compliance at that level for you. The end result is they will prove compliance on your behalf. For example, Datica is HITRUST CSF Certified and has had three independent audits. Leveraging that is how you prove compliance at the infrastructure level.
But the mere fact of being a digital health company, and the very nature of building an application, means you own the burden of compliance proof at application and company levels. You can’t hand off the risks and compliance obligations to someone else, unfortunately.
The good news is proving compliance is possible. The bad news is it’s not free.
In short, the best way to prove compliance at this level is to get your company audited by an independent auditor, who will examine your company in totality, or the app specifically.
Need Compliance Help?
Talk to the experts.