Outstanding Implementation Work Items
The following list of outstanding issues and questions will be addressed by the PCS FHIR Impelmentation group, that will be formed in early 2025. Many of these items came forth through the stakeholder review of the Draft PCS FHIR standard in November, 2024.
| Date | Subject | Issue or Question | Notes | |
|---|---|---|---|---|
| Nov 23 | Transition to FHIR | General Question/Scenario - If a pharmacy were to send a claim today using the CPhA3 standard, and tomorrow they are now on a new pharmacy POS system using the new FHIR standard, what is the expectation for a reversal at the payor end for the claim filled using the CPhA3 layout? i.e. how will this process work? | To be reviewed: Potential approaches: As a starting point, we can assume: a) the sending system must understand the version of the receiving system and vice-versa. b) both sending and receiving system have mapping capabilities from CPHA-FHIR and vice-versa. c) The POS and Adjudicator must understand both FHIR and CPHA for a period of time; eg POS sends CPHA to AdjudicatorA and FHIR to Adjudicator B. d) Once a POS application in a pharmacy updates to FHIR for an adjudicator, nothing should get submitted in CPHA from that point on. e) Once a POS applciation moves to FHIR, the interface will also change, as FHIR typically uses a RESTful interface. So, given this, some viable options for reversal to be discussed are below. Note: This could vary by implementer though ideally we would like to agree on a single approach a) The reversal is sent in FHIR (though it originated in CPHA3) and the receiver can translate it if necessary; the response back to the POS will be in FHIR b) For a short period of time, reversals are handled manually |
|
| Nov 23 | Professional Services - codes | Professional Service claims will have an code for 'Minor Ailments' etc. What will be the sourse for these? i.e Rx Vigilance, FDB? etc. | An implementers group is required to determine what is best; there is a recognized goal is a national code set rather than each implementer to determine. Ideally, to be completed prior to the first implementation. If this work is not complete then it runs the risk of not achieving a national code set. please submit codes it to FHIRPCS@gmail.com. | Proff services group |
| Nov 23 | Codes UF and UG | Code review - eg UF: Patient Gave Adequate Explanation. Rx Filled as Written UG: Cautioned Patient. Rx Filled as Written For UG and UF, will it be possble for a PMB to choose to not allow thoses codes ? Given the broad wording of these exception codes, we observe issues with their use to force a refund when another exception code is not accepted. This leads to issues during audits. We believe it is relevant that a PMB may choose not to make these codes accessible when processing a payment request. | Discussion: es, it is up to the PBM to determine what codes they are supporting, just as it is today. The code set is not intended to impose mandatory use of all codes. If an implementer needs to convey the concept, they must use the code provided in order to do so. One thing I want to explore is that implementer can have a page in this specification to convey these types of differences, eg codes that are not supported but this requires further discussion across all implementers. Ideally, the implementer group (yet to be formed) will do a complete review of these codes in order to streamline them. Different stakeholdrers use different codes today and likely some on the list are not used by anyone and should be removed. I would like to see a standard way of advising vendors which codes each PBM supports so POS can streamline their use accordingly. Also confirm values that are used in a dispense message, if any. | |
| Jan 3 | Capability Tracking | See section on Capability Tracking for review and alignment. | ||
| Jan 3 | Single endpoint for Claims and Reversals? | feedback to be requested by implementation group/confirmed during Trial Use period | ||
| Jan 3 | Profile Creation Claim reversal and response profiles | The message header has an event.system of urn:ietf:rfc:3986. The event.code is the URL from the operation definition OperationDefinition.url | Technical support | |
| Jan26 | Review key identifiers | trace number, claim number and current rX; limited to 9N. Determine how we wish to handle and extend beyond current limit | ||
| Jan26 | Diagnosis System | Can diagnosis.system be mandatory in claim profile? | ||
| Jan26 | Confirm whether special auth is required for Proff Services claim | Added to discussion for August 27 | ||
| Jan 26 | Are all special service codes part of proff services? If YES, remove from Claim.dispense | |||
| Jan 30 | Upload/create Details Adjudication Parameters OUT Profile | Technical work | ||
| Mar 15 | Do we need to support the specifcation of prior intervention codes; those submitted to the primary and indicated on a secondary claim? | |||
| Mar 15 | I have created an extension for the native CPHA 3 message - should we include this if available when mapping has occurred by the sending system? | |||
| Mar 15 | Do we need to indicate whether the prescription is "new" or a "repeat"? there is an extension for this so it was once discussed, eg "new or repeat rx". Not yet in the profile but could be an extension on claim.prescription | |||
| Mar 15 | new fields have been added to the claim response specifically for conveying information related to special authorizations. At this point, special auth start date and expiry date are the main fields. Others may be added to this list as the working group progresses. We will need to ensure that an ‘unlimited’ xpiry date is handled properly as well for ODB limited use products.Is anything else needed? where it goes from there during broader review | |||
| Mar 15 | Usage: Total Quantity Dispense Accumulated. (in the spec already) 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. Feb 13 discussion: Several new fields will be added to the response to support special authorization - needs to be reviewed with the larger TWG group and then I will implement (Feb 2024)Discussion Jan 30 --- BC has hijacked a field (Tarin will email, message line). 8 character coded field as first payor; other payors leverage to understand whether first prov payors have indicated special auth is in place. Marie-Helene --- when will the current authorization expire. Confirm if we need Another "coded" field to provide further context on provincial adjudicaiton details (Tarin to send details and we can review as a group as this is used for COB/secondary payors). Extension - number of authorizations remaining - confirm, and more details; extension on Prescription, need more feedback. Cannot be mandatory - for mapping purposes/will not have this from the onset. Taryn - do we want to call this "quantity remaining? - sometimes days supply is more valid for refills then quantity remaining. | July 23 - reviewed with imp group; will remove Dispense Quantity Remaining - Claim request. Also reviewed and confirmed special auth period, Special Auth Remaining Quantity - Response, Special Auth Total Quantity Dispense Accumulated field -Special Auth - Approved Days Supply - Response and Special Auth - Approved Days Supply - Response. | ||
| Mar 15 | Prescription Quantity Unlimited | This was proposed and an extension created; but it was never bound to the message. Do we wish to include this? | ||
| Mar 15 | Source conformnace version | Do we wish to add this? Used in PrescribeIT. The version number of the software that underwent conformance testing. It may be earlier than the source.version in cases where the application has since undergone changes that do not affect the claims interface. If desired, this could be validated at runtime if registered. May not be necessary; useful for troubleshooting | ||
| Mar 15 | Source province code? was discussed just need to confirm this; I created an extension but it is not yet in the spec | |||
| Mar 15 | Unlimited number of repeats | extension exists; should we add to the rx profile? only populate if this is known/in POS | ||
| Total Authorized Quantity | extension exists; should we add to dispense profile? only populate if known. Note: the Dispense Quantity Remaining is on the claim in supporting info: Total quantity remaining on a prescription after this dispense. The total authorized quantity outstanding after the fill issued as part of this dispense record Usage Note: DHDR Alignment and also on PrescribeIt CPHA Mapping: None, New field | |||
| Mar 15 | french display for codes | |||
| Apr 13 | Requestor.identfier.assigner | See message example & terminology, do we want to use offical code set for Prescribers to match PrescribeIT/Infoway set? If Yes, do we want to include the CPHA value if mapping? | ||
| May 16 | Review event codes for group sign-off | Once complete, create event code value set | ||
| May 19 | is Supply field on Medications | Further information is required to better understand what this is for, before adding an extension to the medication profile | ||
| July 24 | Remove dispense quantity accumulated from the request message - meeting decision | |||
| Aug 22 | COB meeting - add a "system" to the error code that is returned; can be from CPHA, PEI-NeCST or others; update profiles to reflect this | |||
| Aug 22 | COB meeting - Program Type - May need several indicators - TBD | |||
| Aug 22 | COB meeting - obtain list of error codes - to update the spec | |||
| Aug 22 | COB meeting - Add healthcare spending account and wellness as a coverage type; mark as "future use" | |||
| Aug 22 | COB meeting - send out presentation, in prep for next meeting - re digitial signature | |||
| Sept 18 | Ensure that DUR messaging (clinical) is connected to response - may need an extension or this to reference. May add an indicator on process notes |
Resolved Issues
| Date | Subject | Issue or Question | Notes |
|---|---|---|---|
| June 1 2025 | Claim over 10K | Should there be a separate message for this? See section on Claim Request - Over 10K for further details re capability tracking | Implementation Commitee topic for discussion. Message is identical to dispense message |
|Nov 23|SSC -code values to be reviewed |There is further implementation work that must be done to confirm the Professional services claim and SSC values. We will stick with the same code listing as is in CPHA3