NCPDP Update. Review of NCPDP Task Group Efforts and Use Cases for Real-Time Benefit Inquiry Standard. May 23, 2017

Transcription

1 NCPDP Update Review of NCPDP Task Group Efforts and Use Cases for Real-Time Benefit Inquiry Standard May 23, 2017

2 Catherine C Graeff CEO, Sonora Advisory Group, LLC Active in NCPDP since as a member, leader, trustee and staff Member of NCPDP Real-Time Prescription Benefit (RTPB) Task Group since May 2014

3 About NCPDP ANSI-accredited SDO About 1500 members representing 3 major categories of pharmacy services industry Developed national standards named in HIPAA, MMA, other regulations Over 75 Task Groups reporting to 10 Work Groups Develop Standards & Implementation Guides, Guidance, White Papers, etc. After standards are balloted and pass, are approved by ANSI

4 Presentation Overview Define RTPB Task Group Scope Overview of Initial Use Cases (v1.0) Other Considerations Timeline Q&A

5 Real-Time Prescription Benefit Inquiry Task Group Formed in May 2014 due to CMS and industry discussions Identified need for an industry-wide standard solution ONC requested comments as part of the EHR Certification rulemaking process Identified use cases associated with a prescription benefit inquiry Surveyed industry organizations to understand the priority of each use case identified Delivered Business Requirements (use case document, data requirements), not the standard itself in February 2017

6 What Is Today s Problem? The prescriber may not know: If the medication is on-formulary for the patient. If there are any utilization edits (i.e. prior auth., quantity limits). If the patient s cost-share is manageable for the patient. If the patient s choice of pharmacy will impact their cost-share. If the patient is taking a medication that may cause an adverse event. Today s other standards such as the Formulary & Benefit Standard does not provide detailed, patientspecific benefit information.

7 What is a Real-Time Prescription Benefit (RTPB) Request/Response Transaction? A means to provide patient-specific prescription benefit information at the point-of-care Request for prescription benefit information originating from the provider (prescriber) Processor/PBM/Adjudicator provides the response to the request Response represents status at the point-in-time the request was processes

8 Benefits of RTPB Request & Response Facilitates provider and patient decisions on the most appropriate covered drug pharmacy selection the estimated patient cost of therapy Reduces rejected claims at point of dispensing Reducing pharmacy, PBM, provider and patient interaction for benefit related reasons Anticipate improvement in medication adherence

9 RTPB Standard Participants and Flow Provider Data Capture UI Display Request Request EHR/EMR Intermed. Switch (Routing) Processor PBM Adjudicator Response Response

10 Structure of Requests and Responses Each Request and each Response is made up of combined fields or Segments. Segments are Required or Optional, depending upon the Use Case triggered in forming the Response Each Segment is made up of Fields Fields are Required or Situational, depending upon the Use Case triggered in forming the Response Multiple Use Cases can be triggered in a single response by the Payer/PBM Sonora Advisory Group, LLC

11 Examples of Segments and Fields Patient Information Prescription Information Pharmacy Information Provider Information Patient Name fields Product ID Pharmacy ID Prescriber ID Date of Birth Quantity Gender Unit of Measure Member ID Days Supply 11

12 Other Segments Used In Request or Responses Routing Information (always required) Transaction Information (always required) Additional Information Financial Information Coverage Limits Reject/Denial Explanation (required in all but Use Case 1) Drug Utilization Evaluation For each Use Case, Segments are Required or Optional and Data Elements within that Segment are Required or Situational Sonora Advisory Group, LLC

13 What is a Use Case? The Task Group used the term Use Case to describe the most common benefit scenarios, and the fields that are necessary in the Request to allow the PBM to process the request; the fields that are necessary in the Response to provide the Provider/EHR System and Patient with the information necessary to understand the patient s benefit at that point in time, and to take appropriate action in. Sonora Advisory Group, LLC

14 High Priority Use Cases (scenarios) 1. Patient Eligible, Product Covered 2. Patient Not Eligible 3. Benefit Exclusion 4. Formulary Exclusion 5. Coverage Limits 6. Step Therapy Required 7. Prior Authorization Required 8. Out of Network Pharmacy 9. Out of Network Provider 10. Patient/Provider Lock-In 11. Patient DUE Alert 12. Restricted Pharmacy

15 If multiple Use Cases Apply, all required information will be returned in a single Response Provider Data Capture UI Display EHR/EMR Request Response Intermed. Switch (Routing) Request Response Processor PBM Adjudicato r

16 What is the Use Case Document? Captures the business requirements for the development of the initial RTPB Standard for the 12 Initial Use Cases Describes the Request and Response process and scenarios under which a PBM sends a Response Identifies data to be included in the Request and in the Response for each use case Completed and delivered by the Task Group to NCPDP Maintenance & Control February 2017 for approval

17 All Request Transactions Require the Following Segments of Information: Routing/Payer Information Transaction specific Information Patient Information Prescription Information Pharmacy Information Provider Information

18 Two Types of Responses Affirmative Use Case 1: Patient and Drug are covered. Negative Use Cases 2-12: Some issue with the patient, benefit, product, pharmacy, or prescriber that should be communicated to the provider and patient Sonora Advisory Group, LLC

19 Affirmative Responses (Use Case 1) Requires the Following Segments: Routing Information Transaction-specific Information Prescription Information (as submitted) Financial (Estimated Patient Financial Responsibility Any additional segments are optional. Some data elements within a segment may be situational

20 Negative Responses Require the Following Segments: Routing Information Transaction-specific Information Reject/Denial Explanation Prescription Information (as submitted) Any additional Segments are Required or Optional, dependent upon the Use Case. Some data elements within a segment may be situational

21 Other Task Group Considerations In Scope Patient-specific drug benefit info Identify information in provider request Identify information in Processor/PBM/Adjudicator response to request Product alternatives Real-time communication Out of Scope RTPB requests from anyone other than prescribers Payer/PBM s cost of the product Subscriber identification Coordination of Benefits Requests for services, partial fills, compounded prescriptions

22 Use Case 1: Patient Eligible, Product Covered A provider submits a request, it is routed to the Processor/PBM/Adjudicator who processes the request, and sends an affirmative response to the provider. There are no issues with this benefit inquiry.

23 Use Case 1: Patient Eligible, Product Covered Mary Smith sees Dr. Jones, who determines she needs a beta blocker. Dr. Jones selects #30 Bystolic, Elm Street Pharmacy and submits the benefit request. Mary s plan responds with a message that Bystolic is covered and that Mary s copay will be $20 for a 30 day supply at Elm Street Pharmacy.

24 Use Case 1: Patient Eligible, Product Covered Provider Data Capture EHR/EMR UI Display Request Affirmative Response (Financial Responsibility) Intermediary/ Switch (Routing) Affirmative Request Response (Financial Responsibility) Processor/PBM/ Adjudicator

25 Use Case 2: Patient Not Eligible A provider submits a request, it is routed to the Payer/PBM who processes the request, and sends an negative response to the provider. The patient is not eligible for pharmacy benefits on the day the request was received.

26 Use Case 2: Patient Not Eligible Provider Data Capture EHR/EMR UI Display Request Negative Intermediary /Switch (Routing) Request Negative Processor/PBM /Adjudicator Response (Patient Not Eligible) Response (Patient Not Eligible)

27 Use Case 3: Benefit Exclusion A provider submits a request, it is routed to the Payer/PBM who processes the request, and sends an negative response to the provider. The product requested for the patient is excluded from coverage under the patient s benefit plan. No alternatives are available.

28 Use Case 3: Benefit Exclusion Example John Smith sees Dr. Nelson and asks about medicine to treat his erectile dysfunction. Dr. Nelson submits a benefit request for sildenafil. John s plan responds that sildenafil is excluded from coverage under John s plan. John needs to decide if he wants to pay cash for this prescription.

29 Use Case 4: Formulary Exclusion A provider submits a request, it is routed to the Payer/PBM who processes the request, and sends an negative response to the provider. The product requested for the patient is excluded from the patient s formulary. If there are formulary alternatives, up to ten (10) alternative products, and the associated Estimated Patient Financial Responsibility, may be identified on the response.

30 Use Case 4: Formulary Exclusion Example Bob Harrison sees Dr. Maple. Dr. Maple determines that Bob needs to begin statin treatment. Dr. Maple submits a request for Lescol, 30 day supply at Big Box Pharmacy. Bob s plan responds that Lescol is not on formulary, but that atorvastatin, fluvastatin and lovastatin are all preferred formulary products. Bob will pay $10 for a 30 day supply of either formulary product at Big Box Pharmacy. Bob could also pay $20 for a 90 day supply at Big Box or through the plan s mail order pharmacy.

31 Use Case 5: Coverage Limits The product is covered, but a component of the request is not covered for the by the plan for the patient. The plan has a limit on the quantity or days supply allowed, or the patient s age and/or gender may not be clinically appropriate for the requested medication.

32 Use Case 6: Step Therapy Required The product may be covered/approved if Step Therapy Requirements are fulfilled. The plan may require that other medications be tried before the requested medication is approved for coverage. Estimated Patient Financial Responsibility, if provided, is what the patient is expected to pay if edit resolved. Alternative products may be provided

33 Use Case 7: Prior Authorization Required The submitted product requires a prior authorization The patient financial responsibility, if returned, is what the patient is expected to pay if the PA is approved The may return up to 10 alternative products

34 Other Use Cases Use Case 8: Out-of-Network Pharmacy The requested pharmacy is not in the plan s network and the patient will have to pay cash if they choose to use that pharmacy. Use Case 9: Out-of-Network Provider The provider on the request is not in the plan s network and the patient may have to pay cash if they choose to use that provider. Use Case 10: Patient/Provider Lock-In The patient is restricted to a specific provider(s) and the plan will not pay for prescriptions written by the requesting provider.

35 Other Use Cases, continued Use Case 11: Drug Utilization Evaluation (DUE) Alert The plan has information about a medication that the patient appears to be currently taking that is causing a utilization alert severe enough that a claim for the requested product will be rejected at the pharmacy. Limit of 5 specific DUE/DUR alerts Use Case 12: Restricted Pharmacy The drug is covered, but the pharmacy identified in the request is not eligible to fill the product for the patient. Occurs when the patient is locked-in to a specific pharmacy or must obtain the product through a mail order or specialty pharmacy(ies).

36 NCPDP Timeline NCPDP approved Use Case Document and related data requirements at NCPDP Work Group meetings in February 2017 At Work Group meetings in May 2017, a new Task Group formed to address the creation of a single standard supported by both Telecom and SCRIPT syntaxes June Standard development activities commence as with all NCPDP standards

37 When Will the Standard Be Completed? New Task Group will use approved Use Case Document and data requirements to develop the standard in the 2 syntaxes Three year effort to provide this documentation and will streamline efforts Standard will be presented at a future NCPDP Work Group meeting for approval (1 st or 2 nd quarter 2018?) If approved, standard will be balloted during a spring or fall NCPDP ballots voted upon by the NCPDP consensus group. If approved, new standard will go through NCPDP internal processes and obtain ANSI approval Sonora Advisory Group, LLC

38 Questions? Sonora Advisory Group, LLC