Service Apps and the Dashboard

With Noah 4.12 HIMSA has added the ability for Service Apps to send alerts and notifications to Noah. Business systems integrating with Noah 4.12 and newer are required to support service apps and the Noah Alert Dashboard. HIMSA's certification policy statement does provide some flexibly on the timing of required implementation, please see section Business System Adoption of Newer Versions of Noah for more details.

Above: Entries in the session list have been made for patient Amy Connor, by a Service App. The Dashboard icon (the “Globe”) has the number “4” on a red background, indicating that there are 4 unread alerts.

Above: Shows the alerts for the patients, and the corresponding (if any) entries in the session list. The Dashboard is in many ways like an inbox in an email app.

Service Apps

First, a few definitions:

Manufacturer. Generally refers to a hearing instrument manufacturer. It could also mean an audiological equipment manufacturer or any general HIMSA member company.
Manufacturer Backend. An application or system provided by a hearing instrument manufacturer. A Manufacturer Back End is used to facilitate hearing care services between Noah, Hearing Care Professionals (e.g. audiologists), Manufacturers, and patients. This system is generally understood to be a larger system controlled and maintained by the hearing instrument manufacturer. However, the Manufacturer Back End could also be a smaller system such as an MS Windows-based Noah compatible fitting module.
Service App. An application that uses the Noah Web Api to communicate with Noah. In most cases, the Service App is expected to be controlled by the Manufacturer Backend. In contrast to other types of apps using the Noah Web Api, a Service App can be permanently logged in, and thus does not need user interaction.
Notification. A message sent from the Manufacturer Backend to Noah via the Noah Web API. The Notification can contain an Alert (a short message that can be viewed on the Dashboard) and/or an entry in the patient’s journal (for example a Journal entry or an Audiogram).

How does a Service App differ from the typical Noah Mobile User Interactive App?

A Service App uses the same Noah Web Api, but differently:
- A Service App must register as so. During registration, the Service App must specify (to the Noah installation it requests access to) which level of data access it requests. It is up to the administrator of the Noah installation to grant or deny this data access. The administrator can always revoke a grant/denial. See ‘level of data access’
- Authentication does not take place with an interactive user rather is facilitated the the approval process (see previous point)
- A Service App cannot use the Himsa AccessLayer.

A Service App can do most things a User Interactive App can, but is primarily intended to, in prioritized order:

Provide a way for the Manufacturer Backend to send Notifications to a Noah installation.
Make it possible for the Manufacturer Backend to monitor relevant events (for example addition of new patients or journal entries). See also ‘level of data access’.

Level of data access: Events regarding certain types of data (data types 129 Selection, 130 Selection, 131 Fitting, 132 Fitting, 133, 135, 136, 137, 258, 300, 301, 302 and 303 ) are only sent to the Manufacturer backend if they originated from a module from the same manufacturer. Meaning: One cannot “eavesdrop” on the amount of communication with other manufacturers' modules. Other events (e.g. from Audiograms and journal entries - data types 1 and 256) are always sent if requested.

When a Service App registers, it must specify which types of data the app should be able to interfere with, and if the Service App can read/write the type of data and if the Service App should receive events when data with the given datatype is manipulated.

Above: List of apps.

Above: Access rights for the ServiceAppSample app.

HIMSA provides a ServiceAppSample application (incl. program code) that demonstrates the workings of a Service App.

Dashboard

As mentioned above, the Dashboard adds an inbox-like functionality to Noah. Alerts can be sorted, read, and assigned to users. Alerts can be associated with sessions, which can be opened from within the Dashboard. Once an alert has been dealt with, it can be removed from the Dashboard.

Implementing GUI for Dashboard Alerts

Noah Alert Dashboard Alerts are generated outside Noah, received by Noah and then stored in the database, alongside other data objects (actions, patients, etc.).

By use of methods in the BusinessAPI, it is possible for a business system to read and manipulate the Dashboard Alerts.

The BusinessAPI can also, via its event framework, notify business systems when alert related events take place.

There is currently one approach to implementation of GUI for Dashboard Alerts:

Use the Dashboard control provided by Himsa.

Q: Can I create a custom Dashboard for my business system?

A: Currently, this approach is not supported. HIMSA may consider custom dashboards in the future if there are requests for it. Additionally, the Dashboard and Alerts are new to Noah and to hearing instrument manufacturers there is a good chance that features may need to be adjusted as we gain more experience.

Using the Dashboard control provided by Himsa

It is highly recommended looking at the code (especially the file ‘DashboardService.cs’) for the Sample Business System (provided with the Noah installation files).

This is the approach that is used in the Sample Business System. The control is in BusinessSystemExternalControlsLibrary.dll.

Embed the Dashboard control in your own window.
Make your own implementation of a DashboardService that complies with the IDashboardService interface.
For updating Dashboard Alert related information outside the Dashboard control, also look at OnBusinessAPIEvent in the BusinessAPI, and the event types AlertAdded, AlertUpdated and AlertArchived. These can be used to keep the GUI up to date when new alerts are received.