We are pleased to offer customers direct database access to the data stored in Bridge. This allows customers to access their data freely for a variety of applications that require a different interface than the SDK currently provides. It is still strongly recommended to use the SDK for building applications, particularly those that will be universal or need realtime data, but we also understand the benefits of direct access to data outside of our SDK. An example scenario where direct access would be appropriate is to provide a data source for a 3rd-party tool, e.g. a dashboarding or analytics application. We appreciate any feedback to improve the SDK in cases where direct access provides missing functionality or features.
To provide high-quality service and performance, this document provides guidance for accessing data outside the SDK. Keep these topics in mind when querying the Bridge database directly:
- The SDK provides an interface to log an audit trail in compliance with HIPAA rules. The analyst or developer directly accessing the database is responsible for providing HIPAA logging when using a direct connection.
- The SDK provides an interface to access data correctly and consistently. Direct database queries put the responsibility of correct data model use on the analyst or developer composing the queries.
- Use of the SDK ensures consistent performance of applications. Direct database queries could cause performance impact to applications running on a Bridge instance.
- Accessing data exclusively via the SDK provides the highest level of data security. Enabling direct database access introduces potential security risks for remote attacks.
Further details on each of these topics is provided below.
The SDK provides straight-forward methods to log PHI data access. The audit trail of these logs is available in the Service Tools application and allows for queries to determine the PHI viewed by a specific user, what PHI an application provided, or which users and applications viewed specific PHI.
It is possible for any direct database access user to see all clinical data, whereas accessing data via the SDK enable restricted access (via role-based authorization) so that only authorized and authenticated users have access to clinical data.
When using a direct connection, it is the responsibility of the analyst or developer using the connection to provide logging for HIPAA audit purposes. This requires an advanced knowledge of the Bridge data model, the results of the queries being run, and the audience viewing the results.
The SDK provides a consistent way to access data and ensures that the underlying table relationships and parent-child relationships are used correctly. It also provides a straight-forward approach to compose portable (customer-agnostic) queries and applications.
When querying the database directly, the responsibility for correct interpretation of the underlying schema and data model falls on the analyst or developer composing the query. This requires an advanced knowledge of the Bridge data model and logic to guarantee correct interpretation of query results.
When accessing the database directly, there is the potential to compose queries that adversely affect system-wide performance (e.g. extremely large result sets, queries that cause full table scans instead of using indexes, etc.) If application or system performance suffers as a result of direct access queries, we may recommend suspending direct database access and working on an alternative access solution (e.g. replicant db server that does not constrain primary database performance, etc.)
By default, Bridge database instances are configured only to allow connections from localhost. This prevents a variety of security problems by reducing the surface of available attacks on the database. This also means only applications installed by AI will have access to clinical data.
When configuring the database to allow direct access from a remote host, this reduces the security by enabling the external interface, thus opening the system up to an attack from a compromised (or imitated) remote host.
When configuring direct access, we recommend that the system be configured with the following parameters, per industry best practices:
- only allow connections via SSL
- restrict which externals hosts can access the system (via a whitelist)
- create a new / unique username and password for the remote access (not shared with other systems or users), in compliance with your organizations existing security policies