How To: Create a DynamicNPI Organization File Upload – ProviderTrust Support Center

Summary

This article explains how to create and upload an Organization File in the ProviderTrust application, including required and optional data fields, formatting rules, and error prevention tips. Our accepted file format is .csv utf-8 format or .psv. A file template is provided at the bottom of this article, and support is available for additional assistance.

Overview

The Organization File is used to add or update organization-level data within your ProviderTrust system. This article provides detailed guidance on how to prepare and format the file correctly to ensure successful upload and processing.

File Format Requirements

Specification	Details
Accepted File Types	`.csv` (UTF-8 encoded) or `.psv`
Header Row (Row 1)	Must remain unchanged. Do not edit or rename any column headers. Modifying this row may result in file errors.
File Naming Convention	Use your company name and date (e.g., `Test Client - Organization File - 04 29 2020.csv`)
Template Requirements	A downloadable file template is available at the bottom of this article. Remove the example data in Row 2 before uploading.
Multiple Records	Multiple rows may share the same External ID, indicating multiple addresses or attributes for a single organization. This approach allows for the inclusion of multiple addresses or other related information for a single entity.
Removal of Organizations	To remove an organization, enter a termination date in the End Date column or contact your Implementation Manager to enable the auto-termination feature. For more information regarding our best practices, refer to ProviderTrust Best Practices for Ending Monitoring.

Uploading Your File

Once your file is complete and validated, upload it securely to ProviderTrust via SFTP.

For detailed upload instructions, refer to How To: Upload Data to SFTP

If you have any questions about the files, please contact our Client Care team at support@providertrust.com or 615-938-7878 ext 1.

File Specifications

Column Header	Description
External ID	Required The External ID is a variable character field and can include letters, numbers, and special characters. It must be unique across your entire organization. This is the key identifier to add, update, or remove a subject. There is a 255-character limit. If a subject appears multiple times with the same external ID but different DOB, NPI, TIN, or SSN, all rows with that ID will error and display within the error report. If a subject appears multiple times with the same external ID but any name variation (first, middle, or last), all rows with that ID will error and display within the error report. UI Visibility: Yes Included in Reports: Yes
Type	Required Specifies record type; must be Exact Value = "Organization" UI Visibility: Yes Included in Reports: Yes
Business Name	Preferred Legal Name of Business (Example: ABC Company, Inc.). It is a variable-character field that supports letters, numbers, and special characters, with a 255-character limit. This field is preferred—leaving it blank will not cause the file to fail. However, providing a Business Name is strongly recommended, as it: Helps distinguish the client-supplied name from the NPPES name within the UI. Provides context when reviewing verification results. UI Visibility: Yes Included in Reports: Yes
Does Business As	Optional “Doing Business As” name is associated with the individual or entity. This is the trade name or alias under which the provider or organization operates, which may differ from the legal name. "Does Business As" is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: Yes
TIN	Optional Tax Identification Number (TIN) associated with an individual or business. TIN must be exactly 9 digits, including leading zeros, and must not contain any dashes. UI Visibility: Yes Included in Reports: Yes
NPI	Required NPI must be exactly 10 digits. UI Visibility: Yes Included in Reports: Yes
Taxonomy	Optional - Determined during the Implementation process Can be 1 to many. Taxonomy is a variable character field and can include letters, numbers, and special characters. Taxonomy can be used to supply customized data. There is a 255-character limit. Leaving this field blank will not fail the file. UI Visibility: Yes Included in Reports: No
License Type	Required (Only when appending profile data, must include License Type, License Issuer, and License Number for successful entry) License type is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: Yes
License Issuer	Required (Only when appending profile data, must include License Type, License Issuer, and License Number for successful entry.) License Issuer is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: Yes
License Number	Required (Only when appending profile data, must include License Type, License Issuer, and License Number for successful entry) License Number is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: Yes
License Issued	Optional Must be in the following format: yyyy-mm-dd. The data within this column can be left blank and will not fail the file. UI Visibility: Yes Included in Reports: Yes
License Expiration	Optional Must be in the following format: yyyy-mm-dd. The data within this column can be left blank and will not fail the file. UI Visibility: Yes Included in Reports: Yes
Document Type	Optional - Determined during Implementation Document Type should only be used under specific circumstances and should be discussed during Implementation. Two types are available today: Certificate of Insurance and Credential Form. Document Type is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: Yes
Document Expiration Date	Optional - Determined during Implementation Document Type should only be used under specific circumstances and should be discussed during Implementation. Must be in the following format: yyyy-mm-dd There is a 255-character limit. UI Visibility: Yes Included in Reports: Yes
Address Type	Optional: String Value Address Type defines the purpose or category of an address. Common examples include Home Work Billing Shipping Mailing Address Type is a variable character field and can include letters, numbers, and special characters. Address Type can be used to supply customized data. Multiple addresses are supported for organizations and entities. Each address entered will display in the system as a separate record tied to the same subject. There is a 255-character limit. UI Visibility: No (option to concatenate Type name with Address Name) Included in Reports: No
Address Name	Optional The Address Name serves as an additional identifier or label for the address, such as "Corporate Office" or "HR Department." It is not utilized in our screening processes and may be left blank. The Address Name is a variable character field that may contain letters, numbers, and special characters. Address Name can be used to supply customized data. Multiple addresses are supported for organizations and entities. Each address entered will display in the system as a separate record tied to the same subject. There is a 255-character limit. UI Visibility: Yes Included in Reports: No
Address Line 1	Optional Address Line 1 should include the street address (e.g., 123 Main Street). ProviderTrust prefers that home addresses be provided for individuals. A business address may be included only if it is the sole available address. Address Line 1 is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: No
Address Line 2	Optional Address Line 2 should specify secondary address details, including apartment, suite, or unit numbers (e.g., Apt 4B, Suite 300). Address Name 2 is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: No
City	Optional City is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: No
State	Optional State is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: No
Zip	Optional Must be either 5 or 9 numeric digits (no alpha), accepted formats include 12345 12345-6789 123456789 An invalid zip will error out the row. Leaving this field blank will not fail the file. UI Visibility: Yes Included in Reports: No
County	Optional County is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: No
Country	Optional Country is a variable character field and can include letters, numbers, and special characters. There is a 255-character limit. UI Visibility: Yes Included in Reports: No
Business Unit	Optional - Determined during Implementation Can be 1 to Many; if not designated, ProviderTrust will designate as 'No Business Unit'. If a Business Unit is specified, then the Network must also be specified, or the row will error out. Business unit is a variable character field and can include letters, numbers, and special characters. A business unit can be used to supply customized data. There is a 255-character limit. UI Visibility: Yes Included in Reports: Yes
Network	Optional - Determined during Implementation Can be 1 to Many; Network must be supplied if using business units. Network is a variable character field and can include letters, numbers, and special characters. Networks can be used to supply customized data. There is a 255-character limit. Networks cannot exceed 5,000 unique values. UI Visibility: Yes Included in Reports: Yes
End Date	Optional - Required when terminating a profile from monitoring. End date sets a date for monitoring to end for a profile, as well as removes the profile from the Active Population list. A date must be supplied to end monitoring for a subject; it must be in yyyy-mm-dd format. This date represents an "up-to" date. A runnable is executed periodically throughout the day to terminate subjects on that date. If a client enters today's date, the termination will occur the first time the runnable runs on that date. End Date should be left blank for all active subjects. UI Visibility: Yes Included in Reports: Yes

Best Practices for DNPI Organization File Management

These best practices define how organization files should be structured, maintained, and interpreted when using Dynamic NPI (DNPI) with client-supplied data. They combine operational guidance with validated system behavior.

1. File Rules (Ongoing Snapshot Requirements)

Semantics

Each file is a complete, current snapshot of all subjects and licenses the client intends to have monitored as client-supplied.
Files are cumulative:
- Include all active client-supplied licenses and subjects previously submitted.
- Add new subjects and licenses as needed.
- Remove licenses (or subjects) only when you intend for them to stop being client-supplied.

Removing Data (“Delete by Delisting”)

Removing a client-supplied license row while keeping the subject’s NPI row successfully deletes that license from the client-supplied licenses in PT App.
When Dynamic NPI begins monitoring the license, it will appear in the ‘PT Network’ licenses.
Leaving a client-supplied license on the upload file after it has been added to the PT Network will cause the license to appear twice: once in the client-supplied section and once in the PT Network section.
Removing all rows for a subject does not remove or deactivate that subject. The system interprets omission as “no update,” not as a termination request.

Frequency

Files may be uploaded as often as needed, including daily.
To ensure timely monitoring and accurate DNPI license refresh, all intended active data should be submitted by the 15th of each month.

Appending Behavior

When generating a new file:

Start with the previous file.
Retain all active rows.
Append new subjects and/or licenses.
Remove any rows you intend to discontinue as client-supplied.

This behavior aligns with system logic:

Multiple rows with the same External ID aggregate correctly into a single subject.
Ordering (e.g., listing a license row before an NPI-only row) has no impact on outcomes.

2. Profiles, Duplicates, and Alerts

DNPI + Client-Supplied License Interaction

When a license already exists in DNPI, and the client later supplies the same license, the system updates the existing license record rather than creating a duplicate.
Verifications for all associated licenses are refreshed on each file upload.
- Verified Dates will reflect the date of the most recent file.

Temporary Duplication & Alerts

Although tool limitations may allow for alerts during overlapping ingestion periods:

Creation of a DNPI-profile license does not remove the client-supplied version.
Alerts may temporarily appear from either source; this is expected when record sets overlap.
However, outright duplication is uncommon because the system consolidates shared licenses.

3. License Deletion, Visibility, and History

A. Removing Licenses

If a client-supplied license is omitted from a file while the subject remains present, the license is deleted from client-supplied monitoring.
DNPI-sourced licenses cannot be removed by client file deletion.
If a client-supplied license has already been adopted into the DNPI Profile, it also cannot be removed through file management.

B. License History

Deleted client-supplied licenses remain visible in:
- License history
- Reporting
This supports full auditability.

C. Subject Removal

Removing all rows for a subject does not end monitoring.
- The subject remains active unless an End Date is supplied or termination logic is invoked.
This mirrors expected API behavior: a subject is only ended via explicit termination rules, not omission.

4. Special Behaviors

Record Ordering

The sequence of rows (e.g., a license row appearing before an NPI-only row) has no impact on consolidation.
External ID is the authoritative key.

License Aggregation

Multiple rows with the same External ID and Type will always aggregate into a single subject record.
Submitting both NPI-only and NPI+license rows for the same subject correctly merges them—no duplicates occur.

DNPI Permanence

Once DNPI adopts a license into its profile, it becomes:
- Independently monitored
- Not removable through client-file deletion

5. Strategic Recommendations

The following practices are recommended:

Always submit a full snapshot rather than incremental updates to avoid unintended deletions.
Clients should manage any needed deletions or terminations through appropriate updates to the file, including use of the End Date field.
DNPI will assume long-term ownership of licenses once identified; plan deletion expectations accordingly.
Use file omission carefully:
- Omit a license to delete it only after DNPI has captured it, so that it will not be double-verified.
- Omit a subject entirely only if no updates are needed, and ongoing monitoring should continue unchanged.
Submit all critical data before the 15th of each month to align with DNPI updates and monitoring cycles.
Keep External IDs stable; this is the key to accurate aggregation.