Daily Totals and Details Request
The request, Parmaters:IN is identical for the Daily Totals and the Adjudication Details request and is distinguished by a unique transaction identifier (MessageHeader.event id). This is analogous to the current CPHA request.
The FHIR MH.event type will be CPHA transaction type 30 for a Daily Totals Request and transaction type 31 for a Details request.
The FHIR Request for Totals and Details has been updated offering more specific requests, without the same restrictions that exist with CPHA. Though structurally different than CPHA3, this fulfils the existing business requirements in a modernized fashion. While mapping may be achievable to existing CPHA3 functionality, it is significantly more beneficial to the Pharmacy users to natively support the new FHIR queries in order to take advantage of new functionaliy and the flexibility that it offers. It may also be more efficient for adjudicators to support new FHIR queries natively while continuing support for CPHA queries for a period of time, rather than to support mapping between the two message standards.
New Functionality in FHIR
- FHIR transactions are streamlined to a single request for totals (transaction 30) and a single request for details (transaction 31).
- The request for reversals and prior reversals is no longer required as this information will always be returned. Data that is irrelevant may be ignored. Transactions 32 and 33 will be deprecated.
- Time Period - a start and end date can be specified, extending the period of time beyond a single day.
- Start and end date include "time" to allow vendors to restrict to a certain time period within a day, or over multiple days. .
- 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.
- The 14 record restriciton (packets of 13) is effectively lifted. For backward compatibility, requestors may include a count of 14 records to match the current functionality. While the time period is open ended, the maximum recommended period is 31 days which all adjudicators are expected to support in FHIR. Each implementer will communicate their supported time period.
- Six day restriction - indicated in current CPHA3 message. Discussion - do we want to keep this rule?
- FHIR paging mechanism. There is a very high likliness that this will not be required and that all results will be returned in a single query response. For backward compatibility, the paging mechansim may be employed; to be determined after discussion with the implementation committee. It will not be necessary to provide the last prescription number, as the adjudicator will fulfil the query and return the results or one or more pages. The requesting system can specify the limit, however the server can override it if they support less than the count requested. Currently, the spec only has a 14 day restriction flag. Decision TBD Currently, this is not in the specificaiton; may be added. As guidance, 1 MB / 256 B ≈ 3906 records,
5 MB / 256 B ≈ ~19,500 records. .
In summary, the response to a query will be a FHIR bundle, that can return the number of records requested (eg 250) or that can be managed by the server (eg 200). The "searchset" bundle will include the entries (up to the requested count or servers limit per page), the total number of records found and a link for subsequent requests (URL's to navigate through pages; client follows the next link).
Backward Compatibility to CPHA - TO BE DISCUSSED
Considerations:
- Do we need backward compatibility?
- Vendors - retain both query styles? Send FHIR to FHIR adjudicators; CPHA3 to CPHA3 adjudicators - CPHA3 will be deprecated over time
- Adjudicators - assuming these queries are fulfilled outside of adjudication - different endpoint to a reporting/payment interface? If no mapping, will need to keep CPHA3 interface and add a FHIR interface. CPHA3 will be deprecated over time
- Do we make these transactions mandatory for PCS FHIR - MVP? or do we make them optional and it can be sorted between adjudicators and vendors
- to ensure backward compatibility, we need to have additional date in the FHIR message; we need to be able to map trxn 32 and 33 into FHIR and perhaps create the equivalent.
| Mappable to CPHA | Details |
|---|---|
| 14 record restriction | Mappable when the restriction is set to YES. This rule must be in place for implementers who intend to map |
| Results Rule | Carrier+Group inclusion - This is mappable when the flag is set to include. This rule must be in place for adjudicators who cannot support exclusion due to mapping. |
| Reversals & Prior Reversals | Not mappable; can include a flag to make this mappable if desired - Discussion Adjudicators must be able to return all results together to natively support FHIR; if we wish to retain mapping, we need to keep separate transactions, which is not desirable. CPHA3 request can be mapped into PCS; all other results must be stripped out which may not be possible with the current CPHA3 totals & adjudication details |
| Start & End Date | Carriers who do not support more than one day can reject if a period more than one day is specified. |
| Beginning of Record | This is in the spec; marked for backard compatibility; not required in FHIR. **DISCUSSION: IF MAPPING IS DESIRED, WE CAN INCLUDE PARAMETER AS OPTIONAL. Mapping from FHIR, the start date/time may be mapped to "0". The adjudicator can set the restriction to 14 as is done today. Current CPHA Definition 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 | Int he spec, indicated use is for backward compatibility. If not populated, may be mapped from FHIR - if the time is not populated in the end date/time of the request, the query will return the last transaction for that date/time period. Current CPHA Definition: 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. |
CPHA Transaction Definitions
| 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 |
FHIR Transaction Definitions
| FHIR MH.EventType | New Definition |
|---|---|
| 30 | Transaction requesting the accumulated totals for specified adjudication date range. Includes support for totals for specific Carriers and/or Groups that may either be included or excluded in the result set. No restriction on number of records. |
| 31 | Transaction requesting a detailed record of claims, for a specified adjudication range. Includes supports for specific Carriers and/or groups that may either be included or excluded from the result set. No restriction on number of records |
Parameters:IN Structure
The structure of the Parameters IN is identical for the Daily Totals and the Adjudication Details. The only difference will be the MessageHeader.eventType which will distinguish the type of message that is being processed.
The FHIR Profile is found here
Parameters:OUT Structure
The structure of the Parameters OUT is identical for the Daily Totals and the Adjudication Details. The only difference will be the MessageHeader.eventType which will distinguish the type of message that is being processed.
The DRAFT FHIR Profile is found here
Note: Updates to this message are expected once message samples are produced and mappings can be validated.
Backward Compatibility
There are two new FHIR queries that will be introduced to replace the existing queries for Totals and Adjudications results. These queries have been streamlined to support only the required data and have been structured in a way that assists vendors in getting the data that they need in a more logical manner than what is in place with CPHA3 today.
The two queries that map from CPHA3 are as follows:
- Daily Totals Request - Event Code 30
- Daily Totals Response - Event Code 80
- Adjudication Details Request - Event Code 31
- Adjudication Details Response - Event Code 81
As the queries must be backward compatible, it may be necessary to restrict the result set to 14 records, as is done with CPHA. In this case, paging is introduced. If mapping queries from CPHA to FHIR, there must be continued support for the 14 day restriction and it will be up to implementers to determine how this is handled between partners.
It is strongly encouraged that all implementers natively support the FHIR queries in the MVP stage; however this will be determined by the PCS Implementation group. Mapping is possible but it is not ideal.