Full Business System Integration – Procedure

Test Documents

In this flow chart the member company wishes version 1.0 of the business system to be certified and schedules a date for HIMSA to perform the testing. Before the software is submitted to HIMSA the member conducts conformance testing which stresses the software for the proper integration with Noah. During this process the member company will record the completion of each test step. The completion of the test steps can be performed by a human or automated tester. 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 negative/critical manner. If the HIMSA testing is completed successfully the business system will be granted certification. HIMSA will publicly list the business system as certified. If the test is not completed successfully or the member company simply wishes to have HIMSA perform a preliminary test the certification will not be granted. When the company develops a new updated version then the member company can start the process over.  Business System developers are required to submit their newest version at least once per year (12 months) to retain certification.

Minimum Yearly Submission

Each business system licensee is required to submit a new conformance test and schedule an integration test with HIMSA at least one time per year if the system has released a newer version of the system. If the system fails to submit for a new certification at least once per year and a new version(s) has been released to end users HIMSA will revoke all previous certifications.

Q: Why does this requirement exist?

A: HIMSA has received a great deal of complaints from hearing instrument and audiological equipment manufacturers. The complaint is that the version of the system being used for testing by HIMSA is greatly out of date and this raises a great deal of concern while these companies are investigating possible integration problems. This requirement provides a more up-to-date system available to HIMSA to provide better testing.

Q: My Noah related code in my system is very separate from the code which provides my other system features. My company updates non-Noah related features more often. If I have made several releases of my system without touching the Noah related code am I still required to submit a new version to HIMSA once per year?

A: Yes, all other companies testing against your system have no way of seeing for themselves which code has changed in the different versions of your software.

Business System Adoption of Newer Versions of Noah

HIMSA does occasionally make larger changes to the Noah 4 Engine to either support new features or to stay current with changing technology needs.  At the time of this original notice the following more recent examples were relevant:

• Noah 4.5 introduced support for Noah Mobile User Interactive Apps.  A new feature allowing platform independent applications with the ability to exchange data with Noah.

• Noah 4.10 introduced a new networking infrastructure used between Noah clients and servers.  This change was made to provide a more modern approach to networking.

  • Noah Service Apps were implemented but as a Beta only feature.

• Noah 4.12 introduced support for service apps and the Noah Alert Dashboard

As HIMSA makes changes we do understand that there can be a larger impact for business system developers.  HIMSA does require that business systems support all Noah Engine features as it is very important to all module and app developers that Noah should work the same, whether the hearing care business is using Noah System or with business system that has integrated with Noah.  HIMSA also understands that there may be times where HIMSA has made a mistake or not fully understood the ramifications of a required change and would like to take this time to provide notice to how HIMSA can treat this potential issues.  HIMSA feels it is important to make notice to the rules we apply as it is important to our member companies that we apply the rules the same to all. 

Point 1 - If a Noah Engine feature is considered Beta in a version then it is optional for the business system to support that particular feature.  If the business systems wishes to opt-out of supporting a Beta feature then the company is required to inform HIMSA. 

Point 2 - If a new feature or change has been introduced and made available to HIMSA members with SDK information the general timing period will begin.  This can happen at the release of a pre-release or a new release version.

Point 3 - A bug in HIMSA software cannot prevent a HIMSA member company from gaining certification.  Certification can be granted but HIMSA does need to document a note attached to the pubic listing making it clear what the issue is and when it is expected to be resolved.  This is a long standing certification policy.

Point 4 - A HIMSA member company is able to raise an issue that a new feature or change represents a larger than expected change in order to support.  The member company may ask for a waiver to delay support of the new feature or change, in writing, with the following conditions:

• The general timing period is less then one year.  This period starts with the original release date of a Noah version.

• The waiver cannot create critical issues (as defined by the HIMSA certification policy), this may mean that the business system developer may need to create a solution to deal with the missing feature

• The developer must agree to fully support the feature or change in their next Noah version upgrade

• If the developer feels there is a shortcoming or bug in Noah the developer needs to inform HIMSA of the issue.

• The waiver can be included in the HIMSA certification process but will need to be listed as a note to the certification.  The note will include the fact that the developer intends to address the missing feature or change in the next Noah version upgrade.

• The version of the business system must support all other functionality.

The possibility to apply for a waiver with Noah 4.12 has expired as of June 12, 2020 

Examples with the assumption that the date is 20 Jun 2019: 

HIMSA occasionally needing support

HIMSA maintains a large number of business system installations.  Each business system is setup and run a bit differently.  HIMSA is dependent on receiving assistance from member companies when needed.  Historically, HIMSA has had many problems with business system installations ceasing to work for unknown reasons.  This is not an indication of the quality of the software but is most likely just regular support issues.

Q: How does HIMSA define reasonable support with getting assistance with business system problems on HIMSA’s test site?

A: HIMSA needs and expects the business system supplier to take action and provide assistance to HIMSA.  HIMSA expects to receive a response to a request in 1 weeks’ time.

Q: What will happen if a business system is deemed to not be responsive to support requests?

A: HIMSA Management will review the case.  If HIMSA Management determines that the business system has not been responsive then the business system will lose certification for the most recent and all previous certifications.  Business system can regain certification after the support issue has been resolved.

Q: Why does HIMSA take this stance?

A: Certified business systems are included in the certification testing performed with fitting and measurement modules.  Business systems that are currently certified are implied to also be certified with currently released certified modules.  If a business system test site is down and HIMSA is not getting help to resolve the issue HIMSA feels that end users are being misled.