Page Comparison

A business system requiring the use of Noah must use the Business API interface i.e. an instance of the Business API object.

The Business API Object

The BusinessAPI object is the top-level object in the Noah Object Model. This means that references to all other objects must take place through the Business API.

It is the responsibility of the Business system to inform Noah of changes in the current user and currently

selected patient (by calling the methods SetCurrentUserID and SetCurrentPatientID). Given this information, Noah offers the Business system a hierarchy of objects that reflects the current patient’s sessions and data along with a framework for the handling of modules’ access to the data (e.g., start/stop/uninstall).

The object hierarchy can be depicted as shown in the following figure.

NOTE: Noah always reflects the current user and the current patient (if any) as set by the Business system.

Image Removed

Image Added

                                                            Figure: Business API object hierarchy

The Noah object Hierarchy describes the relation between objects in Noah.

The key concept in the Noah Object Hierarchy is the Session List associated with the current patient. The

Session List is an ordered collection of sessions for the current patient.

A Session is an ordered collection of actions, each representing an event that occurred during a patient session. The most recent patient session is the current session, that is, the session that reflects the events in the patient’s current visit.

NOTE:  HIMSA provides a collection of different WPF controls, which uses MVVM design pattern, that can be used by the Business system developers.

HIMSA also provides the Active Document Container used to host NOAH 3 (and 2) modules. The Hosting of modules has, in Noah 4, been moved from the responsibility of the Business system, to be a part of the Noah 4 Framework components.

The Noah 4 object model has been divided into 4 logical entities:

• Engine objects

• Business/Office database objects

• Registry objects

• System database object

Engine Objects

The objects that are defined as Engine objects in the Object hierarchy figure are objects which embed standalone Business API functionality, such as a session filter and a module filter. This functionality can be used by business systems in order to filter the collection viewed.  For detailed object descriptions, property and method information please refer to BusinessAPI NameSpace in the BusinessAPI.chm file.

Business System Database

The Business System database objects (marked in green in the Object model) are the most dynamic objects in the model, and are updated based on the event generated by the business system or any Noah module executed on the same Noah client instance on the given PC.

The Business system objects hold information on the current user logged onto the Business API, and also information on the currently selected patient, including sessions and actions covering all the consultations for the patient in question and with detailed data – e.g., audio, fitting and journal. For detailed object descriptions, property and method information please refer to BusinessAPI NameSpace in the BusinessAPI.chm file.

The group of Business Database objects feeds the following collection properties, which are available on the Business API object:       

• CurrentUser

• CurrentPatient

• CurrentSession

• Unbound Actions

Registration

Objects

The Registration objects hold information regarding the modules installed, which modules are Noah compatible and where the registration process has been executed for the module. Furthermore, it is possible to initiate a start or connect and a stop or disconnect for a specific module. The registration entity is also able to supply data on what the module can make and/or show, and which protocol it supports.

The group of Registration objects feeds the following collection properties, which are available on the Business API object:                     

• Modules

• ActionConverters

The Noah License Object

The Noah Engine contains a licensing system that controls run-time access. The file, demo4.lf, provided with the Noah installation, allows the customer access to the Noah Engine for a 45-day trial period. The business system can read how many days remain in the trial period using the Noah license interface. The Business system can then use this information to inform the user. In order to permanently enable Noah for a customer’s business system installation, the developer’s company or the company’s distributor will need to purchase a Noah Engine license from HIMSA, and supply a variety of user information, including:

• Office Name

• Street Address

• City

• State or Province

• Zip or Postal Code

• Country

• Telephone Number

If upgrading from NOAH 2 or NOAH 3, the Noah serial number must be provided, along with the network license size (1-2 user, 3-6 user, unlimited user). HIMSA will use this information to generate a license file, noah4.lf, that is unique to the user. HIMSA will supply the license file to the distributor/company or to the end user. The file must then be copied to the user’s system(s). The noah4.lf file must be installed in the HIMSA Shared folder.

NOTE: The noah4.lf file may be acquired prior to the initial installation and then installed in place of demo4.lf.