Proper Procedures for Writing and Reading Audiogram Data
This document covers three main topics:
In-Situ Audiogram
Proper method for software saving audiometric data to Noah
Proper method for software reading audiometric data to Noah
In-Situ Audiograms
An in-situ audiogram is an attempt at obtaining thresholds by turning the hearing aid into a transducer of tones.
During 2016, feedback was received by many HIMSA member companies with a large majority feeling strongly that In-situ audiograms should not be stored as publicly readable audiogram data. It is not allowed to store an in-situ audiogram using any current versions of the audiogram data standard. If this consensus happens to change in the future HIMSA would be able to properly update the audiogram data standard so in-situ data would be properly tagged so that no other software reading the data would understand it incorrectly.
Expectations for Measurement Systems Saving Audiogram Data
The following general rules will apply to systems that save audiogram data
If it is the intention of the measurement system to create an Audiogram that will be used for the basis of a fitting or a business system report, then:
It must be prepared to support scenarios where the data may be collected over a time period more than the current calendar day, this period of time is referred to as the assessment period.
Save all of the data collected in 1 action, which will be considered the most recent Audiogram
This will mean that it will need to be prepared to carry forward (copy) data from previously stored data. Please see the "Rules For Carrying Forward Data" section at the end of this document for more details.
Q: How is the assessment period defined
A: HIMSA does not assign a fixed time period to represent how long the assessment period would be. Typical examples would be first determination of loss, first fitting, and fine tuning which may last 2 weeks. Ultimately it is up to the hearing care professional to work with any legal rules or local ethics that should be followed to determine if data not collected during the present session is appropriate to be used and included in the most recent audiogram action.
Example
The following example is provided to demonstrate the above logic. If you have questions then please ask HIMSA a question via our support system.
On Day 1, AC, BC and some speech tests are stored as the most recent audiogram action for the patient
On Day 7, the hearing care professional performs some UCL tests as shown above. This picture is used to show what is collected, not what is saved to Noah.
The measurement system is expected to create a new action on Day 7 and save the AC, BC, and speech data (from Day 1) and the UCL data gathered today.
Q: What should happen if an error was discovered in one of the tests from day 1?
A: That data should of course be corrected. In other words, if new data is collected that would replace data from Day 1 the new data should be used.
Expectations for Fitting Systems Reading Audiogram Data
The following general rules will apply to a fitting system that reads audiogram data
If your system can use or requires audiogram data, then be prepared to locate the latest Audiogram action for the patient, you should have strong confidence that this audiogram is the latest and most appropriate audiogram to use.
Important Note: It is possible that an action's last modified date is misleading and it is not recommended to be used for determining the latest audiogram. For example, The Noah 4 Audiogram module does allow the Noah user to indicate a date in the past as the date of evaluation. If this is done the action’s CreateDate property will be set to the date of evaluation and the last modified date will be today. HIMSA recommends using the CreateDate property when finding the most recent audiogram.
Consider, as an option, if you wish to provide professionals with the option to manually select an Audiogram other than the most recently saved.
At the end of a fitting, you have the option to reference the fitting actions to the Audiogram action that was used.
Q: Is it possible for a fitting module to save an audiogram (e.g. saved in the hearing instrument and then read out) to the selected patient record?
A: Yes, this is possible but the fitting module then needs to follow the same rules as a measurement system. Additionally, the member company will need to alert HIMSA to this fact during certification testing, HIMSA will need to test the module know following the same procedures as a measurement system. As a general statement, HIMSA understands that many companies do offer the ability to store an audiogram inside the hearing instrument. However, it is assumed that it is not normally the full audiogram data that may have been collected or stored in Noah. For example, speech tests and high-frequency tests are assumed not to be stored in a hearing instrument. Fitting module developers need to take great care as to preserve the data so that the most recent audiogram does not effectively lose data. An effective and simple use case for this type of feature would be to allow the storage of an audiogram to a patient when there is no audiogram present. In this case, there is no way to cause any confusion as there is no other audiogram data present. This type of situation may happen in cases where a patient visits a different professional (e.g. perhaps on vacation).
Rules For Carrying Forward Data
It is expected that systems saving audiograms carry forward previous Audiogram data into a new Audiogram data action
If the Audiogram data being carried forward contains data that will not be able to be stored, then the module reading the data must provide a warning message to the professional that there is unsupported data in the record that will be excluded.
Ideally, it would be nice if the message contains some information about what type of data will not be included.
If it is not possible to determine what data will be excluded then at a minimum the software carrying forward the data must provide a generic message that not all data present can be carried forward. If the hearing care professional does not at least receive a tip that some data may be missing they are likely to consider that data has been lost or that there is a critical problem with Noah.
HIMSA considers non-compliance with point 2 as a critical certification issue as testing for data corruption or the appearance of data corruption is a major goal of the certification process.
If the Audiogram data comes from a Noah format conversion (e.g. format 502 to 500) then there is an increased risk that data has been removed in the conversion. A similar warning as listed in point 2 must be applied.
When reading audiometric data in format 500 or newer the application is required to look at the ConvertedFrom attribute to check for this potential issue.
Points 2 and 3 are really most likely to happen in the cases where the data being carried forward was saved by another module or HIMSA member company. In cases where the hearing care professional is using the same measurement system for all measurements, this should not be a problem. Many measurement equipment manufacturers have informed HIMSA that there are times where different systems are used and that it important that they have the chance to read and carry forward this data.
Q: What about the Noah 4 Audiogram module, does it carry forward data made by other modules?
A: No, it currently does not and the logic that controls this was implemented before this document was. HIMSA will be making a change to this logic in the future.
Q: What about private data that was attached to the action from which the data is being carried forward, is that supposed to be carried forward?
A: If the software reading the data is the same that saved it (or the from the same member company) this should be possible as the member company would understand how to read the private format. HIMSA assumes that the member company will just carry forward the private data in this case as it sees fit. However, if the company is different then it will be impossible to carry forward the private data and this is a current limitation with Noah/HIMSA data standards. This limitation is not new and has been the case since the beginning of Noah. HIMSA is currently reviewing this situation for possible solutions.