Supporting Noah 4 Module Disconnect, Patient Switching and Selection

Owned by Scott Peterson
Last updated: Nov 24, 2020 by Andrea Dennis
8 min read



Supporting Noah 4 Module Disconnect, Patient Switching and Selection

Introduction

This document provides a high-level description of the subject matter from the perspective of a product manager. 

Please see the Noah 4 module conformance test for more detailed test steps that exercise different scenarios that apply to this topic.

The API for Noah 4 modules was designed based on some very strong requests that HIMSA received from many different module developers during the initial requirements phase. The features that they were looking for were:

  • Ability to leave a fitting or measurement module open all day long, with the Noah 3 API the module must be closed and reopened each time a different patient record is changed.

  • The ability to select the patient from within the module.

  • In general, it was to be a bit of a concept change, where the modules could run in a more disconnected method from a Noah GUI perspective.

 

These new flexible possibilities do however create a situation where the module has more scenarios to be prepared for.
With the initial release of Noah 4 (March 2011) HIMSA created the certification documents based on the understanding at that time. As it has now been several years since that initial release, it has come to HIMSA's attention, that we need to re-examine the rules and expectations as they apply today. In general, HIMSA wants the support for different features to be more flexible, to give the member company the opportunity to decide what is best for their user needs.
The important topics that will be covered are:

  • Benefits of supporting patient selection from within the module

  • Module Disconnect – 2 Levels of Support

  • Patient Switching – 2 Levels of Support

Benefits of Supporting Patient Selection from within a Noah 4 Module

Patient selection is a feature where your module provides a function of your choice to initiate the change of patients from within the module.  Once this process is initiated the patient management GUI supplied by Noah System or compatible business system will be used.
The easiest way to describe this benefit is with an example using the Noah Journal module. As implemented today, it is possible to:

  1. Open the Journal module from a desktop icon, login into Noah

  2. Click on the patient browser icon

  3. Select the correct patient

  4. Enter the journal, save

  5. Go to step 3 for the next patient

The above example is one that HIMSA is aware of being used by real professionals.

Q: Does this type of workflow make sense for all modules?

A: That is a decision for your company to make. You know what your customers need the most. Perhaps you feel that bypassing the selection of patients in Noah System or the business system is not beneficial ,e.g. the professional can see a preview of the latest audiogram and most recent hearing instruments. Your opinion may also be affected after the rest of the details of this document.

Q: Are there any special preconditions that my module needs to be prepared for?

A: Yes.  The module cannot assume that the business system integrated with Noah will support setting a patient record.  Before offering the support of this feature at runtime, the module will need to check the property ModulesCanSetPatient to see if the value is set to true.

Summary– this is an optional feature that your module can support.
Please note that not all Noah compatible business systems support patient switching to be initiated by a module. In these cases, your module can find out in advance if this feature is supported or not.

Patient Switching – 2 Levels of Support

It is possible for a module to be open and connected to Noah while the professional then switches the selected patient. The selection process will be triggered by the professional changing the patient in the Business System or by another open module initiating this process.
If your modules wish to support any of the below examples, then HIMSA would assume that you want to also support this feature fully:

  • Patient Selection from within a Noah 4 Module (see above section).

  • Desire to leave the module open all day long or as long as possible.



Change to Noah

Starting with Noah 4.8 it will only be possible to switch patients if there is:



  1. Zero or 1 connected module

  2. If a module is connected it must be a Noah 4 API module



If these above conditions are not met then Noah will prevent the switch from occurring.

The already implemented message of 50101 will be processed.

Q: Why is this change being made?

A: There are possible scenarios where several Noah 4 modules (e.g. 1 fitting, 1 measurement, 2 other) are connected.  In these more extreme cases all open modules could be in a situation where the HCP must agree to the patient change in each open module. This could lead to a situation where there is a longer than expected time between your module agreeing to the change and the rest of the modules also agreeing. Making this change will simplify the situation.

Q: What can I do with my module now in order to support patient switching for all the versions of Noah prior to 4.8?

A: HIMSA recommends that you "lock" your module from any possible data changes, user interaction, between the acceptance to switch patient and the actual patient being formally switched. If this is not implemented there is a chance, although extreme, that the user will save data to the incorrect patient record. Another option would be to automatically reject patient switch requests in versions prior to Noah 4.8 and then offer full support when running on versions 4.8 and newer.



Proper support for patient switching is accomplished in 1 of 2 ways:

Before getting into the two different choices please first consider if the professional needs to be asked any question. For example, if your module is open and connected to Noah and there is no unsaved data or modal messages open, then it would seem there is little danger in just allowing the patients to switch in the business system without having to close your module.

1) "Full Support "– provides the best user experience by your module providing a better message to your users and allowing them to make a choice.

Case of the business system initiating the patient switch, unsaved data or open process - If your module asks and the professional does not agree to switch the patient, then it is assumed that they are working in your module and as the confirmation message was displayed by your software they can continue/finish with their work and your software can be brought to the top of open windows for completion of work.  Your module should then deny the patient switch.

Case of the business system initiating the patient switch, no unsaved data or open process - in this case you can decide if you just want to switch patients or ask the HCP for a confirmation.  

 If your module asks and the professional does agree to switch (e.g. they have now saved all the unsaved changes), they can now continue working with the patient they selected.



2) "Meets Requirements" – in this simple method your module can automatically reject the request to switch patients. This will then cause Noah to present a message as shown below.

The professional will then need to:

  • Click on OK

  • Find your module's Window

  • Close the module (may need to save unsaved data or complete work first)

  • Then go back to the business system and try to select the desired patient.

Before deciding to implement this basic method please consider what would most likely trigger this event to take place. Your module is currently open, is there a good chance that the professional still wants to use your module with a new patient? If so, will they find it a little frustrating that they are doing extra unneeded work?



Summary – Your module must support either the "Meets Requirements" or "Full Support" methods.

Module Disconnect – 2 Levels of Support

Noah implements business rules which state that only 1 fitting module and 1 measurement module can be open and connected to Noah at any given time. Noah 4 modules need to be prepared to respond to Noah when Noah asks your module to disconnect. Although Noah will send your module a request to disconnect, please keep in mind that it is the hearing care professional (the interactive user) that initiates this activity. Responding to a module disconnect from Noah can be accomplished in 1 of 2 main ways:

1) "Full Support "– provides the best user experience by your module providing a better message to your users and allowing them to make a choice. 
Before getting into the two different choices please first consider if the professional needs to be asked any question. For example, if your module is open and connected to Noah and there is no unsaved data or modal messages open then it would seem that there is little danger in just closing/disconnecting without asking the professional, this choice is yours to make.

If your module asks, and the professional does not agree to disconnect, then it is assumed that they are working in your module and as the confirmation message was displayed by your software they can continue/finish with their work and your software can be brought to the top of open windows for completion of work.  When the work is completed (e.g. save the changes) then your module can agree to the disconnect.  They should now be able to return to the module they wanted to work with – the one that started this whole process.



2) "Meets Requirements" – in this simple method your module can automatically reject the request to disconnect. This will then cause Noah to pass a message "TooManyRunningModulesOfSameCategory" to the other module that is trying to connect.  

This response will be contrary to what the professional wishes; therefore, the professional will then need to click on OK or respond to the message that the other module presented to the user, e.g. "unable to connect to Noah at this time due to too many modules already connected."

  • Find your module's window.

  • Close the module. You may need to save unsaved data or complete work first.

  • Then go back and try to open the module they wish to open, which was where they first started.

Before deciding to implement this basic method, please consider what would most likely trigger this event to take place. It may be that the professional just likes to keep the module open as long as possible to reduce wait time restarting it again. It may also be something as simple as they forgot that your module was open, e.g. minimized.

General Points

Q: If my module has disconnected should I close the program entirely or can I stay open, but disconnected from Noah?

A: The choice is yours to make. HIMSA will however suggest that if you stay open, but disconnected from Noah, your module will then need to develop a workflow method of your design that would connect to Noah again so the professional can be assured that data is exchanging with the correct patient record. 

Summary – Your module must support either the "Meets Requirements" or "Full Support" methods. Please see Module Implementation for full technical details.