30 & 31 - Daily Totals & Adjudication Details
Overview
The Daily Totals and Adjudication Details that are supported in CPHA3 are limited to return a maximu of 14 records in the query results. This maximum was put into place due to technical restrictions that existed in the early 1990s. As a result, a Pharmacy must execute multiple queries to obtain detailed records for a given day. Each query request specifies and beginning RX record and an ending RX record.
The new FHIR queries are designed to be much more efficient as they remove unnecessary restrictions. However, the Request for Totals and Request for Details are not backward compatibile to CPHA3. If PCS FHIR were to retain backward compatibility, the FHIR query would need to continue support for the 14 detail record maximum. It would also need to retain support for specifying a beginning and end Prescription number in the query request. PCS Implementers agreed that perpetuating this very limited query mechanism was not desirable. Further, these queries are typically supported outside of the core adjuidcation engine making migration to FHIR queries feasible.
The Adjudication Details request is identical to the Daily Totals request in structure but it is distinguished by a unique transaction identifier (MessageHeader.event id).
No Backward Compatibility to CPHA
What this means to implementers
- POS Vendors must support CPHA 3 queries and FHIR queries for a period of time.
- CPHA3 will be deprecated over time, once all adjudicators support FHIR
- Adjudicators will likely fulfil FHIR queries outside of the adjudication system, or as a specific module within the adjuidication system where results are stored. Once on FHIR, Adjudicators must support both CPHA and FHIR until all vendors can send FHIR
- A different endpoint can be established if desired, for a reporting/payment interface.
New mechanism and features
| Feature | Details | Sender Responsibility | Receiver Responsibility |
|---|---|---|---|
| NEW FUNCTIONALITY Re-write Adjudication Details and Totals |
These are completely new and steamlined. These transactions are not mappable between CPHA3 and FHIR | MANDATORY | MANDATORY |
| Remove 14 Day Restriction | The limit of 14 days is removed. The sender can specify the maximum number of records they can support in a single page. FHIR does not impose a limit | Specify Max Records supported in request | May only return the max number of records specified in the Request. If the Adjudicator's maximum limit is less, the adjudicator will return their maximum |
| Remove ability to request results by group. | The PCS implementation committee confirmed that this feature is not used and therefore will not be supported in FHIR | Not applicable as this is not present in the FHIR queries | Not applicable as this is not present in the FHIR queries |
| FHIR Query Design by Adjudication Date, rather than a range of Prescriptions | The query criteria is changing from the current POS request which includes a range of Prescriptions (beginning and end by RX number). The FHIR approach is to request totals or details by a date range which is now possible as many more records can be returned in the query response. This is a more streamlined approach that is much more efficient for all parties | Must support queries by date range | Must support queries by "adjudication" date range |
| FHIR Paging Mechansim | FHIR does not impose a maximum on the number of records returned. If the record max exceeds the maximum supported by the sender and/or receiver, FHIR paging can be used. This allows vendors to send a single query request for details or totals, instead of having to send many requests to achieve the same result | Must support paging | Must support FHIR paging |
| No backward compatibility to CPHA3 | New query style and mechanisms for FHIR | Must natively support new FHIR queries and send to FHIR adjudicators | Must support FHIR queries natively |
| New Results Rule | Requestors can specify a "results rule" to indicate whether they want the response to "include" or "exclude" one or more carriers or one or more carrier/groups, or whether they wish to include ALL. Today they can only include | Must support | Must Support |
CPHA Transactions
Transaction types 32 and 33 from CPHA3 have now been deprecated.
| CPHA Transaction Type | Existing Definition | Deprecated? | Response |
|---|---|---|---|
| 30 | Transaction requesting the accumulated totals for specified adjudication date (for Carrier ID and Group # if indicated) | New FHIR definition - see below | 80 |
| 31 | Transaction requesting a detailed record of claims, for up to 14 consecutive claim transactions, on a specified adjudication date (for Carrier ID and Group # if indicated) | New FHIR definition - see below | 81 |
| 32 | transaction requesting a detailed record of reversals, for up to 14 consecutive reversals, of claims processed on a specified adjudication date (for Carrier ID and Group # if indicated) | Deprecated - data Included in Trxn 30 | |
| 33 | transaction requesting a detailed record of prior reversals, for up to 14 consecutive reversals, of claims processed prior to the adjudication date specified in this request (for Carrier ID and Group # if indicated) | Deprecated - data Included in Trxn 31 |