NCPDP Work Group 11 Task Group: RxFill White Paper on Implementation Issues Purpose: To highlight and provide a general overview of issues that arise in the implementation of RxFill transactions. The discussion does not put forth NCPDP recommendations to resolve each issue, but rather introduces the topics for informational purposes and for potential further review. Introduction: As the Task Group for RxFill clarification researched and discussed the use of RxFill transactions in real-life scenarios, a number of discussion points were introduced that assisted the group in understanding RxFill and in making the clarifications to the SCRIPT Implementation Guide. While important to the overall understanding of the subject, many of the discussion items were not appropriate for inclusion into the Implementation Guide itself. To prevent the loss of the information and to enhance the understanding of RxFill for users of the Implementation Guide, this White Paper was created to make those discussion points available. These discussion points are best understood within the context of the base RxFill information incorporated and updated into the Implementation Guide. It is recommended that the reader review the Implementation Guide requirements and information on RxFill along with reviewing these discussion points. Definitions: Terms requiring clarification as used in this document. Dispensed - in the context of the RXFILL message, means the medication is no longer in the possession of the pharmacy and has been handed, shipped, or delivered to the patient (or the patient s caregiver/representative). If the medication is still located in the pharmacy, it is not yet dispensed. Returned to Stock the procedure of the pharmacy when the patient does not pick up a medication that has already been processed and has been waiting for patient pickup when the medication is either returned to inventory or destroyed.
Discussion of RxFill Operational Issues Automated Triggering of RxFill within Pharmacy: RxFill messages are intended to be sent by the pharmacy to the prescriber to indicate that the patient has actually picked-up the prescription, not that the prescription has simply been filled. The timing of the RxFill must therefore be tied to the action or confirmation of the actual pick-up. Today, even though most pharmacies have significant automation through a pharmacy management computer system, most of the systems do not automatically track the actual pick-up. Instead, most systems track the prescription to the point that it is ready for pick-up and placed in the customer will-call bin. When a customer arrives, the pharmacy conducts a manual process of retrieving the prescription and dispensing it to the customer. The steps taken are not necessarily automated or tied into the pharmacy management system. Without question, there are pharmacy computer systems and technologies available today to track patient pick-up. Point-of-Sale systems, electronic signature capture, Will-Call scanning systems and other technologies are capable of making a positive confirmation of pick-up back to the pharmacy system. But, in the majority of pharmacies today, the pharmacy system in use either does not have this capability, or, the pharmacy has not yet made the additional investment in technology required to do so. In all cases, the pharmacy management systems today would need to design and develop the capabilities to track, trigger, and send the RxFill messages and the data supporting them. Pharmacies would then need to implement these changes to their systems and work flows. Triggering RxFill(not filled) on Return To Stock: One indication of pick-up status to most pharmacy systems occurs if the prescription is Returned To Stock because the patient has not picked up the prescription after a number of days in the will-call bin. The timing of Return To Stock processing varies by pharmacy and may range from a few days to several weeks. During Return To Stock processing, the pharmacy system updates the prescription s status while performing the necessary reversals. For many systems, this is the first active indication of the patient s action, and can be used to trigger an appropriate RxFill(not filled) message. The timing of the RxFill message will vary based on the pharmacy s Return To Stock process. Physician System Acceptance of RxFill: Today, as with most pharmacy software systems, most software systems for physicians do not yet support RxFill transactions. The software developers must design and develop the new function to receive and process RxFill transactions. Physicians would then need to acquire and implement the updated systems. Therefore, widespread
use of the RxFill messages by physician systems, as with pharmacies, will likely take a significant amount of time. Prescriber System Matching: When a prescriber s e-prescribing system receives any transaction today, the transaction must be matched with a specific patient record. Data elements such as a unique patient or record ID might allow a fully automated match between RxFill transaction and patient record. If the original prescription was received by the pharmacy through e-prescribing, the original transaction number can be returned in the RxFill message to assist in matching. If the pharmacy received the prescription in a nonelectronic form, no transaction ID will be available so other data elements must be used for automated matching. It will be important for the physician system to incorporate fully automated matching and processing to ensure the RxFill messages do not add significant workload to the prescriber. New Prescriber Workload: RxFill messages are informational only to the prescriber. They do not replace other work already performed by the prescribers as does a New Rx or Refill Request electronic transaction. If the physician system requires any manual processing by the physician to match RxFill messages to patients, etc, the possibility of adding additional workload to the physician exists. Adding any additional workload should be avoided by the physician system vendor. But if increased, the cost and impact of this additional workload must be considered by the physician and may slow RxFill utilization. Volume of RxFill Transactions: The volume of RxFill messages will be higher than most other e-prescribing transaction types. For example, when a prescriber sends a New Rx transaction to the pharmacy, it will often include a number of refills for the patient. No additional e- prescribing transactions are sent between prescriber and pharmacy for those normal refills. But, an RxFill message will be sent for each prescription filled including one for each refill. An RxFill will also be sent for each portion of a partial fill. Even prescriptions that don t get successfully dispensed to the patient will trigger an RxFill message. Since the volume of RxFill messages would be high if fully implemented, any manual processing, additional work, or cost required by the prescriber or pharmacy to process the messages could be a significant impact on their workflow. HIPAA Privacy: The RxFill transaction is not currently considered a HIPAA covered transaction and generally considered part of treatment within the pharmacy and physician practice. An evaluation and ruling on this issue will be important to prevent the pharmacy or practice from having to acquire each patient s approval to participate in RxFill activity.
If not considered exempt under HIPAA privacy regulations, the additional overhead to the pharmacy to gain, store, and manage patient authorization would be a significant administration hurdle. Patient Privacy: Regardless of RxFill s status under HIPAA privacy regulations, the individual patient s expectations for personal privacy regarding their prescriptions and their pharmacy must still be considered. Some pharmacists are concerned that patients will feel their personal privacy has been violated if the pharmacy sends information on their actions to the prescriber. Some pharmacists have experienced patient complaints for similar information sharing in the past, and, are concerned about implementing the activity automatically across all patients. These concerns might be eliminated if the pharmacy system allowed an Opt-In or an Opt-Out process for RxFill by patient and prescription. Opt-In and Opt-Out Options for the Patient: To address the concerns of privacy or other issues, the pharmacy may consider using an Opt-In program, or, allowing individual patients to Opt-Out upon request. Such programs would require substantial enhancement to the standard implementation of RxFill message processing for most pharmacy software systems. The pharmacy would also need an appropriate administration process to manage such requests. Therefore, Opt-In and Opt-Out programs are not anticipated to be the standard practice for RxFill processing. Physician Liability: Some prescribers have expressed concern that receiving RxFill information about their patients actions regarding medications they have prescribed may increase their legal liability for the patient s ultimate result from the therapy. The concern is that if the prescriber receives information that the patient is not being compliant to their prescription therapy but the prescriber does not intervene with the patient, the prescriber could be viewed as negligent to the patient s treatment. Today, the prescriber does not have significant compliance information unless provided by the patient at the time of treatment, so, automated RxFill messaging brings out a new concern regarding liability. Paying for RxFill Transactions: Generally, most transactions that flow across an electronic prescribing network are assessed a transaction fee. This fee is most often paid for by the pharmacy. For the RxFill transaction, it is difficult to pinpoint a direct financial or operational benefit to the pharmacy as is the case for other electronic transactions. There are benefits of RxFill to the patient for better overall results when working with their physician. The Payer may benefit due to the opportunity to decrease overall patient treatment costs through more compliant and effective medication therapy. The physician may also benefit through
improved and complete prescription and compliance information to be used in treatment decisions for the patients. But a direct benefit to the pharmacy is difficult to determine. Therefore, it may be appropriate for any costs of sending RxFill transactions to be supported by other beneficiaries along with pharmacies. RxFill messages, once fully implemented, will also be a significant percentage of the volume of transactions over an electronic network. On average, a new prescription generally includes the authorization for four refills. Since an RxFill message is sent not only for new prescriptions but for each refill, an average of five RxFill messages may be generated for each one New Prescription electronic message sent over the network. Therefore, any cost associated with RxFill messages will be quickly multiplied by the volume and could significantly impact the organization paying for the transactions. How these costs will be paid for should be further reviewed and addressed by business partners involved in implementing and utilizing these messages. Overlap with the Medication History Transaction: Some information supplied by the RxFill transaction may be duplicated by information provided in the Medication History transaction. As with the RxFill transaction, medication and pharmacy processing information can also be provided by and between pharmacies, payers, and prescribers using the Medication History transaction. Today, the Medication History transaction is most often sent by the Payer to the Prescriber based on information the Payer receives and consolidates from Pharmacies during the adjudication process. The Payer can consolidate and send Medication History on all prescriptions it processes, even if the originating pharmacy does not participate in electronic prescribing or RxFill transactions. But if the Medication History transaction is sent by a Payer, it would not include medications paid for by the patient in cash and therefore not processed through a Payer. And since Payers get the information at time of adjudication, not actual dispensing, the Medication History transaction does not indicate that the patient has actually picked up their prescription. If pickup is inferred, the prescriber should understand the level of uncertainty regarding if the prescription was picked up and the timing of that pickup. A later Medication History transaction may also indicate that the prescription was subsequently reverse adjudicated if a patient never picked up the prescription. A Prescriber would need to request Medication History from all applicable Payers to ensure they received data for all the (non-cash) prescriptions for all of their patients. Medication History transactions if sent by Pharmacies could eliminate the uncertainly regarding if the prescription was actually picked up, and, could include cash transactions. But since a patient might visit more than one pharmacy, an individual pharmacy cannot consolidate the history for a patient for medications filled outside their pharmacy organization. The party requesting the data would therefore still need to request and receive Medication History information from more than one source. The major differences between the RxFill and the Medication History transactions are their timing, their accuracy, and the automation of their processes. Medication History transactions are often individually requested by the physician just prior to a patient visit to ensure complete and accurate records for that treatment. Updates to the
patient s medication history might be spaced out as far as their next appointment. RxFill messages would be received automatically and continually by the physician, therefore keeping an accurate picture of patient medication compliance at all times, not just prior to a patient visit. And RxFill transactions are to be sent specifically at time of pickup, so the accuracy of the information and timing surpasses the Medication History transaction. The timing difference is important if the physician is going to practice proactive compliance management with patients between office visits, not just during an office visit initiated by the patient. If the physician does not use the information in a proactive way between patient visits, the value of RxFill is diminished and its overlap with the Medication History transaction increases. Equally, if Physicians establish nightly updates from Payers for Medication History for all their patients, the timeliness of the data between RxFill and Medication History from Payers is lessened. The overlap of the RxFill and Medication History transactions should be more closely reviewed, and, their appropriate and individual roles clearly defined to eliminate confusion and unnecessary duplication of effort and data in the future. Changing Physicians: When a patient changes physicians, the RxFill messages for their prescriptions will continue to be sent to their old physician associated with that prescription in the pharmacy as long as the patient continues to refill that prescription. To have RxFill messages sent to a new physician, the patient must provide a new prescription to the pharmacy. The pharmacy cannot change the physician on record for a prescription so the RxFill message cannot easily be redirected to a new physician. Opt-In Enhancement for the Physician: Acceptance and utilization of RxFill may be improved by allowing physicians to indicate which prescriptions they want to receive RxFill messages for. Physicians might choose to receive RxFill for patient medications in some cases (diabetes, heart conditions, etc.) but not in others (seasonal allergies, common antibiotics, etc.). This would help reduce the impact of several issues including the volume of messages, cost of messages, privacy, information overload, and others. To implement this enhancement, the SCRIPT Standard would need to be enhanced to allow for a flag in each New Prescription and Refill Response electronic message indicating the physician s preference on receiving RxFill for that specific prescription.