Security Q and A for Noah ES

1

When a Noah ES User uses Noah ES features, they are first identified, authenticated, and authorized by Noah ES via a standard OAuth process within a standard internet browser. A Noah ES-provided account can identify Noah ES users, or the Noah ES account can be configured so that all or some users can use Entra ID (Azure AD) or other systems that support OpenID Connect.

Logging into Noah ES

https://himsanoah.atlassian.net/wiki/spaces/NESP/pages/3166208001

https://himsanoah.atlassian.net/wiki/spaces/NESP/pages/3596877855

2

Today, a Hearing Care Professional (HCP) will likely interact most with Noah ES via the Noah ES Client. The Client is a Windows desktop application that has been used for the last 10 years with the on-premise Noah System 4 product adapted to exchange data with Noah ES services securely. This application is very important as it supports the hearing instrument fitting and hearing loss diagnostic software created by different HIMSA member companies.

Windows PCs are not provided by HIMSA. It is the customer's responsibility to obtain a PC that meets minimum requirements.

These applications are known as “Modules.” Modules typically provide features to diagnose hearing loss or to custom-program hearing instruments for a patient.

Modules are installed on each PC/Noah ES client. Each HIMSA Member company distributes these software applications. These applications gain access to the currently selected patient record. These applications are approved by the Hearing Care Business IT or other management staff by agreeing to install the software on the PC.

The Noah ES Client also provides features like adding and searching for patients. Most importantly, all the data stored by the Noah ES compatible applications are attached to a given patient record and are easily viewable as a combined patient history.

Modules Certified for Noah ES

3

Noah ES account administrators make use of the Noah ES portal to manage users, Apps, and other account settings.

https://himsanoah.atlassian.net/wiki/spaces/NESP/pages/1626734597

4

Noah ES also exposes a REST-based API so browser-based, non-Windows, and Windows applications can exchange data with a Noah ES account.

Access to this API is only made available to HIMSA Member Companies.

Noah Apps, using this API, do not automatically gain access to a Noah ES account. Each App must first request access and then be granted access by a Noah ES account administrator. This approval process includes approving access to different patient demographics and types of data. This approval is at the complete control of the hearing care business and can be edited or removed at any time.

Noah ES compatible Apps

5

HIMSA Member Companies can also create Service Apps (also known as Machine-to-Machine systems) that allow integration directly to a Noah ES account.

Stipulations for access are the same as listed in point 4.

6

Data processing is all processed within regional Microsoft Azure data centers. Paired regions are employed for redundancy purposes. All data in transit is encrypted by use of TLS 1.3. Below is a summary of the main components:

Clustered Microservices

Kubernetees cluster services are used to provide all of the business rules and processing of data while interacting with the the database. The cluster is prepared to scale up resources when needed. Noah ES is set up so that a fallback cluster is ready in the rare event of a major technical issue.

Azure MS SQL Database Failover Groups/Policy

Each NoahES account has its own database. Patient data is not combined with data from another account. All databases are set up so that data at rest is encrypted (AES-256).

Each database is replicated in a secondary data center region and configured in a failover cluster configuration.

Data backups are taken every 10 minutes for 30 days and weekly for 12 weeks. Backups are contained within both the primary and secondary regions.

Audit Trail Storage

Noah ES tracks all user activity (accessing patients, adding data, and adding new users) and stores this information in a separate storage from the patient database.

Data Residency

All data is processed and stored within the following geographic limits (Contained within MS Azure Regions):

• Europe | Europe West, Europe North

• United States | Central US, East US 2

• Australia | Australia East, Australia Southeast.

For example. A European Noah ES customer account will be provisioned in Europe, and the data will only be posted and stored in the European Azure region.

7

HIMSA employees do have access to Noah ES accounts to manage and attend to support issues. By default, HIMSA employees do not have access to see patient data and all management tools used are employed by APIs to the system.

https://himsanoah.atlassian.net/wiki/spaces/NESP/pages/2152005752

8

In the rare event that a HIMSA employee needs more access (e.g., for a technical issue), management approval must be provided, and detailed activity logs are recorded. If access to patient demographics or fitting/measurement is needed, the Noah ES account administrator will also be consulted for approval prior to the work.

9

Noah ES is constantly monitored for reliability. This monitoring includes simulating real user activity using the same software used by Noah ES users.

If an important event occurs, HIMSA will note it on the Noah ES status page. Noah ES accounts also have the option to subscribe to events for this service.

Noah ES Status Page