Overview

The Capability statement must be published by each Implementer. this provides a standardized mechanism for implementers to share key information pertaining to a FHRI implementation. Please refer to the FHIR site for further details.

At a high level, this statement will confirm which transactions are supported and any further impelmenter constraints. This is a declaration of support that will be used by implementers to understand what is supported.

Each implementer must produce a Capability Statement using the following format:

Implementer Information

*Each implementer must provide the following information to be published, as shown in the example below

Date	Adjudicator or Vendor	Name	Contact email	FHIR Mapping or Mix	FHIR Version	PCS Version
exampleDate	Adjudicator	PBM123	PMB123support@gmail.com	FHIR v5.0	1.0.0

Transactions Supported

*Each implementer must fill in the "Supported?" column to indicate support for each transaction.

Code	Description	Notes	Support (Yes/No)
01	Claim Request for Dispense Claim
11	Reversal Request for Claim
51	Adjudication Response to Dispense Claim
61	Adjudication Response for Reversal Claim
20	Totals Request	New transaction code/not mappable to CPHA
70	Response to Totals Request	New transaction code/not mappable to CPHA
21	Adjudications Details Request	New transaction code/not mappable to CPHA
71	Response to Adjudication Details	New transaction code/not mappable to CPHA
NEW	Professional Services Claim Request
NEW	Professional Services Claim Response

Functionality Supported

*Each implementer must fill in the following table to indicate the level of support, natively in their application for each of the following functions. Submitting vendors will use this information to understand what adjudicators are supporting what features; they can then ensure alignment with each other which will reduce the number of errors.

Number	Topic	Details	Support? (Yes/No)
1	Increase Intervention and Error Codes	Increase the number of intervention codes on claim request to 10. Increase error codes to 10.
2	Increase price fields	Increase allowed amounts on request and response message (>9999.99 for cost, and >999.99 for fee)
3	Add units of measure for products	The quantity field will allow for units, eg unit, package, mL, L,g, kg
4	COB, Additional data	New fields to support inclusion of adjudication details from previous payors. The prior adjudication results will be added to the claim request along with minimal information about the prior payor (BIN, Amount paid, Intervention codes)
5	Compound ingredient Breakdown	New fields to allow for compound ingredients will be added (DIN, quantity, fraction of total price)
6	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.
7	Claim Response Details	Add fields to claim response to indicate how much of cost/markup/fee cutbacks can be passed on to secondary third parties and to patient. This helps pharmacies honour contracts insurers make with their customers. Purpose is to help pharmacies obey terms insurer makes with clients.
8	Quantity	Change quantity to include up to 3 decimal places. *Add unit (eg puffer, inhaler, capsule? Conformance Rule: Quantity is used throughout the messages. It may be a drug form (e.g. TAB) an administrable drug (e.g. PUFF) form or a unit of measure (e.g. mg). Aligns with PrescribeIT and DHDR looking for drug form This will enhance adjudication capability
9	Expand response message capability	Change response messages (text) to a list, and increase acceptable character count from 40 characters per message to 1000.
10	Expand response message capability	Add language code (english/french/not specified) to response messages. This cannot be at the bundle level; could be english + french translation and vendor will display based on the user language. Adjudicators should be able to specify blank if unknown (eg CPHA or don't support), and for FHIR, both english and french are expected if possible. Need blank language code for Backwards compability. FHIR responses will contain english + french combined
11	Expand response message capability	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
12	Days supply	will be 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.
13	Diagnosis, up to 5 optional	Leave open in the standard, constraint by, conformance rule
14	Add SIG	Add a field for pharmacies to submit the SIG as part of the claim request
15	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.

Planned Work

*Each implementer must declare support, within their application for each of the following functional requirements:

Number	Topic	Details	Support? (Yes/No)
1	Professional services message	A new transaction to support the Professional service. New Public Clinical Message considered for Phase 2. Create clinical data message to meet the requirement of some provinces. Today the claim message is sometimes used to obtain clinical data. A new clinical message without fiscal data is proposed