With Noah Modules, the established process has been in place for the entire history of the HIMSA certification program. The general premise is that the certification process is highly encouraged but not mandatory under the terms of the integration license.
The member company performs a conformance test to ensure that the module integrates with Noah well. HIMSA then performs an integration test on a test site where all other certified modules are installed on all supported Microsoft Windows operating systems. The main focus is to ensure that the module under test does not cause problems for other certified software.
Special case for critical issues found on business system test sites
As part of a module integration test the modules will be installed and tested for basic functionality on each of the certified business systems currently available. If a critical issue is discovered HIMSA will notify the member company as to the problem. HIMSA will still grant certification in these cases and inform the member company of the issue. The member company will then make their own determination if they wish to continue with the release.
Q: Why does HIMSA have this exception?
A: In the past, business system suppliers performed their own integration testing (twice per year). It was later agreed that it would be better for HIMSA to perform the integration testing in house and also to test modules on each business system at time of integration testing to ascertain any issues. Having HIMSA perform this test gives manufacturers a warning to possible problems. Previously, manufacturers would release a module and then a few months later find out about issues.
Certification of Patches
A member company may occasionally find an issue that needs to be addressed after a software product has been certified and released. Member companies are able to submit a patch for certification if all of the below conditions are met. Certification of a patch is more desirable as testing time and cost is significantly lower.
It is envisioned that patching of certified products will be used to fix emergency types of problems. HIMSA will make every effort to make certifying patches easier and quicker.
If these conditions cannot be met the member company is able to certify the patch as a new release.
The original version must have been listed as Certified by HIMSA or have successfully passed all testing but chose not to be officially certified, see section 1.7.3.1 for more details.
Software must first go through the normal NOAH conformance test before submitting to HIMSA.
The member company is required to inform HIMSA what types of changes have been made. The description must be written so that a HIMSA tester can understand and verify what has been changed.
Installation of the patch must be visible within the module so that an end user would be able to make the determination. For example, the patch level should be visible next to the version of the software (e.g. help > about).
Any feature in the software is allowed to be patched.
Software cannot be patched if the patch introduces a new product or new feature. New features or products will constitute a new version.
HIMSA will then perform a limited integration test. The test will consist of installing the patch, making sure that all other installed modules will launch, and an ad hoc test. The ad hoc test will focus on the problems reported by manufacturer.
HIMSA will not take the time to install the patch on the 14+ business systems. However, HIMSA will perform testing on a given business system(s) if the patch is addressing this type of issue.
Q:Can a patch fix an integration problem with the interaction between NOAH and the software?
A Yes.
Q: Why does HIMSA specifically state that “no new products or features” can be available in order to apply for a patch certification?
A: There are probably times when it is possible to introduce a new product or feature that would virtually not impact the stability of the software. However, it would be very difficult for HIMSA to have the technical expertise to validate that the changes being made are indeed safe. This would typically require good knowledge of the software code in question. As it is very important that HIMSA apply the same rules to all member companies, this simple, but the effective rule has been adopted.
Q: Can I add or update content related features?
A: See Editing and Adding section below.
Q: Can software be patched to fix an issue not related directly to NOAH (e.g. a problem with a fitting formula)?
A: Yes
Q: What if a patch meets all of the requirements listed in this section but does not install the en-US version of Windows. Will HIMSA still actively test?
A: In this case, No. HIMSA will accept the test report and explanation as proof.
Q: Will patched versions be listed on HIMSA Certification web page?
A: Yes, the patched version will be listed as a new certification entry.
Scheduling and Turnaround Time for Patch Tests
Since patch testing requires much less testing time on behalf of HIMSA advanced scheduling is not necessary, although very much appreciated. When the conditions listed above have been met please submit the software and documentation to HIMSA. HIMSA will conclude with the results of the test as quickly as possible. HIMSA will conclude testing within 5 business days.
Editing and Adding Content
It is possible to allow NOAH certified software to update or provide dynamic content without needing to be processed through the HIMSA certification process fully. Content is defined as any type of file that is static and does not control or influence the execution of code. It is envisioned that updated content will be provided online but it is possible for the content to be distributed in any matter (e.g. via a CD update). Below are provided a list of example types of content files:
PDF files
Product brochures
Web based help system
Sound files
Example Scenarios:
Fitting module ABC, version 4.1, is certified by HIMSA – following normal new module procedures
The module’s fitting system’s help system is internet based.
The module developers find that a help topic is incorrect and needs to be fixe
The module developers update the web content; this does not change the module version number. HIMSA does not need to be notified.
Q. What if a content update changes the version number of the software?
A: HIMSA would ask the company to send in a form stating the change and what the version number now is. The member company will also need to make this version available to HIMSA so that it can be installed on HIMSA's test sites.
Q: Can a hearing instrument database (product database) be updated to include new instruments.
A: No, this would be a change that would affect program execution
Q: Can a “best fit” formula be updated?
A: No, this would be a change that would affect program execution. This scenario can of course still be handled via existing patch certification rules.
Q: Can language files be added and updated?
A: Yes.