FHIR Chat · PGx Medication Impact · genomics / eMerge Pilot

Stream: genomics / eMerge Pilot

Topic: PGx Medication Impact

Larry Babb (Mar 05 2019 at 21:29):

There are 3 Medication Impact profiles

• Medication Metabolism Impact Assertion of the expected impact of a particular genotype on the ability of the subject to metabolize medications
• Medication Transporter Impact Assertion of the expected impact of a particular genotype on the ability of the subject to actively transport medications
• Medication Efficacy Impact Assertion of the expected impact of a particular genotype on the efficacy of medications for the subject

The CPIC guidelines show various alternative value sets for some of these, for example

CYP2C19 metabolizer values

• Intermediate Metabolizer
• Likely Intermediate Metabolizer
• Likely Poor Metabolizer
• Poor Metabolizer
• Rapid Metabolizer
• Ultrarapid Metabolizer
• Normal Metabolizer
• Indeterminate

IFNL3 values

• Favorable response genotype
• Unfavorable response genotype

SLCO1B1 Function

• Decreased Function
• Normal Function
• Poor Function
• Possible Decreased Function
• Possible Increased Function
• Possible Poor Function
• Indeterminate

and the list may go on. these are just a few of the ones I have to work with.

Question:
How does the IG support the fact that folks will need to deal with value set bindings that cannot be restricted to the 3 sets provided so far?

Kevin Power (Mar 06 2019 at 00:08):

I have some ideas (and some possible pending changes) - but where did you get those values from? I have this link that we have used to help inform us to date?

https://www.nature.com/articles/gim201687/tables/2
https://www.nature.com/articles/gim201687/

Larry Babb (Mar 06 2019 at 12:27):

The headers of each value set section in my original post is a link to the source where I got them. These all came from CPIC's website for the specific Diplotype-Phenotype tables in the supplemental tables for each gene's drug guidelines. There's dozens of these at least, I only took a small sampling. The one oddball is the IFNL3 guideline (Favorable/Unvaforable Response) which comes directly from the guidelines primary publication - no standardized table was available, so labs presumably use the literature's table to annotate their interpreted findings when reporting.

At least from Baylor's standpoint they seem to use the terminology that is straight out of the guideline literature - not so much the more formalized values that CPIC presumably standardized in the tables used to map the diplotype-phenotype info.

Kevin Power (Mar 06 2019 at 15:02):

I think the guidance would be for data producers to send a code from the standardized list, but also allow for additional values to be sent. Those additional values should be real codes where possible, but if no codes exist, send what you can. And if we have profiles that are overly restrictive and don't allow that, then we should look at loosening them a bit.

Bret H (Mar 06 2019 at 15:16):

@Larry Babb can you note which element you are talking about the value set for? (for general audience it can be helpful).
A problem with all those value sets is that they are not related to an actual quantifiable level of activity. Tell me the difference between Poor function and Poor Metabolizer? Why not use activity: poor for the code with an additional text display of 'Poor Function' or 'Poor Metabolizer?' The code is more restrictive but you can add a display meant for human consumption.

@Larry Babb are there actual groups using the codes above for calculating or are they only used for display?

Larry Babb (Mar 06 2019 at 16:06):

@Bret H these are qualified codes, not quantifiable results as are many of the interpreted results returned in genomic analysis reports (e.g. Path, LPath, VUS, etc..). The CPIC organization is defining these terms and I am not a domain expert by any measure, so I would defer to them.

I reached out to CPIC with the following email this morning ...background...

On Wed, Mar 6, 2019 at 8:21 AM Larry Babb <lbabb@broadinstitute.org> wrote:
I am working with HL7 FHIR and GA4GH GKS (genomic knowledge standards) to help progress the standards behind reporting clinical genetic test results which include PGx test results. I was indirectly involved in the Delphi process some time ago referenced by this page https://cpicpgx.org/resources/term-standardization/.

When I look at the diplotype-phenotype tables for the various CPIC genes, I see terms that are outside the scope of the Delphi results.

So I was wondering if there is any commitment, plan or strong expectation of formalizing all CPIC diplotype-phenotype terminology with these Delphi results?

Essentially, I'm looking for a statement of certainty or uncertainty as to whether the standards organizations like HL7 and GA4GH should realistically work with the phenotype terms found throughout the diplotype-phenotype tables or should we presume these will all map to a future standard that is in the works and soon to appear?

Thank you for any information and guidance you can provide.

--
Larry Babb

... and received a reply back from Mary Relling, which I am now waiting on follow up...

On Wed, Mar 6, 2019 at 9:13 AM Relling, Mary <Mary.Relling@stjude.org> wrote:
Hi, Larry, thanks for reaching out.

Yes, we are aware that for some genes, the terms are outside of the agreed upon standardized terms. (We did acknowledge in our paper that some genes we had not yet addressed, such as VKORC1; since then a few others like RYR1 have come up).

Also, we are aware that “possible” has been added as a modifier.

As part of the CPIC database build, we do plan to try to harmonize as many terms as possible for these “outlier” genes. We were hoping to do this without a formal Delphi process but I don’t’ think we are positive about that. I don’t think we yet know for sure, but if I had to guess, we may have to allow for gene-specific phenotype terms (e.g aminoglycoside otoxicity susceptible vs aminoglycoside otoxicity normal risk for mtRNR1; malignant hyperthermia susceptible vs malignant hyperthermia normal risk for RYR1).

We can provide you a gene-by-gene list at this point with our best guesses, if that would be helpful.

What is your timetable for needing to know?

Thanks and sorry for the hassle.

Mary V. Relling, Pharm.D.
Chair, Pharmaceutical Dept.
St. Jude Children's Research Hospital

I replied to request the gene-by-gene list of their best guesses as I presume it would be better than anything else available.

Bret H (Mar 06 2019 at 16:10):

Thanks Larry. That's helpful. I've not looked at CPIC closely in a while. Can you shoot me a link to see where they define which lists are from the delphi process and which ones are still being debated or brought into alignment?

Bob Freimuth (Mar 06 2019 at 19:23):

@Larry Babb Sorry I did not see this thread in time. Mary's response is the authoritative word, of course, but it also is consistent with what I've heard lately. We can use the CPIC consensus terms when possible, knowing that the genes that weren't considered as part of the delphi standardization process will be done at a future date.

I think the important thing to take away from this is that the field is still a work in progress. We won't have a stable terminology for some time.

Larry Babb (Mar 06 2019 at 19:52):

@Bret H There isn't a link that points to which lists are using the delphi terms and which ones are being debated or brought into alignment? There are only the lists they published and that you need to lookup gene by gene. If you go to any of the specific genes guidelines and look for a link to the diplotype-phenotype table (assuming one exists) then you can sort on the phenotype column to see the unique set of terms. If there is not diplotype-phenotype table available then you generally have to read the main guideline doc to extract what terms to use from the literature, which may not be clear and consistent from each person that does this.

Bret H (Mar 08 2019 at 13:54):

in this case. You could do a specific profile for each Gene in a set of CPIC profiles. Each profile would specify the value set (i.e. write a value set resource) to use and have the HGNC ID for the gene as required. It would be of work to maintain the profiles.

I would not try to have a single inclusive value set with all values from all the lists. With a long list of values an implementer would still need to run logic based on the gene sent, by doing the profiles you save them the effort of looking up the value sets.

A receiving system would be able to receive the profiles, even if they did not implement CPIC IG profiles, as long as the CG IG does not specify which values to use in the value set.

Kevin Power (Mar 08 2019 at 15:40):

in this case. You could do a specific profile for each Gene in a set of CPIC profiles. Each profile would specify the value set (i.e. write a value set resource) to use and have the HGNC ID for the gene as required. It would be of work to maintain the profiles.

That sounds like a significant profile proliferation? How many would it take to support such a model?

Bret H (Mar 19 2019 at 15:24):

Yep. It takes as many as CPIC produces guidelines on Genes. But recall, the profiles are to help by providing guidance to appropriate value sets. Instance data will always conform to the base FHIR spec. It is a question about implementation. But if EMERGE wants to standardize PER gene what the value set can be...what other options do they have? I know they are trying to reduce the number of value sets (and thus provide an option to group genes together - possibly by function - but currently they need a lot of guidance to implementers). An option is NOT to specify specific profiles per gene but then you leave it up to impelementers to implement the CPIC work correctly.

Bret H (Mar 27 2019 at 15:11):

additionally, what happens as the value sets change! There are mechanisms to update servers, but won't servers need to be able to understand the historical values too. Normalizing those value sets is critical and for a computer non-ordinal indicators (e.g. positive, found, detected) are essentially the same thing. The work to be done is with the ordinal lists. There is a way in FHIR to communicate a codded ordinal with its ordinal value. One means to allow for evolution of language (i.e. changes in the displays in the value sets that do not alter the ordinal scale) while remaining backwards compatible is to assign an ordinal value to concepts in an ordinal list...now, we still have a problem if you insert into the list....more food for thought than a suggestion. @Larry Babb how were you thinking of representing the value sets as Value Set Resources? Will the value sets be deposited in VSAC as well?

Bob Freimuth (May 07 2019 at 20:53):

@Larry Babb Where did you end up on this topic? Should we discuss further?

Larry Babb (May 07 2019 at 23:57):

I'm not planning on building Value Sets for different PGx Genes. I will likely use the CodeableConcept.text approach and go with whatever the labs decide to extract from the literature to convey the phenotype. In time as CPIC standardizes the phenotype terms for the different PGx genes or gene combos (i.e. CYP2C9/VKORC1 for warfarrin metabolism) then someone can register these and the community can get some kind of standard computable terminology that is more useful in a broad sense.

Larry Babb (May 08 2019 at 00:02):

@Bret H
In your 3/8 reply above

in this case. You could do a specific profile for each Gene in a set of CPIC profiles. Each profile would specify the value set (i.e. write a value set resource) to use and have the HGNC ID for the gene as required. It would be of work to maintain the profiles.

I'm not sure how to create these profiles and I would need some expert guidance to help collect these specialized terms in any case. I also want to clarify that each of these value sets might be associated to more than one PGx gene as in the case of CYP2C9/VKORC1 for Warfarrin Metabolism.

It sounds like a reasonable idea for the CPIC group to do, but I do not think and individual lab or two will take the initiative to decide on the set of terms and profile it when it really needs to be standardized and shared with EHR vendor systems in a more meaningful way.

If we start by passing the terms as the text attribute of the codeableconcept it would be a good start I think.

Larry Babb (May 08 2019 at 00:05):

@Bob Freimuth I don't think any further discussion will help. I think CPIC is aware and will address the standardization at a pace that they are able to accomplish. But the CG group should keep an eye on it and make sure to standardize those terms that are finalized so they are available to the masses. I'm not sure how to make that happen.

Last updated: Apr 12 2022 at 19:14 UTC