Generic filters


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 Authorization header).

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.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.

Qoltycontracts a number of independent auditing organizations:

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.