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.
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 This field is preferred—leaving it blank will not cause the file to fail. However, providing a Business Name is strongly recommended, as it:
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
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 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.
Comments
0 comments
Please sign in to leave a comment.