Overview of Transparent Noah

Owned by Andrea Dennis
Last updated: Dec 14, 2022 by Scott PetersonVersion comment
4 min read



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.

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” to not allow a Patient requested to be 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 BusinessAPI NameSpace in the BusinessAPI.chm file.

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 datam 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 another 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, the module, 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.

Comments:

Seen from the Business system, it is necessary to implement the ability/functionality to login and select a patient initiated from the Noah Client. In order to do this, a preferred manager must be installed to Noah, and this manager must be able handle the methods defined by the IBSCallBack.

The ModulesCanSwitchPatient property

The name of the property is unfortunately not the best name – since it implies that the Module can switch the active patient. This is NOT the case. A module can only request that the Patient is switched – and this request is sent to Noah Client through the Module API. Noah Client will ask the Business System if it is OK to switch the Patient. If the Business System reply is yes, then Noah Client will actively try to switch the patient (The flow is to next ask all open modules if they are ready to disconnect and then actually switch the active Patient).

It is mandatory to support the transparent methods in the database assembly. The module must be able to “SetPatientIdentification” and “GetPatientIdenfication”.

The ModulesCanSwitchPatient property is default set to “True” in any Noah installation. The Business System can set this property to “False."  If the ModulesCanSwitchPatient is set to “False," then ANY module that requests that a patient is set active will be informed this is not possible from Noah Client and will have to handle this.