Stream: Da Vinci PDex Drug Formulary
Topic: Separate drug list resource
Eric Ellsworth (Jan 07 2020 at 20:36):
A formulary can be thought of as composed of two distinct sets of data.
1) the list of drugs that are covered, together with associated tier information.
2) the specific cost-sharing (copays, coinsurance, drug specific deductibles, maximum cost per fill, etc) that a consumer pays
Item 1 (the list) is currently contained in the FormularyDrugs list corresponding to a particular PlanID. In practice, however, that list is used across a wide range of plans (e.g. all of CareFirst's individual market plans in the DMV/DC area). The current structure requires that list to be repeated across plans. In current practice, the list is usually what is contained in the PDF document posted at link the FormularyURL field. Ideally, this list would have an identifier (with versioning), so various parties can reference this drug list independently of a particular plan
Item 2 is the cost-sharing for that particular plan. Cost-sharing usually works at the level of a plan or product line of plans. Thus there is less replication.
Eric Ellsworth (Jan 07 2020 at 20:58):
"Legacy" formularies (typically printable/PDF documents) that respond to the formulary URL.
Drugs are often listed by class, then alphabetically within a class. Many of these formularies use the convention of capitalizing and/or bolding brand names and putting generics in lowercase italics.
Here are some examples of "legacy" formularies from the ACA and other markets:
Kaiser - ACA/Indiv Colorado
https://healthy.kaiserpermanente.org/content/dam/kporg/mhc/drug-formulary1/co_marketplace_formulary_sec.pdf
No dose form or strength, no brand<->generic (presumably this means brand drugs are available only with exception/prior auth)
Includes tier numbers, no prices
Kaiser - HMO - Mid-Atlantic
https://healthy.kaiserpermanente.org/static/health/pdfs/formulary/mid/mid_hmo_formulary.pdf
No dose form or strength, no tier numbers (tiers may not exist)
Kaiser - FEHB (federal employees) - Denver
https://healthy.kaiserpermanente.org/content/dam/kporg/mhc/drug-formulary1/2020_FEHB_formulary_sec.pdf
No dose form or strength, no brand<-> generic
Includes tier numbers (and prices- probably an exception because the FEHB has only one(ish) plan due to the way the FEHB program works).
Bright Health Colorado - ACA/Indiv - Colorado
https://cdn1.brighthealthplan.com/docs/formulary/2020-co-ifp-formulary-en.pdf
Has dose form and strength
UPMC - ACA/Indiv - PA
https://embed.widencdn.net/pdf/plus/upmc/hd4gndmd4k/2019-advantage-choice-pharmacy-benefit-guide_web.pdf
Has does form but no strength
Includes tier numbers
Jose Costa Teixeira (Jan 07 2020 at 21:11):
A formulary can be thought of as composed of two distinct sets of data.
1) the list of drugs that are covered, together with associated tier information.
2) the specific cost-sharing (copays, coinsurance, drug specific deductibles, maximum cost per fill, etc) that a consumer paysItem 1 (the list) is currently contained in the FormularyDrugs list corresponding to a particular PlanID.
...
Item 2 is the cost-sharing for that particular plan.
I'm in another universe (EU) but just this seems very much "insurance-centric". Formularies have lots of information about the meds themselves, and their primary focus is/was supposedly clinical - about the composition and application of the drugs (posology, targets).
Not wanting to challenge your scope, because I know you have things like NCPDP formulary / benefits. Just just to make clear that in other places the formulary is about clinical first (hence the name Formulary).
Eric Ellsworth (Jan 07 2020 at 21:25):
Here's my proposal:
Make a "Formulary Drug List" object/resource that encapsulates whether drugs are covered, and what tier they are on. This most closely resembles the PDF formularies that are the current legacy standard.
This object/resource should have a global identifier that allows it to be publicly identified (similar to a plan's HIOS ID).
Drugs should be specified in a cascading way:
A
- By brand name (RXNORM TTY=BN)
-
By ingredient (TTY=IN/MIN), provided that this ingredient unambiguously defines a drug product
B -
By dose form group (TTY=SCDG, SBDG)
C -
By drug (TTY=SCD,GPCK,SBD,BPCK)
A query to the resource would then resolve any drugs specified as A or B into C. There could an exclusion mechanism to exclude some C's from the list derived from A or B. Drugs could also explicitly specified as C (this is the current standard for ACA/Medicare formulary data submissions).
The list should also handle the policy variants currently stated in the PDF formulary, e.g.:
Advantage Choice requires you to use a generic version of the drug if one is available. This means that if you receive a brand-name drug when a generic is available, you must pay the brand copayment in addition to the retail cost difference between the brand-name and generic forms of the drug.
Jose Costa Teixeira (Jan 07 2020 at 21:31):
again apologies for input where not requested. in the US you may have it easy and it is maybe possible to have this as a hierarchical structure. But in fact the formulary is a graph of concepts. A polyhierarchical structure. And you mention 4 levels of products, there are more levels than 4.
Lloyd McKenzie (Jan 08 2020 at 04:36):
Have you looked at using the List resource?
Eric Ellsworth (Jan 08 2020 at 14:50):
(deleted)
Eric Ellsworth (Jan 08 2020 at 14:52):
I'm in another universe (EU) but just this seems very much "insurance-centric". Formularies have lots of information about the meds themselves, and their primary focus is/was supposedly clinical - about the composition and application of the drugs (posology, targets).
Not wanting to challenge your scope, because I know you have things like NCPDP formulary / benefits. Just just to make clear that in other places the formulary is about clinical first (hence the name Formulary).
Good points. One thing we were discussing is that the term "formulary" itself is quite overloaded. Your feedback confirms this. I think we are trying to parse out some of the different meanings so we can figure out which resources are applicable for each. Can you elaborate on some of the uses of a formulary that go with the definitions you have mind?
Eric Ellsworth (Jan 08 2020 at 15:27):
Have you looked at using the List resource?
Thanks! I just looked through the collection resources, and a List does seem like it could fit. The idea of tracking changes is definitely valuable in this context.
Jose Costa Teixeira (Jan 08 2020 at 15:31):
Perhaps also good to discuss with the Catalog group. And Pharmacy. @Jean Duteau has been spammed with requests, I presume that we should be closer to having a solution.
Eric Ellsworth (Jan 08 2020 at 16:07):
Let's use this as an example of a "legacy" formulary
https://embed.widencdn.net/pdf/plus/upmc/hd4gndmd4k/2019-advantage-choice-pharmacy-benefit-guide_web.pdf
Eric Ellsworth (Jan 08 2020 at 16:09):
Perhaps also good to discuss with the Catalog group. And Pharmacy. Jean Duteau has been spammed with requests, I presume that we should be closer to having a solution.
Makes sense. Two comments.:
1) The Catalog concept you describe is really beyond what we're working on (now) for this resource
2) The RxNorm coding scheme includes the polyhierarchical relationships you describe. If there exists a need to expose some of these relationships via FHIR, it would be good raise that with Pharmacy
Jose Costa Teixeira (Jan 08 2020 at 16:13):
Catalog was made for polyhierarchical relations. I think MedicationKnowledge resource does not have the flexibility needed for that
Jose Costa Teixeira (Jan 08 2020 at 16:44):
here's a basic scope (just unidimensional). this gets more interesting when we start putting the supply chain dimension in place
(as in: some drugs come from different providers, so they may get different ERP logistic product codes... Some drugs are available in the pharmacy, others are on request, so they may get some different logistic IDs..)
Jose Costa Teixeira (Jan 08 2020 at 16:44):
Eric Ellsworth (Jan 08 2020 at 17:40):
here's a basic scope (just unidimensional). this gets more interesting when we start putting the supply chain dimension in place
(as in: some drugs come from different providers, so they may get different ERP logistic product codes... Some drugs are available in the pharmacy, others are on request, so they may get some different logistic IDs..)
I think this is out of scope of the definition of formulary we're working under. Wish I knew how to advise you where to go.
Jose Costa Teixeira (Jan 08 2020 at 17:43):
That is fine. I don't want to challenge your scope, just raise awareness that things in other places get tricky.
Jose Costa Teixeira (Jan 08 2020 at 17:45):
BTW that image is assuming one country. imagine if there were a federation of 27-1 countries all with their codes, their levels, their requirements.. I just wanted to say this is fun, pick from that what you need. I understand the needs in the US are focused (at least in the beginning) on the insurance stuff.
Eric Ellsworth (Jan 08 2020 at 18:04):
That is fine. I don't want to challenge your scope, just raise awareness that things in other places get tricky.
Thanks. I guess the question is whether there is overlap between the concept of a formulary you are working under and the one we are working under.
Eric Ellsworth (Jan 08 2020 at 20:00):
Here is an ERD for the proposed scheme FHIR-Drug-Formulary-ERD.png
Saul Kravitz (Jan 15 2020 at 15:03):
@Eric Ellsworth - your proposed scheme is not that different than the current IG. Remember the IG is an interface to data, not the way the data will be persisted in whatever database holds the data. So, I don't think some of the 'redundancies' that you point out are significant.
In general, much of the feedback in this thread would have been very useful last spring or during the ballot for STU1...now they will serve as fodder for the STU2 discussions, hopefully after there is some experience suffering from, er using, the STU1 which is about to be published.
Keep in mind that this IG is meant to be a consumer facing formulary that replaces the myriad of different PDFs and web sites that plans provide today. It is NOT meant to support e-prescribing or RTPBC, nor is it meant to replace/recapitulate RxNorm. I think the level of detail provided is appropriate for a consumer shopping for a drug plan, or trying to understand their plan's formulary. The alternatives was not intended to support clinical decision making, but rather to provide a way to link "obvious" alternatives -- e.g., generic alternatives to brand name drugs. In the few plan formularies that I found that included alternative information, this is how alternatives were used.
Last updated: Apr 12 2022 at 19:14 UTC
