Identifiers & matching

Overview

PKB supports 3 types of identifier in the HL7 API:

• • System. PKB assigns each patient a UUID. This is unique across the entire PKB system, and can be used to identify a patient independently of their links to any country, organisation or team.

  • National. A national identifier is an identifier that identifies a patient within a given country, such as an NHS number.

  • Local. A local identifier is an identifier which identifies a patient uniquely for a sender, but not outside that sender. An example would be a hospital number. A local identifier can be associated with either a PKB Organisation or a PKB Team.

See also the Identifiers section of our Data Model for more information.

Identifier type assignment

An HL7 identifier consists of several components. PKB is only interested in the following components:

• • [1] ID

  • [4] Assigning Authority

  • [5] Identifier Type Code

An identifier can appear in either PID-2 or PID-3. The field that the identifier appears in (or its position within the list of identifiers if PID-3), is not important to PKB.

We determine which type of identifier has been provided by matching the Assigning Authority (AA) and the Identifier Type Code (TC) to known types. To provide a national ID you must provide the AA and TC corresponding to the relevant identifier. These are given in the following section. To provide a local ID, you need to first agree with us what AA and TC values you use for each of your identifier types. We need to configure these for you before the IDs will be processed by our HL7 API.

Any supplied identifier that does not match a known type will be silently ignored.

System identifiers

In order to send through the PKB ID, you need to provide:

• • an Assigning Authority of: PKB

  • an Identifier Type Code of: PI

National identifiers

In order to send through a national ID, you need to supply the Assigning Authority and Identifier Type Code as detailed in the table below.

* A note about NHS-Type Numbers. The following 3 National ID Types are drawn from the same numbering scheme, but with non-overlapping ranges. PKB considers them to be separate types. It is the responsibility of the sender to ensure the correct AA/TC values are sent.

• • CHI Number (Scotland): 010 101 0000 to 311 299 9999

  • Health and Care Number (Northern Ireland): 320 000 0010 to 399 999 9999

  • NHS Number (England and Wales): 400 000 0000 to 999 999 9999

Local identifiers

You will need to agree with PKB what local identifiers you would like to send through.

Each PKB Organisation or PKB Team can be associated with multiple local identifier types, and each patient can be associated with multiple ID values for each local identifier type.

AA wildcarding

A local ID type can have a wildcard for the Assigning Authority (but not the Type Code). If this is configured, then an HL7 identifier will be assigned to this type if the TC matches, regardless of the provided AA value.

Restrictions & scope

The scope of AA/TC pairs for local IDs is the whole PKB Organisation. All AA/TC pairs for a PKB Organisation (and for all PKB Teams within that PKB Organisation) must be unique across the PKB Organisation.

In addition, a Type Code can only be used with a wildcarded Assigning Authority if that Type Code is not used by any other local ID within the PKB Organisation (or any PKB Teams within that PKB Organisation).

A local ID AA/TC pair must not match the AA/TC pair for any national ID.

The scope of a local ID is always the entire PKB Organisation which contains it. As such, a team-level HL7 connection can read and write local IDs of a type associated with another PKB Team (providing it is within the same PKB Organisation).

Matching

Once all the provided identifiers have been assigned to their corresponding types, PKB will attempt to match them to an existing medical record.

Hard matching

Hard matching refers to the process of identifying a medical record based on the values of the identifiers provided.

National and Local Identifiers are case sensitive.

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.

Supported fields

• Date of birth is the only supported field for new soft matching configuration requests

End of life support

The following fields are no longer supported for new customers.

• • Surname

    • The soft matching process ignores case sensitivity and the use of whitespace, e.g Smith will match to smith .

  • Forename

    • Forename (full): The provided and known forename values are matched in their entirety, e.g. jo does not match joanne

    • Forename (short): The provided and known forename values are matched up to the length of the shorter of the two, e.g. jo does match joanne

    • Forename (initial): The provided and known forename values are matched just on the initial letter, e.g. jo does match janet

    • In all cases the soft matching process ignores case sensitivity and strips whitespace from the start or end.

  • Gender

  • Postal Code

    • The soft matching process ignores case sensitivity and the use of whitespace, e.g TS1TER will match to tS 1 T er.

NHS number status checking

Some messages cannot be soft-matched based on demographics.

• • When creating a new medical record there is no prior demographic information to match against.

  • When updating the demographic information on an existing medical record we must allow the message to change the existing demographic data, rather than match what is already stored.

Instead, PKB can optionally configure an interface to soft-match these messages based on the NHS number status. If this option is enabled, and an NHS number is provided, then PKB will check that the status is present and equal to “01” before creating or updating the medical record. If the check fails, then:

• • If the target medical record does not exist, PKB will ignore the NHS number and behave as if it had not been provided.

  • If the target medical record does exist, PKB will queue the message as needing manual review. A human must then manually confirm that the unverified demographic changes are correct.

In addition, if this option is enabled then an NHS number must be provided to update the demographics information of a medical record that already has an NHS number associated with it.

Auto create

By default, medical records for new patients are created upon receipt of an A28 or A31 message only. PID segments for other message types that do not match a medical record will return an error. If you would like to disable this strict record checking, such that a new medical record is created whenever an unmatched PID is received (in any message) then we can configure this for you. However, you will still need to send an A28 or A31 to update the demographic details about each patient.

Workflow

The diagram below demonstrates our matching workflow.