Hearing Instrument Manufacturers Backend System Data Exchange with Noah

The phrase "Manufacturer Back End" is understood as an application or system provided by a hearing instrument manufacturer. This system is generally understood to be a larger system controlled and maintained by the hearing instrument manufacturer. However, the Manufacturer Back End could also be smaller system such as a MS Windows based Noah compatible fitting module.

Requirements

Title	User Story	Notes
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 then read access does not need to be granted. It is assumed that a write only setup will require 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 System 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 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.
Manufacturer Back End System Pulls Data from a Noah Installation - Read Access	As a hearing instrument manufacturer back end system I will have the ability to additional 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 app has been granted access by the HCB for the App to read data. Manufacturers may find it easier for gain acceptance from HCB's if they only request write access only.
Patient Record Matching	As a Manufacturer Back End System I will need a way to provide data to a Noah installation and be assured that the data will be attached to the correct patient record. When I later read data I will also want to be assured that I am reading data for a specific patient record. As a HCP I will 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 will be 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 Patients App is registered / linked to the Manufacture back end patient ID is linked with the Noah patient GUID while the HCB is not directly involved. Make sure this gets updated. See Flow Diagrams In General HIMSA plans to use the Noah Patient GUID to match up patient records in Noah and the manufacturers back end system. The Noah Patient GUID will be considered global unique. The ID must also be well known as Static, meaning that it cannot be changed once it has been assigned to a patient record. HIMSA has received reports that the current Noah patient GUID seems to change with some Noah compatible business systems. 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 will retain the same GUID. If two patient records are merging then the patient that is kept will retain 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 then the backend will not be able to send notifications to the database which was previously using the alias? A: Correct. Question - 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.
Time based on UTC	As data is exchanged between a Noah installation and a manufacturers system the time system is in UTC. The UTC based time will be recorded in the data saved in Noah as well. Rationale: It will be 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 add any of the currently supported Noah defined data types to a Noah installation. See a complete list to the right. I will be 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.
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 a Noah installation. Rationale: The primary driver idea for the idea of 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 will wish.	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. Module are also able to ready the local that the Noah installation is currently set for.