DaVinci Payer Data Exchange (PDex) US Drug Formulary | STU2 Ballot
1.2.0 - STU2 Ballot
DaVinci Payer Data Exchange (PDex) US Drug Formulary | STU2 Ballot
1.2.0 - STU2 Ballot
This page is part of the US Drug Formulary (v1.2.0: STU 2 Ballot 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 
This use case allows a member to determine the plan level estimated costs of each of their medications under the drug coverage of their current health plan. An application queries the formulary service for cost information about the drugs that the member has interest in and provides the plan level estimated cost for each medication under the member’s current health plan.
Note that for this use case the health plan would provide authenticated access to the formulary.
This use case allows a consumer to compare the drug coverage of several different health plans and determine which plan has the lowest plan level estimated cost based on their medications of interest. The application can retrieve the consumer’s medication list from an electronic health record system where the consumer’s patient data is stored (outside the scope of this implementation guide). The consumer could also independently maintain their medication list in the application or elsewhere. The application identifies the relevant formulary endpoint through means that are beyond the scope of this implementation guide (see Disclaimers and Assumptions). For each payer, the application queries the payer’s formulary service to retrieve the list of health plans provided by that payer. Then, for each plan,the application queries the formulary service to retrieve the plan-level estimated costs specific to the consumer’s medication list.
Note that for this use case the health plan could provide non-authenticated or open access to the formulary. Non-authenticated access should not maintain any records that could associate an individual with the medications or plans queried.
The formulary service can potentially be accessed two different ways:</p>
When accessing data through an authenticated API, the response for queries on InsurancePlan depends on whether the authenticated member is currently enrolled in a plan and whether they are a member of a group. The following table indicates how the Formulary API should respond to requests when an Insurance plan is specified and when it is not.
| Situation | InsurancePlan specified | InsurancePlan not specified |
|---|---|---|
| No plan available | Zero plans returned (200) | Zero plans returned (200) |
| No plan selected/no group | Zero plans returned (200) | Bundle of available individual InsurancePlans |
| No plan selected/in group | Zero plans returned (200) | Bundle of available group InsurancePlans |
| Plan selected/no group | If InsurancePlan specified matches member's plan, return InsurancePlan, otherwise zero plans returned | Zero plans returned (200) |
| Plan selected/in group | If InsurancePlan specified matches member's plan, return InsurancePlan, otherwise zero plans returned | Bundle of available group InsurancePlans. If no plans available, zero plans returned |
When accessing data through an unauthenticated API, the conformant payer formulary service SHALL NOT require an application to send consumer identifying information in order to query for the list of health plans provided by that payer and the medication and costs for each plan.
Formularies in the United States are normally published by health insurers on an annual basis, with minor updates during the year. It is critical that health insurers update their published formularies following these minor updates.
Insurers regularly administer multiple health insurance and drug coverage plans and each of those plans may have its own formulary.
Each formulary contains a set of drugs and their limits or requirements. Drugs are placed into tiers that largely determine the cost to the consumer/patient. The number and purpose of drug tiers varies across payers. Each tier has an associated cost-sharing model that includes deductibles and/or coinsurance components for drugs in the tier when purchased through various pharmacy types.
In addition to the drug tier, drugs may also list requirements on the patient (e.g., age or gender) or limitations on prescription (e.g., quantity limits).
This Implementation Guide (IG) was significantly influenced by the formulary information model of the formularies for Qualified Health Plans (QHPs) on the federal health insurance marketplace for healthcare.gov. Publishing formularies in the QHP format should be familiar to many payers. Drugs are specified by RxNorm semantic drug codes. The QHP data model mandates specific value sets for some data types (e.g., types of copayments), but leaves value sets for other data types at the discretion of the payer (e.g., drug tier codes, pharmacy network types). The following object model shows the relationships between the resources in this IG. The Formulary profiled resource combined with its associated FormularyItem and FormularyDrug profiled resources represent a formulary list that includes the set of drugs covered and the requirements and limitations of that coverage.
A FormularyDrug represents the individual prescribable drug defined with a specific RxNorm semantic drug code that includes ingredient, strength, dose form, and brand name for branded drugs. These codes are represented in RxNorm with the Term Type (TTY) of Semantic Clinical Drug (SCD), Semantic Branded Drug (SBD), Generic Pack (GPCK), or Branded Pack (BPCK). Additionally, a more general RxNorm semantic drug form group code SHOULD be present for searching across drugs with the same ingredient, brand, and form (regardless of strength). These codes are represented in RxNorm with the Term Type (TTY) of Semantic Clinical Drug Form (SCDG) and Semantic Branded Drug Form Group (SBDG). All drugs with RxNorm Term Type of SCD or SBD SHALL have a coding repetition and RxNorm Term Type of SCDG or SBDG respectively. Drug packs, represented by RxNorm codes GPCK or BPCK may not have a corresponding drug form group. The FormularyItem links a drug with a formulary and includes the attributes that drug has in relation to the formulary, including the drug tier and coverage constraints.
Cost sharing information such as copay amounts and coinsurance rates are determined by a payer in the insurance plan. The amount of copay and percentage of coinsurance is a function of the pharmacy network type (e.g. in network mail order) and the drug tier (e.g. preferred generic). These specific costs are defined in the PayerInsurancePlan . The pharmacy network types and drug tiers, without the cost information, may optionally be included in the Formulary as a convenience for client applications to quickly identify the pharmacy network types and drug tiers contained on the formulary without having to retrieve the PayerInsurancePlan.
The costs for a particular drug in a plan will be determined by the pharmacy network types and drug tier as indicated in the properties of the FormularyItem. These properties are used to link the PayerInsurancePlan specificCost properties (Pharmacy Network Type - InsurancePlan.plan.specificCost.category and Drug Tier - InsurancePlan.plan.specificCost.benefit.type) to identify the costs for the drug under the plan.
Searching for formulary drugs can be done by RxNorm code, RxNorm drug name, and dose form. In a formulary API, payers are likely to only include the specific drugs, specific down to form and strength, that are included in the coverage. If a search does not return the anticipated or desireable results, it is recommended that the client broaden the search (e.g. include both generic and brand RxNorm codes, search on name without strength, or search on an RxNorm code that does not include strength - see more guidance about supported RxNorm code term types below). Additionally, drugs that have special coverage rules may or may not be included in an API. These rules are often expressed in additional formulary documentation, referenced by the InsurancePlan.contact, which SHOULD be presented to the user of the client application.
Formulary searches may be restricted to just the drugs supported by the payer therefore it is up to the user or calling application to convert patient searching requirements for branded or equivalent drugs into one or more formulary searches.
Covered drugs may appear in the formulary and non-covered drugs are simply not included. For example, a payer may pay for a generic form of a drug, but does not have a brand in their formulary. To retrieve matching drugs and available alternatives, it may be necessary for a client to search using the ingredient (generic) in addition to a brand.
The preferred way to search for drugs is to use an RxNorm code (RxCUI). The RxNorm codes and names are freely available and services to look-up codes exist. If a client application is performing a query with the intent on finding generic or brand alternatives, the client application SHOULD search using both the brand and the generic RxNorm code.
Servers SHALL support a MedicationKnowledge.code.coding repetition including the detailed drug, strength, and form, including RxNorm Term Types (TTY) of SCD (Semantic Clinical Drug), SBD Semantic Branded Drug), GPCK (Generic Pack), or BPCK (Branded Pack). Additionally, servers SHALL support a MedicationKnowledge.code.coding repetition including the general RxNorm code (and name) with Term Type of SCDG (Semantic Clinical Drug Form Group) or SBDG (Semantic Branded Drug Form Group) when there is a concept matching the primary code represented by the Term Type SCD or SBD respectively. This requirement includes using the respective RxNorm name in the display of the coding repetition.
Searches for drugs with the above RxNorm Term Types (SCDG and SBDG) by either code will provide the client with a way to search for drugs without a specified strength.
This Implementation Guide provides the ability to search for FormularyDrug (MedicationKnowledge) resources by drug name through the drug-name search parameter. This search parameter is based on the MedicationKnowledge.code.coding.display and provides a full (exact) or partial (contains) equals (eq) string match. Per the FHIR Specification, the Correct RxNorm Display is the Full RxNorm name of either the Semantic Clinical Drug (SCD) or Semantic Brand Drug (SBD). The full drug name has several components presented in the following formats:
In addition to these RxNorm names, drug combination packs may also appear in formularies. Drug combination packs can contain multiple drugs or strengths that are packaged and prescribed together, under a brand or generic drug name, to meet a particular set of administration requirements. The full name for drug combination packs have components presented in the following formats:
Servers are required to support the more general drug form group code and name where one exists. This display name will be included in any drug name search for which the general drug form group code exists. The RxNorm name of these codes has several components presented in the following formats:
The drug-name SearchParameter includes the multipleAnd capability, which allows for multiple drug-name search parameters within a single query. With this capability it is possible to search by drug name and form where a dose form group is not available. This capability should be used sparingly, as each additional partial string search parameter increases the load on the server.
For Example:
MedicationKnowledge?drug-name:contains=acetaminophen&drug-name:contains=Tablet
This search will return all matching drug names with both the ingredient “acetaminophen” and dose form “Tablet”. This will also return any matching combination or pack drugs.
Another factor clients need to consider when searching for drugs by name, is that individual drug names may be contained within combination drugs (e.g., a search on acetaminophen will return many combination drugs). Clients may need to filter search results to fit their requirements.
Finding appropriate alternatives of a prescribed medication is complex and often depends on additional clinical information about the patient well as the condition or set of conditions for which the medication is meant to address. The information and business rules necessary to identify possible therapeutic alternatives, and therefore the ability to search for such alternatives, lies outside of the scope of this guide.
Drug tiers are not standardized. The current Implementation Guide provides a defined, but extensible value set for tier identifiers based on the example list in the QHP formulary specification. A move towards standardization might make this data more useful for clients of the interface.
Pharmacy types are not standardized. The current Implementation Guide provides a defined value set for tier identifiers based on the example list in the QHP formulary specification which mixes channels (retail and mail order) with quantity prescribed (1 month, 3 month, etc). A move towards standardization might make this data more useful for clients of the interface.
IG © 2021+ HL7 Pharmacy Working Group. Package hl7.fhir.us.davinci-drug-formulary#1.2.0 based on FHIR 4.0.1. Generated 2021-12-03
Links: Table of Contents |
QA Report
| Version History |
Search |
|
Propose a change