Mapping vaccines to DRUG_EXPOSURE

[jaygee-on-github]

The IDSR Immediate Case-based Reporting Form used in the African Region does not actually capture they type of vaccine a person received:

This is consequential when it comes to COVID-19 because, in principle, it is necessary to know not just the number of doses but also the vaccine type in order to determine if a vaccinated COVID-19 IDSR case is either fully or partially vaccinated based on the number of vaccine does received and the date of last vaccination.

Under the circumstances, we considered a couple of strategies.

In the first strategy we just assume someone is fully vaccinated if they have received two or more doses even though certain vaccines like Janssen COVID-19 Vaccine (Johnson & Johnson) are "one-and-done".

In the second strategy it is possible to augment the IDSR with country-specific information provided by COVAX:

From the WHO Africa COVID-19 dashboard

Recall that COVAX had a hand in procuring and distributing COVID-19 vaccine doses across the African region. This dashboard includes both the COVAX procurements and the non-COVAX procurements.

In a proof-of-concept INSPIRE adopted the second strategy: we assigned a vaccine type probabilistically to each PERSON who received one or more vaccine doses. Note that in certain countries like Malawi the WHO CRF was amended to include the type of vaccine. This led us to think that in some countries we would and in other countries we wouldn't have to use the COVAX data during analysis.

With vaccine doses reported, using the IDSR and COVAX, INSPIRE created a synthetic source table that looked like this:

During the ETL each row in the source data was used to create a CDM DRUG_EXPOSURE record. Just like with the other tables in the OMOP CDM, a [domain]_concept_id needs to be provided. With a DRUG_EXPOSURE, this would be a drug_concept_id. It comes from one of the standard vocabularies hosted and managed by ATHENA. Here the drug_concept_id identifies the specific COVID-19 vaccine a person received. These concepts come from the standard vocabulary which is actually a set of specific vocabularies that include SNOMED-CT, LOINC, ICD-10, RxNorm and others. One of the "others" is CVX which hosts vaccine codes for vaccines approved for use in the United States as well as vaccines used internationally.

Also note that a DRUG_EXPOSURE also has a drug_type_concept_id which provides the provenance for this information is the Case Report Form.

[jaygee-on-github]

In the end we used CVX for most of the vaccines except for 3 where we used a non-standard vocabulary dm+d. See here.

We also encountered some issues uses CVX. @tathagatabhattacharjee, please comment on these issues.

[tathagatabhattacharjee]

Problem: Issue of lack of inbuilt hierarchy and drug strength in Athena for the CVX concepts.
drug_concept_id of the CVX concepts that were used for mapping vaccines did not have any ancestor_concept_id or descendant_concept_id and thus were not loaded into the concept_hierarchy table in the results schema when the OHDSI's standard SQL script was executed. As a result they were not shown on ATLAS.

Why: The CVX concepts did not have entries in the CONCEPT_ANCESTOR and DRUG_STRENGTH table when concepts were downloaded from Athena. The concepts were available in the CONCEPT table.

Solution: So, alternately, manual update was done in the DRUG_STRENGTH and CONCEPT_ANCESTOR tables to solve this issue.