Feature Overview

Figure 1 below demonstrates the basic issue. In this case the Noah user works in a location where a medical record system is used as the primary record keeping system. As Noah and the medical record system are separated, end users spend a lot of time manually transferring data. The transfer of data is usually done by retyping information and in some cases making PDF files from Noah and Noah compatible software (using a PDF virtual printer) and manually attaching to the patients electronic medical record.
Noah is used to facilitate the storage and retrieval data between different Noah compatible modules. The most
common example consisting of:

• A patients hearing loss is determined by use of a Noah compatible audiometer (A)

• The audiogram data points are collected by a Noah compatible diagnostic module (B)

• The module saves the Audiogram to Noah using a HIMSA defined audiogram data standard

• The patient is then moved to a fitting station. A hearing instrument manufacturer's software module is used to program the hearing instrument. Most fitting software requires the audiogram data in order to properly program (adjust) the hearing instrument

• The audiogram data is retrieved from Noah to the fitting software (C)

• As different activities take place (e.g. fittings and measurement) a historical record is built for each patient record and stored in Noah.

The General Solution

The general solution entails a simple XML (validated via XSD files) based exchange of data between Noah and the medical record system. With this solution Noah's well established interaction with compatible software remains intact while needed patient data can be exported to the medical record system in a XML format.

Q: What is meant by "Medical Record Service"?

A: HIMSA has envisioned this as a generic software application that Noah could interact with. HIMSA would like for the communication to this service to be common so that Noah would not have to be customized for each end user site location. What happens inside the service as far as transferring data to the medical record system is up to end user site location. HIMSA envisions that the site location may use third party tools (e.g. Cloverleaf,
Microsoft Biztalk, NeoTool ect) to work with the Noah based data. Further, it is envisioned that the end user site
location may use other popular messaging standards (e.g. HL7) to move the data within the site location system.

Web Services

HIMSA publishes a HIMSA defined Web Service Interface that is implemented on the side of the Medical record system service. In this case Noah would also be communicating to a fixed web service interface and the Medical record system would then have the freedom to implement whatever system it felt was appropriate.
The Web Service is not a publicly available or shared Webservice. The Webservice is implemented and placed in a location of the company implementing the interface to the medical record system.

High level overview of the main features supported by the API

Measurement data from Noah to the business system

The interface supports the transfer of the following diagnostic measurement data from Noah System to the Business System. This can be accomplished by the Business System configuring the integration so that Noah pushes the data to the Business System or the business system may also pull the data when it wishes to do so.

Q: Why would a Business System wish to support reading audiometric data?

A: This is typically one of the more important features for hearing care professionals. They wish to have the audiometric data transferred to the Business System so that it can used in that system.

Pure tone audiogram graphic

Image Removed

Image Modified

The interface supports requesting Noah to create an imagine of the pure tone audiogram.

Q: Why would a business system wish to make use of this feature.

A: Making use of the feature relieves the developer from creating the visual aspect of an audiogram.

Measurement data from business system to Noah

The interface supports the feature where by the Business System can add supported action data (see details to the right) to the patient record in Noah 4 System.

Q: Why would the Business System wish to support this feature?

A: Some Business Systems provide features which collect data outside of Noah 4 System and wish to transfer it into Noah 4 System for further use. For example, a Business System could support an audiogram entry feature within the Business System. If the Business System transfers this audiogram into Noah 4 System, then other fitting software can use it as part of a hearing instrument fitting process.

Patient demographic data from business system to Noah

The interface supports the feature where by the Business System can transfer the patient record into Noah 4 System. This test focuses just on the transfer of demographic data into Noah 4 System. The focus of this test is to ensure that the patient being added into Noah 4 System contains a BESPID (Back End System Patient ID, Your system ID)

Q: Why would the Business System wish to support this feature?

A: It is assumed that the Business System is the main patient management system and as such, the patient information will be stored in the Business System first. Noah 4 System also needs a patient record. If the Business System supports adding the patient record to Noah 4 System, then the professional will not be required to manually enter this patient.

Patient demographic data from Noah to business system

The interface supports the feature where by patient records can be created in the Business System as a result of the patient record first being created in Noah 4 System.

Q: Why would a Business System wish to support this feature?

A: The Noah user may add a patient in Noah System first. If this feature is supported the Business System can learn of this event and then add the patient into the Business System.

Full patient record import export

The interface supports a full patient record import and export functionality. This enables the business system to export an entire list of actions (in a single file) for a given patient identified by the BESPID (Back End System Patient ID, Your system ID).

Q: Why would a Business System wish to support this feature?

A: The two main use cases are:

• Use the file as a Noah data backup of a given patient, could later be reimported if the data is lost.

• Used for patients that may visit other hearing care offices. Transfer the exported file to another Noah System installation that is integrated with your business system. The file can be imported into the other Noah System installation.

Automatic patient record selection

The interface supports starting Noah and automatically selecting the patient record from the Business System

This functionality will enable the hearing care professional to ask the business system to open the same patient record in Noah System.

Q: Why would a Business System wish to support this feature?

A: The feature can provide a more streamlined and efficient workflow. It is assumed that the professional will start with the patient selected in the business system, when the professional is ready to perform work within Noah they will not need to open Noah, search and select the patient, it can now be done in a more automated fashion.

Technical Overview

Developer Support

As the Webservice interface does not change between the versions of Noah 4 this is a safe and dependable
development environment. The following developer support options are available:

• Internet Forum based support is available at no cost. The forum is appropriate for basic questions and problems. The forum is monitored by HIMSA employees.

• Direct Contact with HIMSA development group. Direct assistance for troubleshooting and advice can be arranged. The fee structure is $150 per hour. This fee is waived for Licensees which have 26 or more sites utilizing Webservices.

End user technical support

The licensee is responsible for configuring, testing and troubleshooting the Webservices interaction between Noah and your system. HIMSA distributors support engineers will not be able to assist in this responsibility as they will not have any knowledge of how your system works. Noah System related support for features not related to Webservices Integration (e.g. troubleshooting a problem where a Noah client does not connect to the Noah Server) is the responsibility of the HIMSA distributor that the end user purchased Noah from.