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:

Further details on each of these topics is provided below.

Guidance Details

HIPAA Logging

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.

Data Quality

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.

Bridge Performance

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

Data Security

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: