Stream: Da Vinci PDex Drug Formulary
Topic: Anticipated Client Queries
Bapi Behera (Jun 04 2020 at 21:48):
Reference : http://hl7.org/fhir/us/Davinci-drug-formulary/
The IG explains "This project defines a FHIR interface to a health insurer's drug formulary information for patients/consumers." The Question is, when considering the consumer, is the consumer an authenticated user (logged in to Insurance provider portal) or Unauthenticated user? was this considered in the IG?
Just wanted to see how the queries can be supposed based on user group.
We have 6 Anticipated Client Queries in the IG.
- Find All CoveragePlans
- Find CoveragePlan by its PlanID
- Find All FormularyDrugs in a CoveragePlan
- Find All FormularyDrugs in a Specific Tier of CoveragePlan
- Find A FormularyDrug by code in a CoveragePlan
- Find A FormularyDrug by code across all CoveragePlans
Thanks for your help.
Saul Kravitz (Jun 05 2020 at 14:18):
The data covered by the IG doesn't include any PHI/PII, so no access control is specified in the IG.
For certain applications, it might make sense to wrap a formulary server with authentication, but that is outside the scope of the IG.
All of the queries you list should be supported. I recommend you take a look at the reference client and server implementations. The client demonstrates the queries you are interested in. See https://confluence.hl7.org/display/FHIR/2020-05+DaVinci+PDex+Drug+Formulary
This should get you started with the client. https://davinci-pdex-formulary-client.logicahealth.org/?utf8=%E2%9C%93&server_url=https%3A%2F%2Fdavinci-drug-formulary-ri.logicahealth.org%2Ffhir&button=
Bapi Behera (Jun 10 2020 at 15:39):
Thanks Saul for the info
Bapi Behera (Jun 10 2020 at 15:45):
In the Query, GET [base]/List?_profile=http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-CoveragePlan&identifer=myPlanID
myPlanID - Will it support multiple myPlanID?
Jason Teeple (Jul 23 2020 at 15:58):
@Saul Kravitz How do we reconcile the CMS ruling against this IG if it is assumed no access control? The CMS regulations state that Formulary is part of the Patient Access API which is behind security.
Saul Kravitz (Jul 23 2020 at 19:20):
@Robert Dieterle
Hi Jason, The formulary IG is access-control agnostic. It doesn't specify that access control is required, nor say that it is forbidden.
Jason Teeple (Jul 23 2020 at 20:22):
Thanks @Saul Kravitz
So how are we suppose to reconcile against the CMS regulation that states formulary is part of the Patient Access API (which has access control)? Additionally, how would a 3rd party Developer find the List logical ID?\
Saul Kravitz (Jul 23 2020 at 21:06):
@Robert Dieterle
I don't understand the contradiction.
Formulary IG defines the API for querying (publishing) formulary information, and is silent about access control.
If an endpoint added access control and was in conformance with the Formulary IG...is there a problem?
Can you expand on the 'List Logical ID' question?
Jason Teeple (Jul 24 2020 at 19:02):
@Saul Kravitz The access control would be in the patient compartment. Outside of the access control question; In regards to List.ID, what would be the initial query into List (CoveragePlan)? How would the request know to send back relevant coveragePlan data for the requestor?
Saul Kravitz (Jul 24 2020 at 21:50):
@Robert Dieterle I think you are asking how does the formulary know which CoveragePlan to associate with a particular patient, right?
The formulary is completely patient agnostic. One can query all of the CoveragePlans -- https://davinci-pdex-formulary-client.logicahealth.org/coverageplans?utf8=%E2%9C%93&button=
If you know the ID, you can query a specific one. Linking a member to their plan is outside the scope of this IG.
Jason Teeple (Jul 27 2020 at 17:16):
If the IG is patient agnostic and the CMS regulation states that formulary is under Patient Access API, isn't there a disconnect between the two?
Last updated: Apr 12 2022 at 19:14 UTC
