Adjudication Details Operation

The Adjudication Details Request in FHIR is a new request message that will replace the following CPHA transactions. This query is being re-structured though it maintains a mapping to the existing CPHA transactions. Adjudicators are encouraged to natively support this transaction as soon as possible though it is not mandatory for the MVP phase.

This single FHIR transaction (event type =31) replaces the following CPHA transactions:

  • 31 Detailed record of claims for up to 14 consecutive transactions. Response is 81
  • 32 Detailed record of reversals for up to 14 consecutive reversals Response is 82
  • 33 Ddetailed record of reversals for claims processed prior to the ajudication date specified Response is 83

The purpose of these transactions is to obtain details of claims and reversals for a period of time during, or for an entire adjudication date for the purpose of resolving an unexplained variance between accumulated daily totals received from the processor and the provider's record for the same period of time.

This capability is invoked by using the $daily-details operation. This is an operation rather than a query because key data in the message header can be re-used in an operation, rather than a straight query on existing records. The operation is invoked using an HTTP GET and responds with either an OperationOutcome (if there were errors) or a Parameters OUT instance containing the result.

The request is identical to the Daily Totals request in structure but it is distinguished by a unique transaction identifier (MessageHeader.event id). The queries will be executed using a custom FHIR Operation, "$daily-totals" or "$daily-details" which also distinguishes the type of request.

Operation Definition Response
[base]/$adjudication-details Bundle with Message Header, focus = parameters:In resource. Custom FHIR Operation/Parameter resource Bundle, Message Header, focus= Parameters:Out
Detailed Record by Date

Profile Summary

Profile Name Profile Link
Bundle Bundle Profile
MessageHeaderRequest Profile for MessageHeaderRequest
Parameters Request ParametersIN
Parameters Response ParametersOUT



Changes from CPHA

Trxn CPHA Definition FHIR Definition
31 Transaction requesting a detailed record of claims for up to 14 consecutive transactions, for a specified adjudication date for Carrier ID and Group # if indicated Transaction requesting a detailed record of claims (pay provider & pay patient) and reversals for the time period specified. The result set will either include or exclude any listed Carriers and/or Groups that were specified in the query request. Transaction counts/totals will be provided for each day within the requested time period
81 Response to a request for a detailed record of accepted claims The response will include transaction counts/totals for each day within the requested time period. Daily totals will be broken down by pay patient and pay providers and will also include reversal counts.

The three CPHA transactions are streamlined into a single FHIR message that covers all of the existing functionality and improves the functionality as follows:

  1. The 14 record restriction has been removed. While the time period is open ended, the maximum recommended period is 31 days.
  2. The new structure specifies an "include only" or "exclude only" rule that allows vendors to specifically request that one or more carriers and/or group be included or excluded in the result set.
  3. Paging is not required at this time; all results will be returned in a single response message. Should we need to introduce paging, the FHIR mechanism will be followed. As this could return thousands of records, it will be up to each adjudicator to advise the PMS vendors of their restrictions, eg they may restrict each query to a maximum of 30 days. Rejections should specify the limits on time period that the adjudicator supports. PMS vendors may make this configurable in order to avoid rejections.
  4. Backward compatibility to CPHA is maintained; however the parameters for beginning and end records will be phased out over time as implementers move to FHIR.
  5. The result set will include both claims and reversals which supports mappings to CPHA results by ignoring data that is irrelevant.



Requires review by TWG

The FHIR Response Message will be a bundle with:

Resource Cardinality Description
MessageHeader 1..1 The Messaging header The focus of the message will be the Parameters resource or Operations Outcome if errors should occur.
Parameters 0..1 The parameters OUT; mandatory for all successfuly queries
OperationOutcome 0..1 This resource is used when there are errors found in the request

Out Parameters: (Successful response)

Each record returned - group by date and trxn type (always return two records, one for 01 and one for 11. One record for each date that will return two rows.

Parameter Part Name Cardinality Type Details
Parameter Adjudicator ID 1..1 identifier also in message header
Parameter Event Code 1..1 code fixed value = "90" for Adjudication Details Response
Parameter Claim Total for Period (trxn type=01) 1..1 money Total for time period specified
Parameter Claim Reversal Total for Period (trxn type=11) 1..1 money Total for time period specified
Parameter Claim Record Details 1..* see below repeats for each record
Part AmountPaidToPatient 1..1 money
Part AmountPaidToPharmacy 1..1 money
Part RX Number 1..1 identifier
Part Date 1..1 dateTime
Part TrxnID 1..1 code Value = 01 for claims or 11 for reversals



31 - CPHA description Update or remove from FHIR spec


Transaction requesting a detailed record of claims for up to 14 consecutive transactions, for a specified adjudication date (for Carrier ID and Group # if indicated).

The purpose of these transactions is to obtain details of claims and reversals for a period of time during, or for an entire adjudication date for the purpose of resolving an unexplained variance between accumulated daily totals received from the processor and the provider's record for the same period of time. The provider will obtain a complete record of claims (code 31) before proceeding to obtain a complete record of reversals of claims processed on the adjudication date (code 32) and subsequently to obtaining a record of reversals of claims that were processed prior to the adjudication date (code 33). Providers should use this option only when necessary.

The last current prescription number (Field D.55.03) processed before, and the last current prescription number processed during the selected time period will identify the beginning and the end of the detailed records being requested. When detailed records for an entire adjudication date are required, the beginning of the record will be zero (000000000) and the end of the record ewill be 999999999. (TO BE DISCUSSED)

The maximum number of detailed records that can be delivered in response to a request is fourteen (14). If this is not sufficient to provide complete detail records for the timeframe identified above it will be necessary to initiate another request.

To do this, the provider must be sure to use the last current prescription number received in the last detailed record as the "Beginning of Record" (Field F.91.03). The "End of Record" (Field F.92.03) will continue to be identified by the same current prescription number as was used in the initial request for records within the same adjudication date. The process of requesting and receiving packets of 14 detailed records will be repeated until the requested detail is delivered or the variance has been identified.

32 - CPHA description


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).

The response is a CPHA transaction code = 82, Response to a request for a detailed record of reversals of same date claims.

The CPHA definition below is applicable to this Operation. The message structure will become a FHIR Parameters resource; **however, the execution of the Totals transaction may remain the same. ** This ensures that this operation is backward compatible to the CPHA message structure.

33 - CPHA description


Transaction requesting a detailed record of reversals, for up to 14 consecutive reversals, for claims processed prior to the adjudication date specified in this request (for Carrier ID and Group if indicated).

General Discussion

Discussion - FHIR mechanism for paging, instead of this should be used - let's review for backward compatibility purposes


CPHA Definition

The purpose of these transactions is to obtain details of claims and reversals for a period of time during, or for an entire adjudication date for the purpose of resolving an unexplained variance between accumulated daily totals received from the processor and the provider's record for the same period of time. The provider will obtain a complete record of claims (code 31) before proceeding to obtain a complete record of reversals of claims processed on the adjudication date (code 32) and subsequently to obtaining a record of reversals of claims that were processed prior to the adjudication date (code 33). Providers should use this option only when necessary.

If possible, the provider should identify a time period during which the variance may have been caused. Such a time period will be defined by a Beginning of Record (Field F.91.03) and End of Record (Field F.92.03). The last current prescription number (Field D.55.03) processed before, and the last current prescription number processed during the selected time period will identify the beginning and the end of the detailed records being requested.

When detailed records for an entire adjudication date are required, the beginning of the record will be zero (000000000) and the end of the record will be 999999999. The maximum number of detailed records that can be delivered in response to a request is fourteen (14). If this is not sufficient to provide complete detail records for the timeframe identified above it will be necessary to initiate another request. To do this, the provider must be sure to use the last current prescription number received in the last detailed record as the "Beginning of Record" (Field F.91.03). The "End of Record" (Field F.92.03) will continue to be identified by the same current prescription number as was used in the initial request for records within the same adjudication date. The process of requesting and receiving packets of 14 detailed records will be repeated until the requested detail is delivered or the variance has been identified.

The Response will be a Detailed Record Response (CPHA: 81,82,83). This will be a FHIR parameters instance. An example response can be seen ## here.

Anne review above approach with TWG

CPHA Requirements:

Request for Totals and Detail Records (same for both queries)

FHIR Parameter Name CPHA FIELD # STATUS DESCRIPTION
IIN A.01.01 M Issuer Identification Number identifies issuer of benefit card N 6
Version Number - Obsolete A.02.03 M Corresponds to CPhA Pharmacy Claim Standard version number used to transport this messageN 2 Current version # is "03"
Transaction Code A.03.03 M Identifies purpose of transaction A / N 2
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)
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)
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)
Provider SoftwareID A.04.03 M Identifies computer system in pharmacy A / N 2 See Terminology section for codes.
Provider Software Version A.05.03 M Identifies version of provider software A / N 2
Active Device ID - Obsolete-LL A.07.03 O Provides active device identification code A / N 8
Pharmacy ID Code B.21.03 M Pharmacy identification code A / N 10
Provider Transaction Date B.22.03 M The date on which the provider sends the request N 6 YYMMDD, established for the time zone in which the provider is located at the time that the request for totals or details is transmitted.
Trace Number B.23.03 O The unique number produced sequentially by the Provider for each transaction transmitted by the provider N 6
Carrier ID C.30.03 O Identifies the plan type or benefit program A / N 2 The provider may utilize this field to identify a particular plan within an IIN to obtain more precise summaries, if payments areissu ed by carrier ID, or to obtain more concise detailed records from adjudicators who segregate accounts by carrier ID.
Group Number or Code C.31.03 O This is a number or code assigned by the plan administrator, payor, processor or benefit card issuer to identify a specific group of benefit recipients within a carrier (Field C.30.03) designation A / N 10 See Section A for added information. A further breakdown of a summary or detailed record than is available from carrier ID may be obtainable from some adjudicators who use a group number or code to identify a significant number of beneficiaries (e.g. when a carrier ID contains less than 10 group designations).
Adjudication Date F.90.03 O The adjudication date assigned to claims and reversals, at the time of processing, for which the totals (code 30) and the claims/reversal details (code 31) are being requested N 6 YYMMDD assigned by the processor in Field E.01.03 at the time the claims were adjudicated or the reversals were processed. Request may be for current day's totals or detail or for a closed adjudication date during the last 6 days.
Beginning of Record F.91.03 O This is the last prescription number which precedes the prescription at which the detailed record being requested begins. A provider who requests a detailed record that begins at the time of opening, on an adjudication date, will indicate "0" (zero) as the "last prescription number". In a request for a time period during the day the "last prescription number" will refer to the last prescription which was filled or reversed before the transaction at which the requested record begins. The processor who receives the request will identify the exact time,during the adjudication date, at which the transaction on the prescription number referred to occurred and will return a detailed record of the first 13 transactions (claims and reversals) which follow or until the "End of Record" (Field F.92.03) has been reached, whichever occurs first. The provider may continue to request packets of 13 transactions by repeating the procedure, using the last prescription number in the previous packet, until the "End of Record" or the record of the last transaction for the adjudication date has been received.
End of Record F.92.03 O This is the number of the last prescription to be included in the detailed record being requested N 9 The number of the last prescription may refer to either a claim or a reversal. If this field is blank, the "End of Record" will be the last transaction submitted on an adjudication date.


Transactions 31, 32 and 33

The purpose of these transactions is to obtain details of claims and reversals for a period of time during, or for an entire adjudication date for the purpose of resolving an unexplained variance between accumulated daily totals received from the processor and the provider's record for the same period of time.

The provider will obtain a complete record of claims (code 31) before proceeding to obtain a complete record of reversals of claims processed on the adjudication date (code 32) and subsequently to obtaining a record of reversals of claims that were processed prior to the adjudication date (code 33). Providers should use this option only when necessary. ??? why??

If possible, the provider should identify a time period during which the variance may have been caused. Such a time period will be defined by a Beginning of Record (Field F.91.03) and End of Record (Field F.92.03). The last current prescription number (Field D.55.03) processed before, and the last current prescription number processed during the selected time period will identify the beginning and the end of the detailed records being requested.

Conformance Rule When detailed records for an entire adjudication date are required, the beginning of the record will be zero (000000000) and the end of the record will be 999999999.

Conformance Rule The maximum number of detailed records that can be delivered in response to a request is fourteen (14). If this is not sufficient to provide complete detail records for the timeframe identified above it will be necessary to initiate another request.

To do this, the provider must be sure to use the last current prescription number received in the last detailed record as the "Beginning of Record" (Field F.91.03). The "End of Record" (Field F.92.03) will continue to be identified by the same current prescription number as was used in the initial request for records within the same adjudication date.

The process of requesting and receiving packets of 14 detailed records will be repeated until the requested detail is delivered or the variance has been identified. Use FHIR mechansim, ensure backward compatible

Transactions 81,82,83

The processor will maintain detailed information on each claim and reversal for electronic recapture for seven days. This will include current prescription number and amount payable or amount reversed (including all costs, fees, upcharges and taxes). The processor will forward this detailed information on each claim or reversal contained in the detail records requested by the provider. Detailed records of claims (code 81), reversals of current claims (code 82) and reversals of prior claims (code 83) will be processed and sent as separate transactions. The records will follow a time of adjudication sequence beginning at the time of the first transaction which was processed following the current prescription number contained in the Beginning of Record (Field F.91.03). The maximum number of detail records that can be delivered on a single request is 14 (248 bytes). The provider will initiate as many requests as are required to deliver the detailed records desired during a specified adjudication date. Current prescription numbers that are identical may occur more than once during an adjudication date (e.g. a claim is resubmitted following a reversal or rejection). This creates a possibility that the prescription number which appears more than once during an adjudication date occurs at an interval of 14 records. If this happens to be the number which identifies the beginning of the record the same 14 records may be repeated in response to requests for more than one packet (14 records). To prevent this it is suggested that processor systems be programmed not to duplicate a record that has already been transmitted until all of the detailed records for that adjudication date have been sent. In response to a request for detailed records, the processor will return Fields E.01.03 through E.06.03 plus the number of detail records (Field H.65.03) followed by up to 14 repetitions of Current Rx Number (H.66.03) and Amount Payable/ Reversed (H.67.03)