The Back-end System Patient ID = BESPID

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.