...
Excerpt |
---|
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:
How does a Service App differ from the typical Noah Mobile User Interactive App?
A Service App can do most things a User Interactive App can, but is primarily intended to, in prioritized order:
Level of data access: Event regarding journal entries 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 if journal entries of when data with the given datatype are 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:
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.
|