Implementation Approach
The following content is provided as a starting point for discussion & review. It is a DRAFT
Problem Areas Addressed by the FHIR Standard
The following problem areas have been identified and will be addressed by the new FHIR standard. The timing for each will vary across implementers and will be determined by each, based on their ROI, Priority and Product Roadmap.
| Problem Area | Description | How Addressed in FHIR |
|---|---|---|
| Professional Services | New, separate transaction specifically designed for Professional Services | TBD - Requirements under development |
| Coordination of Benefits (COB) | Improve COB adjudication; increase number of claims processed | Share Prior Payor Adjudication details, Patient Paid Amount |
| High Cost Drugs -> over 10K | Send a single claim over 10K | Extend all cost fields in request and response messages |
| Improve Automation Capabilities | Additional data to support improved adjudication, reduced auditing and clawbacks. | Compound ingredients, Patient Paid Amount, SIG, Days supply over 999 |
| Processing Improvements | Changes to improved user experience, and Support Troubleshooting | Additional error codes, messages directed to patient or pharmacist, french or english indicator |
| Legislative & Jurisdictional Requirements | Address mandatory requirements driven from new legislation; align with adjacent message standards | New fields for Quebec Pricing, DIS Prescription Identifier and PrescribeIT Prescription Identifier |
| Modernization Items | Update the standard to modern technology | Support FHIR, JSON and new message format |
Implementation Timing & Approach
It is highly unlikely that all stakeholders implement this new version of the Canadian Pharmacy Claims Standard at the same time. This is a very challenging task as there are multiple forces impacting vendor and adjudicator timing, including value proposition, product roadmaps, costing and resources. As such our approach assumes that we cannot completely coordinate on implementater's timing, though it is highly encouraged.
Assumptions:
- Vendors, Adjudicators and Networks will implement at various times, in accordance with their business cases and product roadmaps.
- Networks MUST implement FHIR and support this first, prior to vendors sending FHIR and before the first adjudicator can receive FHIR. Networks must support the existing CPHA3 version and FHIR simultaneously.
- It is expected that both CPHA and FHIR will exist for several years. As a stakeholder group, we can establish a target end date, but we cannot enforce this timing. Furthermore, pharmacy vendors support multiple versions of their software and cannot always coordinate updates to every store at the same time. There will be variances in this regard as well.
- Phased Approach: Not all features/functions will be implemented by everyone at the same time. As such, version control mechanisms must be in place. This includes capability tracking at the feature/functional level. By example, support for a single claim over $10,000 is a functional change that must be tracked by both the sending and receiving applications.
- Phase 1 will likely be an MVP - Minimum Viable Product. Implementers will work together to define this but in general we expect that few if any legacy/back end changes will be required for MVP. Some stakeholders may wish to support other optional features during MVP; howver, the minimum viable approach will likely be defined as accepting FHIR and mapping into existing backend formats.
| MVP | Details |
|---|---|
| 1 | Upgrade technology to new FHIR standard and map CPHA3 or backend/legacy system format |
| 2 | Pharmacies send FHIR claim; Adjudicators accept and respond with a FHIR response |
| 3 | Pharmacies will only send FHIR claims to FHIR adjudicators and CPHA3 Claims to CPHA3 receivers |
| 4 | Send additional information that is available in the Pharmacy and Adjudicator systems today (eg SIG, Compound ingredients) |
| 5 | Professional Services claim must be supported as a separate transaction |
| 6 | Legislative requirements will be addressed if possible |
Backward Compatibility
CPHA v3 and FHIR will co-exist for both vendors and adjudicators for the following reasons:
- Vendors may not roll out FHIR to all of their client sites on a given day
- Adjudicators could adopt FHIR before all PMS vendors have adopted FHIR; they must provide a CPHA response if they receive a CPHA request
- All Adjudicators and All vendors will not all move to FHIR at the same time
- Adjudicators may have multiple systems; therefore will not implement once for all carriers
- PMS vendors may have multiple systems/versions and may not migrate to FHIR at the same time.
In order to support migration from CPHA to FHIR, it is highly likely that implementers will introduce a "mapping" layer within their systems during the MVP stage. Though this approach works fairly well, there are some complex mappings that must be addressed. In general, native support is always recommended over mapping so it will be beneficial to move to Post MVP as soon as possible. It is also important to note that both the Claim Reversal and the Daily Totals will NOT be mappable and therefore the only implementation approach that is viable is for implementers to support both CPHA and FHIR for a period of time.
There are mechanisms within FHIR (using a Capability Statement) for any implementer to publish the FHIR version, features and constraints that they are conformant with. This may be very helpful in supporting adjudicator-vendor communications in this regard.
Vendors and Adjudicators support both versions
Assumptions
- Vendors must send CPHA3 to Adjudicators who support CPHA3
- Vendors who are FHIR-compliant must send FHIR to Adjudicators who support FHIR, once they have have this capability
- Vendors must support both CPHA and FHIR until such time as all adjudicators are on FHIR
- Adjudicators on FHIR must issue a "capability statement" that details which transactions they support and what particular features (eg support claims over 10K)
- Adjudicators who support FHIR must natively implement the FHIR reversal and the Daily Totals as these transactions cannot be mapped.
- Adjudicators who implement FHIR must continue to receive and respond to CPHA3 transactions until such time as all vendors support FHIR. Said otherwise, adjudicators must support both CPHA3 and FHIR for message exchange.