Qolty is deployed in a HIPAA secure way. Let us explain the infrastructure: We offer a cloud-hosted version of Qolty. In this model, we take care of the infrastructure and you take care of the data. Your cloud deployment of Qolty will have the full set of features, and it can be configured in any way you need. If you prefer to have complete control over your infrastructure, we also offer a self-hosted version of the software. In this model, you supply Linux-based application and database servers, and you install and manage your Qolty deployment yourself. Under either of these models, you are in complete control of your data.
Hospital Hosting SMART Apps Qolty can be used as a backend for your SMART on FHIR applications. Build apps quickly or deploy apps written by other people against a backend that supports the complete SMART on FHIR specification. You can populate Qolty with data from other sources by taking advantage of FHIR endpoints or by using HL7 v2.x interfaces. You can also populate other systems with data generated and/or collected by your SMART apps by means of FHIR interfaces, HL7 v2.x interfaces, or other types of exports.
This page provides a quick overview of the concepts involved in how Qolty delivers a secure app for you, even on private label. It would be a good idea to read the whole thing before moving on to more specific implementation pages.
Security in Qolty has several components that work together to provide overall security. These are shown in the diagram below.
FHIR Listener modules are typically configured to require some sort of authorization information in each incoming request.
For example, a FHIR endpoint configured with HTTP Basic Authentication would expect an
Authorization header in each request, containing a username and password. The system can be configured to make access control decisions to block or allow access to specific groups of resources and operations based on the authenticated user. The system can also be configured to allow access to specific resources and operations by anonymous users (i.e. requests with no
FHIR endpoints can also be configured to look for an OpenID Connect (OAuth2) bearer token, and can make security decisions based on that authentication.
Both the JSON Admin API and the Web Admin Console require authentication, and an Inbound Security module is used to provide that authentication. For the JSON Admin API, the Inbound Security module is used to verify credentials that arrive with each request. For the Web Admin Console, the Inbound Security module is used to authenticate the user that signs into the console.
In order to authenticate users, Qolty needs to be able to communicate with some sort of user store where credentials are stored. By default Qoltycomes set up to use a Local Inbound Security module, which stores user credentials in the Qolty administration database. This is a good option and it works well; however, if you are integrating into an existing environment with existing user stores (e.g. a hospital with a corporate Active Directory database), you might want to integrate with that database in order to provide single sign-on capabilities. This is accomplished through the use of different types of Inbound Security modules.
By default, all actions are audited in Qolty’s audit database. The audit database is a set of tables in Qolty’s administrative schema that record actions, including what was done, who did it, when they did it, and where on the network they came from.
Outbound security modules are used to provide security to external applications. Currently the only Outbound Security module is the SMART on FHIR OpenID Connect module. This module can be used to sign users into a SMART on FHIR application that is integrated into Qolty. Optionally, this module could be paired with an external Inbound Security module in order to provide SMART on FHIR authentication via an external directory, such as a corporate Active Directory.
Securing the Engine
Qolty utilizes industry standard, HIPAA-compliant, and National Institute of Standards and Technology (NIST) recommended encryption standards to protect client information. Qolty is hosted in AWS Eastern Region and we have a business associate agreement (BAA) in place with Amazon. Our databases are 256 bit AES encrypted.
- The Qolty API scales to balance traffic across available application instances. Our endpoints receive automatic security updates, and we force HTTPS at the endpoint layer.
- Application code runs in Docker containers in the app layer. We deploy code changes without any interruption to traffic.
- Qolty applications and databases are redundant across AWS Availability zones, so if an outage occurs in one AZ, we failover with minimal interruption to traffic.
- App and database containers run in a private subnet, inaccessible from the outside internet. Access is restricted to the app and bastion layers. Internal database traffic that contains any confidential information is encrypted.
- Database filesystems are encrypted using AWS managed keys. Encrypted backups are taken nightly, or more often if you require, and stored in a separate geographic location.
Independent Third Party Audits
Qoltycontracts a number of independent auditing organizations:
- Penetration Testing to identify potential system vulnerabilities. This ensures any security issues are resolved before they have a chance to arise, and that data is properly guarded.
- Code audits are regularly done to scan our code base and find and address any security vulnerabilities.
- Intrusion detection is done by Threatstack to monitor all system-level events and report any incongruent activity, like a user promoting their privileges or modifying files.
Between the app and Qolty end-to-end encryption is done to secure all data transmitted over an HTTPS connection. Within the Qolty application, we support modern industry OAuth and SAML standards to authenticate applications that send to Qolty and to authenticate with applications that receive information from Qolty. We store sensitive credentials as salted as hashed values for an additional layer of security.
TCP traffic from Health Systems is encrypted via a secure VPN connection. We use an IPsec protocol to ensure all traffic within the VPN is encrypted and authenticated. The VPN is consistently monitored with a heartbeat to ensure the connection is healthy.
- All employees are required to encrypt their hard drive, making obtaining information from a lost or stolen computer impossible.
- Each employee completes mandatory HIPAA training and criminal background checks prior to employment.
- Two Factor Authentication is an optional security feature we provide to further protect data. The first factor is a user’s password; the second is a code sent to the user’s phone. With both, access to the dashboard is easy. If you’re a hacker who has someone’s password, but not their phone, access is prevented.
- Audit logs record all web events, meaning every query or access through the website is documented. This tells us what in Qolty is accessed, when, and by whom.
- Data concealment is another technique we use that makes directly accessing patient data doable, but difficult. We maintain logs of every message that moves through our system, but only show meta-data related to its processing—not the actual PHI content.