• Noah 4.7 has now introduced new features for WSI

• With Noah 4.5 and newer it is not needed to install the “Noah Client plugin” to be able to start Noah and set a patient from the Business System client (Use the “NoahWebIntegrationGUIStart”)

• With Noah 4.5 and newer it is possible to have created patients sent from Noah to the Backend system (If a patient is created in Noah the Patient information is sent to the back end system)

• Notice that Audiogram 501 has been released by HIMSA, but currently data is always converted to format 500

• It is now possible to configure, which version of the HIMSA data standard schemas is to be used in a given transfer, hence giving the option to use different schema versions for different Noah locations.

• Deleted action is now exported with a operation=”Deleted” attribute on the action element. (WSI Level 2 or higher)

• The WSI interface is extended with a number of new methods.

• Full patient records send and receive. Patient data can be send from Noah to the backend for saving or for distribution to another Noah location.

• Start Noah and set a patient in Noah by bespid from another application located upon the same Client PC as Noah.

• It is now possible to specify which IP address or logical name the Noah web service should use e.g. if you are running your Noah server upon a server, which supports more than one IP address.

• The manual workflow is now fully implemented

• A new feature where it is possible to request a picture of an audiogram has been implemented. This is a new method on web service interface. See string GetImageOfData.

• The full flow for importing data into Noah has been implemented according to the flowchart in Appendix 2: Import flow:

  Especially one error where it was possible to overwrite a Patients BESPID has been solved

• The e-mail notification in case of errors has been implemented. Note that can only be used within a domain where the e-mail system allows that e-mails are sent (smtp server).

In order to use the Web Service Integration it is necessary to accept that:

• Patient data to Noah must always contain all data elements:

  If a data element is NOT included in the XML from the back-end system when it is imported to Noah then the data element in Noah will be blanked out

• When transmitting an action from Noah it is the Public part of the action that is transmitted

• When using the GetPicture functionality that is released with Noah 4.3 – it is important that the Noah Server installation has an Audiogram Chart installed – this can be done in 2 ways:

  - Installing the Noah 4 Audiogram Module on the server.

  - Using the WSI installer - The version of the WSI installer that matches the version of Noah System 4 you are using.

Basic Overview of WSI

The WSI components

All necessary components for WSI will come with a normal Noah 4 installation – but they will first be initiated or started up when you run the “WSI installer”.

• For Noah 4.14 and prior versions, the installer is to be downloaded from Web Service Integration Website. Copy the folder to the hard drive and run the “NoahWSISetup.exe”.

• For Noah 4.15+, the NoahWSISetup.exe is found in the Noah installation, at C:\Program Files (x86)\HIMSA\Noah 4

An alternate way of setting up the WSI simply to set everything in the Noah Business System Integration Tool (NoahBSIntegServerTool.exe) that can be located in the Noah 4 folder on the hard drive.

To use the WSI functionality, the licensee needs to implement a BEWS following the guidelines in this document. HIMSA has developed a sample BEWS that can be downloaded, tested reviewed, copied from the HIMSA site.

The WSI license file

When WSI functionality is enabled on a Noah Server – then it is important that the WSI license exe has been run on the Noah Server computer as well – otherwise the WSI will not work. A WSI license file is created by HIMSA specifically for each new WSI Licensee and sent to the Licensees HIMSA contact.

A new WSI license file must be obtained from the Licensee every calendar year.

The licensee will be responsible for distributing this special license file to each one of the end-user sites. This license file is separate from the normal Noah 4 runtime license file. The license file is not unique for each end-user license site but rather one license file is used by all end-user sites receiving services from your company.

Important WSI license file information

The license file will be valid for one calendar year and the Licensee must have an updater from HIMSA every year to ensure that customers can keep using WSI functionality. Since the WSI license is created with a time limit (calendar year) it is very sensitive in respect to the user changing time/dates on the PC.

An example: If the user sets the time forward to “date X” to test something and then afterwards sets the time back to current date – then the License system will sense that the time is set back and will CEASE TO WORK until after “date X”. There is nothing HIMSA can do about this and the ONLY SOLUTION is to re-image the server or wait until “date X”.

Configuration of the WSI

When using the WSI installer it is necessary to set up the configuration of the WSI as well – there are many parameters to set up and they are specified in the “Configurations” section of this document. The WSI installer will take the user through all the different options.

The configuration of WSI can be done via import/export of configuration files. Note that there is one configuration file for each group of functionality. If the configuration needs to change this can be done using the “Noah Business System Integration Tool” (Default location on Windows 7 (64 bit): c:\Program Files (x86)\HIMSA\Noah 4\NoahBSIntegServerTool.exe))

Automated vs. Manual WSI

The focus in the first versions of WSI has been on the automated workflow – but with Noah 4.3 the full manual workflow was also introduced.

Automated workflow: Every time a valid action is saved in Noah it will automatically be transmitted to the BEWS.

Manual workflow: When the user selects to transmit an action in Noah then the export is performed.

It is possible to combine manual and automated WSI – which can nice when testing the setup.

When Noah is triggered to send data to the BEWS, Noah Server will then package the data using the format described in the PatientExport.XSD. The action data – like the Audiogram data – is converted to format 500 XML and embedded into the PatientExport data. In the current implementation there will only be one action in each PatientExport – but note that this could be changed at a later stage as the PatientExport.XSD allows for more than one action in each Patient Export. Only the public part of the Noah action will be exported out of Noah.

When using the Automated WSI, data will be exported to the BEWS when it is saved into Noah using a Noah compatible module. This is assumed to be the normal trigger for sending data. There is a small time delay from the time an action is saved until it is actually transmitted – this is because some modules, like the Noah 3 Noah Audiogram module, send several actions and a delay is needed to ensure that they are all received before the transmission starts.

Another way to get data from Noah is to create a “BES query” (See BESQuery), where the BEWS can send a query for specific actions to be exported. The parameters in the query can be Patient ID (see The Back-end System Patient ID = BESPID), time interval and action type. For example, the BEWS can request that Noah (re-)transmits:

• All audiograms and fittings for a specific Patient, that were saved in the Noah database in the last

• Or BEWS can simply request that Noah transmits all Hearing Instrument Selections that were made in the Noah

Please note that only the public part of a Noah action is transmitted using the WSI.

If WSI is using ConformanceLevel 2 or higher, WSI will export the deleted action to the backend with the action marked as deleted.

How to determine if an action is already received in BES

Since Noah actions do not have a unique action ID, it must be determined if an action is already received by looking on the Patient, the TypeOfData, the ActionDate,  and the LastModifiedDate. The only element that will change if the action is updated in Noah will be the LastModifiedDate.

When exporting and importing Patient data between two systems, it is essential that the Patient has a uniqueID that can be used for unique identification

• The Noah System WSI uses the ”Back-end System Patient ID”(BESPID):

• The BESPID is a unique identifier that is appointed by the Back-end System. This identifier must always uniquely identify the patient in the Back-end System

• This ID is attached to the Noah patient record but does not replace the Noah patient ID

• This feature is a behind-the-scenes type of feature, the end-user is not involved directly, and there is no GUI in Noah to support it

In the Noah database a special field is prepared for the BESPID. As seen in the PatientExport.XSD, the BESPID is always mandatory when communicating Patient data.

If a Patient in Noah has been updated with a BESPID it means that from now on, all data received from the Back-end system with this BESPID will be updated on this Patient. The following rules apply:

• Demographic data

• When patient data is received from the Back-end system, the current Noah demographic data will be over-written.

  • This is also the case if the demographic fields are empty! Meaning that the Back-end system should always send the data that it has decided should be stamped on the Noah Patient data for this

  • Also data elements that are missing will be blanked out – so remember to include all important demographic data to the Patient data. For example, if “Address1” is not included in the PatientExport data – then Address 1 will be empty for the Patient after

• Noah action data

  • Noah action data will be merged or added to the Patients current object hierarchy in the Noah database

PatientUpdate method

When the WSI is enabled, there is a good possibility that it is not a new installation and that the end user already has an existing Noah Patient base. Since WSI was not enabled before, none of the existing patients will have a BESPID attached. When data is exported out of Noah and to the BEWS, then the Patient is in principle unknown and it will be needed to go through a “Resolving process” in the Back-end System.

From Noah’s side, a temporary “Noah BESPID” will be created and entered in the PatientExport data. This BESPID will be pre-fixed with “Noah” – and be followed by a unique key of 16 characters. When the Patient has been resolved in the Back-end System, it will be necessary for the Back-end System to update Noah with the correct BESPID that the Back-end System has created itself. The BEWS must initiate a Patient Update where the temporary Noah ID is exchanged to the correct BESPID.

For Patients that were created in the Back-end System this is not a problem, since they will carry a BESPID when being transmitted to Noah.

HIMSA assumes that BES will take the necessary steps to ensure the patient coming from Noah is properly matched up with the patient record in the BES database. The logic that the BES performs to ensure proper matching is completely controlled by BES, but HIMSA will ask that it is documented how this procedure is implemented when the BES WSI implementation goes through HIMSA certification. For example, the BES may take a similar approach that Noah System uses - that being that if there is a possible conflict the user in BES will be prompted to review the conflict and make the correct decision.

Resolving incoming Patients

When a Patient is created in the Back-end System, the data should be transferred to Noah with a BESPID. When Noah receives the data from the BEWS it will try the following logic:

1. If a BESPID match is found in the Noah database

   1. Noah will overwrite all demographic data (including name fields) with the newly received data and will insert any attached actions to the current action

2. If a BESPID match was NOT found in the database

   1. Noah will try to match first name and last name with existing Patients that does not already have a BESPID in the

      1. If a match is NOT found – then the new Patient will be inserted in the Noah database as a new patient

      2. If a first name/last name match is found – then Noah will place the incoming Patient in the resolving queue and let the Noah GUI know that there is Patient data.

         1. An end user must manually confirm that the first name/last name match is either the same patient that should be updated OR it is a completely new patient, in which case the incoming patient is simply inserted into the database as new.

Please note that there are configuration possibilities to set up how this should work. It can be set up to “Always need manual confirmation” or “Automatic match if demographic data have 100% match” – please see the “Configurations” section for more details.

The resolution is done in special GUI components in Noah System.

The Noah 4 Web service integration functionality should support all Noah 4 action types that are available in format 500 and have a public standard. Support in this case means both import to and export from Noah 4.

Import and Export only contains the public part of the action types. Please note that the modules can have support for entering private data in the public blob – as an extension to the public data. This data is NOT transferred.

The following list of data can be exported to the BES and imported into Noah from the BES (And this is configurable in WSI Configuration)

• Patient demographic (Only Noah 4.5 and newer)

• Audiometric

• Impedance

• Real ear measurement

• Hearing instrument test

• Hearing instrument selection

• fitting

• remote control

Only public data – format 500 XML

Note: does not include Questionnaire, Journal module actions, Ear scan actions and Video Otoscopy.

The Noah 4 web service integration contains full patient record import and export functionality. This enables the business system to export an entire list of actions for a given patient identified by the bespid. The business system will receive a NHAX formatted string, which the business system can chose to save as a backup of a given patient, or to send it to another Noah installation which the patient system supports. The other Noah installation can then import the patient and the patient’s action and the user of Noah 4 will be able to see and work with the patient from inside Noah 4 Gui.

The import will use the Bespid for identification of the patient so if the Bespid exists inside the receiving Noah installation, an update is done, otherwise the patient and actions are inserted.

A separate web service is created for support of this functionality, so that this functionality will work decoupled from the other web methods. A patient with records can vary in data size therefore the transport mode is set to be streamed.

Important notice: If the receiving Noah is set up to use manual patient numbering, then the manual patient number will be overwritten by an automated number if a patient is updated using the Full patient record import.

Starting Noah from another App on the same PC

This functionality will enable the user of the business system to select a patient in the business system and start Noah from inside the business system. In order to do so, it is necessary to use a plugin to the Noah Client service. This plugin needs to be installed on the client PC and registered towards Noah client.

The plugin will expose a few method calls that can be used by the application. The following methods can be used. Please see Using NoahWebIntegrationGUIStart for further instructions on how the plugin is registered and how to use it inside a C# application.

If error handling is needed because data is not received or transmitted, this must be done using the Noah Business System Integration Tool. This tool will provide log facilities and overview of transactions in error. It is possible to release transactions that for some reasons were not transmitted or to delete actions that should not be transmitted.

Number of re-tries and e-mail notifications

Under “Configurations” it is possible set up how many times to resend a message that was not successful. Default is to retry 3 times with 2 minutes in between. This can be set up in the configuration.

It is also possible to set up an e-mail address that can receive an e-mail if messages are still not sent after re-trying the requested number of times. The e-mail service will be dependent on an available smtp service that the NWS can access- and that the e-mail system allows that e-mails can be sent without specific use of userid and password (which cannot be saved into NWS).

Logging

Importing or exporting data from Noah is captured in the Noah ServerService log or in the HIPAA log if enabled.

It is necessary to set the log-level to “Debug” to be able to find errors. Start Noah Console – select the Noah Log Tool – Set Log levels and select “Debug” for all. When the error is found, reset the log-level to “Info”, as the debug log level will influence performance.

The Noah 4 Web service shows a number of methods that can be accessed through the Web service interface.

The methods handle patient import, patient update, backend initiated transmissions (BesQueries), and web service control.

void ImportPatients(string NoahLocation, string BusinessSystemUserId, string data)

Imports the Patient data to the Noah System database. This is done either directly or through the patient resolving screens in Noah, depending on the patient whether it’s new or updated.

void PatientUpdate(string OldBusinessSystemPatientId, string BusinessSystemPatientId)

Changes the BusinessSystemPatientID of the patient identified by OldBusinessSystemPatientID. The new BusinessSystemPatientID must be unique in the Noah Database.

void ImportConfigurationSettings(ConfigurationType cfgType, string data) string DoQuery(string BusinessSystemUserId, string data)

Starts a query job on the Noah Server. The job is executed asynchrony. The data of the query is returned via DataFromNoah() to the back end system.

Parameters:

• String BusinessSystemUserID is returned in the DataFromNoah() BusinessSystemUserID

• String data is the query xml, see chapter BESQuery for more

Returns an id of the job, executing the query.

bool CancelJob(string jobid)

Cancels the query job identified by jobid (the returned value from DoQuery()) Parameters:

• String jobid, the identification of the job to be canceled.

Returns true is the job was found and canceled else

void HaltTransmitter(bool bHalt)

Enables/Disables transmissions (DoQuery and automatic data transmissions) from the NoahServer. Parameters: 

• Bool bHalt, true stops the transmission, false enables transmissions.

string GetImageOfData(int datatypecode, int dataformatcode, string publicdata, ....)

This is a new method on the INoahBusinessIntegrationWebInterface, which has been implemented with Noah 4.3.

GetImageOfData returns an image of the data in publicdata, which is if type datatypecode, dataformatcode. The returned image format, width, height and dpi as in the parameters. In order to use this method it is necessary to install an “Audiogram Chart component” on the Noah Server. It is this component that will actually create the picture. The Audiogram Chart component does not yet come automatically with Noah System and it is necessary to install it. The WSI installer (https://himsanoah.atlassian.net/wiki/spaces/AD/pages/499253358/Mandatory+knowledge#The-WSI-components) now contains this functionality and can be used, but it is better to install the new Noah 4 Audiogram Module with an updated chart. 

Q: Does the image include speech audiometry data?

A: No, only pure tone data is supported.

Method signature:

string GetImageOfData(int datatypecode, int dataformatcode, string publicdata, int height, int width, int dpi, string imagetype, int regioncode, int languagecode, Property[] additionalProperties);

Parameters:

• int datatypecode : The Noah data type code (Audiogram = 1)

• int dataformatcode : The Noah data format code (XML=500)

• string publicdata : The public data as a base64 encoded string

• int height : The wanted height of the returned image

• int width : The wanted width of the returned image

• int dpi : The wanted dpi of the returned image

• string imagetype : The wanted image format of the returned image “gif”, “jpg”, “jpeg”, “png”

• int regioncode : The regional code used (symbols etc.) (Microsoft LCID’s)

• int languagecode :The language code (texts) (Microsoft LCID’s)

• Property[] additionalProperties : Additional properties is an array of Key, Value pair strings. The properties is specific to which “ImageCategory” is

The method returns the image byte[] as a base64 encoded string.

Specification of additionalProperties

Please note that all values must be in Culture invariant format (decimal separator dot), Name and Values are case sensitive.

Color is Microsoft Brushes.

int RequestWSIConformanceLevel(int requestlevel);

 

Negotiate between the Backend service and Noah on the level of WSI.

Backend sends a request to Noah on which WSIConformanceLevel it wants to work with. Noah responds with the level Noah can handle, this level should be used for future communication (WSIConformanceLevel attribute in NoahDataExchange and BESQuery xml).

The default is level 1 (Previous to Noah 4.4)

Please note the differences in the schemas for the different WSIConformanceLevels. Schema files are versioned by the V(x) in the filename. E.g. PatientExport.xsd and PatientExportV2.xsd for Level 1 and 2.

Noah is looking for the WSIConformanceLevel attribute in the received XML, to determine which schemas to use for validation etc. If no WSIConformanceLevel attribute Level 1 (default) is used.

bool Resend(string jobid);

 

Request to resend previous failed transmissions. If jobid parameter is an empty string, Noah will resend all failed transmissions, else only for the specified jobid.

Noah returns true if executed. The Resend operation might not result in any transmissions, if either the jobid was not found or no transmissions could be set to the resend state.

JobStatus[] Status(string jobid);

 

Request status for either a single job identified by jobid, or for all currently queued transmissions (if jobid is an empty string).

The returned data is an array of JobStatus structure.

JobStatus structure:

Jobid    : The id of the job. (Empty string means not belonging to a specific job)

Pending : number of transmissions not yet transmitted.

Queued : number of transmissions that is put into the failed queue.

The BackEnd Webservice must implement the following interface.

[ServiceContract(Namespace = "http://himsa.org")]

public interface INoahBusinessIntegrationWebOtherSideInterface

{

/// <summary>

/// DataFromNoah method

/// </summary>

/// <param name="NoahLocation"></param>

/// <param name="NoahUser"></param>

/// <param name="BusinessSystemUser"></param>

/// <param name="MessageID"></param>

/// <param name="data"></param> [OperationContract]

void DataFromNoah(string NoahLocation, string NoahUser, string BusinessSystemUser,

int MessageID, string data);

}

The name of the client endpoint must be

“BasicHttpBinding_INoahBusinessIntegrationWebOtherSideInterface.” This name is used to determine the configuration for transmitting to the Back-end Web service.

<client>

   <endpoint address="http://localhost:8001/NoahBSOtherEnd" binding="basicHttpBinding"

bindingConfiguration="BasicHttpBinding_INoahBusinessIntegrationWebOtherSideInterfac

e"

contract="NoahBusinessSystemSide.INoahBusinessIntegrationWebOtherSideInterface"

name="BasicHttpBinding_INoahBusinessIntegrationWebOtherSideInterface" />

</client>

DataFromNoah

The method is used by Noah Web Service to transmit data to the back end system.

Parameters:

• String NoahLocation

• String NoahUser

• String BusinessSystemUser

• Int MessageID not used

• String data

The Data contains the XML document defined in the Schema files NoahDataExchange.xsd, PatientExport.xsd etc.

It is possible for the Back End system to request a transmission of patient(s) and their actions, based on Action createdate and or DataTypes and or BackendPatientID’s (BESPIDS)

The query is done via a XML document that specifies the query to execute against the Noah Database.

The Noah Web Service has the method DoQuery() that puts the query in the Noah Web Service job queue.

Please note the <xs:attribute name="WSIConformanceLevel" type="xs:int" use="optional"/> which was added and was defined for Noah 4.4. The value controls the conformance level for the returned data. (Default is level 1.

Example:

<?xml version="1.0"?>

<Query xmlns=http://www.himsa.com/BESQuery.xsd WSIConformanceLevel=”2”>

<CreateDate>

<StartDate>2010-03-20T10:29:23</StartDate>

<EndDate>2012-03-20T10:29:23</EndDate>

</CreateDate>

<DataTypes>

<DataType>Audiogram</DataType>

<DataType>HearingInstrumentSelection</DataType>

</DataTypes>

<BESPIDS>

<BESPID>0000002</BESPID>

<BESPID>0000006</BESPID>

</BESPIDS>

This will return Patient actions created between StartDate and EndDate, only Audiograms and HearingInstrumentSelections for BESPIDS 0000002 and 0000006

Omitting BESPIDS will return for all BESPIDS the same applies for CreateDate and Datatypes. Omitting StartDate or EndDate will be open StartDate or open EndDate.

The following example returns all audiograms.

<?xml version="1.0"?>

<Query xmlns="http://www.himsa.com/BESQuery.xsd">

<DataTypes>

<DataType>Audiogram</DataType>

</DataTypes>

</Query>

</Query>

The NoahBSPatientRecordTransferIntegServer has two methods for patient record export and import.

[ServiceContract(Namespace = "http://himsa.org")]

public interface INoahBusinessPatientRecordTransferInteface

{

[OperationContract]

byte[] PatientRecordTransfer(string BusinessSystemPatientId);

[OperationContract]

int PatientRecordReceive(string NoahLocation, string BusinessSystemUserId, byte[] patientData);

}

The web service is started upon a different port then the Noah 4 wsi web service in order to not interrupt the patient import and export of new and altered actions used for the primary WSI operations.

PatientRecordTransfer 

For export of patient and his or her records please use the PatientRecordTransfer method e.g. The Business system request’s one of it Noah 4 sites to export all records for a patient, which is identified by the BusinessSystemPatientId passed to the PatientRecordTransfer. The method will return a byte array, which is NHAX formatted. The byte array can be saved as it is on the Business server side for backup purposes or if the patient data is to be passed to another Noah site. – Do not alter the byte array, since that can cause the imported back into Noah to fail.

PatientRecordReceive

For the importing of patient records into a given Noah site, please use the PatientRecordReceive method. The import method takes 3 parameters the Noah locations as a string equal to the Noah location values used in the PatientImport method. The 2nd parameter is the BusinessSystemUserId used to identify who has made the transfer. During the transfer Noah will check if the patient is already in the database, if it is, the patient data will be updated.

It is no longer necessary to configure the Noah client service to use the NoahWebIntegrationGUIStart.dll via NoahConfig.exe.  Since Noah 4.5, the NoahWebIntegrationGUIStart.dll is part of the Noah installation. If the client is using Noah 4.4, it is necessary to copy the dll to all Noah client PCs, that will use this facility. HIMSA has created a program “NoahClientPluginConfig” which can be run and will copy and will register the dll with Noah (available in the SDK)

If you wish to register the dll manually, this is also doable:

Copy the plugin NoahWebIntegrationGUIStart.dll – that can be downloaded from the himsa.com website to the PC.  Then from within the Noah 4 installation folder, start a command prompt to register the dll. NoahConfig.exe enables this configuration: Start a command prompt inside the directory where Noah 4 is installed and type NoahConfig –rncedll = “The full path to the plugin dll surrounded by double quotes” as shown below:

Please observe that the computer must be restarted before this change takes effect.

Noah Web service integration can be configured by the use of the Noah Business System Integration Tool, (NoahBSIntegserverTool.exe) which can be found in the Noah 4 application folder.

The Noah Business System Integration Tool (short: NBSIT) will allow the user to enable and disable the WSI functionality from the menu File -> Enable Web Service Integration. Note that the functionality can only be enabled if a valid license is installed. NBSIT will check the validity of the license.

Under the Windows menu, five sub-menus are found enabling the user to follow-up on imported and exported data Inbox and Outbox menu(See Inbox and Outbox), restarting the Noah service and doing archive management. Furthermore, all the configuration parameters can be accessed from the configuration menu.

The Inbox form enables the user to trace the imports made to Noah, and if needed, mark any import to be resolved and thereby forcing a reimport. The trace or events for an import in Noah can be seen by selecting a particular import in the top list box name Inbox and the Inbox log (lower list box) will then show the events for this import. (Please see RequestWSIConformanceLevel Flow and Appendix 1: Error Codes for a list of Error Codes).

Get Data: Select a Business system user id from the drop down list.  Then press get data and all rows which are not imported into Noah for resolving reason or due to BESPID errors will be displayed. If the trigger flag checkmark is set to all data, data which is already imported into to Noah will be shown.

View Data: Select a row and press the view data button and the imported XML data is shown in a viewer.

Clear Flag: Clear the trigger flag, this will put the already imported data into a resolving mode.

Set Flag: Sets the trigger flag. Noah will not try to resolve the data imported.

View Data: (Inbox log) As for the inbox list view.

The form contains info on the communication from Noah to the backend system. The upper view is the status and contents of the Transmit queue.

Right clicking on an item shows a menu, where it is possible to re-transmit or delete the selected items.

The lower view shows a log of the transmit process.

It is possible to remove old entries via “Clear old logs”, or right click on the view to show a menu to delete the selected items.

The menu Start Windows Service opens a form, which gives the current status of the Noah server service installed on the PC. The service can be started, stopped or restarted.

Start: Starts Noah server service on the local PC.

Stop: Stops Noah server service on the local PC.

Restart: Restarts Noah server service on the local PC.

The archive management form enables the user to archive data from the inbox and inbox log in the web service data repository.

Date: Archive date. The archive will be created from this date and back.

Archive…: Opens a folder dialog so that the user can point out the location of the archived data. When the folder is located the data will be saved to a csv file and deleted from the repository from the date typed in.

Restore..: Opens a file dialog, which enables the user to point to the csv file to restore into the web repository.

Each of the configuration forms has its own unique configurations schema and xml file, so when exported it can only be imported by the same form. The default configuration is installed during the initial execution of the NoahWsiSetup exe, where the default settings files are imported. The settings files are saved in the Noah WSI db repository.

Each of the configuration forms has a delete button and an export button. The delete button will delete your current settings. You can export your configuration by the use of the Export button. If no settings are defined and stored in the Noah WSI db repository for a configuration part, e.g web service settings, the user will be prompt for an xml file to import. The user can cancel the import of the file and thereby create a new empty configuration for the viewed part.

Web service settings

Noah web service integration offers two ways of defining the web service’s communication settings, either by using of the Noah Business System Integration Tool or by editing the traditional config file shipped with the web service assembly of Noah (NoahWebIntegration.dll.config), which can be found in same directory as the other config files used by Noah.

If the communication is to be undertaken with the use of security certificates, then it recommended that the traditional config file is used. It is also strongly recommended that all editing of the config file id be done using the SvcConfigEditor.exe from Microsoft, it can be found in the windows SDK v6.0.

No matter, which configuration method is used, the following fields in the web server settings are mandatory:

BackEndWebServiceName, Name, NoahSiteIdentification and NoahWebServicePort.

If it is needed to run the webservice upon another IP address than the one, which is default for the PC server, then it is possible to specify this in the parameter NoahWebServiceId.

The communication protocol is made up of an endpoint definition, which contains one or more binding definitions.

If the communication protocol for the Noah web service endpoint binding is chosen to be either basicHttpBinding, basicHttpContextBinding, wsHttpBinding or wsHttpContextBinding, the web service settings configuration can be used for setting the communication parameters.

Note that the parameters: MaxBufferPoolSize, MaxBufferSize, MaxReceivedMessageSize, MaxStringContentLenght and MaxCharTableCount must be considered, since they control the max data size to import from and in to the backend system. The data size can vary depending on the number of actions included in the xml string. See picture below:

For a detailed description of all WCF communication parameters please consult: http://msdn.microsoft.com/en-us/library/ms731734.aspx or http://msdn.microsoft.com/en- us/library/ms733099.aspx or Windows Communication Foundation – Unleashed isbn-13 978-0- 672-32948-7.

When the Noah Web service is installed, the service endpoint bindings both for client and server is set to a basicHttpBinding. MaxBufferPoolSize, MaxBufferSize and MaxReceivedMessageSize to 65535 and MaxtableCharCount to 1000000.

The e-mail settings form facilitates the possibility to configure the e-mail functionality implemented in Noah web service.

Emails: Contains the email addresses which will receive an e-mail in case of a malfunction of the web service.

EmailSender: Who is sending the e-mail.

EmailServer: Name of the e-mail server.

EmailServerPort: Port for sending.

Items:

EnableAutomaticExport enabled: Automatic means when an action of an “enabled datatype” is saved to the database, and not changed within AutotransmitActionsAfter time.

EnableManuelExport enabled: Manuel export is by right clicking on an action of a “enabled datatype” in the session browser.

The following items are the enabled datatypes:

• • AudiometricData

  • ImpedanceData

  • RealEarMeasurementData

  • HITData

  • HearingInstrumentSelectionData

  • FittingData

  • RemoteControlData

AutotransmitActionsAfter - is for AutomaticTransmissions and is the time that the exporter waits before sending the saved action. The default is 5 seconds.

TimeBetweenTransmissionRetries -  is the time to wait between transmission retries, default is 2 min.

Retries -  is the number of attempts to transmit an action.

DefaultBusinessSystemUserID - is default BusinessSystemUserID to use in transmissions (default is WSI).

The setting for the import is edited in the Import settings form. (See picture below).

AlwaysPromptForImport: If set to true, all patients imported will show up in the resolve dialog. ImportAt100: If set to true, Noah web service will in the case of a resolve situation update the found patients demographic data only if there is a 100% match on all demographic data (Names, Addresses, phone numbers…)

In Noah 4.2 both the “AlwaysPromptForImport” and the “ImportAt100” should stay false.

Database setting for Noah web service is for Noah 4.3 and later. All clean-up operations done on the web service repository for Noah 4.2 are done in the Noah Business System Integration tool from the archive menu.

CleanUplevel: (Not yet implemented!)

UseCleanUp: (Not yet implemented!)

The Patient Record Transfer Settings are  like the web service settings form.  It is used for setting up the web service for the full patient record transfer.

EnablePatientRecordTransfer: Set to true in order to enable the full patient record transfer.

NoahpatientRecordTransferWebServicePort: used to set the port for the web service.

Close timeout: Close time for Web service

Open timeout: Open Time for Web service

ServiceEndpoints: See web service settings form

The CustomMetaDataControl is only used when doing manual WSI. It is a way to capture extra information about the session – which is solely exported to the BES. It is not stored in Noah. It is also possible to set up a signing process – which will request a special signature from the person who is exporting the data. See sample “CustomMetaDataControl” section “CustomMetaData”

Assembly: The name of the assembly to be used for CustomMetaData. On input this must be the full path, the assembly must exist, on the local server pc.

Control Name: The name of the UserControl in the assembly that implements the interface ICustomMetaDataCtrl. The combobox contains a list of control names that implements the ICustomMetaData interface in the assembly. (Defined in CommonControlsLibrary.dll)

Version: The version of the Assembly specified above.

When the configuration is saved into the database the assembly is saved to the database as well.

The assembly is then parsed to the client pc’s on request, if the clients assembly has a lower version.

The ICustomMetaDataCtrl interface is defined in the CommonControlsLibrary assembly.

A CustomMetaData control must implement this interface on the usercontrol to show in the Manual export form.

Sample of a CustomMetaDataControl in the Export form. The customMetaDataCtrl occupies the space in the middle of the form between the 2 lines.

Glossary

WSI Ports

The following design notes are the overview flow chart.  It can be used for discussions and for understanding the flow.

Automatic export flow

The use of e-mail notification was first implemented with Noah 4.3

The manual export flow is first finalized with Noah 4.3

The BES has the ability to create patient records in Noah. A common example would be a patient record exists in the hospital system.  This patient record can be pushed to Noah.

The BEWS can use the method PatientUpdate to update the BESPID for a patient. The BEWS can also update a Patient with a blank BESPID, meaning that the current Noah Patient is no longer tied to the BESPID (In case of mistaken resolve process or Patient matching).

There can only be one Patient with a BESPID in the Noah database. It should be rejected if there is a request to update another Patient with an already existing BESPID.

Appendix 1: Error codes

The following figure shows a logical view of Noah 4.

The Noah 4 system can be divided into 6 logical groups:

• Business API

• Module API

• NOAH 3 Module Server

• NOAH 2 Module Server and wrapper

• Noah 4 Client – windows service

• Noah 4 Server – windows service host the web

One of the objectives of Noah 4 is to convert COM to .NET components. However, some COM components remain due to the requirements of backwards compatibility. It is also a requirement that the HIMSA development platform should be the latest Visual Studio version.