Security

Security capabilities integrated in API Server include Authentication, Authorization, Access Control, Auditing, and end-to-end encryption between applications using the API services and the API Server.

Authentication

The API Server supports end user authentication through integration with Microsoft Azure Active Directory (AAD) services. Three classes of users are supported:

1. Providers and Staff

2. Patients and Authorized Representatives

3. Application Services

In addition to user authentication, applications using the APIs are also authenticated by presenting their application identifier and an application secret to the API services during the authorization process.

Provider and Staff User Authentication

Providers and staff can log in to a SMART on FHIR application that use the APIs provided by the API Server using same login credentials as they would with either athenaPractice or athenaFLow. These users are managed by the provider organization in their Business to Business (B2B) AAD tenant. This method is intended to be used by applications which are principally designed for use by providers and their staff, but can also be used by applications designed for patient use.

Patient and Authorized Representative User Authentication

Patients and their authorized representatives are granted access to use the APIs for a given patients chart log using an Azure Active Directory Business to Consumer account linked to their email address. They can log in to a SMART on FHIR application using the email address authorized to access the chart using a singular Business to Consumer (B2C) AAD tenant. This allows patients and their authorized representatives to maintain a single user identity across multiple organizations using the athenaPractice or athenaFLow product. Applications designed for patient access should account for the case that a single individual may have access to records for more than one patient within a given organization. For example, an individual may have access to his or her own records, those of his or her children, and those of his or her spouse, parents or other persons for whom he or she has been authorized to access. Applications should not assume that an individual may only be accessing his or her own records.

Application Service Authentication

Some applications log in to the API server directly to support their operations. The API provides servers such as these the capability to use a single login to manage the information they need to access through athenaPractice or athenaFlow with minimal application changes. This method may be used by applications providing portal services, secure messaging, patient facing registration or scheduling capabilities, et cetera.

Authorization

Authorization services use the OAuth 2.0 protocol as defined by RFC 6749 . Users accessing the system as a provider, staff, patient or authorized representatives are authorized via the SMART on FHIR protocol. When the user is authenticated as a provider, staff, patient or authorized representative, they must provide authorization for the application to use APIs using the SMART on FHIR Protocol. Only after the user authorizes access is access granted to the application requesting API access. A successful authorization provides the application with a code it can use for a preset period (usually an hour) before it must request a new code. If the application fails to request a new code before expiration of the previous code, it must request a new authorization from the user.

Service Applications are authorized by Resource Owner Password Credentials Grant defined in OAuth 2.0. The authorization process for the application is handled offline by the provider organization. The following steps must be completed.

• Provider organization must create a login with the API Server User role enabling the application to be authorized to the system. The provider organization must share the credentials created for that service application user with the application developer/owner.
• Service Application owner/developer must register the application at the Developer Portal and safely store the assigned client id and client secret.
• Service Application must be configured to use the client id, client secret, service application user and password. All 4 of these items are required for successful authorization requests to the API Server.

Authorization by Client Credentials Grant has been deprecated and will be discontinued in the future. The password credentials grant is more secure and enables API Server to include identity of the Service Application in audit logs.

Access Control

All access controls are managed using the athenaPractice or athenaFLow application. Individual provider or staff users are granted API access only to those resources reflecting information they otherwise have access to through using the athenaPractice or athenaFLow product. For example, a user that has access to registration information in the product, but does not have access to chart access will not be able to access resources in the patient chart such as medications, conditions, allergies, vital signs or lab results, but will be able to view and possibly change the resource associated with the patient.

Patient access controls are governed by the Patient role in athenaPractice or athenaFLow. When the API server is first installed, this role is configured to allow patients to access only certain APIs. For example, the user can read chart and practice management resources associated with the patient, but will not be able to update or create new resources associated with the patient chart. The default configuration for the patient role also prohibits patient access to sensitive documents. Access controls can be changed by updating the access for the Patient role in the athenaPractice or athenaFLow product. All patient or authorized representative users are given the same access to each chart to for which they are approved. One cannot grant or revoke access to specific capabilities for an individual user at this time.

To create a service user and grant them access, the provider organization must create a new user to athenaPractice or athenaFLow and assign them to the API Server User role. By default, these users will be given the access associated with that role. Access permissions may be granted or revoked for that specific user to provide more fine-grained access control, allowing for example, one service user to access only practice management resources, and another access to both practice management and clinical resources.

Audit

API accesses are audited in theathenaPracticeand athenaFLow audit logs, and are also recorded in the Meaningful Use activity log for use with quality measures. The first access to each type of resource for each authorization grant is recorded in the audit log during the period over which the access code is valid. Audit information is available to authorized users with System configuration permission via the AuditEvent resource.

Encryption

When installed or updated, the API Server is configured to only allow access via encrypted protocols. The API server requires that information access be encrypted using Transport Layer Security version 1.1 or higher. TLS Version 1.2 is strongly recommended.

Obtaining Application Credentials

Prior to using the APIs, an application must first be configured with its application credentials. Obtaining these credentials is a simple process that can be performed over the web by accessing https://mydata.athenahealth.com . Two credentials are provided: The application identifier, and the application secret. Both are stored in the form of a JSON Web Token that has been digitally signed by a certificate owned by Athenahealth. The application secret must be kept secure and should only be accessible to application developers. It should not be embedded within the application directly, but may be stored in secure storage on the system where the application itself is stored. This is to ensure that other parties cannot create applications that masquerade as those of someone else.

Access to Sensitive Information

Clinical resources can be marked as sensitive by identifying that the patient has a sensitive chart, or by including this information in a document that is configured to be a sensitive document. These markings in the product database manifest themselves in FHIR Resources as security tags.

Resources for patients whose charts are marked as sensitive will include a security tag containing the restricted (R) code from the HL7 Version 3 Confidentiality vocabulary. Resources for patients whose charts are not marked in this fashion will include a security tag using the normal (N) code from that vocabulary. The system will not show users restricted resources unless they have been given access to sensitive charts. There is no break glass capability.

Resources created in the context of a sensitive document will include a security tag using a code from a site specific vocabulary created from the confidential document type code list. Users without access to confidential documents of the specified type will not be able to access those restricted resources.

Patient and authorized representative users will be assigned the security restrictions associated with the 'Patient' role in athenaPractice and athenaFlow. The initial product configuration does not grant access to any information marked as sensitive to patients or their authorized representatives (via senstive chart flags or confidential document types). Organizations must determine what sensitive content will be available to these users after the API Server is installed.