Claim Request - New Fields
The claim request supports all of the current functionality found in CPHA3. The key differences are identified below and details are found in the table:
1. FHIR splits Professional Services from a Dispense claim.
2. FHIR supports claims over 10K
3. FHIR dispense claim supports additional information that is not supported in CPHA3
The following provides a more detailed view of the key changes that implementers will see within the FHIR message itself. Note: This list covers the vast majority of new fields; however some, such as new fields in FHIR that contain fixed values or those that are structural in nature are not included in this list as there is no impact to business data.
| No. | Feature | Details | POS - Sender Responsibility | Adjudicator - Receiver Responsibility |
|---|---|---|---|---|
| 1 | Units of measure for products | The quantity field will allow for units, eg unit, package, mL, L,g, kg | POS must include where value is known | Adjudicators may ignore initially; should support when possible |
| 2 | COB - New Prior Payment Details for Downstream Claim request | New fields to support inclusion of adjudication details from previous payors in the claim request. The prior adjudication results will be added to the claim request along with information about the prior payor (BIN, Amounts paid, Intervention codes, Response Codes) | POS must map into FHIR | Receiving systems may ignore initial and support when possible |
| 4 | Compound ingredient Breakdown | New fields to allow for compound ingredients (DIN, quantity, fraction of total price) & indicator of active ingredient | POS must include data when known | Adjudicators must minimally store data and fully support when capable. |
| 5 | Diagnosis, up to 5 optional | Allow up to 5 diagnosis codes. | Sending system must include where known | Receiving system may ignore?TBD |
| 6 | Rendered Dosage - SIG | Add a field for pharmacies to submit the SIG as part of the claim request. Included to enhance adjudication /audit capability. | Sending system must include where known | Receiving system may ignore. |
| 7 | Total Quantity Dispense Accumulated field | The total number of pills "adjudicated" for a special auth number. An Adjudicator authorizes the number of pills against a special auth number; the dispenses may occur across several pharmacies. This accumulated total is returned as part of the adjudication result as informational data. | Sending system must include when known |
Receiving system consume when possible |
| 8 | Expand response message capability - Target Patient or Pharmacist |
Add flag on response message to indicate if it targeted at the patient or pharmacist. Field length/list will be handled by default by changing to JSON. Drug engine/DIA can start populating longer messages whenever they are ready. Pharmacies don’t need this at all since they have other means of doing interaction checks, including DIS.??? to be discussed* Today, 3 of 40 characters; if extended | ||
| 9 | Medication code system | Add “Type” identifier on medication (eg DINS) to identify origin of pseudodins (NPN, Opinions,etc). This helps adjudicators to choose the correct product for adjudication. | POS systems must send | Receivers may use the data when required |
| 10 | Pharmacy ID Assigning Authority (static value) | OID to align with other standards; this is fully mappable | POS systems must map and send | Receivers may use the data if deemed necessary |
| 11 | Banner Pharmacy Identifier | Identifier assigned by Banner and will assist with troubleshooting. Optional use as determined by implementer Organization.identifier slice |
POS systems must send if required by an implementer | Adjudicators will use the data if deemed necessary |
| 12 | Software Vendor pharmacy identifier | Identifier assigned by vendor, used for troubleshooting. | Optional use as determined by implementer | Optional as determined by implementer |
| Enhance field formats | Enhance field formats in the legacy applications to accommodate for the changing health care landscape | |||
| 1 | Increase price fields | Increase all dollar amounts on request and response message (eg >9999.99 for cost, and >999.99 for fee, special service fee) | Capability tracking/coordination between implementers may be required. | |
| 2 | Deferred - New field for dollar value paid to patient | The response message will be enhanced for deferred payments (insurer pays patient). This will enable COB, and responses for delayed adjudication. There is logic in the PMS today CPHA3 that blocks COB if a code QJ is returned because vendors do not know the amount to be paid to the patient and therefore vendors cannot properly calculate and submit the previously paid amount on claims to subsequent payors. In FHIR standard, the pay to patient amount will be included which will be shared when sending the claim to subsequent payors. This will prevent subsequent payors from overpaying the claim. The QJ code will be deprecated as it is not necessary to indicate a deferred payment because we will have a specific field to indicate the dollar value paid to the patient. Vendors will be able to remove the COB restriction because they know the amount. For payors that support pay patient claims (transaction type 04), return the amount paid to the patient in the new field, and return 0 in the amount paid to the pharmacy field. Transaction 04 will be deprecated |
||
| 3 | Quantity - Increase Decimal Places | Change quantity to include up to 3 decimal places. Added quantity unit, eg g, mg, ml, tablet, capsule, puffer etc. Aligns with PrescribeIT and DHDR looking for drug form** This will enhance adjudication capability |
||
| 4 | Expand response "message data line" - |
Change response messages (text) to a list, and increase acceptable character count from 40 characters per message to 1000. TBD upper limit on list | ||
| 5 | Days supply - Increase | Extended to allow specification of a larger duration. It is currently limited to 999 days, but some products (eg IUD's) may last for up to 5 years. | Sender must increase where possible; Receiving systems may map anything over 999 to 999 |
|
| 6 | Combine Pay Cardholder + Pay Provider | Transactions that are separate in CPHA will be combined into a single transactions that will specify the requested payee. The claim response will specify who the adjudicator will be paying. FURTHER DISCUSSION AND EXAMPLES REQUIRED | ||
| 7 | Increase Intervention Codes | Increase the number of intervention codes on claim request to 10. | Must be managed; receiver may reject if necessary (in the case of a mapping failure) or ignore additional codes Coordination between implmeenters may be required |
|
| 8 | Expand response message capability - Language |
Optional language code (english/french/not specified) to response messages. Allows vendor to display based on the user language. Adjudicators may specify blank if unknown (eg CPHA or don't support), and for FHIR, both english and french are expected if possible. FHIR responses will contain english + french combined | ||
| 9 | Increase Error Codes | Increase the number of error codes on claim response to 10. | TBD whether additional error codes can be ignored for MVP | |
| 10 | Network Totals | This query has been updated to streamline the number of queries supported | Mandatory when moving to FHIR | |
| 11 | Get Adjudication Details | This query has been updated to streamline the number of queries supported | Mandatory when moving to FHIR | |
| 12 | Source Prescription ID | Generated by EMR or PMS; this optional element is important to provinces who may track a prescription through its life cycle | MedicationRequest.identifier | |
| Fulfill legislative requirements | Fulfill legislative requirements or provincial requests | |||
| 1 | New Quebec Pricing Fields | Allows the Quebec Reference Price | Senders must send values in accordance with legislation Capability Tracking not required |
|
| 2 | Provincial Prescription Number | New Optional field used upon request from Jurisdiction | ||
| 3 | PrescribeIT Prescription Number | New Optional field used upon request from Jurisdiction | ||
| Modernize CPHA | Modernize CPhA from flat file to FHIR+JSON for future interoperability and ease of maintenance | |||
| 1 | FHIR & JSON format | Update from existing CPHA3 data format from fixed-width to JSON with UTF-8 encoding. Field mappings are one-to-one with CPHA3, but the structure is a FHIR JSON message. re minimum (i.e. tx number + date). | ||
| 2 | Separate DUR messaging | Update the structure of the message so that clinical messaging is separated from the fiscal portion of the claim | Built into FHIR structure | |
| 3 | Remove unnecessary fields | Remove fields that are not used in CPHA3. This includes reducing the number of fields required to cancel a prescription | ||
| 4 | New Professional services message | A new transaction to support the Professional service. Mandatory support from onset; Adjudicator must determine fixed values that are in CPHA3 but not in FHIR when mapping request | ||
| 5 | Terminology Mappings | In a few cases, FHIR terminology is mandatory and therefore must be mapped into current values. For example, gender codes must be mapped | ||
| 6 | Deprecate Messages in CPHA that are not used | No impact on implementers | ||
| 7 | Re-write Adjudication Details and Totals | These are completely new and steamlined, with mandatory support | These transactions are not mappable between CPHA3 and FHIR and therefore must be natively supported from in MVP |