The default view for Admin Configuration is the listing of all partners in the system. A partner is the top-level entity that represents a collection of healthcare providers. The list includes the partner name, partner Id, and account status. The list can be filtered by the name of the partner, or those partners containing an organization name or Client ID. Partial searches are allowed, and it should not be case sensitive. In the upper right of the list we display the total count of partners.

To view/edit a partner, select it from the list. Choose Add Partner to create a new partner. You will be required to enter a unique partner name and account status before saving. 

Figure 172 - Partner Listing

Configuration

If you select any partner in the list or create a new partner, you will be shown the Partner Configuration screen. At the top of the screen, we provide a breadcrumb to navigate back to the partner list. And then we show the name of the partner and a color-coded account status. The Configuration tab is organized into two sections: Partner Information and Integration.

Figure 173 - Partner Configuration

Partner Information

The section defines the basic properties of a partner: Name, ID, and Account Status. The Edit button in the upper right activates edit mode so that you can change the Partner Name and Account Status. The partner name must be unique. The partner ID is a system-generated, unique identifier for the partner and cannot be edited. To commit changes made to this section, press Save. Pressing Cancel will abandon your changes.

Account Status

To edit a partner’s status, choose Edit Account Status in the upper right. The Account Status dialog will appear.

Figure 175 - Edit Partner Account Status

The supported account status values for a partner and their purpose are outlined below:

If a user attempts to login to Admin and the partner is not Account Status = Active, they will receive the following message: “Access is denied. Please contact Support.” If they attempt to login to the Patient Portal via secure bill link or bill code, they will receive the following message: “Access is denied. Please contact your provider.”

NOTE: It is recommended that you give the organizations under each partner the same Account Status to avoid conflict.

Integration

The Integration section provides configuration of the integration with third-party systems. This includes API-level integration for pulling patient demographics/statements/balances and submitting payments back to the EHR. API integration reduces the dependency on file-based methods and provides real-time integration of patient balance and payments/refunds. The default value for EHR Platform is None.

athenahealth
If your partner is integrating with athenahealth, choose a value of athenahealth from the list and enter the practice ID into the External Id field.

Azalea Health
PatientPay supports direct API integration with both Azalea Ambulatory and Inpatient. Statement, claim, and patient demographic data are fetched via API and the FHIR R4 industry standard. Payments and refunds are submitted back in real-time via API to complete the loop. An Azalea “organization” is akin to a PatientPay partner and is uniquely identified with a client UUID from the Azalea Client Configuration module. Each Azalea “location” will result in a PatientPay organization with a matching name. Organizations are typically created per Tax ID (TIN).

If your partner is integrating with Azalea, choose Azalea Health Ambulatory or Azalea Health Inpatient from the EHR Platform drop-down list and enter the client UUID into the External Id field. This will connect the two systems together. Additionally, your PatientPay integration specialist will ensure that the client UUID(s) are configured in the FHIR feed. PatientPay staff will have to request access to this client's application/endpoint in the Developer portal (see Applications menu).

Azalea SmartLaunch™ actions are setup to provide SSO integration with PatientPay Admin and give end users shortcuts to common features. Ambulatory offers three actions:

• Bill Payment → navigates to PatientPay Bill Pay for the current bill
• Guarantor Details → navigates to PatientPay Guarantor Detail for the current account
• Now Payment → navigates to PatientPay Now Payment for a time-of-service payment

Inpatient offers one action, Make a Payment, which directs the user to PatientPay Guarantor Details. Below is an example of the SmartLaunch actions in Ambulatory:
 

For Ambulatory, PatientPay will load into an iFrame after automatically authenticating the user via SSO. Inpatient will load into a separate browser tab. Once a payment is made, the user can simply close the popup or tab to end the session and return to Azalea.

PointClickCare
If your partner is integrating with PointClickCare, choose a value of PointClickCare from the list and enter the OrgUuid into the External Id field. This will establish the OrgUuid to use for all API calls to PointClickCare.

Figure 174 - Integration Configuration

Additionally, PatientPay supports integration with virtual credit card (VCC) issuers to support fully-automated VCC payments and reimbursements. Providers that wish to utilize Optum Straight Through Processing (STP), can choose Optum from the VCC Issuer drop-down list. This will enable each organization under this partner to enroll in Optum STP VCC payments via Admin Configuration for Organization (Payments tab).