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.
| Drawio | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
Procedure
When a module is submitted for HIMSA Certification, it must first be processed through a full integration test. Before submitting the module to HIMSA, the member company
Before the software is submitted to HIMSA, the member conducts conformance testing, which stresses the software for proper integration with Noah. During this process, the member company will record the completion of each test step. A human or automated testing system can perform the completion of the test steps.
The member company will next submit a signed test report, test steps completed, and software to HIMSA.
HIMSA will then perform the test steps that HIMSA is responsible for. Generally, these test steps focus on the important integration points as well as ensure that the software does not impact other certified software in a negative/critical manner.
If the HIMSA testing is completed successfully, the module will be granted certification. HIMSA will publicly list the module as certified and also make the module available to other HIMSA member companies should they wish to obtain a copy for testing and troubleshooting purposes.
If the test is not completed successfully or the member company wishes to have HIMSA perform a preliminary test, the certification will not be grantedwill complete the conformance test and provide documentation to HIMSA proving that the test steps pass. The focus of the conformance test is to help ensure that the module integrates with Noah well.
The Integration test, performed by HIMSA employees, is focused on helping to ensure that the module does not cause critical issues for other modules, business systems, or Noah.
If the integration test is successful and the member wishes to obtain certification, then HIMSA will list the module and version on a public http://himsa.com listing. See requirements for Public Listing and Commercial Availability for further details. When the software is commercially available (date supplied by the member company), then HIMSA will also make the software available to member companies via special http://himsa.com credentials. Access to other company modules is made available for testing and troubleshooting purposes only.
| Info |
|---|
The diagram and text has been updated to a changed procedure. See numbered points 1-4 |
Patch Certifications
Member companies can patch/update a module previously certified by HIMSA, where the testing process used involved a full integration test. The main benefit of this approach is that the member company can deploy its update without needing to schedule patch testing with HIMSA, as this is no longer performed. Patch Certification is an option. A member company may always opt for a full integration procedure.
For the public, there will be no way to tell if a module version has been conducted with a full or patch certification process.
Point 1 - The first important criterion that must be met is that the version applying for patch certification cannot include any new features
Q: Why does HIMSA specifically state that “no new features” can be implemented to apply for a patch certification?
A: There are probably times when it is possible to introduce a feature that would 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: Is it possible for a hearing instrument fitting module (or similar) able to add new products that can be programmed with the patched version?
A: Yes
Other details
Installation of the patch must be visible within the module so that an end user can determine that the correct version is installed or patch is applied. Typical examples are:
The version number is listed (e.g., using semantic versioning x.x.x.3, where the x.x.x.2 was the previous version)
A label next to the version indicating an update (e.g. x.x.x.3 patch b)
Any feature in the software is allowed to be patched. This includes addressing issues with the integration with Noah.
Point 2 - A time limit for using the patch certification process is 365 days from the certification date that was performed by HIMSA using the full integration test process. The submission from the member company must be received by HIMSA within this time period. HIMSA is not able to grant extensions.
Point 3 - The member company has the option for a patch certification,
Point 4 - If the patch process is desired, then the member company is still required to conduct the conformance testing and paperwork and submit it to HIMSA.
HIMSA will not conduct any testing of the software. HIMSA is relying on the testing performed by the member company. HIMSA will ensure that the latest certified version of the module is installed on the HIMSA integration test sites.
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.