Update IG DaVinci Payer Data Exchange (PDex) US Drug Formulary | STU2

[prb112]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Upon release of an official STU, the IBM FHIR Server should update the following IG:

DaVinci Payer Data Exchange (PDex) US Drug Formulary | STU2 release needs to be added to the IG

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Acceptance Criteria

1. GIVEN [a precondition]
   AND [another precondition]
   WHEN [test step]
   AND [test step]
   THEN [verification step]
   AND [verification step]

Additional context
Add any other context or screenshots about the feature request here.

[tbieste]

I see there is now a 2.0.0-ballot release of PDex (http://hl7.org/fhir/us/davinci-pdex/2022May/). Is that the version we want to include, or do we need the final 2.0.0 release?

[prb112]

best to wait until it's at http://hl7.org/fhir/us/davinci-pdex/STU2/

[lmsurpre]

from the readme in fhir-ig-pdex-formulary:

# Steps to update
1. download the npm package for whatever version of PDEX US Drug Formulary you want (and note what downloads we used from where in this file)
2. update `src/main/resources` with the latest conformance artifacts and `src/test/resources` with the latest examples
3. if its a new version
   - ensure references from the previous package are version-specific (e.g. to avoid a 1.0.1 profile from picking up a 1.1.0 valueset during validation)
   - add a new provider (`src/main/java` and `src/main/resources/META-INF`)
   - create tests for this new version (update ConstraintGeneratorTest and PlanNetResourceProviderTest)
4. execute ResourceProcessor from src/test/java with the proper arguments
5. execute SearchParameterAugmenter from src/test/java with the proper arguments

package is at https://hl7.org/fhir/us/davinci-drug-formulary/package.tgz

[lmsurpre]

I POSTed each of the Formulary STU2 samples to a server with our IG installed and the only peculiarity I noticed is that a number of the ValueSets could not be expanded.

This shows up as a validation warning with code "incomplete" and details text like "Membership check was not performed: value set [X] is empty or could not be expanded".

• http://hl7.org/fhir/ValueSet/jurisdiction (GraphDefinition.jurisdiction)
• http://hl7.org/fhir/us/davinci-pdex-plan-net/ValueSet/InsuranceProductTypeVS|2.0.0 (InsurancePlan.type)
• http://hl7.org/fhir/us/davinci-drug-formulary/ValueSet/SemanticDrugVS|2.0.0 (MedicationKnowledge.code.coding)
• http://hl7.org/fhir/us/davinci-drug-formulary/ValueSet/SemanticDrugFormGroupVS|2.0.0 (MedicationKnowledge.code.coding)

Sometimes these valuesets reference data we cannot include in our open source project, so there may or may not be much we can do about that.
I'll open a separate issue to investigate it.

[lmsurpre]

update: the two "SemanticDrug" ones are composed from system http://www.nlm.nih.gov/research/umls/rxnorm which we do not ship by default

the http://hl7.org/fhir/us/davinci-pdex-plan-net/ValueSet/InsuranceProductTypeVS|2.0.0 one is a little trickier. this valueset actually comes from a different IG (pdex-plannet).

I think we added the version suffix in error thinking it was part of this IG.

Based on the packaged ImplementationGuide resource, it should probably refer to version 1.0.0 of that valueset instead:
{
"id": "hl7_fhir_us_davinci_pdex_plan_net",
"uri": "http://hl7.org/fhir/us/davinci-pdex-plan-net/ImplementationGuide/hl7.fhir.us.davinci-pdex-plan-net",
"packageId": "hl7.fhir.us.davinci-pdex-plan-net",
"version": "1.0.0"
},
Re-opening for @PrasannaHegde1 to address.

[lmsurpre]

I found a spec bug, opened https://jira.hl7.org/browse/FHIR-39401 for it, and created a pull request to address this and the previous comment.

[lmsurpre]

After the fixes, I confirm that I can now search usdf-FormularyDrug (MedicationKnowledge) by code.
Additionally, I confirmed that the system is looking.

In the future we could consider either:
A. explicitly marking formulary as dependent on plant-net; or
B. copying that valueset directly into the formulary ig since I think that is the only dependency on plan-net

However, I think this is good for now.