Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
The information contained in this document is subject to change without notice.
HIMSA II K/S MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OR SUITABILITY FOR A PARTICULAR PURPOSE. HIMSA II K/S shall not be liable for errors contained herein or for incidental consequential damages in connection with the supply of, performance of, or use of this material.
This document contains proprietary information which is protected by copyright.
All rights are reserved. No parts of this document may be photocopied, reproduced or translated to another language without the prior permission of HIMSA II K/S.
This policy document is presented so that the reader can gain as much information they need or want to in regards to the HIMSA certification program. There are more links to additional information depending on the type of product being integrated with a HIMSA product.
This document does not require technical experience. This document is written with the assumption that the reader will fall into one of the following categories:
Software Business Manager
Project Manager / Team Leader
Quality Assurance department employee
Software Developer
Covered Products
The certification program covers both software and hardware – The general term “Solution” will be used in the rest of the documents. The following HIMSA products are included:
Noah
o General Noah (Engine) – Noah System
o Noah 4 Compatible Business Systems (full business system)
o WSI (Web Service Integration)
o Noah 4 and 3 API modules
o The certification process also covers hardware which is commonly used between many different manufacturers
Noahlink Wireless and NOAHlink
HIPRO (not a HIMSA product but included in testing)
Noah 4 Mobile API
Noah ES API
Certification can only be granted or maintained when related to a HIMSA supported version for a given solution.
Goals of the Certification Program
The most important goal of the certification program is that obtaining certification represents a quality testing program. It is very important that hearing care professionals, member companies, and HIMSA can feel that the certification program is reliable. The certification program will be continually monitored and updated to meet the ever-changing software and hardware environments. Changes will be made to address new issues and provide the most efficient test procedures possible.
The following is a list of goals for the certification program. These goals provide details as to how the polices are formed. Each item provides more details as to the goal:
1.01 – Hearing Care Industry is in control
Description
Hearing healthcare companies would like to be in control of defining how to best conduct quality testing. HIMSA and its member companies wish to promote quality testing that is represented by the HIMSA certification process.
Preconditions
There is a central authority to administer and track test results (e.g. HIMSA)
Rationale / What Problem Does This Solve
If the hearing healthcare companies are not in charge or have a significant voice, then there is a risk that other organizations will define their own test procedures that may be poorly designed or incomplete.
One quality assurance standard of integration testing instead of many.
Additional Description
1.02 – Prevent inter solution -company problems
Description
A primary focus of the certification program is to catch problems that occur between different company solutions before the solution is in use by HCP’s.
The certification program is not meant to specify how well a solution looks or acts as long as the solution does not have bugs or design flaws that adversely impact other solutions/member companies/HIMSA.
The certification programs ultimate goal is to prevent issues defined as “critical” from occurring. In order to be critical, it must have the possibility of adversely impacting a HIMSA or other HIMSA member company product.
Preconditions
This goal applies to solutions that are commercially available as well as in limited release (e.g. beta testing).
Rationale / What Problem Does This Solve
It is not within HIMSA’s scope to set rules for a member company on “how good” their solution is. HIMSA’s job is to test or define tests that determine how the solution interacts with a HIMSA solution and other member company solutions.
Additional Description
Example of where HIMSA is not concerned:
A fitting module crashes if a user selects GUI A, C, and then B in certain circumstances. The result of the crash does not impact Noah and other fitting modules can start without intervention (e.g. computer reboot).
In this case the HCP should be able to determine that this is not a Noah bug but rather a member company issue; therefore, the HCP will complain to the member.
1.03 – Member companies want to avoid critical problems
Description
Members do not wish for their software to cause critical issues for other industry solutions. They also do not wish to be impacted by another system offered by another member company.
Preconditions
The HIMSA member company is highly concerned about causing problems for other companies and believes that the HIMSA certification program will help avoid problems. It may be that they feel they have not caused any problems in the past and do not see the need to be certified by HIMSA.
Sometimes HIMSA assumes that the size of the company has an impact. There are some companies that have 50+ software developers with a full QA department to back them up. Then, there are some companies with 1 developer who also conducts the QA testing.
Rationale / What Problem Does This Solve
If a member company causes a problem for another system it is often considered negative advertising for the company that created the problem. But, sometimes both companies will disagree with who is at fault and they will blame each other.
Additional Description
Q: Is the certification program responsible for testing/certifying other solutions from non-member companies?
A: No, this is out of the scope of the HIMSA certification program
1.04 – HCP’s expect conflict-free solutions
Description
HCP’s expect that the solutions they use will not cause conflicts with each other. In a perfect world, HCP’s would like to never have a problem with software/hardware. But what is even more difficult is solutions from different companies causing problems.
Preconditions
The solutions being used are only considered when made by a HIMSA member company.
Rationale / What Problem Does This Solve
If there is a conflict between two different companies there is often finger-pointing going on between the two companies and the HCP is confused as to what to do. They do not get the sense that anybody will fix the problem.
Additional Description
HCP’s would probably like it if HIMSA could include the certification process to guarantee 100% bug-free solutions; however, this is not the aim of the program.
1.05 – HIMSA expects conflict-free solutions
Description
Just like a member company, HIMSA wants to avoid causing critical issues for member company products or be negatively impacted by member solutions.
Preconditions
Rationale / What Problem Does This Solve
As the organization that manages the certification program, it would seem self-defeating to not support and follow its own certification program!
In rare but important cases, a member creates a critical problem for a HIMSA product but as a paying member company to HIMSA, the member company strongly suggests that the problem may not need to be addressed or addressed as quickly as HIMSA would like it to be. It is nice for HIMSA to have well-established rules to follow in these situations, rules that are expected to be applied evenly to all companies.
Additional Description
In addition to the extensive QA testing performed by HIMSA, it does also follow the same certification procedures, examples:
Noah System tests as a fully integrated business system.
Noah 4 Audiogram module tests just like a normal audiogram module would.
1.06 – Certification with little or no outside company involvement
Description
HIMSA Members want to be certified with as little outside company (e.g. HIMSA) involvement as possible.
Preconditions
This is not a new goal, we assume it is implied but it is not written in the current policy handbook.
Rationale / What Problem Does This Solve
Releasing solutions on a tight schedule and on time is a challenging process. As soon as an outside process is involved, additional risk is added to meet the schedule.
Apps that also need additional approval (e.g. iOS store approval) further complicate releases.
Additional Description
Over the years HIMSA and the certification committee members have worked to find ways to reduce or remove test steps that are not effective anymore – typically due to technology advancement/changes. Historically the approach of being cautious to start and then relax has been taken.
1.08 – Quickly Determine Certification Status
Description
Before an HCP utilizes a solution provided by a member company they need a way to find out if the solution is HIMSA certified.
HIMSA will provide a method where interested individuals will be able to look up the certification status of a member company status. Additionally, the member company will have a method to list and promote their product’s certification independent of a HIMSA provided method.
Preconditions
Rationale / What Problem Does This Solve
An HCP may refuse to use the solution if it is not HIMSA certified.
A HIMSA provided solution provides a neutral third party convenient method to quickly lookup information. Member company technical support troubleshooting a problem involving another company’s solution may want to check that the other solution is HIMSA certified. If a product is not certified it may place doubt if the solution is performing as required.
HIMSA member companies may wish to have their own method to better promote the certification program and support for it.
Additional Description
Today, HIMSA’s most effective means is providing different searchable lists in order to quickly look up the HIMSA certification status via our web site page listing.
HIMSA does provide a certification seal logo that can be used by a HIMSA member company but in the past few years, interest has dropped.
There may be new more interesting ways to list certification as well.
1.09 – Data Integrity and Usability
Description
HCP’s, HIMSA and members place a high priority on data integrity. It is of the utmost importance that data is not corrupted or perceived, by a non-technical user, to be corrupted.
A high priority is also placed on the ability to read standardized data saved to Noah via other companies in a predictable manner.
Preconditions
Rationale / What Problem Does This Solve
If there is an issue that is found to corrupt data or give the impression, the effected party generally is very concerned and may easily lose faith in HIMSA and member companies’ ability to process their patient-related data.
HIMSA constructs tests for members and HIMSA to perform to make sure that shared data (e.g. data following the Audiogram data standard) is not only well-formatted but more importantly, tested to make sure that it is read and understood properly.
Additional Description
HIMSA feels that this problem has almost effectively been removed from the Noah environment but would never want to let our guard down.
HIMSA’s internal policy is that this type of issue is always regarded as a show stopper.
1.10 – HCP’s expect their data is secure
Description
HCP’s expect that their patient-related data is secure and handled properly. This is currently a topic that is not discussed in the policy handbook. HIMSA believes that this is implied today – at least from the perspective of Noah System. Noah compatible business systems often provide (or are required) a contractual promise about how the HCP’s patient and other related data will be used.
Preconditions
Handling data properly can technically be different depending on the locale in which the HCP resides but as far as Noah is concerned, meeting the requirements as outlined by US HIPAA/HITEC security mandates applies well for all locales.
HIMSA and members are not always responsible for all aspects, examples being:
Noah System has to provide a user authentication method but does not need to enforce that it is used.
HCP’s must have policies and procedures in place to determine which users should have certain rights – this is not our concern.
Rationale / What Problem Does This Solve
HIMSA believes HCP’s assume that the data contained in Noah is handled appropriately as there are no known issues where it has been misused. The data is appropriately secure with today’s existing interfaces.
With Noah mobile there are new possibilities for use of data. Although HIMSA is not aware of any member companies today, it is possible that a member company could create an app that may use data in a way that is perceived as improper in the eyes of the HCP.
Additional Description
HIMSA’s document “App Data Access Rules and Use of data” currently provides more details on this subject.
The main points about the use of data is assumed to be something like what is listed below:
1. Explicit notification of data copy. The app clearly makes it known in the GUI that the data will be transferred to another system and for what purpose.
2. Implicit notification of data copy. Through the use of the app, it is obvious via reasonable HCP use that the data will be transferred to another system. Examples being:
An order app where the pure tone audiogram is needed as part of the order and is shown on the order form.
A synchronization feature where the app will copy all or large subsets of patient data.
3. Service apps can work in an automated fashion and an interactive user is not necessarily watching what is going on. HIMSA will require contractual assurances that the app developer clearly state to their users, in writing, how they will use the data collected.
4. Data copied by 1, 2, and 3 above cannot be used for any other purpose than originally copied for. This also means that even if the data is patient de-identified (i.e. name is stripped off) it still cannot be used for any other purpose. Using the order app – audiogram example above, this would mean that the company copying the audiogram could not combine this audiogram with other patient audiograms to run analysis on hearing loss vs. types of instruments ordered.
·Note: Please keep in mind that most countries today have strict rules on the use of patient-related data (e.g. HIPAA). These rules will also act as a very powerful deterrent from inappropriate use of data. However, once data has become de-identified HIPAA no longer applies.
5. The HIMSA certification process can be fashioned to ask for details about what data might be copied out of Noah and then verify that either A, B, C is met. It will be challenging to set a rule as to what might meet the criteria for B but we can try.
Q: What happens if somebody breaks the rules?
A: This would mean that the app would not be eligible to receive certification status. If the app was already certified and a situation was found to be occurring afterward then HIMSA will reserve the right to revoke the certification.
1.11 – Easy access to other certified solutions
Description
As has existed since the beginning of the certification program, all HIMSA member companies will have access to other member company certified solutions for no charge. Access to the certified and commercially available solutions is only for testing and troubleshooting purposes only.
Preconditions
Only HIMSA member companies have access, not HCP’s. The member company is to only use the other company’s product to troubleshoot a reported problem or to use for internal Noah integration testing.
Access is provided for fitting and measurement modules and any software using the Noah mobile API. Today, Noah compatible business systems are not available via HIMSA.
Access is only available for commercially available products. If this is not the case it causes problems for members to list a product as certified if the solution is new and for competitive reasons the member cannot allows others to see it.
HIMSA provides access to HIMSA member company employees by individual user account (e.g. himsa.com account) via an elevated permission. All download activity is tracked per user.
HIMSA member companies are able to ask HIMSA for a log of download activity as it pertains to their software.
Rationale / What Problem Does This Solve
Used to troubleshoot a reported possible conflict with another company’s solution. With this access, the other member does not need to be contacted to gain access. If contact was necessary, it may signal to the competitor that there may be a problem
Members have the ability to recreate the exact test environment that HIMSA uses during integration testing – to help ensure that HIMSA’s testing will go smoothly.
Additional Description
Q: Can the App developer charge a fee for other HIMSA members to use the certified and commercially available product?
A: No
In some cases, the application will be publicly available (e.g. the Apple or Android Store) so there no need for HIMSA to assist. In other cases, HIMSA will plan on continuing to host a solution where the solutions can be downloaded from a user authenticated section of himsa.com.
Q: Is it possible to obtain access to products that are not certified?
A: No, HIMSA’s certification process only applies to products that have been certified.
Use of Licensing Systems to Control Access to Module Functionality
Some companies may wish to control access to module functionality via the use of a licensing system (e.g. a certificate code or online activation system). There is no issue with this type of setup as long as HIMSA and other HIMSA member companies have equal and sufficient access to features related to NOAH integration.
Q: What level of functionality must be freely available to HIMSA and other HIMSA member companies, upon officially certification, for testing and support reasons?
A: Any function or feature which relates to the reading/writing of NOAH Data or NOAH scenario (e.g. opening a module after use of another) interaction that can happen by end-users of the software in the field.
Q: Can a member company implement a licensing system and wish to have the option to grant access on an individual company basis.
A: Yes, the company can grant an individual access company as long as the company responds to requests in a reasonable manner. An example of this would be creating a license file that lists the user as a specific company.
Q: My application has a lot of features that have nothing to do directly with Noah, do these features need to be available to all?
A: No, if you wish to control access by different means (e.g. a license file or user rights) it is fine to not show features, as long as these features have no interaction with Noah (either reading or writing Noah related data). The version of the application must be same as what is certified by HIMSA.
1.12 – Certification cannot be revoked
Description
If a member company received certification then HIMSA cannot take it back.
Precondition
Certification was granted.
The certification was also gained without intentionally misrepresenting or misguiding HIMSA during the certification process.
The certified product does not break any contractual agreements in regard to the use of Noah data.
In the cases of point 2 and 3 above, the HIMSA Test Review Board will be consulted before HIMSA communicates a decision.
Rationale / What Problem Does This Solve
When the certification program originally began HIMSA was instructed to remove certifications if a critical issue was found at some point after certification was granted.
This was reversed because it created an unproductive environment where nobody would talk to HIMSA about problems because they were too concerned about losing certification. Additionally, member company employees not involved directly with HIMSA (e.g. Sales employees) felt betrayed by HIMSA.
Additional Description
If a critical issue is found after certification is granted HIMSA will post details about the issue publicly. Typically this is posted as a basic note attached to the web site listing. If the issue is found to be more severe HIMSA will pursue publishing the issue more broadly (e.g. send out a technical support bulletin to support engineers and end users).
1.13 – HIMSA is neutral
Description
HIMSA is a neutral 3rd party determining the course of action, the severity of the issue, and public documentation. HIMSA applies certification rules equally to all members and is clearly communicated to all interested parties.
During a certification test or after (e.g. an HCP related support issue) an issue may occur where HIMSA is unable to determine which solution is at fault. HIMSA will apply its experience as a neutral 3rd party to arrive at a productive resolution.
It is possible as well that the issue may be HIMSA related.
Preconditions
The only issues that HIMSA gets involved with are in terms of public documentation deal with critical issues that may occur with Noah or another certified solution.
Rationale / What Problem Does This Solve
Certification testing is often the last step in a product release and member companies need a fast judgment. As there is not another HIMSA member companies need HIMSA to apply rules evenly and equally.
Additional Description
HIMSA does keep internal track of past complex issues to help guide decisions in the future – a precedence of decisions.
If a member company does not agree with a HIMSA judgment it can appeal to the certification review board – which is currently the HIMSA Management Group.
1.14 – Promote common interactions
Description
The certification program promotes common interactions properly between HIMSA and member company solutions.
Preconditions
Rationale / What Problem Does This Solve
In cases where it is desirable to have a common interaction, the certification program helps guide member company integration implementation by designing appropriate test steps for member companies to use.
Additional Description
Examples:
Updated data events – An audiogram is updated while a fitting module is open. This may impact the fitting. HIMSA designs the test to draw attention to this possibility but leaves the reaction up to the member company as they see fit.
Current testing procedures include requirements for members to test their product against different measurement data records (primarily audiograms at this point). It is hard for HIMSA to always know how the member’s product uses this information but by requiring the testing we assume and hope that potential mistakes will be found. If there is a problem HIMSA does not consider this critical but leaves it up to the member on how to address the issue.
Critical Issues
A major goal is to avoid critical issues from happening to Hearing Care Professionals (HCP’s). In order for an issue to be considered critical two main conditions must be met:
The error must be consistently repeatable. HIMSA must be able to reproduce the error more than one time. HIMSA will routinely attempt to reproduce the problem on more than one system in order to rule out test system malfunctions.
The error must be reproduced using the software in a reasonable an intended manner. HIMSA acknowledges that almost any software package will crash if enough attempts and stress are applied. HIMSA will always test in a reasonable manner. This is accomplished by using the software as a typical end user would.
The following high level issues are considered critical for HIMSA certification:
2.01 - Causes Noah or a certified NOAH-compatible product to be terminated unexpectedly
Description
Problems that result in Noah or other certified software no longer responding to user input, closing down unexpectedly, being unable to launch, or simply locking up. HCP’s expect that software should not crash and also expect that they should not need to restart the software or worse, reboot the computer.
Preconditions
Noah or other certified software must be prevented from running as expected. Example of issue not being considered critical: The fitting module under test crashes, the HCP is able to continue using Noah and can also launch and use other types of modules. This would not be considered a critical error because it only made the module that crashed look bad.
2.02 - Fails to Release System Resources
Description
Noah compatible applications using system resources such as memory and other physical connections (e.g. USB and Bluetooth) must properly leave the hardware in a state which does not cause issues for other certified systems.
Preconditions
Must cause another certified system from working as the HCP would expect it to.
Rationale / What Problem Does This Solve
Additional Description
Example 1: Module does not release COM port
Audiogram module A connects to the audiometer on COM port 1. After the audiogram has been collected and stored in NOAH, module A is closed. The end user uses a com port switch box as they share COM port 1 with HIPRO. Upon switching over to HIPRO fitting module B is unable to access the HIPRO as the com port was not properly released by module A.
Q: Does this section apply to HIPRO and NOAHLink?
A: Yes, if a program does not properly release HIPRO or NOAHLink consequently causing problems for another program in which this device cannot be used, it would be considered critical.
Q: Would a Blue Tooth device be considered a communication port?
A: Yes
Example 2: Module leaks memory
Measurement Module A has been used for the last couple of hours. This module has a significant memory leak resulting in a large reduction in available system resources. Module A is left open and the user attempts to launch fitting module B. Fitting module B locks up during initialization. Since A is causing a problem for B module A would be considered to have a critical error.
2.03 - Changes configuration or initialization files in a way that interferes with the operation of NOAH or a certified NOAH-compatible product
Description
It is important that a certified software program not change commonly used configuration files or system files which will adversely affect another certified program. Error causes here could occur during software runtime or installation.
Some examples (but not limited to) are provided below:
Common System files (downgrading files)
Shared 3rd party software components
System Registry files, .ini files, etc.
Preconditions
Rationale / What Problem Does This Solve
Additional Description
Q: What if my software makes use of a 3rd party package? I am following their installation instructions but HIMSA has now found that other certified software is having a critical issue?
A: HIMSA has come across this issue in the past. The issue is most likely to occur where module A was designed to use version 1.1 of the common component. The 3rd party then releases version 1.2 but this new version introduces some backward compatibility issues. Module B installs version 1.2 causing module A to have a critical error. If this occurs HIMSA will place responsibility on the 3rd party software component maker.
If the 3rd party caused this mistake HIMSA would not be able to grant certification to module B. It would be the responsibility of the member company which develops module B to take this issue up with the 3rd party component developer.
In these cases, it is very likely that HIMSA will need to get effected company developers involved to determine which program is at fault. As in the text above, it could have been possible that the developer of module A did not follow the components SDK correctly thus causing the problem when the new component was released. If this is the case module A would be at fault.
Example 1:
A module distributes Noah interface components that are out of date. The distribution of Noah API components is not necessary nor is it allowed or recommended. In this case, the module installs and registers the common API components on a computer resulting in future modules from properly registering with Noah – The HCP is not able to install and use the module until the Noah installation is repaired.
2.04 - Causes Corruption or gives the HCP the impression of data corruption
Description
HCP’s need to count on the fact that their database is sound and is working as expected. There have been times in the past where modules have inadvertently stored data in the NOAH database incorrectly causing the database to be corrupt. Great strides have been made with NOAH 3 and 4 but HIMSA still places the highest priority on stability of data.
Preconditions
Rationale / What Problem Does This Solve
Additional Description
Example 1: Module indicates saved data but data is not saved
An HCP performs a binaural fitting session. The module, due to a bug, only saves fitting information for the right ear, but the left selection and fitting icons/actions are present in the session browser. When the end user goes back to reopen the session the left data will be missing. Even though the database has not been corrupted the typical end user would assume that there is something wrong with the NOAH database.
Example 2: Audiogram data incorrectly saved
An HCP uses Audiogram module A to save AC points. The module is set up to save HTL data (e.g. preferences set to use HTL). However, as the data is saved to NOAH the points are labeled as SPL. Fitting module B attempts to read this data but cannot use the audiogram. Fitting module B reports to the end user that the audiogram is unusable.
Since the Audiogram module stored data incorrectly and other programs cannot use it as desired, this issue would be considered critical.
Example 3: Module is unable to read data in another format
The currently selected patient record contains an audiogram stored in format 200. Fitting module A launches and is unable to read the audiogram, the modules states that there is a problem with the data. The fitting module is not able to read the data because it has not correctly called the data format converter (which is supplied within the NOAH framework).
2.05 - Saves Noah actions to the Noah database without populating agreed upon public data format
Description
Data fields defined as mandatory must be populated and must be populated with realistic values.
Preconditions
Rationale / What Problem Does This Solve
Additional Description
Example 1:
The hearing instrument module saves a hearing instrument selection without saving the model and serial number as required. With the release of Noah 4 a very popular feature which was requested for Noah System to display the latest device model and serial for the left and right ears. It has been a rule since the release of Noah 4 to populate this data as without it Noah end users feel that Noah is not functioning correctly.
Q: What if the hearing instrument does not have a serial number?
A: Then it is fine of course to not fill in the data.
Additionally, each type of Noah integration may specify special certification issues. Please see the conformance test document for the integration product you are working on for further details. In these cases the topic will be clearly documented in a “Special Certification Issues” section.
Public Listing and Inter Member Company Access to other Company Certified Software
There are different policies that cover the public listing of a certified product and how other member companies may have access to other company certified products. Generally, the policies are as follows:
Public listing / if a product is certified by HIMSA then HIMSA must have a way to publicly list what versions of products have been certified.
Inter member company access / certified products must be available for other member companies so that they can have theopportunity use they products for testing and troubleshooting purposes.
The text in this section applies to all products being certified.
HIMSA Test Sites and Administration
HIMSA has two offices that perform testing and administration for certification, Copenhagen Denmark and St. Paul, U.S. Solutions developed in North or South America are handled via the St. Paul office, all other countries are handled by the Copenhagen office.
Q: If my software is developed in Europe and the Copenhagen test site is booked for my desired test date is it possible for the U.S. office test site to perform the integration test?
A: No, HIMSA has attempted this arrangement in the past with no success. In the event that HIMSA has a question or problem the time difference eventually causes the test to drag out too long. In these cases both HIMSA and the member company found it to be an undesirable situation.
Miscellaneous
The licensee is invited but not required to attend the integration testing at HIMSA.
The licensee will receive up to 16 hours of integration testing per calendar year at no charge. HIMSA will assess a fee for additional testing. The fee will be calculated as an hourly rate that reflects HIMSA’s costs for such testing.
Reporting Results
If HIMSA testing is required HIMSA will report to the licensee the results within one week of the licensee’s submittal, barring exceptional circumstances.
In either case, pass or fail, the integration test report may include findings that fall outside the scope of certification testing but have a potential impact on the stability or ease of use of the product.
If the test fails the report details will be treated as confidential material.
If the test passes:
o For Noah 3 and 4 API modules and full business systems, the details of the test results will not be posted publicly.
o For Noah Mobile API applications and WSI based business systems test details will be posted publicly as documented in the respective test procedures.
The test report will be distributed only to the licensee that submits the software product for testing and will be treated by HIMSA as confidential material.
If the software product passes integration testing, HIMSA will grant the licensee the right to label the software product with HIMSA’s certification seal.
What if HIMSA finds a critical issue during testing?
If HIMSA discovers a critical issue with the software in for testing and it is determined that the issue lies within that package the software will not be able to be certified. When a critical problem appears as a conflict between two or more products, HIMSA will determine which product is the source of the problem. To assist with this determination, HIMSA may require the participation of the licensees involved to isolate and diagnose the problem.
A HIMSA Member company does not agree with a HIMSA decision
In the unlikely event that a member company does not agree with a HIMSA decision (e.g. determination of fault or interpretation of a problem), the member company can, as a next step, make an appeal to the HIMSA Certification Test Review Board. The Test Review Board will review the issue and render a decision based on viewpoints from HIMSA and the member company in question. Currently, the Test Review Board will consist of HIMSA Management Group members or employees they wish to appoint. The Management Group member consists of individuals for each of the 5 HIMSA partner companies.
Since spring 2006, no appeals have ever been made. HIMSA strives to be very fair. HIMSA only wishes to have a clearly know “next step” in the event of a dispute.
The other points apply to the test review board:
The Member Company must appeal HIMSA’s test results within 10 business days after receipt of the integration test report.
The Test Review Board will most likely meet via teleconference or email depending on the complexity of the issue.
The Test Review Board is required to render its decision within 10 business days of HIMSA receiving the appeal.
More Details per API Integration
The above text has discussed points that apply to all products integrating with Noah. Each different API offered by HIMSA has additional special policies. Please follow the links below for more details.
The text in this section applies to all products being certified
Scheduling
The licensee should notify HIMSA three weeks in advance of submitting a software product for integration testing by email or phone(email is preferred). HIMSA will then notify the licensee in writing of a confirmed test date. If a specific test time is requested but cannot be fulfilled HIMSA will return with new opportunities and confirm via email when accepted by the licensee.
Pretest
A member company is able to ask HIMSA to perform an unofficial test if it just wished to gain feedback. Pretests do require that the member company required test steps be first completed before HIMSA will conduct testing.
Double Booking
Many licensees would love to be able to schedule a test and then reserve a backup date just in case an unexpected delay occurs. It would be nice if HIMSA was able to offer this type of service but our testing resources cannot accommodate for this. Keeping this in mind HIMSA will use the following policy in regards to booking multiple tests.
Licensees may book one-time slot per software product per 30 day time period
Occasionally a licensee may wish to book a “pre-test”. A pre-test would consist of HIMSA going through the normal integration test with the understanding that the licensee wishes to see how the module will fare in an “official” test. Booking a pre-test with HIMSA is acceptable. However, HIMSA will require that both scheduled time slots are used. If one of the time slots is not used then HIMSA will charge for an 8-hour test.
Q: What is the difference between a pre-test and double booking? A company could just as easily double book and tell HIMSA that it is a pre-test.
A: Yes, this could be the case. HIMSA hopes that member companies will not abuse this policy. If HIMSA starts to see a pattern where companies are double booking under the guise of pre-tests then HIMSA will be forced to make a stronger policy. HIMSA really does not wish to come to this point and hopes that all companies will act on good faith.
Cancellation
If the licensee has arranged for a certification testing appointment, but for various reasons cannot meet the agreed appointment, the licensee must inform HIMSA no later than 5 p.m. 2 business days before the test. If this notice is not received HIMSA will charge for 8 hours of testing.
Certification Seal and Copyright
Certification Seal
HIMSA will make the certification seal available to licensees in an electronic format. The licensee may display the seal only in a manner that refers to the specific release number that underwent testing. For that specific release number, the licensee may display the seal on any language version. Please see “How to use the Tested and Certified for NOAHSEAL” for additional details.
Violation of Seal or HIMSA Copyright
If a licensee releases a product without undergoing certification testing and labels the product with HIMSA’s certification seal in violation of HIMSA’s copyright, or otherwise misleads customers, HIMSA will take whatever actions are deemed appropriate to inform its customer base and/or pursue legal remedies.
Validity of Submitted Test Materials
If HIMSA determines that the certification testing materials submitted by a licensee contain false or misleading information, HIMSA may take whatever actions are deemed appropriate to ensure full testing of the licensee’s product(s) and/or pursue legal remedies.
System Locale/Language Support
HIMSA’s integration test sites are installed on the en-US versions of operating systems (e.g. Windows). The software must be able to be installed on this operating system setup. HIMSA prefers that the module is able to run in English text but this is not mandatory. Support for English will enable HIMSA to perform any testing and administration work faster reducing your companies included hours for certification.
