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 a 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:
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. | |
| 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:
see Connect Patient Noah → Manufacturer Back end 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:
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. |