Understanding attributes and attribute clusters 

  • UMPI
  • Attribute Clusters

Each source record you provide to Universal MPI, and each reference identity in CARBON, 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 MPI includes three categories of attributes: Core, Extended, and Custom

Core attributes

Core attributes exist in both the Universal MPI data model as well as the CARBON reference 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 MPI 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 MPI 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.
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 MPI, 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:

  • M - Male
  • F - Female
  • U - Unknown
  • O - Other
  • T - Transgender
  • A - Ambiguous

 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
Email Email address Email address

Extended Attributes

Extended attributes exist only in the Universal MPI data model but not in CARBON. 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
External Unique ID Issuer

The name/code of the issuer of the external unique ID. The external unique ID is an ID proprietary to Verato, Inc. subject to restrictions on cover page 6 created and assigned outside of Universal MPI, typically by a client's previous MPI, MDM, or other matching software. Universal MPI 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 MPI/ 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 MPI 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 MPI 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 MPI 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 MPI 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 MPI. 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 MPI. Custom attributes are not subject to any normalization or validation processing. Universal MPI 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. 

Web service interactions are available to insert, update, retrieve, and delete data from the Universal MPI. Refer to our Web Service API documentation for more information about these services.