| Attribute or attribute cluster |
Standardization performed by Provider Identity |
| All |
Extended ASCII characters with a logical ASCII equivalent are converted to their ASCII equivalent. For example, the extended ASCII character Ñ is converted to the ASCII character N.
|
| All |
Alphabetic characters are converted to uppercase. A subset of the Extended Attribute fields can optionally be kept in their original case, but by default all alphabetic characters are converted to uppercase. |
| Name |
- Numeric characters are not removed from name attribute values (though this can be changed with a configuration setting by contacting Verato support).
- The position of name strings are not changed during normalization, but they are factored into matching decisions. For example, one provider record might have the name strings First Name=”JOHN PAUL” and Last Name=”SMITH”, while a second provider record might have the name strings First Name=”JOHN”, Middle Name=”PAUL”, and Last Name=”SMITH”. In this case, the position of the name strings are not changed or standardized, but the matching algorithm is designed to recognize that there is still a match between the names JOHN-JOHN and PAUL-PAUL.
- Multi-byte characters, if present, are NOT removed from name strings for many different non-LATIN character sets, such as Chinese or Arabic character sets. However, this behavior is not exhaustive for the entire set of UTF-8 multi-byte characters. There can still be multi-byte UTF characters that get removed during standardization.
|
| Address |
Address components are standardized in several ways consistent with US Postal Service conventions. Examples include:
- Street direction values presented as a full text string are converted to their 1- or 2- character abbreviation (N, S, W, E, NW, NE, SW, SE)
- Street type values presented as a full text string are converted to their USPS short format (Street becomes ST, Avenue becomes AVE, and so on)
- Ordinal street names are converted to their numeric format (Second Street becomes 2 ND ST)
- Unit, suite, or apartment information is parsed into address line 2, even if it is presented as part of address line 1
- State names presented as a full text string are converted to their 2-character abbreviation (California becomes CA) Multi-byte characters, if present, are NOT removed from city or state attributes, but they are removed from address line 1/address line 2 attributes for many different non-LATIN character sets, such as Chinese or Arabic character sets. However, this behavior is not exhaustive for the entire set of UTF-8 multi-byte characters. There can still be multi-byte UTF characters that get removed during standardization.
|
| Gender |
Gender values are standardized to single-character gender codes of M, F, U, O, T, A, and N if the full string is provided as input. For example, an input gender of FEMALE is standardized to F. An input gender value that does not correspond to M, F, U, O, T, A, or N is not standardized – it is stored as-is.
M = Male, F = Female, U = Unknown, O = Other, T= Transgender, A = Ambiguous.
|
| Phone |
- Alphabetic characters and punctuation symbols are removed.
- A 10-digit phone number can be submitted either in its entirety (e.g., 1112223333) or broken down into an area code and the remaining digits (e.g., 111 and 2223333)
|
| Email |
- Prefix “mailto:” is removed if present
- Common consumer email domains are appended with “.com” if missing (gmail, yahoo, Hotmail)
|