Pharmacy Payment

Pharmacy payment processing plays a vital role in the healthcare ecosystem by ensuring prescription drug claims are reimbursed accurately and on time for pharmacies, Pharmacy Services Administrative Organizations (PSAOs), healthcare payers, and members. Hence, Oracle Revenue Management and Billing has designed a solution that provides integrated framework for managing pharmacy reimbursements, payment generation, remittance processing, claim holds, and payee-pharmacy relationships.

The solution is constructed around a configurable Payee-Pharmacy hierarchy that grants support to both direct pharmacy reimbursement models and PSAO-mediated payment models. The solution also enables claim processing, payment extraction, ACH/Check disbursement, remittance advice generation, and payment monitoring through a centralized architecture. The Payee-Pharmacy hierarchy is represented by using the Person Entity in ORMB.

Person Entity - The person entity is bifurcated into two major entities such as:

  • Parent Entity (Payee) - The parent entity represents the entities that receive payment, including:

    • Independent Pharmacies

    • Long-Term Care Facilities

    • Members

    • Pharmacy Services Administrative Organizations (PSAOs)

    • SPAP/ADAP Organizations

    • Subrogation Entities

    Each parent entity owns the following accounts:

    • Part-D Payment Account

    • Non-Part-D Payment Account

  • Child Entity (Pharmacy) - The child entity represents:

    • Long-Term Care Facilities

    • Members

    • Pharmacies under PSAOs

    • SPAP/ADAP Entities

    • Subrogation Entities

    Each child entity owns the following accounts:

    • Part-D Usage Account

    • Non-Part-D Usage Account

    Note: The parent and child entities are connected using effective-dated Person-to-Person relationships, allowing pharmacies to move between PSAOs over time while maintaining historical payment associations.

Payment Processing - The payment processing is bifurcated into following categories:

  • Inbound Integration

    • The pharmacy and payee information originates from the (iSeries) source system and is transmitted through the Data Integration Hub (DIH).

    • The inbound message creates and maintains entities like Persons, Accounts, Policies, Relationships, and Payment Configurations.

    • The customer inbound message processes Payee Information, Pharmacy Information, Banking Details, Addresses, Contact Information, and OPP (Other Pharmacy Payable) Data.

  • Claim Processing

    • Claims are accumulated on child pharmacy accounts.

    • Payment and hold rules determine the eligibility, due dates, and payment timing.

  • Hold and Payment Rules

    • The attributes required for configuring the hold or payment business rule is sourced from the Parameter entity in the ORMB application, where the source entity is set to Transaction, or Person, or Account, and the parameter usage is configured either as hold or payment business rule.

    • The pre-defined parameters (such as Carrier, Account, Group, Line of Business, Provider State, National Provider Identifier (NPI), Vendor ID, Claim ID, Member ID, Payment Due Date, Calendar or Business, Entity Type, Source, PSAO ID, Claim Number, Claim Status, and Claim Sequence) where the source entity configured as Transaction is pre-configured based on the business requirements which along with other user-defined parameters can be referenced to configure either the hold or payment business rule in the ORMB application.

    • The pre-defined parameters (mentioned in the above point) are configured with the following attributes:

      • The Source Entity field is set as Transaction.

      • The Value field is set as Adhoc.

      • The Parameter Usage field provides an option to select:

        • Price Item

        • Payment or Hold business rule

    • While defining the hold or payment business rule, following conditions should be met:

      • Every hold business rule may have one or more attributes to define the hold business rule eligibility criteria, and at least one attribute must be provided while defining the hold business rule. Additionally, the value of all the attributes must be internally concatenated by using the logical AND operator.

      • Each payment business rule must have an Entity Type attribute to define the payment business rule eligibility criteria. In addition, each payment business rule may have one or more attributes to define the payment business rule eligibility criteria.

  • Payment Generation

    • Refund Requests and Automatic Refund Creation

    • Banking information determines whether payment is issued via ACH or check.

    • The ACH Payments mode is selected when:

      • The routing number is valid (i.e. 9 digits).

      • The bank account number is provided.

    • The Check Payments mode is selected when:

      • The banking details are missing.

      • A failure occurs in the routing number.

      • An invalid bank information is detected.

      Note: If the invalid routing numbers are received from the upstream system, ORMB application does the following:

      • The payment method by default is set to Check.

      • The notifications are generated.

      • The invalid banking data is prevented from getting stored in the database.

  • Payment Extract and Acknowledgement

    • Payment files are generated for SAP/ERP.

    • Acknowledgement files from banks/SAP are processed to update payment status (Issued, Cleared, Void, etc.).

  • Remittance and Reporting

    • 835 Remittance Advice (RA) is generated.

    • Explanation of Payment (EOP) is generated.

    • Check Extracts are generated.

    • GCP Claim Extracts are generated.

    • Part-D and Non-Part-D Processing is supported.

The pharmacy payment solution provides an end-to-end ORMB framework for managing pharmacy networks, processing claims, applying payment rules, generating payments (ACH/check), handling refunds and remittance advice, and maintaining complete visibility through Pharmacy Payment 360° screen.

Parent topic: Pharmacy Benefit Managers