 | 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.
...
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:
...
The possibility to apply for a Noah 4.13 Waiver will expire on
Noah 4.14 and Noah 4.15 do not include major changes that impact business system integration.
| Note |
|---|
Important Exception to this policy - See Noah Alert Dashboard, Service Apps and Noah 4 Compatible Business Systems |
...
Topic | Conclusion |
|---|---|
A business system, currently using Noah 4.4, wishes to support Noah 4.10 but is having difficulties making the necessary updates to support Noah mobile user interactive apps. | The business system cannot apply for a waiver. Noah mobile user interactive apps were first introduced with Noah 4.5 well past the 1 year general time frame. |
A business system, currently using Noah 4.9, wishes to integrate with Noah 4.10 but does not wish to support Service Apps as it is currently in Beta. | The business system does not need to support a Beta feature. |
A business system, currently using Noah 4.9, wishes to integrate with Noah 4.12 as soon as it is released. The business system developer can see that the Noah Alert Dashboard GUI changes will take some extra time that is currently not available. | The business system can apply for a waiver as the general timing period is less than one year. The business system developer agrees to resolve the issue in their next Noah version upgrade. |
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.
...