Last Update
HIMSA has recently been made aware of a number of issues related to HIMSA Data Standards and Runtime data converters. These issues will be addressed in the upcoming Noah 4.13 release. HIMSA is in contact with companies that we are aware of that are impacted by these topics. However, there could be cases where you have software in development that has not been released or has just recently been released.
HIMSA plans to complete all testing in Mid December and release Noah 4.13 at the beginning of January 2021. HIMSA will plan to make a pre-release version (for testing only) of 4.13 available in the near future if you wish to perform your own testing. This page will be updated with information on how to obtain this pre-release and any other new information periodically.
Who does this topic apply to? Who at your company should be made aware of this?
The topic of data standard validation and runtime conversion is usually handled by software developers or similar technical positions
The topics being addressed are split into two main types
Applications that Save XML formatted Data in one or many of the below formats
Audiogram Format 500 and 502
Real Ear Measurement Format 500
Hearing Instrument Test Format 500
Admittance format 500 and 501
Audiogram Meta Data Format 500
Hearing Instrument Selection Format 500
Hearing Instrument Fitting Format 500
Cochlear Sound Processor Selection Format 500
Noah Alert Dashboard Notification Format 500
Note: Your application is not impacted if it saves data to Noah using a legacy format (200 or 100)
Upcoming changes
UTF Encoding | Current documentation states that the only allowed encoding of an XML file is UTF-8. HIMSA has been made aware of at least one case where a Noah compatible application is saving data using UTF-16. With Noah 4.13 and newer, the validation process will be upgraded to check for invalid UTF encoding, if found the data record will not be allowed to be saved to Noah.
Declaring and using additional XML namespaces | HIMSA has found a case where a Noah compatible application has saved audiogram data using format 500 but has introduced some additional namespaces not defined by HIMSA. From a purely technical perspective, this is legal XML but causes confusion when other applications read the data. The additional namespaces can be perceived as different definitions of data and this contrary to the concept of HIMSA data standards. With Noah 4.13 and newer, the validation process will be upgraded to check for any additional namespaces, if found the data record will not be allowed to be saved to Noah.
Applications that Read Format 200 Audiometric Data
Many applications still wish to read Audiometric data in using the format 200 audiogram standard. HIMSA has a few cases where data stored in format 500 has been saved in a way where the provided runtime converter is not able to convert the data at runtime as expected. Below is a list of the issues being resolved
Extra space in the end of an element name | HIMSA has run into some cases where some XML element names have an extra space at the end of an element name. Although this is unexpected it is not invalid XML.
Byte Order Mark (BOM) present | The converter is currently not expecting a BOM to be present and is not able to handle this situation. This will be resolved.
If you have additional questions or need more information please use our support system and your issue will be attended to by a HIMSA support engineer.