Each source record you provide to Universal Identity, and each reference identity in the Reference Database, is comprised of multiple demographic data values. These values are known as Attributes. Some attribute values are logically grouped together into Attribute Clusters. For example, the attributes of first name, middle name, and last name are grouped together into an attribute cluster known as Name.
Universal Identity includes three categories of attributes: Core, Extended, and Custom.
Core attributes
Core attributes exist in both the Universal Identity data model as well as the Reference Database identity data model. They have pre-defined data structures and are used in the matching process to determine whether two identities are the same or not.
The core attributes are also evaluated against a normalization and validation service to remove certain anomalies or format certain attributes more consistently – for example, an SSN number submitted to Universal Identity with hyphens will be normalized to remove the hyphens; or an SSN number that is invalid (for example the Social Security Administration rules indicate that any SSN beginning with 9 is invalid) will be persisted in Universal Identity but marked as invalid for matching purposes.
Core attributes table
| Cluster | Attribute | Description |
| Source | Name |
The name/code of the source from which a specific customer record comes. |
| ID |
The local unique identifier of a specific customer record within the source, also referred to as Native ID. |
|
| Name | First name | First name for a person |
| Middle name | Middle name for a person | |
| Last name | Last/family name for a person | |
| Suffix | Suffix, e.g. Jr., Sr., etc. | |
| Address | Street line 1 | 1st line of the street address. Certain components of the street address, such as street type or street direction, may be normalized to their abbreviated versions. For example, STREET would be normalized to ST, or WEST would be normalized to W. |
| Street line 2 |
2nd line of the street address. Certain components of the street address, such as unit type, may be normalized to their abbreviated versions. For example, APARTMENT would be normalized to APT. |
|
| City | City for the address | |
| State | State code (2-digit) for the address. State names that are fully spelled out (e.g. KANSAS) will be normalized to the 2-character code (e.g. KS). | |
| Postal code | Zip code (5-digit or 5+4 digit) for the address. | |
| Country |
Fully spelled-out country names that are valid will be normalized to a 3-character code. Any invalid country names will simply be converted to uppercase. |
|
| Type | Label specifying the purpose of the address. | |
| Birthdate | DOB |
Birth date, in ISO YYYYMMDD format Birth dates with or without hyphens or slashes are acceptable, so 19720514, 1972-05-14, and 1972/05/14 are both acceptable. |
|
Social Security Number
|
SSN |
9-digit US Social Security Number. SSNs with or without hyphens are acceptable, so 987-65-4321 and 987654321 are both acceptable. Regardless of whether SSNs are provided with our without hyphens, during ingestion into Universal Identity, each SSN is normalized to remove hyphens and any other non-numeric characters. |
| Gender | Gender |
Gender code – M, F, U, O, T, A, and N are valid. Full gender text strings will be normalized as follows:
Strings of ‘Not Applicable’, ‘NA’, or ‘N/A’ will be normalized to N. |
| Phone Number | Country Code | Country code prefix |
| Area Code | 3-digit area code prefix with no parentheses or other punctuation. | |
| Number | 7-digit base phone number with no hyphens or other punctuation | |
| Extension | Phone number extension | |
| Type | Label specifying the purpose of the phone number. | |
| Email address | Email address | |
| Type | Label specifying the purpose of the email. |
Extended Attributes
Extended attributes exist only in the Universal Identity data model but not in the Reference Database. They have a pre-defined data structure but are not yet used in the matching process. They are not subject to any normalization or validation processing. A subset of the Extended attributes are search-able using the demographicsSearch web service.
Extended attributes table
| Cluster | Attribute | Description |
| Death Details | Deceased Indicator |
This field indicates whether a person is deceased. The following values are accepted:
|
| Date |
Date of the person's death. Note |
|
| City |
City where the person died. Note |
|
| County |
County where the person died. Note |
|
| State |
State where the person died. Note |
|
| Country |
Country where the person died. Note |
|
| External Unique ID | Issuer |
The name/code of the issuer of the external unique ID. The external unique ID is an ID external to Verato, Inc. created and assigned outside of Universal Identity, typically by a client's previous MPI, MDM, or other matching software. Universal Identity does not honor this external unique ID during its own matching process, but clients can store and retrieve the external unique ID as an extended attribute if it benefits their business processes. |
| Value | The value, or ID number itself, of the external unique ID. Typically, the combination of the issuer + value is unique. The combination of issuer + value is also searchable using the demographics Search web service. | |
| Status | Status of the external unique ID. This status is not assigned or managed by Universal Identity/ It is simply a place to store the status of the external unique ID as managed by whichever external system generated it. | |
| Start Date | Start or effective date for the external unique ID. | |
| End Date | End date for the external unique ID. | |
| Alternate Identifiers | Type | The name/code of the type of alternate identifier – Universal Identity does not impose any standard or list of acceptable values for the type, it is up to each client to define the type codes/names they will use. The Alternate Identifiers extended attribute is a place to store additional identifiers that might be relevant to each client’s business. For example, it could be used to store Medicaid numbers or Customer Loyalty Numbers. |
| Issuer | The name/code of the type of alternate identifier | |
| Value | The value, or ID number itself, of the alternate identifier. The combination of type + value is also searchable using the demographicsSearch web service. | |
| Start Date | Start, or effective date of the alternate identifier. | |
| End Date | End date for the alternate identifier. | |
| Health Insurance Coverage | Payer Name |
Name of the health insurance payer. The health insurance coverage information extended attribute is a place to store a variety of information about a person’s health insurance coverage. |
| Plan Type | Type of health insurance plan. Universal Identity does not impose any standard or list of acceptable values for the plan type, it is up to each client to define the types they will use (such as PPO, HMO, or other types). | |
| Group Number | Group number of the insurance coverage. | |
| ID Number | Member ID number of the insurance coverage. The ID Number is also searchable using the demographicsSearch web service. | |
| Subscriber ID | Subscriber ID number of the insurance coverage. | |
| Sequence Number |
Sequence number for the insured person within the policy – typically the combination of subscriber ID and sequence number creates a unique key. |
|
| Start Date | Start or effective date of the insurance coverage. | |
| End Date | End date of the insurance coverage. | |
| Multiple Birth Indicator | Indicator |
Y or N value. Y indicates that the person is known to be a twin, triplet, or other multiple birth. N indicates that the person is known to be a single birth. Value is left blank if unknown. |
| Guarantor | Relationship |
Guarantor’s relationship to the Universal Identity identity. Guarantor information is an extended attribute used to capture the identity of a healthcare patient’s guarantor The guarantor is the person responsible for paying for care, such as a parent or guardian, when the Universal Identity identity is a child or minor. |
| First Name | Guarantor's first name | |
| Middle Name | Guarantor's middle name | |
| Last Name | Guarantor's last name | |
| Suffix | Guarantor's name suffix | |
| DOB | Guarantor's date of birth | |
| SSN | Guarantor's social security number | |
| Address Line 1 | Guarantor's address line 1 | |
| Address Line 2 | Guarantor's address line 2 | |
| City | Guarantor's city | |
| State | Guarantor's state | |
| Zip | Guarantor's zip code | |
| Phone | Guarantor's phone number |
Custom Attributes
You can define custom attributes in their instance of Universal Identity. They do not have a pre-defined data structure. Each client must define and interpret the structure of the custom attributes based on the JSON objects they submit into Universal Identity. Custom attributes are not subject to any normalization or validation processing. Universal Identity software is not aware of, and does not interpret, the contents of the custom attributes.
Custom attributes do not have a pre-defined data structure. If you want to use custom attributes, you must keep track of the data structure and use that data structure consistently within the JSON object. Custom attributes are represented in the JSON object by prefixing the custom attribute name with “custom.”
For example, suppose you wanted to use a custom attribute to capture the information about a person’s vehicle: the make, model, and year of the vehicle.
Within the JSON object for the identity in a postIdentity web service request, you would insert the following JSON object:
"custom.vehicle": [
{
"make": "Honda",
"model":"Accord",
"year": "2013"
}Whenever that identity is retrieved, the identity object will include (along with the usual core and extended attributes) the custom attribute.