Soft Matching

Soft matching is an optional process allowing for stricter patient matching based on demographic fields in addition to any identifiers, such as an NHS number. If soft matching is enabled, then when an HL7 message is successfully matched to a patient record based on the provided identifiers (hard matching) then PKB will also check that the demographics in the HL7 message match those that we have in the record. If they do not match, then the message will be quarantined for review by an Organisation Administrator.

There is an exception to this - soft matching will be bypassed if PKB detects that a previous accept/reject decision has already been made for the same data point. In that scenario the same decision will be applied to the HL7 message, regardless of whether the configured demographics fields match. For example, if a lab result is added into a patient's record on Monday, but a correction is sent on Tuesday with incorrect demographics, then the message will still be accepted because the Filler Order Number will match the initial data sent on Monday. This also applies retrospectively. For example, if a lab result is quarantined for Organisation Administrator review on Monday, but a correction is sent on Tuesday with correct demographics, then the message from Monday will be automatically accepted along with the message from Tuesday. This logic helps to ensure that a data point is accepted/rejected consistently; this is safer, and also reduces false-positives, freeing Organisation Administrators to look at messages containing data points that have consistently failed to match the target patient.

Note: Demographic-based soft matching is not applicable to messages which create a new patient record or update the demographics of an existing patient record (i.e. ADT A28/A31) - see the NHS number status checking section below.

Example with soft-matching turned on:

• Customer A sends an appointment via an HL7 message

• We check the message is valid (e.g. is structured correctly and contains all required values)

• If that is OK, we check that the PID segment of that message contains a national or local identifier that matches one of our existing PKB records.

• When a match is found we return an automated response to say the message can be processed.

• We then check the date of birth supplied in the HL7 message against the date of birth in the patient record.

• If the date of birth values match the appointment is added to the patient record. If they don't match, the message is held for review by the organisation administrator who can then choose to release the data or reject it.

Supported configuration

PKB supports using the date of birth for soft matching, as this provides the appropriate level of data quality checking for when we receive HL7 messages. The rationale is that:

• There is a hard matching requirement for a national and/or local identifier to be provided which is the primary mechanism for ensuring data is added to the correct patient record.

• Given that the soft matching adds a further check to this, the use of Date of Birth alone adds a sufficient data checkpoint.

• For a message to add data to the wrong patient it would have to match both the hard matching and the date of birth. The addition of further soft matching is unlikely to identify any message being sent for the wrong patient that wasn't prevented by these checks.

• Date of birth is less likely to suffer from both errors in data entry and genuine updates. Therefore, using dob provides a robust additional data quality check with a reduced likelihood of messages being unnecessarily held for manual review by the Organisation Administrator.