Verato MDM Cloud™ standardizes (or normalizes) incoming attribute values before they are used in identity resolution. Standardization removes invalid values and enforces a consistent format so that matching decisions are made against clean, comparable data.
This behavior applies to all entity types resolved in Verato MDM Cloud™:
Person entities (Core Person and Patient domains)
Practitioner (Type 1 Provider) entities
Organization entities (Core Organization domain)
Health Facility (Type 2 Provider) entities
Standardization applies to the same attributes for every entity type, with one exception: the Name and Gender attribute rules do not apply to Organization or Health Facility (Type 2 Provider) entities. All other attribute rules below apply to every entity type.
Standardization runs on both web service requests and batch files. Standardized values are persisted in their changed form, not alongside the original input. When you later retrieve an identity, the attribute values returned are the standardized values rather than the values originally submitted. The exact treatment varies by attribute, as described below.
Processing order
Standardization is one step in a defined sequence that runs before a resolved identity is persisted:
Validation — Data from the incoming record is validated against the data-type configured for the attribute in the console.
Normalization — Values that pass validation are standardized according to the rules below.
Persistence — The normalized values are persisted with the resolved identity.
If an attribute's data-type is set to code set, the configured code-set value is persisted rather than a normalized free-text value. For details on defining and managing code sets, see Code Set Management.
Data Standardization
Attribute or attribute cluster
Standardization performed by Verato MDM Cloud™
All
Extended ASCII characters that have a logical ASCII equivalent are converted to that equivalent. For example, Ñ is converted to N.
Alphabetic characters are converted to uppercase. A subset of Extended Attribute fields can optionally retain their original case, but the default is uppercase for all alphabetic characters.
Name
Applies to Person and Practitioner (Type 1 Provider) entities only. This attribute is not standardized for Organization or Health Facility (Type 2 Provider) entities.
Numeric characters are retained in name values by default. This can be changed with a configuration setting — contact Verato support to request it.
The position of name strings is not altered during normalization, but position is factored into matching decisions. For example, one record may store First Name = JOHN PAUL and Last Name = SMITH, while another stores First Name = JOHN, Middle Name = PAUL, and Last Name = SMITH. The strings are left as submitted, and the matching algorithm still recognizes JOHN–JOHN and PAUL–PAUL as a match.
Multi-byte characters are generally retained for many non-Latin character sets, such as Chinese or Arabic. This handling is not exhaustive across the full UTF-8 multi-byte range, so some multi-byte characters may still be removed during standardization.
Birth Date
Birth date values are standardized to ISO format, YYYYMMDD.
Input may include or omit hyphen or slash separators. MMDDYYYY input is accepted and converted to YYYYMMDD.
Input in MMM DD, YYYY format (for example, Jan 1, 2024) is accepted.
Two-digit-year input (YYMMDD or MMDDYY) is converted to YYYYMMDD only when the result is clear and unambiguous. For example, 030405 is ambiguous — it could mean March 4, 2005, or April 5, 2003 — so it is rejected.
Invalid dates and future dates are rejected during standardization.
SSN
Alphabetic characters and punctuation symbols are removed.
The last four digits are retained.
Address
Address components are standardized to align with U.S. Postal Service conventions. Examples include:
Street direction written in full is converted to its 1- or 2-character abbreviation (N, S, W, E, NW, NE, SW, SE).
Street type written in full is converted to its USPS short form (Street becomes ST, Avenue becomes AVE, and so on).
Ordinal street names are converted to numeric form (Second Street becomes 2 ND ST).
Unit, suite, or apartment information is parsed into address line 2, even when it is submitted as part of address line 1.
State names written in full are converted to the 2-character abbreviation (California becomes CA).
Fully spelled-out valid country names are converted to a 3-character code (Germany becomes DEU, Canada becomes CAN). Invalid country names are simply uppercased.
Multi-byte characters are retained in city and state attributes, but removed from address line 1 and address line 2 for many non-Latin character sets, such as Chinese or Arabic. This handling is not exhaustive across the full UTF-8 multi-byte range, so some multi-byte characters may still be removed.
Gender
Applies to Person and Practitioner (Type 1 Provider) entities only. This attribute is not standardized for Organization or Health Facility (Type 2 Provider) entities.
When a full string is provided, gender is standardized to a single-character code. For example, FEMALE is standardized to F.
An input value that does not map to one of the supported codes is ignored, and nothing is stored.
Supported codes:
Code
Meaning
M
Male
F
Female
U
Unknown
O
Other
T
Transgender
A
Ambiguous
X
Non-binary
N
Not applicable
Phone
Alphabetic characters and punctuation symbols are removed.
A 10-digit phone number can be submitted either in full (for example, 1112223333) or split into an area code and the remaining digits (for example, 111 and 2223333).
Email
A mailto: prefix is removed if present.
Common consumer email domains are appended with .com when it is missing (for example, gmail, yahoo, Hotmail).
Comments
0 comments
Article is closed for comments.