PatientPay offers flexible integration with your EHR or system of record to retrieve statement (bill) and patient/guarantor data, and submit payments/refunds for reconciliation. This includes API integration with popular EHRs including:

• athenaHealth
• Azalea Health
• PointClickCare

Additionally, one of the simplest and most common integrations is via batch file upload via SFTP. This is similar to how EHR/RevCycle/billing solution providers send printed statement data to their print vendor. PatientPay offers a JSON statement file specification to support receiving statement data or lockbox payment data in batch. If partners do not use one of our supported EHR API integrations, and cannot create a file that matches our JSON statement file specification, we offer data transformation services as part of our solution. Please consult your PatientPay account manager for more information.

• Lifetime JSON Statement Specification
• Episodic JSON Statement Specification
• Lockbox JSON Specification
   

Download Specification in Excel

Lifetime vs. Episodic Billing

What’s the major difference between Lifetime and Episodic bills? This is terminology that PatientPay uses to differentiate between two styles of billing. If you intend to have only one active bill for a given patient, choose Lifetime. This means PatientPay will use a single bill that gets updated/amended over time. If you intend to have more than one active bill for a given patient, at any time, use Episodic.

Structurally, the JSON for both lifetime and episodic are almost identical. They both use the same field names and validation during ingestion. The major difference is where the payers array is placed. For episodic, it should be outside of the patients block. For lifetime, it should be inside the patient block.

They are very different in how we match existing bills. In the case of Episodic, bills are created based on the unique statementId in the JSON. If you change the statementId, it will create a new bill. In the case of Lifetime, we do not check the statement ID. Patients and bills are fetched based on the  clientId and accountId. We retrieve bills based on accountId and check the existing statementId.

When it comes to refunds, Lifetime bills will apply refunds to a single bill. For Episodic, the refund is applied to the same bill as the original transaction. 

Significance of Client ID

The Client ID is a unique identifier for an organization in our system. Considering that we are multi-tenant, all partners should use a unique client ID for each organization to avoid conflicts. It must be universally unique across all tenants so please coordinate with your PatientPay representative to ensure there is no conflict and setup a good naming convention. The clientId field in the statement JSON file is used to match to an existing organization.

Statement Ingestion

The statement ingestion process is the primary method by which PatientPay receives and creates patient/guarantor and bill records. The PatientPay system trusts balances that come from the system of record, typically a EMR, practice management or billing system. If a bill has a balance due in the initial statement file ingestion, and the patient pays in PatientPay, we expect the organization to post these transactions back to their financial system using the Recon file to keep balances in sync. If we receive future statements, we will reinstate the balance due based on what’s provided in the statement and begin communicating with the patient. We also overwrite the bill in our system with the latest statement so the data should be cumulative.

The PatientPay file monitor service detects new file drops via SFTP and queues up the statement to be processed. Depending on which inbound queue the file is dropped in (e.g., Lifetime, Episodic, etc.), the appropriate parser will be used to process the file. The file is split into individual statements, pushed onto a message queue, and eventually picked up and sent to the bill processor.

The Dunning collector runs on each statement that is ingested. This is considered Day 0. Any communications will always be queued up the following day, Day 1, from the effective created date of the bill, with the exceptions of weekends and holidays, per the Dunning configuration for the practice/organization. The cutoff for ingesting a file and queuing up communications next day is midnight EST.

Reconcilation

Reconciliation (Recon) is a process by which an organization/practice matches the funding deposits made by PatientPay into their bank account with their accounting system or system of record. Our Recon file(s) contain all transactions for a given merchant ID (MID). Admin Configuration provides configuration of the Recon behavior for an organization. Typically, organizations have separate MIDs for credit card and ACH transactions. PatientPay also supports optionally using a separate MID for insurance payments and subscriptions to make those payments easier to reconcile. Separate recon files can be generated for credit/debit, ACH, ACH rejects, ACH refunds, Cash Register transactions, insurance payments, lockbox payments, and subscriptions. Organizations can even share MIDs if they are comfortable with a single Recon file. The Reconciliation process requires a number of steps to confirm that payments are settled and funded before appearing in the Recon Report. Admin Configuration settings for Recon also determine whether the MID is recon'd based on settled, captured or funded.

The Recon file generation routine runs every day of the week starting at 6AM and looping through each active organization MIDs. Each Recon file is delivered to our customers via SFTP, unless using API integration.

Settlement

Initially when a credit card is used to make payment, we perform a $0 authorization to ensure we have correct card details. When the batch closes around 9:30PM EST (batch cutoff can be configured per MID with the payment processor), the transaction will change from Authorized/Captured to Settled. It may take up to 24 hours to move some of the transactions to be settled. It is important for PatientPay to record the settlement status because a transaction can only be voided until it is Settled, after which it requires a refund. It’s a subtle but important difference in how our Admin treats voids/refunds. And refunds incur transaction processing fees. The batch cutoff for the MID is also the transaction cutoff for any Recons that are based on Captured status instead of Funded.

PatientPay will query the payment processor via API and update the settlement status for the previous day's transactions at 7AM EST each day. The Transaction Details screen in Admin will reflect the settlement date.

Funding

It can take 2-3 business days for transactions to be funded. American Express cards can take longer (typically 4 business days). ACH payments typically take 4-5 business days to be funded and they can be rejected due to insufficient funds.

PatientPay will query the payment processor via API and update the funding status for transactions at 10PM EST each day, using a 10-day lookback. The Transaction Details screen in Admin will reflect the funding date.

Recon Specification

The following link documents our Recon specification:

Recon Specification

Printed Statements and Letters

PatientPay contracts with our of print shop to handle printed statements and letters, should the provider choose to send them in their Dunning configuration. Partners that want to use their print shop will want to share our print JSON specification.

Integrating PatientPay into Your Patient Portal

Some partners may want to launch PatientPay's Patient Portal directly from their member portals to make bill pay more seamless and not require the patient to authenticate with a separate login. We provide the following URL launch protocol to allow the PatientPay’s Patient Portal to be integrated into third party portals.

The primary entry point is the Bill Code Login screen which prompts for a bill code and date of birth. The production URL is https://www2.patientpay.net/security/login/code, however most partners will utilize a vanity URL (e.g., xyz.patientpay.net) that’s included on the printed statement and provides branding for the organization.

Figure 1 - Bill Code Login

When calling this URL, you have the option of specifying the bill code and/or date of birth as query string params. NOTE: Date of birth should be the guarantor’s date of birth and formatted MMDDYYYY. For example: https://www2.patientpay.net/security/login/code?billCode=3f700c1e-4&dob=07021996 will prefill the bill code and date of birth and authenticate the patient before viewing their bill.

Figure 2 - Prefilled Bill Code Login

If using a vanity URL, you can use the same parameters. NOTE: You should exclude the “http://” prefix on the URL. For example: xyz.patientpay.net?billCode=3f700c1e-4&dob=07021996. The caller has the option to only provide the bill code, or only provide the date of birth. The user will be prompted to enter the missing value before authenticating and viewing the bill.

Generating a Unique Bill Code

One prerequisite for integrating PatientPay Patient Portal into member portals is partners are responsible for generating the unique bill code (per patient/guarantor account) and passing it to PatientPay in the statement JSON field externalBillCode. Typically, PatientPay generates a unique bill code at the time the print batch is queued up each day for the partner. However, if we receive a value for externalBillCode during Ingestion, this will be used instead to access the patient's account via the Bill Code Login screen. Best practice is to generate a UUID (Universally Unique Identifier) and use the first 10 characters of the 36-character value (e.g., a81bc81b-d).