Module Implementation

Implementing the Callback handler

To ensure proper interaction between the module and Noah – the module must implement the callback methods of the ‘Himsa.Noah.Modules.ICallbackHandler’ interface.

There are two situations the callback handler must address:

When a second module from an module category with the cardinality of 1, (this applies to measurement and fitting modules which can only have one connected module at any time), then the already connected Noah 4 module will receive a call to the ‘AcceptToDisconnect’ callback method.
If the connected Noah 4 module returns ‘true’ to indicate that the module accepts to be closed it will receive a ‘ModuleDisconnect’ event when it should disconnect. A module with unsaved data may choose to ask the end user for the action to take before disconnecting.
If the connected Noah 4 module returns ‘false’ to indicate that the module does not accept to be closed it will not receive a ‘ModuleDisconnect’ event.

If a patient switch is initiated by the user, then all connected Noah 4 modules are asked if it is OK to switch the patient. All modules will receive a call at the ‘CanSwitchPatient’ method. If all connected Noah 4 modules returns ‘true’ to indicate that the patient switch can take place – then Noah client will start the patient switch. In this case Noah Client iterates through the list of running modules and for each module notices if the module connected with ability to switch patient or if it has to use the old method of disconnecting and connecting again.

o True Noah 4 Modules that connected with the ability to switch patient will receive the “PatientChanged” event when the patient is changed and must then act properly (update patient information) (See more under “Connecting the Module”)

o Modules that the uses the old disconnect method will receive the “ModuleDisconnect” event and will have to disconnect and connect again to retrieve the new patient

o In both cases – if one module rejects to switch patient then all modules will receive the “CanSwitchPatientCanceled” and do not have to change patient or disconnect

o IMPORTANT NOTE! There is a time period between when the module has replied to the “CanSwitchPatient” request until the actual “PatientChanged” or “ModuleDisconnect” or “CanSwitchPatientCanceled” is received. In this time period the module must NOT let the user input data as Noah is in a Patient Switch state. The module does not know which patient the data will be saved to and worst case is that data can be saved on the wrong patient.

C# sample code for callback handler:

public class MyCallBackHandler : MarshalByRefObject, Himsa.Noah.Modules.ICallbackHandler

{

public bool CanSwitchPatient()

{

// Handle the callback here.

return // true or false.

}

public bool AcceptToDisconnect()

{

// Handle the callback here.

return // true or false.

}

Implementing the event handler

To ensure proper interaction between the module and Noah – the module must in addition to implementing the callback methods also subscribe to events from Noah. The module can receive multiple events from Noah, (defined by the ‘Himsa.Noah.Modules.NotificationType’ enum type).

The event handler is needed for the module to be able to react to certain events, like ‘ActionAdded’, ‘ActionUpdated’, ‘ActionRemoved’or ‘LanguageChanged’ etc. Modules must be prepared for unknown events (i.e. ignore them) in order to be forward compatible.
Which events the module should subscribe to are optional, except for one event – ‘ModuleDisconnect’.

If Noah requests a module to disconnect by raising the ‘ModuleDisconnect’ event, the module must disconnect (This is a requirement to be certified). All other events are considered informational for the module. See ‘

Table 2- Noah 4 ModuleAPI events’ for all events.

When the module's event handler receives an event from the ModuleAPI it will receive a class of type ‘Himsa.Noah.Modules.NotificationType’. See ‘Table 1- Properties of the NotificationType’.

Table 1- Properties of the NotificationType

Property Name	Description
Notification	This property is of type ‘Himsa.Noah.Modules.NotificationType’ – see Table 2- Noah 4 ModuleAPI events. The Notification property describes the change to the system e.g. ‘ActionRemoved’ or ‘ActionAdded’.
ActionId	This property is of type int and contains additional information for action related events e.g. when the module receives an ActionAdded Notification (event) – the ActionId property holds the action id of the added action. A zero value indicates that the ActionId is not relevant for this Notification (event).
SessionId	This property is of type int and contains additional information for session related events e.g. when the module receives an SessionAdded Notification (event) – the SessionId property holds the session id of the added session. A zero value indicates that the SessionId is not relevant for this Notification (event).
ModuleId	This property is not currently used.

Table 2- Noah 4 ModuleAPI events

Event	Description	Handling	version
None	Indicates no action should be taken. Not currently used.	Optional	4.0
ActionAdded	Indicates an action was added. The accompanying NotifyEventArgs type contains the added ActionId.	Optional	4.0
ActionsAdded	Indicates that one or more actions were added.	Optional	4.0
ActionRemoved	Indicates an action was marked as removed (it hasn't been deleted and can be restored by a Business system that supports this feature). The accompanying NotifyEventArgs type contains the removed ActionId.	Optional	4.0
ActionPurged	Indicates an action was purged from the database. The accompanying NotifyEventArgs type contains the purged ActionId.	Optional	4.0
ActionRestored	Indicates a removed action was restored. The accompanying NotifyEventArgs type contains the restored ActionId.	Optional	4.0
ActionUpdated	Indicates an existing action was updated. The accompanying NotifyEventArgs type contains the updated ActionId.	Optional	4.0
		Optional	4.0
UnboundActionAdded	Indicates an unbound action was added. The accompanying NotifyEventArgs type contains the added ActionId.	Optional	4.0
UnboundActionRemoved	Indicates an unbound action was removed. The accompanying NotifyEventArgs type contains the removed ActionId.	Optional	4.0
UnboundActionRestored	Indicates a removed unbound action was restored. The accompanying NotifyEventArgs type contains the restored ActionId.	Optional	4.0
UnboundActionUpdated	Indicates an existing unbound action was updated. The accompanying NotifyEventArgs type contains the updated ActionId.	Optional	4.0
		Optional	4.0
SessionAdded	Indicates a session was added. The accompanying NotifyEventArgs type contains the added SessionId.	Optional	4.0
SessionRemoved	Indicates an existing session was removed. The accompanying NotifyEventArgs type contains the removed SessionId.	Optional	4.0
		Optional	4.0
PatientUpdated	Indicates that one or more properties of the current patient have changed.	Optional	4.0
EnableeTONADeclined	OBSOLETE. Message from the OAS that a request to enable eTONA can’t be carried out.	N/A	4.0
eTONADisabled	OBSOLETE. that eTONA functionality has been disabled.	N/A	4.0
eTONAEnabled	OBSOLETE. that eTONA functionality has been enabled.	N/A	4.0
LanguageChanged	Indicates the language was changed by the business system.	Optional	4.0
PatientChanged	Indicates that the current patient was changed.	N/A	4.0
SafeToClose	OBSOLETE. Request from the business system, if the module is safe to close.	N/A	4.0
StatusUpdateAdded	OBSOLETE. Indicates a status update was added.	N/A	4.0
StatusUpdateUpdated	OBSOLETE. Indicates an existing status update was updated.	N/A	4.0
UserChanged	Indicates that the current user has been changed.	N/A	4.0
UserUpdated	Indicates that one or more properties of the current user have changed.	Optional	4.0
RegionChanged	Indicates that the region property has been changed.	Optional	4.0
ModuleDisconnect	This Indicates that the module has been asked to disconnect by Noah. It is mandatory for modules to handle this notification.	Mandatory	4.0
StateReestablished	This Indicates that Noah Client has reestablished the state i.e. all information cached in Noah Client are refreshed. The module must reread all information cached internally. This can occur when a computer wakes up after hibernation or the connection to the server has been reestablished.	Optional	4.1
MustDisconnect	This Indicates that the module will be disconnected within 5 seconds. This may occur because Noah Server has a need for all Noah Client to disconnect.	Optional	4.1
CanSwitchPatientCanceled	Indicates all modules that have previously accepted to switch patient will receive this event if another module has declined to switch patient. The current patient will not be changed.	Optional	4.2
ResumeSuspendStartRecover	Indicates that the PC has been resumed after a standby or hibernation, this event is sent when Noah is starting to recover i.e. rebuild the internal state. This process will be transparent for modules except that they will receive relevant events about changes just as if the system changes had happened in a running system. Check the ‘ResumeSuspendEndRecover’ event for further information.	Optional	4.2
ResumeSuspendEndRecover	Indicates that Noah has recovered after the PC has been resumed from a standby or hibernation, this event is sent when Noah has completed the recover process. Check the ‘ResumeSuspendStartRecover’ event for further information.	Optional	4.2

C# sample code to set up the event handler

// Subscribe to ModuleAPI events.

myModuleAPI.EventPublisher.Notify += MyNoahEventHandler;

C# sample code for a very simple event handler:

// Handle ModuleAPI Events.

private void MyNoahEventHandler(object sender, EventArgs e)

{

Himsa.Noah.Modules.NotifyEventArgs eventArgs = e as Himsa.Noah.Modules.NotifyEventArgs;

if (eventArgs == null)

return;

switch (eventArgs.Notification)

{

case Himsa.Noah.Modules.NotificationType.ActionAdded:

// An action was added to the current patient.

// Perform required action.

break;

case Himsa.Noah.Modules.NotificationType.ActionUpdated:

// An action of the current patient was modified.

// Perform required action.

break;

case Himsa.Noah.Modules.NotificationType.ModuleDisconnect:

// The module is requested to disconnect.

// Perform required action.

break;

}