DaVinci Payer Data Exchange (PDex) US Drug Formulary
1.1.0 - STU 1.1

This page is part of the US Drug Formulary (v1.1.0: STU 1) based on FHIR R4. The current version which supercedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions

Home

DaVinci Payer Data Exchange US Drug Formulary

This implementation guide defines a FHIR interface to a health insurer's drug formulary information for patients/consumers. A drug formulary is a list of brand-name and generic prescription drugs a health insurer agrees to pay for, at least partially, as part of health insurance coverage. Drug formularies are developed based on the efficacy, safety and cost of drugs. The primary use cases for this FHIR interface enable consumers/members/patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans.

A key architectural issue that is beyond the scope of this implementation guide is how a user finds the FHIR endpoint for a particular formulary. This implementation guide assumes that the FHIR endpoint is known to the user.

Introduction

This implementation guide (IG) introduces two FHIR profiles, along with associated extensions, search parameters, and value sets.

  • CoveragePlan: The CoveragePlan profile of the FHIR R4 List resource provides links to information about the plan and formulary, contact information, a description of the drugTiers and associated cost sharing models of the plan, and a list of FormularyDrugs.
  • FormularyDrug: The FormularyDrug profile of the FHIR R4 MedicationKnowledge resource provides plan-specific information about a prescribable drug identified by an RxNORM identifier. Cost sharing for the drug are described by reference to a drug tier defined as part of the coverage plan. Extensions to the MedicationKnowledge resource support important search use cases. Due to the immaturity of the MedicationKnowledge resource, it is expected that it will undergo changes, and those changes may require evolution of the FormularyDrug profile.

Two searchParameters have also been defined to facilitate the anticipated use cases. See the Anticipated Client Queries section for a description of how to query the CoveragePlan and FormularyDrug profiles in support of the anticipated use cases.

  • DrugPlan: Makes the DrugPlan identifier of each FormularyDrug accessible for query
  • DrugTier: Makes the DrugTier identifier of each FormularyDrug accessible for query

Expected Users

This Implementation Guide is intended for insurers within the United States. Currently, many insurers make their formularies available to patients using PDFs or drug search forms through their websites. Providing formularies using FHIR may allow patients to more easily comparison-shop between plans and could help insurers educate consumers about the differences between various drug tiers/classes.

Disclaimers and Assumptions

  • Drug Formulary includes Plan-Level Data Only: The intent of this implementation guide is to make the plan-level information regarding formulary content and cost-sharing available through a standard interface for third party applications. Most users will access this data through a third party application. That application should clearly communicate to the user that the cost-sharing information in the formulary may not tell them precisely what they will pay at the pharmacy, and might not reflect their drug benefit. There is an ongoing effort by Carin/NCPDP to develop a Real Time Pharmacy Benefit Check (RTPBC) implementation guide. Future ballots of this implementation guide and the RTPBC implementation guide should be harmonized.
  • The MedicationKnowledge Resource is immature: When designing this IG, we initially planned to profile Medication.  Based on a strong recommendation from the PharmaWG we shifted to profiling Medicationknowledge.   The PharmaWG felt that MedicationKnowledge was a better choice, even with its low maturity, since it is more suitable as an artifact and already included some of fields that would be required as extensions to medication (e.g., classification). MedicationKnowledge and FormularyDrug will co-evolve moving forward.
  • The formulary endpoint is known to the client: This IG assumes that the formulary endpoint is known to the client.  There is an overarching system architecture issue that is critical to resolve -- how does the client discover the FHIR endpoint of interest.   For the purposes of this IG, we consider that problem out of scope.