Soft-Matching

Soft matching is applied at a customer's request to the patient PID (Personal Identifiable Information) data supplied in the HL7 messages we receive (excluding demographic update/create messages). Once an HL7 message has been checked to ensure the PID segment contains "hard matching" values that match an existing patient record (e.g national identifier such as an NHS number or local hospital ID such as an MRN) and we return an acknowledgement response, we then check it meets the soft-matching criteria.

If there is a failure to match the soft-matching criteria in the HL7 message PID segment with the data held in the patient record, the message will be held for review. The data in the message will not be added to the patient record but will instead be placed in an HL7 review area, waiting for the Organisation Administrator to manually review the mis-match and decide whether to approve or reject the message for inclusion in the patient record.

Example with soft-matching turned on:

  • Customer A sends an appointment via 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.

Additional technical detail on the use of identifiers and matching can be found in our development wiki

Supported configuration

PKB supports using date of birth for soft matching, as this provides the appropriate level of data quality checking for when we receive HL7 messages. The rationale being 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 check point.

  • For a message to add data to the wrong patient it would have to match on 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 the 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.

FAQ

  1. Will changing existing soft-matching rules, retrospectively apply that change to messages currently being held for a soft-match failure?
    A: No, any change will only apply to HL7 messages received from the time of the change.

  2. Could PKB accept or reject all messages currently being held for soft-matching failures en-masse?
    A: Yes, that could be achieved, please request via a FreshDesk ticket.

  3. Are there any complications or risks if messages are just re-sent (by the trust) or approved en-masse from the HL7 review queue for processing (possibly just for the last 6 months)?
    A: We would recommend clearing down the queue of messages being held for review prior to re-sending those messages. Beyond that, PKB has logic that handles the processing of received messages in the correct order where corrections or deletions are a consideration.

  4. Does soft-matching have to be applied?
    A: No, this is an optional configuration setting