Personal data and HIPAA compliance information

Effective Date: 7/1/2021

Purpose

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a United States federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient's consent or knowledge.

This document outlines the tools and processes Xchart, Inc. (operators of Xchart.com) has in place have to secure sensitive patient information and comply with HIPAA.

Encryption of data

HIPAA states that data is encrypted both in transit and at rest.

• Encrypted in transit: All application traffic for all of our apps and services to Xchart.com are encrypted via HTTPS. This includes:
  • Our case editor web app
  • Our case manager web app
  • Our API that both of the above use
  • In addition, any non-HTTPS traffic is redirected to HTTPS.
• Encrypted at rest: All user and patient data is stored using cloud services provided by Google Cloud. Not only are these data-centers physically secured, they're on a specific list of services that Google has identified as being fully HIPAA compliant. All services operate and store data using services explicitly listed there.

Data should only be accessible by authorized users

This is always the toughest part, but what follows are the systems we have in place to mitigate risks of unauthorized access. They are organized below, grouped by attack vector.

• Unauthorized access through third party scripts, XSS: We employ a Content Security Policy (CSP) that limits scripts to only be loaded from trusted domains. Additionally, load very little 3rd party code from external sources at runtime. For example, we don't even use any 3rd party scripts for analytics. The only real exceptions to this are as follows. And even these are only loaded when needed:

  • Stripe - Industry standard payments processor.
  • Firebase Authentication (A Google Product) - We don't want to store anyone's password, so we leave this up to the teams of security experts at Google.

• Unauthorized access through user accounts by compromising the user database:

  • User accounts and passwords are stored by Google using their "Firebase Authentication" systems built specifically for storing and validating user credentials.
  • As a result, passwords are never stored in our systems directly. In fact passwords never pass through our application servers. Instead, passwords are validated from the browser directly with Firebase Authentication's account service and our application receives a token that we can use to retrieve proof of that validation after a successful login attempt.

• Unauthorized access by knowing or using computers to repeatedly try various passwords

  • We do "bot detection" using reCAPTCHA. This is another Google product for helping differentiate between a human attempt to sign in (or perform another sensitive action) and a "bot" software program trying to gain access to an account. We're using reCAPTCHA 3 which is the latest (and most sophisticated) available version at the time of this writing.
  • Even if the password is compromised, we require Multi-factor Authentication for access to patient data. In order to access an account, a user has to prove not only knowledge of the email and password, but also the ability to receive an OTP (one-time password) sent via SMS or email to the phone number / address associated with the user's account.

• Unauthorized access from using an idle computer left signed in

  • After a period of inactivity users will be automatically logged out of the site and will have to re-authenticate(much like your online bank).

• Unauthorized access from another organization's poor security practices

  • When designing database schemas it is common to store resources by type. For example you might create a single "patients" database table where all the patient information is stored as entered by multiple customers. This is not what we do. Instead, all medical-related data from each customer organization gets stored in its own dedicated, separate datastore. This dramatically reduces risk of accidental "leakage" of data from one organization to another. If a user from another organization mismanages their account and someone gains access to their account, only the records in that organizations datastore could be compromised. This limits the possibility that another user's poor security practices puts your patient's data at risk.
  • API access is maintained through API authorization tokens. These tokens allow us to track roles, authorizations, and organization membership(s) of the grantee. Each call to fetch data from the API checks these values to ensure the user is allowed to do the operations requested and ensures that the token has not expired.

• Access through compromised secrets:

  • All "system secrets" such as API keys, etc are stored using a tool designed specifically for that purpose that is only made available to the server at runtime. They are not stored in the application code itself in the version control system.
  • The production secrets are not accessible even to developers working on the codebase unless specifically granted.
  • Development is done on separate systems that mirror production systems, but use different secrets and fake medical data.

• Access through "inside knowledge" of the codebase:

  • Code that goes to production is thoroughly reviewed and tested.
  • No back doors. We avoid creating systems that allow secret backdoor access for "admins".
  • Access to the code that runs the API is, is in itself, very access restricted. It is only available to developers who need to work on the system and as previously stated, the code bases themselves do not contain "secrets".

• Access through a compromised server:

  • We vet our use of 3rd party libraries in our server code. This limits the surface area of sources of potentially vulnerable code.
  • We audit these 3rd party libraries for known, registered vulnerabilities, using npm audit which compares our list of dependencies (and their sub-dependencies) against a large database of known vulnerabilities.
  • We use the Principle of Least Privilege to limit what our running servers have the ability to do. Using Google Cloud's IAM policies we limit data access of the servers themselves to the minimum required amount. So even if servers are compromised the potential damage is as minimal as possible.