Each source record you provide to Provider Data Management, 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.
Provider Data Management includes three categories of attributes: Core, Extended, and Custom.
Core Attributes
Core attributes exist in both the Provider Data Management 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, a NPI number submitted to Provider Data Management with hyphens will be normalized to remove the hyphens.
Core attributes table
Cluster | Attribute | Description | Intended Provider Type |
Source | Name |
The name/code of the source from which a specific provider record comes. |
Individual or Organization
|
ID |
The local unique identifier of a specific provider record within the source, also referred to as Native ID. |
||
Person | First name | First name for a person | Individual |
Middle name | Middle name for a person | ||
Last name | Last/family name for a person | ||
Prefix | Name prefix, such as Dr., Mr., or Mrs. | ||
Suffix | Suffix, e.g. Jr., Sr., etc. | ||
Credential | A person's credentials, such as MD, DO, or PhD | ||
Organization Name | Legal Business Name | The legal business name or most used named for the organization. | Organization |
Other Name | Any other name that the organization may be referred to as. | ||
Parent Organization Name | The name of the organization’s parent company. | ||
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. |
Individual or Organization |
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. | ||
Name | Free-form field to specify custom name for address. | ||
Type | Label specifying the purpose of the address. | ||
Contact Information | Address |
Includes city, address type, postal code, address name, state, and street line 1 and 2. The location type and descriptive name attributes within the attribute cluster accept free-form values. Multiple contactInformation instances can be created within a provider record and multiple phone and/or fax numbers can be assigned to a single address location within contactInformation. All or some of the attribute fields within the contactInformation cluster may be populated—there are no required attribute fields. |
Individual or Organization
|
Phone Number |
Is a list of phone numbers including phone number and type. |
||
Fax Number |
Is a list of fax numbers including fax number and type. |
||
National Provider Identifier
|
NPI |
10-digit National Provider Identifier as assigned by the National Plan and Provider Enumeration System (NPPES). |
Individual or Organization
|
Entity Type Code |
This is a required field. When adding a new provider record, set field value to "1" for individual practitioner data and "2" for organization data. |
||
License
|
Number |
The medical license number issued to a provider by a state. |
Individual or Organization
|
State |
The state that issued the license. |
||
Taxonomy Code |
The 10-character code that designates the classification and specialization of the license, typically per the National Uniform Claim Committee (NUCC) code set list. |
||
Grouping |
A major grouping of services or occupations of health care providers. This attribute is auto populated by PDM if the submitted Taxonomy Code matches a code defined in the Verato-maintained global list and can only be populated by this automated process. |
||
Classification |
A more specific service or occupation related to the Provider Grouping. This attribute is auto populated by PDM if the submitted Taxonomy Code matches a code defined in the Verato-maintained global list and can only be populated by this automated process. |
||
Specialization |
A more specialized area of the Classification in which a provider chooses to practice or make services available. This attribute is auto populated by PDM if the submitted Taxonomy Code matches a code defined in the Verato-maintained global list and can only be populated by this automated process. |
||
Effective Date |
Effective date of a Provider license. |
||
Expiration Date |
Expiration date of a Provider license. |
||
Last updated date |
Date of last update for a Provider license. |
||
Status |
The status of a Provider license. |
||
Status Detail |
A description of the status of a Provider license. |
||
Profession code |
A code that identifies the Provider profession; a unique key of the profession. |
||
Profession rank code |
A unique identifier of the license rank associated with the Provider license, if applicable. |
||
License Type |
This field allows you to identify the type/title of the license/certification. For example, a potential type could be DEA or CDS license. |
||
Specialties
|
Taxonomy Code |
The 10-character code that designates the classification and specialization of the license, typically per the National Uniform Claim Committee (NUCC) code set list. |
Individual or Organization
|
Grouping |
A major grouping of services or occupations of health care providers. This attribute is auto populated by PDM if the submitted Taxonomy Code matches a code defined in the Verato-maintained global list and can only be populated by this automated process. |
||
Classification |
A more specific service or occupation related to the Provider Grouping. This attribute is auto populated by PDM if the submitted Taxonomy Code matches a code defined in the Verato-maintained global list and can only be populated by this automated process. |
||
Specialization |
A more specialized area of the Classification in which a provider chooses to practice or make services available. This attribute is auto populated by PDM if the submitted Taxonomy Code matches a code defined in the Verato-maintained global list and can only be populated by this automated process. |
||
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. |
Individual |
Phone Number | Number | 7, 10 or 11 digit phone number with no hyphens or other punctuation | Individual or Organization |
Type | The type of fax number, such as Reception or Billing. Freely enterable; does not need to conform to any predefined values. | ||
Fax Number | Number | 7, 10 or 11 digit fax number with no hyphens or other punctuation | Individual or Organization |
Type | The type of fax number, such as Reception or Billing. Freely enterable; does not need to conform to any predefined values. | ||
Email address | Email address | Individual or Organization |
Extended Attributes
The Extended attributes and attribute clusters in Provider Data Management that are not used in the matching algorithm are list in the table below.
Extended attributes table
Cluster | Attribute | Description | Intended Provider Type |
Medicare Info |
In Pecos |
A flag to represent if the provider is enrolled in the Provider, Enrollment, Chain, and Ownership System(PECOS). |
Individual |
Accepts Medicare |
A flag to represent if the provider accepts Medicare. |
||
Disciplinary Info |
Warning |
Indicator that a sanction prevents a Provider from billing Medicare. |
Individual |
Exclusion Type |
Explanation for why a Provider was barred from billing Medicare. |
||
Location Info |
Rural/Urban/Suburban |
Indicator for where a practice location exists. |
Individual |
Colo Code |
Practice co-location code; may be used to link providers practicing at the same location; derived algorithmically from our reference data vendors. |
||
Education |
Med School |
Medical school the provider received a degree from. |
Individual |
Grad Year |
Year of medical school graduation for the provider. |
||
Alternate Identifier |
Value |
The value of the identifier. |
Individual or Organization |
Type |
The type of identifier represented by the value. |
||
State |
The state that issued the identifier or that the identifier is valid within. |
||
Issuer |
The organization that issued or assigned the identifier. |
||
Group Taxonomy |
Group Taxonomy Code |
The 10-character code that designates if an Organization is a Single- or Multi-specialty group. |
Organization |
Authorized Official |
First Name |
Give name for a person known to represent an organization. |
Organization |
Middle Name |
Middle name for the authorized official. |
||
Last Name |
Last/family name for the authorized official. |
||
Title |
Title of the authorized official. |
||
Prefix |
Name prefix, such as Dr.,Mr., or Mrs. |
||
Suffix |
Name suffix, such as Jr., or Sr. |
||
Credential |
The authorized official's credentials, such as MD, DO, or PhD. |
||
Phone Number |
7, 10 or 11 digit phone number used to contact the authorized official. |
||
Practice Info |
Estimated Practice Years |
Estimated number of years the provider has been practicing. |
Individual |
Custom Attributes
You can define custom attributes in their instance of Provider Data Management. 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 Provider Data Management. Custom attributes are not subject to any normalization or validation processing. Provider Data Management software is not aware of, and does not interpret, the contents of the custom attributes.
Custom attributes are represented in the JSON object by prefixing the custom attribute name with “custom.”
For example, suppose a client wanted to use a custom attribute to capture the information about when a practice location was open for business–the days of the week and time of day when open, plus any notes.
Within the JSON object for the identity in a postIdentity web service request, the client would insert this JSON object:
"custom.businessHours": [
{
"days": "M - F",
"time": "9AM – 5PM",
"notes": "Saturday by appt only"
}
The client has decided that is the structure they want to use to record all 'open for business' information. Whenever that identity is retrieved, the identity object includes (along with the usual core and extended attributes) the custom attribute–it is up to the client to be aware of and interpret the custom attribute structure.