DaVinci Payer Data Exchange (PDex) US Drug Formulary
2.1.0 - STU 3 (ci-build)
DaVinci Payer Data Exchange (PDex) US Drug Formulary
2.1.0 - STU 3 (ci-build)
DaVinci Payer Data Exchange (PDex) US Drug Formulary, published by HL7 International / Pharmacy. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-pdex-formulary/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
The formulary service can potentially be accessed two different ways:
When accessing data through an authenticated API, the response for queries on InsurancePlan depends on whether the authenticated member has access to the plan in relation to their membership.
Clients can determine the Formulary InsurancePlan(s) that the member is subscribed by first retrieving the Payer Insurance Plan(s) and identifying the Formulary(s) through the Payer Insurance Plan InsurancePlan.coverage.
The following table indicates how the Formulary API should respond to requests when a Formulary Insurance plan (by resource reference) is specified and when it is not.
| InsurancePlan specified – GET by resource ID | InsurancePlan reference not specified - Search |
|---|---|
| Return plan if covered by insurer and included in group if member is part of a group If not, return 400 |
Return all plans if covered by insurer and included in group if member is part of a group If none, return 200 |
Access to other profiled resources in this IG (FormularyItem & FormularyDrug) is not constrained by this IG.
Server implementers SHALL make other profiled resources in this IG (FormularyItem, FormularyDrug) associated to a member’s available plans available through authenticated access. This IG does not define restrictions on authenticated access to resources not associated with a member’s available plan or the Plan Location resource.
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.
Bulk data guidance in this version of the IG is draft only. It has not appeared in ballot and has not been fully tested.</i></b>
A server MAY support Bulk Data IG for the retrieval of formulary data not related to an individual. The Bulk Data IG may be used because the data set for formularies could be large as a server may manage multiple formularies, each of which may contain thousands of drugs. If and how authorization is supported is not defined by this specification, however, the Bulk IG does provide guidance on SMART Backend Service Authorization.
If a Formulary server supports bulk data export:
[base]/InsurancePlan/$export to export all plan & formulary information.
InsurancePlan, Basic, MedicationKnowledge, and Location resource types containing formulary related data associated with all formulary related plans.[base]/InsurancePlan/$export?graph=usdf-PayerInsurancePlanBulkDataGraphDefinition) to request returning results starting at the PayerInsurancePlan.[base]/InsurancePlan/$export?graph=usdf-FormularyBulkDataGraphDefinition) to request returning results starting at the Formulary. This request would not return PayerInsurancePlan resources.[base]/InsurancePlan/[id]/$export to export plan specific plan & formulary information.
InsurancePlan, Basic, MedicationKnowledge, and Location resource types containing formulary related data associated with the specific plan.This guide provides a mechanism for rudimentary drug searching and filtering based on drug codes, names, and forms, by requiring server systems to support this data. This capability is not robust and client systems are encouraged to augment their drug searching capabilities using outside services or data sources to better meet the needs of their users.
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.
Note: In addition to the guidance and requirements below regarding searching for drugs based on an RxNorm code or display, servers may wish to support additional coding systems and display values in order to represent specific drugs that may have the same RxNorm code, but have different coverage specifics as defined in the Specific Drug Coverage Details section. This may result in more than one FormularyDrug with the same RxNorm code and display value.
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.
Specific Drug Coverage Details
RxNorm codes and descriptions were chosen as the mechanism for searching and describing covered drugs for consumer use because that is what consumers will generally have access to given the requirements laid out in US regulation. RxNorm is also the code system used for many outpatient pharmacy prescribing transactions.
RxNorm provides a consumer accessible categorization for prescribable drugs. This categorization may not be specific enough for payers that have very detailed coverage constraints they feel are necessary to express to their members.
This IG Provides the following ways to express various levels of coverage (coverage status, requirements, or costs) for multiple drugs represented under one RxNorm code.
Specific drugs identified by unique FormularyDrug resource instances that are associated to a Formulary with specific coverage conditions, requirements, and costs through a FormularyItem. A specific drug code using NDC or other code system is included as a FormularyDrug MedicationKnowledge.code.coding that includes the specific name in the display to enable searching. Drugs identified by a general RxNorm code in a single FormularyDrug MedicationKnowledge resource with specific coverage conditions and requirements communicated in the referenced FormularyItem. Specific details including drugs covered or not covered, coverage conditions, or requirements are specified in the FormularyItem Basic.extensions[usdf-AdditionalCoverageInformation-extension].
To the Searching Formulary Drugs section, at the bottom of the main section add:
Note: In addition to the guidance and requirements below regarding searching for drugs based on an RxNorm code or display, servers may wish to support additional coding systems and display values in order to represent specific drugs that may have the same RxNorm code, but have different coverage specifics as defined in Specific Drug Coverage Details. This may result in more than one FormularyDrug with the same RxNorm code and display value.
RxNorm codes and descriptions were chosen as the mechanism for searching and describing covered drugs for consumer use because that is what consumers will generally have access to given the requirements laid out in US regulation. RxNorm is also the code system used for many outpatient pharmacy prescribing transactions.
RxNorm provides a consumer accessible categorization for prescribable drugs. This categorization may not be specific enough for payers that have very detailed coverage constraints they feel are necessary to express to their members.
This IG Provides the following ways to express various levels of coverage (coverage status, requirements, or costs) for multiple drugs represented under one RxNorm code.
Version 2.1.0 of this IG added the Insurance Plan Coverage profile for linking a patient's coverage to specific drug plans in a Payer Insurance Plan.
First, the Payer Insurance Plan profile added a new constraint under Coverage making InsurancePlan.plan:drug-plan.identifier must-support, providing an identifier to link to inside the InsurancePlan resource which may include multiple actual plans (later versions of FHIR have a new resource called InsuranceProduct, which addresses this confusions (a given product may have multiple plans).
The new Coverage profile extends the US Core Coverage profile and adds two cross-version extensions to enable features of Converage not available in FHIR R4, specifically a reference to an InsurancePlan resource that contains the specific drug plan in question, as well as adding an identifier extension under Coverage.class:plan to reference InsurancePlan.plan:drug-plan.identifier, since in FHIR R4 Coverage.class only allows a string to identify the actual plan.
This solution may require multiple Coverage resources on a given FHIR server even though in the real world there may be a single plan that covers all situations, one for drug coverages and another for everything else, and that the current solution will be revisited for FHIR R6.
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 means to identify therapeutic alternatives to drugs does exist in the industry, but such capability is complex, requires clinical information about the patient that is not within in scope of this guide, and a clinical understanding of the intended therapeutic use of the medication which is not generally within the competency of most members. The information and business rules necessary to identify possible therapeutic alternatives, and therefore the ability to search for such alternatives, currently 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 benefit 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 © 2022+ HL7 International / Pharmacy. Package hl7.fhir.us.davinci-drug-formulary#2.1.0 based on FHIR 4.0.1. Generated 2024-12-16
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change