Noah 4 Transparancy

Noah 4 modules are able to take advantage of the features and functions available for “Transparent Noah”.  The overall idea behind Transparent Noah is that the end user can start the module directly from the Desktop without starting the Noah GUI (Noah System or the Business System). Noah is always running as a service but the user will not see or know this.

It is the module’s responsibility to register and connect to Noah when it is activated and once the connection is done Noah will evaluate if a user is logged in or not, if not, then Noah will ask the user to log in and this dialogue is the default User manager dialog provided by the Business System.

Prior to Noah 4.9 Noah would remember that a user was logged in, even if all modules and Business System have disconnected, but only for 2 minutes. With Noah 4.9 and newer this is not the case and the user will be automatically logged out. This change was made as the previous implementation was considered a security risk.

When a module connects to Noah it can request that a certain patient is set as the active patient in the Business System. In order to do so the module must know some exact identification for this patient. The identification is data that the module itself labeled the patient with, for example, when the first fitting was saved. The request can only be fulfilled with the acceptance of the Business System and the Business System can always reply “No” to a request of this kind. Noah Client has a property that the Business System can set to “false” in order not to allow that a Patient is requested set by the Module. Then the flow below will stop when the module requests that a Patient is set active and Noah Client will always reply “No” to the Module. The property is called ModulesCanSetPatient and is a documented property in the Business API documentation.

The Noah database contains room for modules to be able to place/label all patients with identification data, like the HI serial number or other unique data that can be read in the HI next time it is attached.

This means that for instance a fine tuning session can be done in an easier workflow:

1. The module is started from the desktop

2. The hearing instruments are connected via NOAHlink

3. The module reads data – e.g. serial number in the hearing instrument

4. The module connects to Noah

5. The module requests that a patient with certain data (serial number) is set active

6. The Business System activates the patient (There is a process for this.  See if other patient is active and other modules are connected, if not, then activate)

The module should clearly display the active Noah patient when it has connected. Since Noah is transparent, the user does not have any other places to see the active patient.

It is recommended that after the module has connected, it asks Noah about the active patient and immediately shows the patient data in the GUI (e.g., in the frame or having a patient banner).

If it is not the module itself that has requested that a patient is activated it is recommended that the module requires that the user accept the active patient and if the user replies “no”, handles this.

The patient can be changed in different ways. One way is described above by letting the module request that a patient with certain identification be set as active. Another is to let Noah show the registered Patient Manager.  This is a more simple Business System provided GUI that lets the user search and select a patient from the Noah database. In Noah System the module has the option to request that the Patient Manager is opened with a certain “Skin” (font and color) that matches the module. The User can also simply open the Noah System main GUI or any Noah 4 compatible Business System and select the Patient from there.