API Reference

Adjustments

🚧

This endpoint is in beta and as such all content below is subject to change.

Overview

Adjustments represent modifications to a patient's balance. Adjustments can be applied for a variety of reasons including insurance write offs, late fees, or employee discounts.

Adjustments may subtract from a patient's balance (credits) or add to a patient's balance (debits). Credit adjustments are represented with a negative value and debit adjustments are represented with a positive values.


Use Cases

The NexHealth API does not provide individual patient balance; however, it can be calculated by adding together charges, payments and adjustments associated to a particular patient. Depending on the target EHR, the creation of a positive value payments will be created as an adjustment. For more information, please see the "Supported Health Record Systems" section of the Payments landing page.

Requesting Additional Associated Entities

For collection queries (/adjustments), only the id of the associated entities are returned in the response. However, the single :id query can include additional related record details. Please refer to the include[] query parameter on the view adjustment page for a current list of available options.


Creating Adjustments

❗️

Asynchronous adjustment creation - the importance of webhooks

Please note that creating an adjustment transaction via the NexHealth API is asynchronous and therefore it is necessary that you also subscribe to the ”adjustment transaction insertion webhook” which fires upon complete or failed response from an integration when inserting adjustments into an EHR.

Depending on the integration, the creation of adjustment transaction which includes provider_splits and charge_splits may result in multiple adjustment records in the target EHR. In order to associate the adjustment transaction with the resulting adjustments(s), please match on transaction_id.

🚧

Debit adjustments

EHRs do not allow unallocated/unassigned debit adjustments and therefore, when creating an adjustment transaction with a positive value amount, a provider or charge split is required. Attempts to create adjustment transactions without provider or charge splits will result in an error.

Transaction ID

The creation of one adjustment transaction may result in multiple payment records in the target practice management system. Therefore a NexHealth adjustment transaction may have a one to many relationship with the corresponding patient adjustment ledger line items in the target database. For this reason, NexHealth requires that API users manage transaction IDs.

The adjustment_transactions.transaction_id entered will be stored as the resulting adjustment.transaction_id and may be used to match payments with the adjustment transaction that generated them.

Transaction ids are a customer generated id and must be unique. Please construct your id by combining a prefix identifying your company name. For example, three consecutive payment transactions created by NexHealth may be as follows: "NH:201", "NH:202", "NH:203".

Type name

This field allows for the customization of adjustments types on adjustments created via the NexHealth API. Adjustment types identify the type used to make an adjustment (e.g., over charged patient, discount, medicaid adjustment, etc.).

Please note that offices may manually create their own adjustment types and therefore, they may vary from office to office. When creating a adjustment transaction, the type name field must exactly match, including capitalization. Attempts to create a adjustments transaction with a type name that does not match an existing adjustment type name in the target practice management system will result in an error. To understand which adjustment types are available, please first make a call to view adjustment types. More information can be found on the adjustment types documentation page.

Provider and charge splits

NexHealth offers the ability to split an adjustment between different providers or charges. Please note that these are value splits and therefore the sum of the splits must equal the total amount of the adjustment transaction. Provider and charge splits with a sum not equal to the total amount of the adjustment transaction will result in an error.

You may only split a adjustment transaction among entities of the same kind. In other words, when creating an adjustment transaction, you may indicate either a provider split or a charge split. Adjustment transactions indicating both a provider and charge split will result in an error.

  • Provider split: A provider represent an employee who can be booked for an appointment at a given practice. Provider splits may be used if the office receives a single adjustment and wants to allocate a portion of that adjustment to one or more providers.
    • In the example below, this adjustment transaction has a total amount of $150 which is split as follows: $100 to the provider with id 001 and $50 to the provider with id 002.
      "provider_splits": {
        "001": "100",
        "002": "50"
      },
      
  • Charge split: A charge in NexHealth represents a patient or their insurance plan being charged money for a service provided. Charges may also be referred to as “completed procedures”. A charge split may be used if the office wishes to indicate that one payment covers 2 charges/completed procedures.
    • In the example below, this adjustment transaction has a total amount of $500 which is split as follows: $125 to the charge with id 113 and $375 to the charge with id 114.
      "charge_splits": {
        "113": "100",
        "114": "50"
      },
      

Supported Health Record Systems

Dentrix

📘

Creating an adjustment with charge split for Dentrix offices

Note that it is not possible to associate an adjustment in the Dentrix software with a charge, so the synchronizer will instead find and use the provider associated to that charge. In other words, if you create an adjustment transaction for a Dentrix office via the NexHealth API and pass a charge split, the resulting adjustment created in Dentrix will have a provider association instead of a charge.

Dentrix Enterprise

No EHR specific notes

Eaglesoft

No EHR specific notes

Open Dental

No EHR specific notes