HIMSA is here to help. HIMSA recommends and assumes the developer of the module has done the following before the module development begins:
The developer has a basic understanding of Audiology or has access to an Audiologist.
HIMSA expects the developer to have read through the SDK. The SDK needs to be read first before looking at the Sample Module code.
The developer has worked with Noah to get an understanding of how Noah works.
The developer has looked at the sample module code and worked with the compiled version of the sample module in Noah system.
*Note: The Sample Module Code is a great reference but you do not want to base your module off of it.
Yes. The Module Conformance Test document and the Module Integration Test document will show you exactly what HIMSA tests during certification testing. These documents lay out step by step how a module should react in different scenarios. To see these documents,
click here.
Please see Constant Definitions. If you cannot find one that is for your data pick 257, Other Information. HIMSA can also help recommend one- What if I cannot find a data standard format for saving?
For some of the data types there is no data standard format defined. In these cases use 0. Ask HIMSA if you cannot find a format data standard and if 0 doesn’t work.
No. This is for hearing instrument manufacturers only. Therefore you cannot use the HI selection datatypes. You cannot use 129 and 130.
No. This is only for hearing instruments only.
HIMSA has basic knowledge of Audiology and is not the appropriate information source. Any Audiometric questions should be addressed by an Audiologist.
This is true that the SDK is geared more for these type of modules as they are the most common. This being said reading through the SDK will help you understand the whole process of getting your module to work correctly with Noah 4. Many of the items in the SDK are geared for any type of module.
No. HIMSA recommends you use the sample module as a sample. The sample module is meant to give you an idea of how to get your module to interact with Noah 4. Secondly the latest version of the sample module that has been released with the latest version of Noah may have features not supported in older versions of Noah 4. Your module may not work with older versions of Noah 4 due to this if you build your module off of the Noah 4 Sample Module.
No. Doing so can cause Noah or other modules to break. You do not need to distribute any of HIMSA’s files. If Noah is installed the Noah files you need are already present on the machine. Distributing HIMSA files will most likely result in a critical issue during a HIMSA certification test resulting in being denied certification.
Yes. It can be found here.
No. However HIMSA strongly recommends your module be submitted for certification testing. HIMSA’s certification testing is designed to test your module to make sure it works with Noah and other modules. Certification testing is a great way to find critical bugs before your module is released. Secondly there are end users who will not install a module unless it is HIMSA certified. These users know that HIMSA’s certification process is designed to make sure the module will cause them no problems and work like they expect.Click here for module API test documentation
Click here for important certification policy information
There are 3 supported Audiometric data standards in Noah, 100, 200 and 500. Noah has built in converters that you can call that will convert the data into a format your module supports. So in the question above you would call a converter that will convert the data from format 500 to format 200. Please see ActionConverter Object..
No. This is the module’s responsibility. HIMSA recommends that on launch your module checks to see if it is already open and connected to Noah. If another instance of your module is already open and connected then your module should stop any attempts to open a second time.
Yes. Please see Constant Definitions. - Will I break anything by running the UpdNoah.exe on a version of the Globob.stg that does not need to be update?
No. The UpdNoah.exe does a comparison. If nothing needs to be added to the globob nothing happens. The UpdNoah.exe also does not downgrade the globob.stg.
Please see Module Deployment. There is sample code in Noah 4 sample module too. Take a look at the code behind the “Get Noah Properties” button.
Q: Is there a way I can store general information in Noah that is special for my module?
A: Yes, The Noah 4 API provides modules with the ability to store and later read back data this information. Typical uses of this feature are:
- Preference settings
- module configuration data
The storage could be compared to system registry key entries but rather then being stored in the system registry the information is stored within the Noah database. The information will be available to any workstation that uses the Noah database.
There are three different levels of storage available.
- Manufacturer Setup - useful for module system wide information
- User Setup - useful for preferences and settings per Noah User
- Patient Setup - information that applies specific to a single patient record.
In all cases the storage is per module. This means that each member company is separate. There is no public or preferred public data standard.
What are the different Blob files? Below is the name, size, and explanation of the different blob files that a module can use when saving data to Noah.
*Note: The blob sizes cannot be configured. The sizes shown below are the maxim size limit.
MaxBigBlobSize: 3 MB - Action Public Blob
MaxFastViewBlobSize: 3 MB - Blob for Fast Data View
MaxManufactureBlobSize: 3 MB -
MaxPatientBlobSize: 1.3 MB - Patient Setup Data
MaxSetupBlobSize: 3 MB - User Setup Data
MaxSmallBlobSize: 3 MB - Action Private Blob
