Complex Mapping Rules FHIR-CPHA
This section itemizes mappings that are considered to be more complex. Some involve implementers to add specific coding. Others are considered to be complex simply because they are not straight field to field level mappings.
Claim Request
| Subject | CPHA ID | Field Name | FHIR Mapping rule |
|---|---|---|---|
| QJ Code | D.65.03 | Intervention/Exception | CPHA Code has been deprecated. QJ=deferred payment - patient to pay pharmacist can be derived using Payee Type = "subscriber" on the response message |
| DA and DBCode | D.65.03 | Intervention/Exception | CPHA Codes DA and DB have been deprecated. They are no longer required as the code meaning can be derived from the Claim Request, using the Prior Payor response(s)(FHIR: Claim.Insurance.ClaimResponse). The carrier and policy can be used to determine the type of coverage in prior claims and the DA/DB can be calculated by the adjudicator. THE FOLLOWING RULES ASSUME THE PRIOR PLANS ACCEPTED THE CLAIM (Response Code A or B). 1. If there is only a single plan for this claim (one instance of coverage in the FHIR message), DA/DB does not apply 2. When adjudicating a claim for the second plan, AND If the first plan was public (FHIR: Carrier + policy), * Assume DA code 3. If adjudicating a claim for the second plan, AND If the first plan was private (FHIR: Carrier+ policy), Assume a DB code 4. If adjudicating for YOU, third plan where 1-public + 2-private + 3-you, AND If the payor immediately before you was private(2), assume DB * If you are GreenShield, also assume DA in addition to DB 5. If adjudicating for YOU, third plan where (1-private + 2-public + 3-you) AND If the payor immediately before you was public(2), assume DA 6.. If plan is NIHB, the store is Ontario, the drug is an ODB Limited Use Product, and patient has ODB coverage, then * Assume DA 7. If the prior plan REJECTED the claim (response code R), and the pharmacy skipped the plan, then: * If you are NOT ESI, rejected plans are not taken into count when calculating DA/DB. Example: Public/private (rejected) then submitted to Private, neither the DA or DB would be apply to private * If you are ESI, then do not take into account the prior rejected plan if one of these error codes was included in the response: 'A6,C1,C4,C6,C8,CW,DX,EN,HA,HE,MW,MY,PA,QD,QJ,RW,SA', otherwise treat the rejected plan as a valid prior payor. |
| TransactionCode | A.03.03 & E.03.03 | Message.Header.event.code | The values are not a 1:1 mapping. Refer to Terminology for mapping rules - https://simplifier.net/guide/pharmacy-claims-standard/home/terminology-and-identifiers/event-transaction-code-for-review.page.md?version=current| |
| Single Claim over 10K | D.66.03 and others | Claim.item.detail.net.value | Claims over 10K must be managed as a 'feature', whereby the Pharmacy sending system understands whether the target adjudicator can accept a single claim over 10K. As CPHA3 supports a maximum drug cost of 9999.99, claims over this amount are split into two claims that together make up the entire drug cost. Special service codes are used to convey that the claim has been split. From a mapping perspective, this would mean that a single claim request would need to be split into two claims in the adjudicator engine if they do not natively support a single claim over 10K. The reverse situation is also true, whereby two claims being submitted by a PMS system must be mapped into a single claim. Neither of these two scenarios are feasible. Also of note, FHIR extends the dollar limits to allow for a single claim over 10K. Currently, claims over this amount are mapped into multiple claims. It is not possible to map two inbound claims into a single claim for adjudication without serious risks; therefore, mapping will be prohibited and partnering systems must agree on timing and coordinate this during the implementation phase Much further work is required to determine the implementation approach for this particular feature but at this point in time we beleive that it must be managed through the publication of "capability statements". This allows the sending system to understand what the adjudicator can support at any point in time. The sending system can then align accordingly. This will require coordination amongst implementers. The SSCs that are used today are: R = partial claim, cost exceeds $9999.99. S = remainder of claim, cost exceeds $9999.99 These will continue to be used for split claims. |
| Intervention Codes | D.65.03 | Intervention/Exception | When an adjudicator maps from FHIR-CPHA, they may receive more than 2 codes (CPHA3 limit). It may be necessary for the adjudicator to reject if there are more codes than what they can manage. |
| New Professional Service Claim | PCS FHIR includes a separate message specifically designed for professional services. When mapping to CPHA3, this MessageHeader.event code (interaction) must be recognized and mapped into the CPHA 3 format. Refer to Terminology, Event Code listing for mapping details | ||
| Deferred - Trxn 04 Deprecated |
N/A | Deferred Payments | For payors that support pay patient claims (transaction type 04), these will no longer be supported and instead, the payee on the claim request will be used for this purpose. On the response, adjudicators must return the amount paid to the patient in the new field, and return 0 in the amount paid to the pharmacy field |
| Claim.Diagnosis | D.51.03 | Medical Condition / Reason for Use | CPHA limits this to a single code, 6 digits; FHIR will allow 0..*, with a practical limitation of 10. Implementers will determine the code system to be used |
| Special Services Fee | D.72.03 | Claim Dispense Request | In CPHA this is being used for various reasons, eg it may be used by some to convey the remaining balance between what the provincial plan amount is and the total submission amount. It could also be used to convey the eligible amount from the provincial plan. In PCS FHIR, we are able to add a field to the dispense claim to convey the eligible amount from the provincial plan. Adjudicators are using this value to drive some adjudication rules. **More information is required before this field will be added. |
Response Mapping - FHIR to CPHA3
| Subject | CPHA ID | CPHA Name | Notes |
|---|---|---|---|
| Response Status | E.05.03 | ClaimResponse.disposition | |
| Alert Codes - Clinical | E.06.03 | ClaimResponse.item.adjudication.ClinicalAlertCode | Clinical messaging will be split out from the fiscal response codes. Example: MA Avoidance of Alcohol Indicated POS vendors can expect that the use of this field will happen over time, as it is not mandatory for MVP. As such, vendors must understand that Alert codes may appear in either the Response Code field or the Alert code field, until such time as all implementers support this new field. |
| Patient Pays Amount | D.75.03 | Previously Paid | Derive from the ClaimResponse.payeeParty.type = subscriber. The ClaimResponse.total.amount.value will indicate the amount paid to patient (aka subscriber) |
| BC Codes | Special Auth | POS vendors no longer need to transpose data from the primary BC response to the secondary claim request when both primary and secondary are using PCS FHIR. POS vendors will need to map into CPHA3/special auth field when downstream payors support CPHA3. In PCS FHIR, a new field called Pertinent Adjudication Details will be used to send these details. POS systems will need to map from this into CPHA3/special auth field when downstream payors support CPHA3. In PCS FHIR, the field will be included in the Prior Claim Results as well as in the Primary claim response, therefore no mapping when primary and secondary are on FHIR |