Expand acceptable zip codes to accommodate international postal code formats.

[mjfos2r]

Currently we exclude all postal codes that are not five numeric digits zip5, with the possibility of expansion to ZIP9.
To keep from excluding all international postal codes, this should be expanded to accommodate the various formats that may be encountered.

Of these, I've identified two that are highest yield: Canadian and UK.

Canadian postal codes are officially described here and are of a standardized six character format with alphanumeric characters possible.

UK postal codes are described here and officially here and are much more variable.

Of course, handling international postal codes can easily become its own project, but I feel that expanding the acceptable formatting during validation would resolve a few hundred dropped records.

This could be be performed by additional functionality where a country check is executed and for non-USA countries, the respective format is used to validate that field.

[AshlinHarris]

Thanks very much! It's extremely helpful to have feedback on other site's EHR.

Would it make sense to avoid most validation here? A few considerations:

• Validating specific data elements could take significant time.
• Suppose a postal code is rendered invalid due to human error, data entry restriction, etc. Shouldn't the resulting value still contribute towards the linkage probability?
• Suppose an invalid value is intentionally provided by the patient across health systems. Could there be cases where this should indicate linkage?

A simple strategy could be to filter out only values that are known to be unfit to use for linkage. A good rule of thumb may be to mark fields as invalid if they contain characters used to flag non-values or notes in the EHR. Some general patterns I've observed:

• using exclamation marks to indicate fake names: "ZZZTEST!!!", "NOT PROVIDED!"
• using angle brackets to indicate comments: ""
• using numbers in names: "Child1", "Boy3"

There may be other regular patterns, though these could be more difficult to accommodate, and the chance of false positives could be higher. Some patient names seem to me to be placeholders, especially for infants.

The simplest way forward in general may be:

• Normalize characters where the transformation is unambiguous, especially if the value is expected to be subject to data entry limitations, or if the the potential loss of information from removing the value would be unacceptable. Removing diacritic marks is a prime example.
• If the field contains a no-go character such as !, discard it as invalid
• Leave the remaining text unchanged.

I do agree that some validation makes sense wherever we're comparing positionally and not with ngrams. However, validation takes additional effort and can be error-prone, so I'd limit it to cases where it's essential to the project. Still, I'm happy to include any validation methods you plan to contribute, though I may add a toggle to disable these where needed.