From: Corey A Spears Date: Wednesday, June 30, 2021 at 10:18 AM To: "jean@duteaudesign.com" Cc: "jnhatem@hotmail.com" , Dave Hill Subject: Re: Da Vinci Formulary IG - Query for resources in scope of IG Greetings Jean, We had a discussion this week at the Pharmacy WG about a couple of tracker items for the Da Vinci PDex Formulary IG that John thought we should ask your thoughts on. FHIR-31683 – Can't query Lists that are CoveragePlan Profiles FHIR-31684 – Can't query MedicationKnowledge instances that are FormularyDrugs Both of these are somewhat similar from a general perspective, but differ somewhat as they relate to the use case and perhaps how they might be address. At a high level, we have the CoveragePlan (profile on List) and Formulary Drug (profile on MedicationKnowledge). It is possible that a FHIR server may support more than our formulary IG and there could be List and MedicationKnowledge resources that are meant for other purposes. Clients need to be able to query for resources that are addressing the needs of this IG. Currently the IG proposes using the meta.profile (_profile search parameter) to be able to query matching resources. Noting that meta.profile is not required in this IG and that it has been noted that using meta.profile is not a recommended practice for retrieving a “type” of something, we are looking for a different way to address the need. Da Vinci has not yet determined how important 31684 is to the use case, so we will be consider it further for the next ballot. 31683 is a more immediate concern. For STU2, since List is turning out to not be a great fit for the IG, we will be looking at InsurancePlan or possibly cataloging capability O&O is working on with the Composition resource. In the mean time we should find an answer for the STU Update. The List resource has a code element defined as “This code defines the purpose of the list - why it was created.”. This seems like a good fit. Upon discussion in the PDex meeting, someone suggested a possible code of DRUGPOL from the http://terminology.hl7.org/CodeSystem/v3-ActCode CodeSystem. Any thoughts on this approach? 31684 looks to be a bit more complicated, but we have not even determined if it truly is necessary. As part of the Patient Access API, the client will have the PlanId and can query the MedicationKnowledge with the extension that includes PlanID. For the shopping experience, this would only be relevant for a client system that does not know a PlanID, but only wants resources associated with a formulary. This could possibly already be handled in a couple of ways: 1. The PlanID extension is required in the profile, so one could query MedicationKnowledge?PlanID:missing=false (assuming the server supports it) 2. Retrieve all of the PlanIDs by querying the CoveragePlan (List profile) then query MedicationKnowledge with the retrieved PlanIDs. (This becomes easier if we address 31683) Assuming we actually find a business need for this requirement, do you feel one of the above options is sufficint, or should there be another means we should consider? Thanks for your time and consideration. BTW, Jean, your email address in the HL7 Global Membership directory seems to be an old address. -- Corey Spears Health Technology, Principal L223 - Open Health Services 917-426-7397 MITRE | Solving Problems for a Safer World™