Claim Response - Message Structure
The processor adjudicates the claim as it is received, and returns the results of adjudication immediately. The results will include an explanation using response codes and text should the claim be rejected. An accepted claim includes payment details which will align with the payment to the provider.
The MessageHeader.eventCode will indicate whether this is a CPHA 51 (Response to Medication claim) or 52 (Response to Professional Services claim). Additionally, for a pay cardholder claim, the ClaimResponse.payeeType will indicate who will be paid.
The same response is used for both the claims that are paid to the provider (51) as well as claims that are paid to cardholders (54). In CPHA, there was a response to pay providers for batch (57) which has now been deprecated.
FHIR Message Structure
The follow diagram depicts the high level structure, showing all resources that are included in the message and how they are linked together.
Profile Summary
| Profile Name | Profile Link |
|---|---|
| Bundle | Bundle Profile |
| MessageHeaderResponse | Profile for MessageHeaderResponse |
| ClaimResponse | Profile Claim Response |
| Prior Payor Response | Prior Claim Response Details |
| Patient | Profile for Patient |
| Coverage | Profile for Coverage |
| Prior Coverage | Profile for Prior Coverage |
Business Rules
The Claim Response and the Prior Claim Response both contain the Disposition and Outcome fields. These are crucial for the POS vendor and Pharmacy User to understand what has occurred so they may take appropriate action. The following is provided as guidance to Adjudicators in setting these values that will be passed on to downstream payors.
When setting the outcome:
- The outcome will be set to "complete" when the claim can be fully adjudicated, even when the claim is rejected due to plan restrictions.
- The outcome will be set to "error" when there are corrections to be made, eg when the plan or plan member cannot be found.
When setting the disposition:
- Adjudicators should return “accepted” in the disposition, IF the claim has been fully adjudicated. Note: Plan may pay zero dollars
- Adjudicators should return “rejected” when they are unable to fully adjudicate the claim. In this case, the outcome will be "error"
- For REJECTED status, Pharmacist MUST decide to a) retry claim with different data b) cancel the prescription, eg try different drug, or patient doesn’t want the rx c) skip the plan entirely and move to secondary payor
When to include the COB/Prior Adjudication Results
- If the claim is not paid in full, the Prior Coverage resource and the COB Claim Response are included, so that the Pharmacy can include these resources in the downstream claim.
- Provenance is not in scope for the MVP, initial phase of implementation
Additional Pertinent Information for Downstream Payors
Currently in CPHA, some data is passed on as messages in the claim response. The POS system, then transposes the data and moves it into the Special Auth field in the downstream request. This process is cumbersome and is potentially error prone. In the FHIR standard, this information will be passed on in the Claim Response and in the Prior Claim Results. There is a new "PertinentDetails" field which supports a "Category code", eg BCCodes, and a "Reason Code" that will be defined for each implementer and use case. The POS system will take this information and place it in downstream claim requests, without a need to transpose the data.
Known use cases
BC Codes: The vendor interprets/passes on to secondary in this field. Returned from BC, in equivalent of CPHA message lines (4 fields/Yes or No) – passed on to Pacific blue in the special auth field - D.64.03
RAMQ vendor logic: If RAMQ paid, then proceed with secondary, assuming it was paid under special auth RAMQ. Note: RAMQ look at passing definitive information that this was paid under special auth