Matching Patient Record IDs Between a Business System and Noah ES

This document is currently a preview and draft, If you are interested in more details or have input please open a support issue with the subject “Matching Patient Record IDs”

The Need For A Solution

The general need is that business systems will find it useful to exchange data with Noah ES. For example, if a business system wants to obtain a copy of a newly created audiogram for a patient in Noah ES, then it can do so in a few different ways:

  • Query Noah ES by patient name and hope that there is an exact match, once found then obtain the latest audiogram action

  • Subscribe to Noah ES events; when the event is received, the business system will then need to find a match in the business system.

The above processes will run much smoother if the business system can have a level of assurance of the correct patient if a unique ID is used. In the case of Noah ES and a business system, each system will have its own unique patient id.

As each system has its own ID, there must be a method to link the two IDs together.



General Solution

Step 1, the suggested first step is to migrate data into Noah ES. The main benefit is that it will be easier for the business system to work with Noah ES via the modern REST-based API. There are no understood benefits of working with the data before moving to Noah ES.

The Noah Migration Process is a very robust tool that can handle large workloads while allowing HCPs to use Noah ES simultaneously.

Also, consider using to first search for and merge duplicated patient records.

If you have a large operation with many offices, you may also wish to make use of to separate access into smaller groups. Please for further information.


Step2, select a link strategy.

As illustrated to the right, there are two strategies:

  • Option 1 - Add the business system ID to the Noah ES Patient record. Once the business system is sure of the two patient records, use the Noah ES API provided method to add the business system patient ID to Noah ES. Once this ID is attached to Noah ES, the business system can then select this patient (programmatically) via the business system patient ID. Additionally, the business system can look up the Noah ES Patient ID via the business system patient ID.

  • Option 2 - Add the Noah ES Patient ID to the business system patient ID. This is the reverse of the above idea. In this case, the business system keeps track of the patient’s ID.

  • Option 3 - implement both options 1 and 2

Step 1 - Migrate data to Noah ES

Finding Matches - Option 1

The ID linking options are straightforward options and easy to implement. Finding the matches when there are many patients in the Noah and business system database can be challenging.

This first option makes use of export lists of patients. Two options are supported:

  • CSV - a text-based export of patient demographic data only. This can be used within MS Excel and many other programs for visualization and organization

  • XML - XML formatted export of patient and diagnostic information saved to Noah using of one of HIMSA’s published data standards.

Once the list format is selected and exported, the following general steps will be followed:

  • The business system would export a list of patients

  • The business system developer would arrange for a procedure of reviewing the lists and recording the Noah ES patient ID in the business system list.

  • The business system developer then makes use of the Noah ES API to

    • Select the patient by Noah ES patient ID

    • Add the business system ID to the Noah ES patient

    • Repeat the process for all patients on the list.

Two small examples are provided at the bottom of this section.



Finding Matches - Option 2

With this second option, the business system developer does not export lists out of Noah ES but rather takes an approach such as:

  • Selects a patient in the business system

  • Queries Noah ES for a potential match

  • If a match is found, then make the link

  • If the patient is not found and it is felt they have never existed in Noah, then take this opportunity to add the patient now.

    • When the patient is added, the business system can also match the patients

  • If a potential match is found but unclear, then save the patient for later manual review


Poplular demogrpahic fields that can be used for comparrison

  • Patient ID - A globally unique ID. This ID is not visible via the Noah ES Client GUI

  • Patient Number - Noah offers the ability to use manual patient numbering. If this is selected, then the user is required to enter in a patient number. This is usually associated with an ID coming from another system.

    • If manual patient numbers were not used, then the Patient number is automatically assigned.

  • Name

    • First, Middle, Last

  • Date of Birth

  • Telephone number

    • Mobile, Home, Work

  • City

  • Address

    • Address 1,2,3

Popular non-demographic data that can be used for comparison

  • The serial number for hearing devices is assigned to the patient record. It is also possible to view the manufacturer (by code) that is associated with the serial number to help ensure uniqueness.