The Noah Alert Dashboard is a graphical feature used by Hearing Care Professionals (HCP's) to help manage patient care situations that have deemed to be of greater importance, a topic that would require the HCP to act in some way.
The Noah Alert Dashboard is not an API. However, the only way for data to be fed into the Dashboard is by HIMSA member companies making use of a combination of the:
The main purpose of this collection of documents is to provide an introduction and summary of the application of the above APIs as they pertain to the Noah Alert Dashboard.
The Noah Alert Dashboard was first released with Noah 4.12
Scope and Responsibilities
This represents an HCP working in their office using Noah as they normally do today.
After selecting a patient record to work with, the HCP selects the appropriate fitting module. This is existing functionality.
The manufacturer is responsible for creating the fitting module. Each manufacturer has its own fitting modules.
The patient is at home (or other remote location) and is using the hearing instruments and App that is also created and controlled by a specific manufacturer.
You will notice that the diagrams are shaded in blue. The use of color is to make it clear what company is responsible for the development and control of the application software or device.
The manufacturer has created an App that will install on the patient's personal computing device, assumed to be a Phone or tablet.
The communication between the device and hearing instrument is assumed to be facilitated via BLE but could in theory be accomplished in other ways. The important point here is that the manufacturer is in control of deciding and controlling the method.
This icon is used to represent the general idea of a web conference. Typical features that exist are:
Voice
Video
Chat
The presentation and the underlying conference service is provided by each manufacturer. This also means that the feature, if supported, will need to be included in both the applications used by the HCP and the patient.
For the purposes of this document, the icon is shown next to the fitting module. This implies that the web conference functionality could be directly embedded into the fitting module or could also be in another application controlled by the manufacturer.
The same applies to the conference service provided to the patient on the App. It is assumed that the manufacturer would wish to embed the communication into the app itself but is the choice of the manufacturer.
This is a summary of the explanations so far, showing the applications created and controlled by manufacturer ABC
The only main item that has not yet been discussed is the “Manufacturer Back End”. This icon is used to represent a system (e.g. Cloud, enterprise back end system) or collection of systems either owned or purchased by the individual manufacturer. The back end could be used to:
Help facilitate the web conference features between the HCP and the patient
Help facilitate the communication to the App and/or hearing instruments
Hold data temporarily or permanently.
In other words, the icon is used to represent that some coordination of facilities may be needed and that these facilities are provided (or arranged) by the manufacturer.
HIMSA is not pursuing any of these features.
Other manufacturers, such as Manufacturer XYZ, also control their own systems and are shown in orange in the diagram to stress this point.
Below are a number of definitions that are helpful to be aware of before reviewing more information about the Noah Alert Dashboard
Word/Phrase | Meaning / Reason |
|---|---|
Patient | Person that uses hearing instruments, is received hearing care services |
HCP | Hearing Care Professional, this phrase works nicely to represent audiologists, hearing aid dispenser |
HCB | Hearing Care Business, a group of HCP's that may work in one or many offices. |
Manufacturer | Generally refers to a hearing instrument manufacturer. Could also mean an audiological equipment manufacturer or any general HIMSA member company. |
Manufacturer Back End | An application or system provided by a hearing instrument manufacturer. A Manufacturer Back End is used to facilitate hearing care services between Noah, HCP's, Manufacturer, and Patients. 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 application running on a PC within the hearing care office. The important aspect is that the application is implemented to make use of the web API and implemented as a service app. |
Noah Action | A Noah action representing a set of data that can contain publicly and/or privately formatted data. This data is stored in Noah. |
Noah Remote Notification | Noah Remote Notifications are used to describe information generated as a result of remote hearing health care. Noah Remote Notifications come from Noah compatible software solutions made by HIMSA member companies. The most likely source will be a Manufacturer Back End System or potentially a fitting module. Noah Remote Notifications can be used to carry information into a Noah installation from the outside world (e.g. Hearing Performance information from the patient's app) or used to store data in Noah representing work done by the HCP (e.g. new hearing instrument fitting sent to the patient's App) |
Noah Action Alert | A Noah Remote Notification that has been set with a special status indicating they are to be shown in the Noah Alert Dashboard. |
Noah Alert Dashboard | A GUI tool that will help HCP's be aware of important information. It is important to not refer to it just as "dashboard" as other applications may also have a "dashboard". |
Open or Archived | A Noah Action Alert can be open (visible in the Noah Alert Dashboard) or Archived (not visible in the Noah Alert Dashboard). Once the Alert has been archived, it cannot be be opened again. |
Remote Categories for Noah | Commonly agreed to categories of information and related interactions with patients that are not in the physical presence of the HCP. These categories are used in Noah to convey information to the HCP's in Noah so that they can have a common understanding no matter which manufacturer they have received data from. Noah Remote Categories are not designed to convey status or progress of an issue the patient may be having. |
Noah Action Alert Priority | A priority, optionally and solely set by the HCP for a Noah Action Alert. The patient or the Manufacturer Back End may very well have their own use and definition of priority but they are not transferred to Noah. |
Noah Session Browser | A GUI tool that shows all Noah Actions for a single patient record in Noah The Noah Session Browser will record/show Noah Action Alerts but will not show alert priority. |
The Noah Alert Dashboard provides a visual software tool that makes it easy for Hearing Care Professionals (HCP's) to be made aware that there is important patient-related information. Noah provides many features used to convey the historical information for a patient but typically only when the patient record is selected in Noah by the HCP. The Noah Action Alert Dashboard provides an overview of information for all patients that are contained within a hearing care business's (HCB) Noah installation.
Title | User Story | Notes |
|---|---|---|
Entry is made into Alerts Dashboard by Manufacturer Back End System | A Manufacturer Back End System has the ability to provide data to a Noah installation that indicates to Noah that an entry is made into the Noah Action Alerts Dashboard. Precondition: Noah mobile has been enabled and the manufacturer's application (e.g. a manufacturer's back office system) has been approved by the HCB to exchange data with the HCB's Noah installation. | Q: Are Noah users able to create an entry in the alerts dashboard using a dashboard GUI feature? A: No. Q: Is it possible for a HIMSA member company to provide data to Noah, attach the data to a patient record but not have it be referenced in the alerts dashboard? A: Yes, in this case the data is represented in the Noah session browser. |
Manufacturer entry into the Noah Alert Dashboard includes unique patient ID | The exchange of patient data is done so with patient GUID's. The patient GUID is used to make sure that correct patient records are exchanged. Rationale: Very important to ensure that patient data is not being mixed up. | See Patient Record Matching for more details |
Manufacturer provides appropriate category | Manufacturer systems providing an action alert to Noah applies the most applicable category that is defined by Noah. Rationale: Categories are used to help HCP’s quickly and easily determine what type of action alert is being displayed. | See Remote Activity Categories Only one category can be applied to a single entry that will be shown in the Alerts Dashboard. Q: What should member company software do when multiple categories can apply to a given entry in the alerts dashboard? A: The member company will need to pick the more appropriate single category. At present the defined categories are related to remote hearing instrument related fittings. In the future it is possible that different groups of categories could be defined for different uses (e.g. IOI-HA questionnaires) |
Manufacturer provides additional text | Manufacturer software systems can provide additional text to further describe the action alert. Rationale: The text is displayed in a selected dashboard entry to provide additional summary data | Q: How much text can be provided? A: There is no limit except what Noah defines as the Action public data maximum, currently set to 3 MB) |
Application link | A Manufacturer provides linking information for each action alert entry. The linking information contains one or two links only. Rationale: Noah uses this information to request the appropriate application to be opened so that the HCP may review more information or utilize features provided by that application. | The linking information can result in opening:
The manufacturer makes the decision if they wish to support choices 1,2, or 3. |
Provide Noah with icon for use in Action Alert Dashboard | Manufacturers are able to provide Noah with an icon of the manufacturer's choice to be used in the Noah Action Alerts Dashboard. The manufacturers are able to provide and later update this icon. Rationale: Supports ease of use. | |
Provide Noah Action Alert Grouping information | As an option, the manufacturer back end system may provide Noah grouping information that associates with a Noah Action Alert. Rationale: This grouping information can be used to later visually enhance any Noah actions visible in the Noah Session Browser that are related to the Noah Action Alert. | |
Review Noah Action Alert entries even if the patient record is in use elsewhere. | HCP’s will be able to read all data available in a dashboard entry even if the patient record is open on another computing system where the Noah installation is sharing a common database. Rationale: HCP’s will find it frustrating to review alert information but cannot because the patient record is currently selected on another computer workstation. | Q: How will Noah react if the following conditions are present:
A: The HCP is still able to view the information in the Action Alert. However, if the patient is already opened on another workstation, they will not be able to open the module via the button in the dashboard or from the embedded session browser. |
If requested module is not installed on the computer workstation | If a manufacturer back end provides an application link that results in Noah asking a module to be opened, then it is technically possible that the module is not installed. By default, Noah reacts by showing a list of installed modules that are registered with Noah as supporting the data type associated with the action/activity. In the case of opening a module from the Noah alert dashboard, this would be Dashboard Notification data type (code = 303). See example 1 to the right. If there are no installed modules understanding this data type, then Noah provides an error message. See example 2. Q: Module developers sometimes need to retire old software and create a new module to show data created by the old module. Does Noah provide support for this situation? A: Yes, the Noah 4 module API provides for the ability to include a Module Alias with the installation of the new module. When the alias is in place, Noah will then use the new module by default. See ModuleAlias Object for more details. | Example 1, missing module with list of Modules that can read the data Type In this example, an audiogram action was activated from the Noah session browser; this action was created by an audiometer manufacturer. In this case the companies module is not installed. Noah has presented the below screen listing the modules that can read Audiograms. The user may now select a module to open the action.  Example 2, No installed modules Similar to example 1, in this case there are no audiogram modules installed.  |
Categories for remote fittings have been defined and included as a HIMSA data standard.
The NotificationAction-303-500.xsd schema file defines the element "category" as a string value. As of the list of valid, approved, and enforced categories are listed below.
As patients will begin to receive more care remotely (not in the physical presence of a HCP) there will be benefits by incorporating data collected from the field into Noah. Additionally, it will be helpful to categorize the data. The main goal of this document is to define these categories so that all companies providing the data to Noah (e.g. assumed to be hearing instrument manufacturers) will categorize data in a common way. If the categories are not applied the same then the HCP may be confused or have a harder time understanding what the data is about. More details about the level of complexity of the categories will be presented further down. First it is important to have a general understanding about some key concepts.
For the rest of the document the term DATA will be used to generically represent information that is associated with a remote fitting, patient activity (use of the instruments) and patient feedback.
DATA that is collected from the field is:
Collected from the patient by the manufacturer interfacing with the patient's App, which the manufacturer has also created
Assumed to be processed in some way by the manufacturer to provide a useful benefit to the HCP. This processing is assumed to be done using a back-end system supplied by the manufacturer.
Provided to the HCP's Noah installation by the hearing instrument manufacturer.
The DATA that is provided to Noah will be formatted in general terms as a Noah Action. This means that there will be data storage for public data (following a HIMSA defined data standard) and private data (following a data standard only understood by the creator of the data (the manufacturer).
Important Information about Categories
Categories are designed to be helpful to a HCP (not the patient) but are very neutral in nature. The categories will help HCP more quickly determine the general idea about what the data is a about, meta data.
Categories are not designed to be used for statistical analysis (e.g. satisfaction scoring).
Categories will not be used by Noah to apply workflow or business rules in an automated fashion. It seems reasonable that the a HCP may react differently when they see one category versus another but Noah will not.
Categories will have short names.
When DATA is Categorized it will also be possible and recommended to include a text description for further details. The text description will not be standardized.
Q: Would manufacturers be expected to support providing information for all of the below categories?
A: No, This is an individual company decision. However, each company is expected to make every reasonable effort to use the categories according to the definition.
Categories | Definition | Examples of text that could be included, they are not predefined choices | Notes |
|---|---|---|---|
Remote Fitting Status | Activity related to hearing instrument fitting |
|
|
Hearing Performance | Patient's opinion on their ability to hear well in a variety of listening situations |
| Example, the listing in Noah would show the category of "hearing performance" with a simple text of "I am not able to hear my TV well" if the patient entered this text. Or, if the data was categorized by a system completely then it could be category of "hearing performance" with simple text of "Hearing TV Issues" |
Usage Status | Information about the usage of hearing instruments |
|
|
Device Performance | Potential improvement or issue to report, hardware related issues |
|
|
Message | A simple text based message |
|
|
Request for assistance | A request for help or appointment |
|
|
Sound Quality | Patient's opinion on their perception of sound quality |
|
|
Satisfaction | Indication of general satisfaction or satisfaction as it relates to a particular feature or aspect |
|
|
Other | A category of information that does not fit into one of the defined categories |
|
|
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 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:
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. |
This flow diagram provides a good overview of the most typical workflow taking into account the patient, manufacturer back end system, Noah and the HCP
Graphical items that have a paper/pencil icon next to will display additional important text based information upon hovering over it.
This flow covers how a patient can be connected to a manufacturers back end while starting from the side of Noah. This connecting process is done in a live scenario, one where the HCP is helping (via the fitting application) to setup the connection of the APP to the manufacturer back end.
Graphical items that have a paper/pencil icon next to will display additional important text based information upon hovering over it.
Identity Helpers:
Provide features that help Manufacturer Back End Systems more quickly identify HCB's, HCP's, and patients as they interact with Manufacture Back End Systems.
Many of the below points use the phrase "General Noah Storage Benefit" to describe a rationale. The benefit of storing information in Noah provides the following benefits compared to storing the data outside of Noah (e.g. storing the information in a system registry key, xml file, stored on a computer)
The data is stored inside the Noah database. Data is easily backed up and restored with the other important patient data. The database is also a more secure storage location.
If the new PC is implemented (which hosts the database), then moving the database to the new PC will result in keeping the information.
If the Noah installation is networked, then data will be available on each Noah workstation automatically. Between 50-60% of installations use a shared database between computers inside the business.
Title | User Story | Notes |
|---|---|---|
HIMSA Member application stores private data for the Hearing Care Business (HCB) | As a HIMSA member company, I have the ability to store and retrieve important information in Noah that my application will use as it pertains to a HCB. Examples of this type of data are:
Rationale: General Noah Storage Benefit | Q: Is it possible for other company applications to read this private data? A: No. HIMSA API's will not make this possible. This is an available feature for the Module API but not yet the Noah Web API. See Diagram 1 below. |
Noah provides a globally unique Hearing Care Business / Noah Installation ID | Member company Noah compatible applications are able to read a globally unique ID for the HCB which is the Noah Mobile Alias. The Noah module API now makes it possible to read the Noah Mobile Alias. Rationale: This ID provides an additional identifier that can be used by the member company's outside systems. | Q: Why is the phrase "Noah Installation" mentioned in the title? A: From the perspective of a Noah installation, the database is seen as unique. If a HCB has 3 non-networked installations of Noah then each installation is seen as unique, HIMSA has no way to know that these 3 separate installations are for the same HCB. This situation is also the case if a HCB runs 3 physically distinct offices. Each office may share a database in each office but Noah/HIMSA has no hard knowledge that they are the same company. Further, it is possible that Noah is setup so that a database is shared by many offices. The unique ID will be the Noah Mobile Alias. Starting with Noah 4.10 the ModuleApi has been extended with a new method ‘GetNamesForRemoteHost()’ which return a collection of aliases/remotehost names. Q: What will happen if a back end system sends patient data to the wrong Noah installation? A: HIMSA will reject the data and return an error code. |
HIMSA Member application stores private data for the Hearing Care Professional (HCP) | As a HIMSA member company, I have the ability to store and retrieve important information in Noah that my application will use as it pertains to a HCP. Examples of this type of data are:
Rationale: General Noah Storage Benefit | This is an available feature for the Module API but not yet the Noah Web API See Diagram 1 below. |
Noah provides a globally unique Hearing HCP ID | Member company Noah compatible applications are able to read a globally unique ID for the HCP. The member company application can read this ID and enclose it with data that is sent outside of the Noah installation. Rationale: This ID will provide as an additional identifier that can be used by the member company's outside systems. | With Noah 4.12 and newer, each Noah user will have a GUID assigned to it. |
HIMSA Member application stores private data for Noah patient records | As a HIMSA member company I have the ability to store and retrieve important information in Noah that my application will use as it pertains to a specific patient. Examples of this type of data are:
Rationale: General Noah Storage Benefit | This is an available feature for the Module API but not yet the Noah Web API See Diagram 1 below. |
Noah provides a globally unique Patient ID | Member company Noah compatible applications are able to read a globally unique ID for patient records.The member company application can read this ID and enclose it with data that is sent outside of the Noah installation. Rationale: This ID will provide as an additional identifier that can be used by the member company's outside systems. | Noah patient records have a patient GUID. |
Noah Will NOT append application links with additional ID's or information | When links to another application are activated by a HCP (as a Noah user), Noah activates the linking information provided by the member company. Noah will not add any additional information in the activation of the link. The link is provided to Noah from the manufacturer's back end system. Any and all information the back end needs to operate will need to be included in the link provided to Noah. |
Diagram
Manufacturer back end systems make use of the Web API (as a Noah mobile service app) to send data to a Noah database. Noah Mobile makes use of the Noah mobile alias (a name picked by the HCB and ensured to be unique by HIMSA) to provide the unique ID. The below flow charts covers this topic and other details.
Graphical items that have a paper/pencil icon next to will display additional important text based information upon hovering over it.
Continue to → Full Guide - Noah Alert Dashboard