Upcoming Noah Data Standard Validation Rules and Runtime Converter fixes with Noah 4.13

Owned by Scott Peterson
Last updated: Jan 08, 2021
3 min read

Last Update Dec 2, 2020

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. 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.