Stream: Da+Vinci+PDex+Plan-Net
Topic: Payer Pharmacy Networks
Kate Dech (Jul 29 2020 at 22:52):
Has anyone else started implementing/modeling the pharmacy network directory using DaVinci Plan-Net yet? I am from a PBM Payer and I am struggling to figure out which specific resources we need. We have no experience with the Validated Healthcare Directory - maybe others aren't either. For Pharmacies I see a lot of repetition between Organization/Location/HealthcareService resources. Curious how other PBMs or Payers have mapped out their resources (of if you are interested in collaboration on this)? Does DaVinci have a concept like the CPCDS data mapping that may point us to the resources/data we must or could use? Thanks much!
@Bapi Behera , @Mona O , @Annette Kuball
Virendra Shinde (Jul 30 2020 at 19:41):
+1
Saul Kravitz (Aug 13 2020 at 04:00):
Take a look at the new examples in the build. Explanatory text to follow.
Kate Dech (Aug 14 2020 at 03:24):
@Saul Kravitz - Thanks for the update. I've taken a look and see a few gaps between what we do from the PBM payer side. One thing to call out is that we have distinct "sub-types" of the overall Pharmacy Network. This is directly tied to our contracts - retail, mail order, specialty (and even more specific networks within specialty for specific disease states - a hemophilia network, for example). A pharmacy may report that they are a specialty pharmacy but if they are not contracted for specialty on your plan, they would not be "in network" for that member for specialty.
Your examples have just a single pharmacy network and the organization affiliation are the "parent orgs" for individual pharmacies. PharmOrgA.
I had been looking at the OrganizationAffiliation as a possible container for these sub-network types - using the OrganizationAffiliation.specialty taxonomy codes to differentiate mail vs. retail vs. specialty vs. LTC, etc. (We also looked at using InsurancePlan.coverage.type and InsurancePlan.coverage.network to denote retail and its network, mail and its network, LTC and its network , etc. but it looks like only the InsurancePlan.network is a search parameter - not the network within coverage or plan.) So in a use case where a member wants to find the mail order pharmacies in network on their plan, we would connect the plan to the network to the org affiliations specifically for the Mail Order specialty.
Also when I look at elements of HealthcareServices and Locations, it seems like each individual pharmacy will need both - 1 per location. The location will specify the address, phone, geo coordinates, hours of operation. But healthcare services are really describing the services at a location...is there a drive up window, do they offer immunizations, do they support spanish language, is there an onsite clinic. These are elements found on HealthcareService, but they are inherent to the location. (Other than the language, these other services are elements that a pharmacy reports to NCPDP per location. I was anticipating using the .characteristics element to render all of these services that the pharmacy reports they have at this location.)
A couple of other gaps are the need to differentiate of a 30 day retail network and an extended supply retail network (where members can fill 90-100 days supply). We also have some preferred networks (preferred 30 day retail versus standard 30 day retail). These need to be structured elements that can be used for searching or filtering results. So we can't rely on the name saying one network is preferred or extended supply. Still need to find where we can manage these additional types of network indicators.
Look forward to chatting more and seeing where this goes!
@Bapi Behera , @Annette Kuball , @Mona O
Saul Kravitz (Aug 14 2020 at 22:16):
Hi @Kate Dech (@Robert Dieterle )
See our growing set of examples and associated drawings -- https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/representing.html and https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/patterns.pptx . I think we cover the case you describe. The different pharmacy offerings would be described by a healthcareservice with category=pharmacy, and a specialty from one of the NUCC codes describing specialty pharmacies. Our examples include Mail, Retail vs Compounding pharmacy, and that is how we recommend representing this type of information.
I'll let Bob (@Robert Dieterle ) comment on the healthcare service per location.
If there are additional common patterns that should be included in the examples to increase the chance that implementers choose a common (and thus searchable) way of representing the information, I'd love to add them to the IG.
Thanks for your feedback.
Kate Dech (Aug 17 2020 at 14:39):
Thanks Saul. This does help for sure. But I still have some concerns about the model and assumptions here. Compounding Services truly are a service offered by SOME pharmacies that are part of the contract retail pharmacy network. Therefore, we need to note that a) the pharmacy is in the retail network (PBM/Payer limitation) but they offer a compounding service (pharmacy reported addition). I think we would prefer to see these non-contracted definition elements represented within healthcareservice.characteristics. A pharmacy can report a number of services to NCPDP - separate from taxonomy - about their services (things like, delivery, drive up window, offer immunizations, DME, and compounding). If HealthcareService.specialty reflects the contract of what a pharmacy is allowed to do in your network, then something compounding shouldn't go there unless a payer has a distinct compound network contract.
Also - how do you reflect independent pharmacies? Does that one store become the OrganizationAffiliation, Organization, HealthcareService AND Location? 4 resources for one pharmacy?
Saul Kravitz (Aug 17 2020 at 18:35):
@Robert Dieterle @Gail Kocher
Hi Kate, My coauthors are better positioned to comment on the first question.
Re the second question: My understand is that indeed those four instances are required:
Organization: Information about Managing Company to enable search by name
HealthcareService: Supports general queries
Location: to support search by location, and have contact, accessibility, etc
OrganizationAffiliation: to connect associate the Organization, Location, and HEalthcareService with Network(s).
Robert McClure (Aug 17 2020 at 22:59):
@Kate Dech
A pharmacy can report a number of services to NCPDP - separate from taxonomy - about their services (things like, delivery, drive up window, offer immunizations, DME, and compounding)
Can you tell us what elements in SCRIPT carry this information? Or is it some other NCPDP standard? Are these codes or strings?
Gail Kocher (Aug 17 2020 at 23:35):
Compounding Pharmacies can be identified using the taxonomy code for "Compounding Pharmacy"
Kate Dech (Aug 18 2020 at 13:23):
@Gail Kocher If we use taxonomy as the limits of our contracting (our retail network, our specialty network), then we can't use taxonomy to reflect an additional service like compounding (because we do not contract a compounding network - they are part of our retail contract and they happen to offer compounding services). Again, I am approaching this from the perspective of the payer and wanting to refer a member to a in network pharmacy for these services...we need to clearly distinguish a contracted "specialty" network versus a pharmacy that reports they are a specialty pharmacy. So again if healthcareservices.specialty(taxonomy) is the only place we can denote what they are contracted for within a network, then we can not use it for the pharmacy reported taxonomy codes.
But @Robert McClure : to address your question. Yes, these are elements reported to and distributed by NCPDP as part of their dataQ product. My coworker @Annette Kuball is getting some additional info about this.
Annette Kuball (Aug 18 2020 at 14:19):
Good Morning Robert. @Robert McClure: I will try to give some details regarding the "Services" file we receive from NCPDP. @Kate Dech. First item to note: We receive Delta update files once per week. There is a monthly file - once per month, but we do not load this monthly. It's a huge file and we have the base data in our systems, so we only need to load the weekly updates. The Services file contains strings of data regarding individual pharmacies. |0101143Y02Y05Y09Y12Y16N19Y26Y29Y33Y35Y37N40| This is one record - first 7 characters are the Provider ID followed by indicator and code for each service reported by the pharmacy. Things like, delivery, drive up window, offer immunizations, DME, and compounding, etc. Codes are NCPDP Standard codes supplied in the Appendix of the layout format. Like Kate mentioned above: these are Pharmacy Reported Services, not services offered based on Contracts. Please let me know what other questions you have and I'll do my best at answering them.
Gail Kocher (Aug 18 2020 at 14:45):
@Kate Dech I am also a payer. The contracted specialty for a Pharmacy will be in OrganizationAffiliation. HealthcareService is about the kinds of services available. It just so happens that taxonomy codes are sued in both. You could convey this in HealthcareService.type, noting that there is no value for compounding pharmacy but the value set is extensible.
Kate Dech (Aug 18 2020 at 14:46):
@Gail Kocher - That aligns with what I would model. The orgAffil to the network defines the network rules. Great!!! Thank you!
Robert McClure (Aug 18 2020 at 14:53):
What I'm wondering, as the terminology guy, is what set of additional concepts would we like to see to represent the information you are getting from NCPDP? Sounds like (for pharmacy information at least) it would be useful if we could include the set of special pharmacy capabilities NCPDP can represent. @Margaret Weiker Can we discuss the logistics of this?
Kate Dech (Aug 18 2020 at 15:00):
@Robert McClure - We can share some ideas we had for mapping the NCPDP reported services (part of the dataQ files from NCPDP) within the healthcareservices.chararacteristic codeable concept. Pharmacy-Services-Attributes.xlsx
One worksheet shows the breakout of elements and its possible codes. (It looks like one large code system and smaller valuesets per element). The other worksheet was our atttempt to model/fit this into the healthcareservice.characteristic element - which looked like the one element that didn't have a required binding that we could use for this info.
Another idea would be to define a pharmacy profile of healthcareservice that would have named slices of characteristics for these codes to be mapped to.
Saul Kravitz (Aug 18 2020 at 18:28):
@Kate Dech Can you please send me a description/drawing that fleshes out this issue? I think the subtlety of when to use OrgAffil vs when to use HealthcareService is worthy of a clarifying example in the IG that I'd like to sort out with @Gail Kocher , @Robert Dieterle and @Robert McClure . Thanks.
Robert McClure (Aug 18 2020 at 20:05):
In our work of crafting specific terminology to support Plan Net, we did not discuss what information would be represented in HealthcareService.characteristic. In fact, that element is not changed from the base FHIR resource in our IG; and in the base and in Plan Net, the element is unbound (has no value set at all). So technically an implementation can put whatever they want in there but it would not be interoperable exchanged, it is not a Must Support, and therefore I assume there is no expectation of interoperable searching on this element. Certainly a specific implementation could add that in a particular system. Not sure what we need to do other than determine if @Kate Dech's use case warrants an interoperable approach. @Robert Dieterle @Saul Kravitz
Kate Dech (Aug 19 2020 at 22:24):
@Saul Kravitz Sorry for the delay in getting this example to you. This slide deck attempts to show how we could render pharmacy data the most efficiently and the plan-network data the most efficiently for the types of pharmacy contracts we may have. Pharmacy Networks are very large - 60,000 pharmacies so the number of resources this takes to represent has me concerned about performance and result size. OrgAffiliation-for-Pharmacy-Networks.pptx
Last updated: Apr 12 2022 at 19:14 UTC
