Hearing Instrument Manufacturers Backend System Data Exchange with Noah

Platform Independent

As a HIMSA member company, I want HIMSA to create software interface features that are platform independent.

Rationale: HIMSA member companies do not wish to be tied to a specific technology or platform to exchange data with Noah. 

Manufacturer Back End System Pushes Data To a Noah Installation - Write Only Access

As a hearing instrument manufacturer back end system, I have the ability to send data to a Hearing Care Business (HCB) Noah installation

Rationale:

• As understood, the main objective is for a manufacturer to gather information obtained from systems that work outside of the HCB office and then send it to the Noah installation.  There is not a need to read data from Noah.

• This is a Privacy By Design point as there is no reason to read data, so then read access does not need to be granted.

• It is assumed that a write only setup requires less legal contract requirements between a HCB and a Manufacturer.

Precondition: The Manufacturer Back End System will use a Noah Web API and the Manufacturer Back End System will need to be approved for use by a HCB Noah Administrator.

Q: Does the the system pushing data to Noah have to be a "back end system", one that is assumed to a centralized server system?

A: From the current understanding, this is the most likely case but it could be any type of computing system (e.g. software running on a PC in a HCB office) as the technical implementation is to use technology that is platform independent.

see Asynchronous Flow

Manufacturer Back End System Pulls Data from a Noah Installation - Read Access

As a hearing instrument manufacturer back end system, I have the ability to additionally pull date from Noah.

Rationale: The manufacturer wishes to offer a feature that requires more access to data.

This access is also available with the assumption that the App has been granted access by the HCB for the App to read data.

Manufacturers may find it easier to gain acceptance from HCB's if they request write access only.

Patient Record Matching

As a Manufacturer Back End System, I need a way to provide data to a Noah installation and be assured that the data is attached to the correct patient record.  When I later read data, I also want to be assured that I am reading data for a specific patient record.

As a HCP I desire a very automated solution as Noah and the manufacturer back office exchange data - link patients together.

It is currently envisioned that the patient record matching process is supported in two main ways:

• Synchronous, the Patient's App - Manufacturer back end system patient ID is linked with the Noah patient GUID during a live session between the HCP and the patient.  For example, during the first fitting, the fitting module communicates with the manufacturer back end to join both patient records.

• Asynchronous, the Patient's App is registered / linked to the Manufacture back end patient ID which is linked with the Noah patient GUID while the HCB is not directly involved.

see Connect Patient Noah → Manufacturer Back end

In General, HIMSA uses the Noah Patient GUID to match up patient records in Noah and the Manufacturers back end system.  The Noah Patient GUID is considered globally unique. 

Patient Merging

Noah System 4.8 and newer offers a feature to merge 1 or more patient records into 1 patient record in Noah, see https://www.himsa.com/en-us/news/himsanews/mergeduplicatepatientsfeatureinnoahsystem48.aspx

Q: When two databases are merged, does the patient moving into the master database receive a new GUID?

A: No, the patient retains the same GUID.  If two patient records are merging, then the patient that is kept retains the GUID.

Q: If a patient record is duplicated (e.g. has been exported to another database), is the manufacturer back end expected to send notifications to multiple databases? 

A: No, only the database where the activity was generated from.

Q: Once an alias has been claimed by another installation, will the back end not be able to send notifications to the database which was previously using the alias? 

A: Correct.

Q: If a HCB exports a patient record to another system (e.g. a laptop with a different database, a local database), will the main office database (the Alias) no longer be able to receive notifications?

A: No, nothing changes.

Q: If there are many aliases, why does the Noah module API not provide all of the alias?  Why does the API just not return one alias to use? 

A: Only one is needed for the back end to interact with the Noah installation.

Also see Noah Mobile Alias - The Unique ID to a HCB Noah database

Time based on UTC

As data is exchanged between a Noah installation and a manufacturer's system, the time system is in UTC.  The UTC based time is recorded in the data saved in Noah as well.

Rationale: It is possible that data is collected, stored, and processed on systems all existing in different time zones.  For example:

• Data collected from a patient App

• Data processed and stored in a manufacturer back end

• Data stored in Noah

Ultimately, the HCP will want to see the information as it pertains to their time zone.

Add any Noah Data Type into a Noah installation

As a Manufacturer Back End System, I have the ability to add any of the currently supported Noah defined data types to a Noah installation. 

I am able to add both public and private data.

Rationale: Manufacturer Back End Systems need flexibility to add all types of data to provide useful features. 

In other words, a back end system should have the same abilities to add data that a fitting or measurement module can today.

Find a complete list of Noah defined data types at Constant Definitions

Manufacturer back end creates Fast Data View (FDV)

Manufacturer Back End Systems have the ability to optionally include a Fast Data View along with the data that they provide in a Noah installation.

Rationale: The primary driver idea for FDV's was getting very quick access to fitting related data.  As the main data being exchanged is remote fitting related, it seems very reasonable to assume that HCP's will enjoy FDV's.

Language / Locale support

As a hearing hearing instrument manufacturer providing a back end service, I would like to make sure that any text based information I provide to a Noah installation is in the language/locale that the HCP desires.

The solution assumes that fitting module (or other Noah compatible application) is aware of the language/locale settings and passes this information along to the back end system.

Modules are also able to read the local language that the Noah installation is currently set for.