2021-04-23 PDex Meeting

Da Vinci Implementer Support Page

Implementers can take advantage of tools: See the Reference links on the Payer Data Exchange (PDex) page to access links for Reference Implementations, sandboxes, test scripts, and more!

Da Vinci PDex for Patient Access API Frequently Asked Questions (FAQs)

CMS Final Rule Questions and Answers log

NEW link: ONC FAST National Healthcare Directory (including end points) solution page that includes links to everything (solution doc, Connectathon, HL7 workgroup, etc.): https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/National+Healthcare+Directory

Call to All Implementers: We learn as a community and iterate on the IGs through real world experience, so your contributions are welcome! Please come with your questions. Options:

1) Send them to us on Zulip: 

• PDex: https://chat.fhir.org/#narrow/stream/235286-Da-Vinci.20PDex - may be updated. Mark Scrimshire
• Formulary:  https://chat.fhir.org/#narrow/stream/197730-Da-Vinci.20PDex.20Drug.20Formulary
• Plan Net/ Directory: https://chat.fhir.org/#narrow/stream/229922-Da.2BVinci.2BPDex.2BPlan-Net
• tag Vanessa Candelorato make sure they get to this agenda if not answered. 

2) Ask questions live on the call

3) Edit and add your question to this page (in this box under "Question")

See page: Da Vinci PDex for Patient Access API Frequently Asked Questions (FAQs)

Plan Net FAQ Review Sean Mahoney

Corey to review the list of tickets for STU Update to the IG

Reviewed the plan for FHIR-29965, FHIR030925, FHIR-28293 - will provide guidance. Proposed: Remove this HOIS, ID needs to be unique with respect to the end point of the client.  End Point = "The thing the API is calling" in the way it's written, it's the patient access API.  Don't want to say that the ID needs to be unique across the

• ID needs to uniquely Identify a formulary.  What about orgs that have a single end point across multiple lines of business. They will do their own  
• Plan ID has one plan to one formulary.  Each Plan ID should have a unique ID for each formulary that is supported. 
• Separate the HIOS ID, and say in general, the Plan ID should be unique
• We cannot say one plan ID would have one formulary.... this id difficult due to active plans, different years.  For HIOS, we can have one, for others it's hard. 
• IG doesn't look at history. 
• back to this issue here:
  • I'm a patient, I have a drug plan, I want my formulary. 
  • I'm not enrolled in a drug plan, I want to see what formularies are available. 

Plan ID has to be unique within the provider of those formulary(s).  If contracted out to the PBM. and they are doing this for 1000 health plans, there is a unique id for each plans and each customers.  HOIS Id doesn't cover everyone.  

• HOIS was a good place to start. 

App Developer is going to payers patient access API end points, then given permission by the patient with their drug plan.  I already know I have a unique plan. 

Can we stay in bounds to sub out "Hois ID" with a "generally need an ID"

Corey Spears- will propose some language options.

Learned that examples of items on Formulary that don't have RxNorm codes could be disposable DME supplies (e.g., test scripts)

• The CMS Patient Access API Rule does not require DME or "supplies" to be included in Formulary.  Intent: Formulary in the context of the rule was only envisioned to cover drugs.

  • See rule: paragraph 422.119 Accessible Content 2ii.
  • Formulary is only required for Part D. 

• Acknowledging that it is in the workflow for certain PBMs, consumable DME is out of scope for this IG. 

• Focus on MedicationKnowledge, not disposable DME (test scripts, etc.)
• Delay between on formulary and having an RxNorm code is small and manageable.
• see discussion here: https://chat.fhir.org/#narrow/stream/197730-Da-Vinci.20PDex.20Drug.20Formulary/topic/NDC.2C.20RXCUI.20and.20RXNorm 
• RM is proposed, If we need it, we could do something like RxNorm if you have it. If not, use a subset of SNOMED.  BD - this wouldn't help. 
• Risks: 
  • If we stick with RxNorm, we could get wrong codes
  • Extensible beyond RxNorm - opens the door, allows for other possible items on Formulary. 
• Value of Formulary refresher (e.g. cost of drug, Prior Auth requirements, pre-reqs.) - does the industry need that for non-drug items?  
• Could, in the future, have other formularies for DME, Test scripts, etc.  but some would expect that to be outside of this IG. Other option would be in a future version of this IG.  Would need a different profile beyond MedicationKnowledge.
• In summary, this IG supports Drug Formulary, that would have RxNorm codes. 
• Next Step: leave as is, consider for STU2 or future items.  

Adjourned at 12:57pm EST.

Source PowerPoint: PDEXandUSCoreRelationship.pptx

Source code is here: https://github.com/HL7/davinci-epdx

• Other Spreadsheets used to support tables in PDEX IG:

• PDEX-USCore3-1-1-2020-10-20-v5.xlsx
• PDEX-Plannet-formulary-2020-10-20-v3.xlsx
• Observation-FHIR_R4 v1.4.xlsx

HL7 FM PDEX What to Review 2020-10-20-v1.pptx