Best Practices

real time prescription benefit workflow the representative ndc of the single requested medication, days' supply, quantity and requested pharmacy are required in the rtpbrequest modifying any of these fields after the original request and before routing the prescription may impact the rtpbresponse, therefore a new rtpbrequest is recommended the pbm/payer's ability to price a medication is based on the quantity and days' supply when sending days' supply and/or quantity ensure that they reflect what may be dispensed at the pharmacy the rtpbrequest is most effective if triggered automatically when the required data elements are available allowing the prescriber to trigger with the use of a prompt or button will result in lower utilization of the real time prescription benefit information rtpbrequest the provider vendor should populate the rtpbrequest patient demographic information with the same patient demographic information from the 271 eligibility response to ensure patient matching by the pbm/payer to aid in patient matching, it is recommended to use the value exactly as it was received in the 271 eligibility response customers can use their drug compendia and/or any other sources of drug information to find the average daily dose for the medication and use that to populate the days' supply in the rtpbrequest before sending to surescripts customers should include icd 10 diagnosis codes on the rtpbrequest to improve pbm/payer processing accuracy any secondary partner pharmacy (also referred to as affiliated pharmacy) provided on the rtpbrequest should be a pharmacy that is owned and operated by the requesting organization or one that the requesting organization has a contracted association with to avoid unnecessary errors, rtpbrequests should be sent only to active pbm/payer customers whose directory service level supports real time prescription benefit the service level is called 'patmedbenefitcheck' ndc related errors are common error types to reduce the occurrence of these errors, send the representative ndc for the requested medication do not send repackaged, obsolete, private label or unit does ndc unless it is the only ndc available to identify the medication concept rtpbresponse alternatives if the rtpbresponse contains alternative pharmacytype options or medications, the provider vendor should allow the prescriber to easily switch to that alternative alternatives could include medication, supplies, and pharmacies pharmacy alternatives can include all types (i e , retail, 90 day, mail, specialty) if the prescriber selects a different medication, they should be given the opportunity to review the prescription details prior to routing there may be instances where the price of an alternative is higher than that of the requested medication at the time of the rtpbrequest as deductibles are realized, it is possible for copay and the cost to the patient’s prescription benefit to be more beneficial than the requested medication additionally, the cost to the patient’s prescription benefit plan may be lower on the alternative real time prescription benefit display estimatedcombinedplanandpatientsavings/estimatednetplancost in certain scenarios or environments, such as accountable care organizations (acos) or high medicare part d populations, providers may want to consider the cost to the plan (plan pay) when making prescribing decisions if either element is received in the rtpbresponse, the provider vendor can display this information user interface real time prescription benefit information is most effective if displayed directly to the prescriber without requiring user interaction it is recommended that the information be displayed on the primary screen for the prescriber to view without having to click into a separate screen prescribers are less likely to view the information if a click or separate screen is needed to display the information if space is a concern, some of the real time prescription benefit information can be displayed with the use of a hover over or secondary screen for example, deductible amounts may be returned on the response, but displayed using a hover over for more information, please see display requirements docid\ nysveavsrly7thlkahfi4 user interface examples example of estimated patient costs (hover format) example of coverage alert (hover format) example of coverage alert (list format) patient information unavailable for patient there are some scenarios in which the provider may not be able to access real time prescription benefit information for a patient in these instances, the provider vendor should do the following when encountering an error, display a user friendly message to prescriber indicating that benefit data for patient is currently unavailable or, continue the e prescribing workflow without notifying the prescriber extensibility extensibility was added to allow trading partners a consistent way to include additional information in the rtpb messages it was created to enable the integration of extra information in messages in a safe and meaningful way, it can help streamline testing of new data elements, maintain the standard's simplicity while accommodating uncommon use cases, and most importantly, paves a quicker path to introducing new features that benefit patients, providers, pharmacies, and payers surescripts will not validate data in extensions beyond the schema requirements it is recommended that partners do not reject transactions that include an extension that is not expected and instead ignore the information when using extensions, the following rules as defined by ncpdp must be observed the core schema must be followed extensions must not contradict the base standard extensions must not alter content from the base standard extensions must not be used when standard fields are available external code list values cannot be modified by extensions