30-31- Request For Daily Totals & Adjudication Details
The Daily Totals and Adjudication Details that are supported in CPHA3 are limited to return a maximum 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 Adjudication Details Request is identical to the Daily Totals Request in structure, however it is distinguished by a unique transaction identifier (MessageHeader.event id). ). 30 = Request for Daily Totals and 31 = Request for Adjudication Details
No Backward Compatibility to CPHA3
The PCS FHIR transactions are new and not backward compatible to the existing CPHA3 queries, as it not possible to otherwise advance to modern standards in any meaningful way. As these are queries, backward compatibility is not essential as the new queries can be supported in parallel with existing CPHA3 ones.
Benefits
The new FHIR queries are designed to be much more efficient as they remove unnecessary restrictions and allow for a single query to return a large amount of results. 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. Additionally, these queries now allow for a range of dates/times to be executed, rather than a restriction on a single day.
PCS Implementers agreed that perpetuating this very limited query mechanism was not desirable. Further, these queries are typically supported outside of the core adjudication engine making migration to FHIR queries feasible.
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 adjudication 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.
| Feature | MVP Scope | Details | Sender Responsibility | Receiver Responsibility |
|---|---|---|---|---|
| Daily Totals and Details | Totals and Details:Parameters:IN | |||
| NEW FUNCTIONALITY Re-write Adjudication Details and Totals |
MANDATORY | Completely new and streamlined. These transactions are not mappable between CPHA3 and FHIR | MANDATORY | MANDATORY |
| Remove 14 Day Restriction | MANDATORY | The limit of 14 days is removed. However, the sender can specify the maximum number of records they can support in a single page. FHIR does not impose a limit | MANDATORY Must specify Max Records of records that may be returned in the query result |
MANDATORY 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. | NOT APPLICABLE | The PCS implementation committee confirmed that this feature is not used and therefore will not be supported in FHIR | NOT APPLICABLE Not present in the FHIR queries |
NOT APPLICABLE Not present in the FHIR queries |
| FHIR Query Design by Adjudication Date, rather than a range of Prescriptions | MANDATORY | 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/time 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 | MANDATORY Must support queries by date/time range |
MANDATORY Must support queries by "adjudication" date/time range |
| FHIR Paging Mechanism | MANDATORY | 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 | MANDATORY Must support paging or always submit a restriction of a 14 record maximum |
MANDATORY Must support FHIR paging |
| No backward compatibility to CPHA3 | MANDATORY | New query style and mechanisms for FHIR | MANDATORY Must natively support new FHIR queries and send to FHIR adjudicators |
MANDATORY Must support FHIR queries natively |
| New Results Rule | MANDATORY | 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 | MANDATORY |
MANDATORY |
Message Structure
The message structure is identical for the Daily Totals and Adjudication details request. The Message Header.event code is used to distinguish between request types.
