FHIR Chat · PGx Overall Interp Profile · genomics / eMerge Pilot

Stream: genomics / eMerge Pilot

Topic: PGx Overall Interp Profile

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

Currently there are 2 overall interpretation profiles in the CG IG

Genomic analysis overall interpretation - Provides a coarse overall interpretation of the genetic results reported.
Deletion-duplication overall interpretation - Provides an overall interpretation of whether any deletions or duplications were found as part of the genetic analysis

In our PGx panel we have several sub PGX interpretation results (metabolism, efficacy, etc) that we would like to provide an overall interpretation for (i.e. positive, negative, inconclusive) to describe whether or not the PGx phenotype is normal or abnormal or indeterminate.

I was thinking of using the Genomic analysis overall interpretation above but that seems like it might not be the right fit. We may want to consider using the standard terms from CPIC for the EHR Priority Result Notation which has the following values:

Abnormal/Priority/High Risk
Normal/Routine/Low Risk
None

The question is
Should we create a separate "PGx Analysis Overall Interp" profile and if so, should it have the same or different terms than the "Genomic Analysis overall Interp profile"?

Also, since PGx testing can often report multiple PGX results, can we use the same (or different) PGx Analysis Overall Interp to summarize the nested individual overall interpretations for each individual PGx result reported? This is the model we envision for the eMERGE PGx model.

Kevin Power (Mar 05 2019 at 23:56):

Well, first the GF#16935 will trigger the removal of the Del-Dup overall interp profile. Doesn't help you much, but FYI.

Regarding the CPIC 'EHR Priority Result Notation' - Do you know if this happens to a LOINC code that CPIC requested? I don't remember seeing it before, but we should check that first.

To the question of 'override Genomic Analysis Overall Interp' or 'new PGx Analysis Overall Interp profile' - I am leaning towards something more like the first - allow the current Overall Interp profile to use different answer lists. Right now, it would require LL541-4 - but perhaps we should change this to Preferred or even Example? Then if other answer lists exist that make more sense, they could be used.

Do others have thoughts? @Lloyd McKenzie @Liz Amos (for Clem who doesn't seem to be on Zulip)

Lloyd McKenzie (Mar 06 2019 at 00:50):

The notion was that both Del-dup and overall interpretation would be single values at the report level essentially identifying "did you find anything interesting?". However, I guess in theory we could do that at the package/grouping/panel/whatever we call it level too. I don't know if we can use the same LOINC codes or not though

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

Before we go to deep into alternative value set bindings for a single Genomic Analysis Overall Interp, we should determine if we even need alternative value sets for PGx overall interp (or the Del-Dup one that is being removed).

If we do decide there are different use cases that warrant alternative overall interp value sets then...
I think we'd be fine with genericizing the Genomic Analysis Overall Interp profile to support multiple answer lists as this would then be able to support new lists going forward, but my concern is that would create a flexibility that goes counter to the idea of standardization (I think).

I'm assuming that consumers will look for specifically coded observations using matching on LOINC Codes like the one for Genomic Analysis Overall Interp and if there are "variable" value lists with different LOINC answers with a variety of codes then it may be difficult for the consumer to handle that situation.

I could be wrong - but I think the folks that want to consume and act on the incoming HL7 data prefer a more controlled situation that doesn't require unpredictable data.

If the answer is to make this a single Profile with interchangeable value sets (answer lists) then how do we share/register the value sets for a given case? Would this be done in the IG? And can we discuss how a consumer would be able to distinguish which value set was used in a given record - because that might be needed to trigger any type of CDS mechanism downstream?

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

but my concern is that would create a flexibility that goes counter to the idea of standardization (I think).
That is a valid concern, but we have to balance the usage of standardized codes AND meeting the labs where they are today. Where we are comfortable relying on a single, standardized list, we can and should. However, I don't know how often that will be the case.

I could be wrong - but I think the folks that want to consume and act on the incoming HL7 data prefer a more controlled situation that doesn't require unpredictable data.
You are certainly not wrong, but we don't always get what we want. :slight_smile: As I mentioned in another thread - we do have the option of requesting the labs to send the best matching item from the standard list, but still allowing other 'codes' to be sent.

If the answer is to make this a single Profile with interchangeable value sets (answer lists) then how do we share/register the value sets for a given case?
I am actually not sure of the best way to do this. Perhaps @Lloyd McKenzie or @Patrick Werner can weigh in?

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

There is an interpretation field in observation resource which accounts for a labs need to report critical values. @Larry Babb have you looked at this filed? the list :
Abnormal/Priority/High Risk
Normal/Routine/Low Risk
None
fits in there

Larry Babb (Mar 06 2019 at 15:51):

@Bret H I've noticed this field before and often thought it would be the right place for things like "overall interp values". But I see that in the ObsBase profile for the IG that it is explicitly eliminated, so I figured it wasn't something that played nice with the CG IGs approach to returning overall interps.

If the observation.interprtation is a good approach, then I would suggest using this for all "overall" results as it incorporates POS, NEG, or inconclusive (indeterminate).

I'm guessing the reason this is removed from the ObsBase profiles and an Overall Interp profile was created is because it is presumed that multiple sub-observations need to be aggregated to a single overall interp, which is not how the observation.interpretation field works.

observation.interpretation A categorical assessment of an observation value. For example, high, low, normal.

I could use this for the EHR priority values specified by CPIC for each PGx result, but I'm not sure what I'd do for the cases where there are combo diplotypes to arrive at a single result (e.g. CPY2C9 & VCKORC1 for Warfarin Metabolism)

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

that's right, we removed it on purpose. I need to go back and think about it. Sorry not to have a quick return.

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

Perhaps Observation.interpretation should be applicable to some of our profiles, and removing it in ObsBase was too broad. Perhaps it should be allowed on the impact profiles?

I could use this for the EHR priority values specified by CPIC for each PGx result, but I'm not sure what I'd do for the cases where there are combo diplotypes to arrive at a single result (e.g. CPY2C9 & VCKORC1 for Warfarin Metabolism)

If I understand, I think you could have two Genotype findings (CYP2C9 and VCKORC1) and a single PGx impact observation that .derivesFrom() both Genotypes?

Lloyd McKenzie (Mar 06 2019 at 15:59):

@Kevin Power Standardizing terminologies becomes easier when they're:
a) small
b) the concepts being represented are well known and standardized
These two things together mean that even if systems aren't using the 'preferred' terminology internally, it's not an insurmountable task for them to create mappings to a standardized set of codes. (Not that they might not grumble and complain enormously at the imposition :)).

In this case, I'm pretty comfortable that we have (a). I'm not so sure that we have (b).

In any event, if we were to define a broad, relatively all-encompassing value set and then wanted to refine it for particular situations, you can certainly do that with profiles.

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

adding onto LLyod's comments. The danger in adopting all the various terms into a single code system is ambiguity. I think it is worthwhile to look more deeply at what the 'job' to be done is with the element and reporting of the phenotype. Is this purely for display? Or do can we see a use case for computation? If it is meant to be computed upon refer to Llyod's comments on terminologies. The same can be said for using terminologies computationally, they are easier to writing programming code to deal with when a) small, b) the concepts being represented are well known and standardized

Kevin Power (Mar 06 2019 at 16:09):

In any event, if we were to define a broad, relatively all-encompassing value set and then wanted to refine it for particular situations, you can certainly do that with profiles.
Can you easily summarize the mechanics of that? I have some vague notion, but I sure could not do it today.

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

@Kevin Power use a ValueSet resource is one option

Lloyd McKenzie (Mar 06 2019 at 16:20):

When you define a derived profile, you can change the binding. Specifically, you can tighten the binding strength and/or specify a different value set that reduces the set of codes in the value set. (Actually, if the original binding was example or preferred, you can do whatever you like in the binding for a derived profile. Also, if the original binding was 'extensible' you can add to the codes in the value set, though there are rules about what's legitimate to add and what's not.)

Kevin Power (Mar 06 2019 at 16:35):

So, it seems we need to document all the possible values in the "overall interp" space into one place (might make a nice Google Doc) and then see how we might define 1..* value sets and then consider how we might derive 1..* profiles? For each of the values, we should indicate the source and if we can use existing code systems (LOINC, SNOMED, ..)? Does that seem like the right next step?

Lloyd McKenzie (Mar 06 2019 at 16:49):

That's a possibility. Note that we don't necessarily need to define 1..* value sets or profiles. Having implementers pick randomly from a semi-narrow pool of concepts will still drive more consistency than no guidance at all. We also need to consider how much standardization the industry is willing to tolerate/can manage.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 07 2019 at 14:30):

Late to the party here... Keep in mind in the US and other countries adhering to accreditation requirements, the performing laboratory will validate the test system including how results are reported. If a FDA 510(k) vendor system is used to generate results, responses/test result values must be in accord with the manufacturer's package insert per CLIA law in US. Expect genomics and PgX testing to have fewer IVD vendor systems and more of a mix of Laboratory Developed Testing (LDTs), but those have to be clinically validated as well. Ideally, these labs would use standard responses as indicated, but if they don't, their results shouldn't be changed downstream. Concur they should be mapped to standard code systems so they can be computable and integrated into CDS, actionable, etc.

Larry Babb (Mar 07 2019 at 20:39):

@Kevin Power

If I understand, I think you could have two Genotype findings (CYP2C9 and VCKORC1) and a single PGx
impact observation that .derivesFrom() both Genotypes?

That's correct

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

@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM When reporting with coded values the product insert does not specify which coded value to use. The lab simply needs to choose an appropriate coded value. Right?

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 08 2019 at 13:48):

Correct.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 08 2019 at 13:52):

Package inserts indicate what/how results are to reported, but an IVD vendor isn't going to go through re-approval with FDA just to ass LOINCs, or other codes. Further, their lawyers have concerns about such an approach. This is why the LIVD standard was created to provide LOINCs corresponding to vendor results to assist lab professionals for finding what's needed for mapping in their LIS/APLIS. It'll help standardize mappings and reduce variety of mapped LOINCs for the same result performed in labs across the world.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 08 2019 at 21:07):

@Bret H
here's a random insert for a test that identifies CYP2C9 and VCKORC1 http://www.autogenomics.com/pdf/INFINITIWarfarinAssayPackageInsertUSA.pdf

See page 8 Interpretation of Results Section for the allowed responses from this particular vendor.
One example of how the results might look:
2C92, 2C93 and VKORC1 3673 (-1639) variants interpretation (test result field: .................................. (test result value field) Wild Type, Homozygous, Heterozygous, or Indeterminate

One would want to LOINC encode the test result field: 79716-7 CYP2C9 gene product metabolic activity interpretation in Blood or Tissue Qualitative by CPIC
The Test Result Values would be encoded with SCT as in the v2.51 guide for reporting results.

In FHIR the interpretation would be a simple qualitative observation with the result values and the Observation Resource could be used. It would be aligned with v2 reporting but not as much with the current CG guide. It just dawned on me this might be an interoperability issue when folks start widescale modeling/reporting with FHIR if done differently. Then there are those in the V2 to FHIR calls that want to "translate" v2 messages to FHIR. That won't work very well with CG. fyi @Kevin Power (may need to discuss with implementers/future call).

Kevin Power (Mar 08 2019 at 22:14):

Yup, your concern is the whole reason it made sense to have CG rep's on the V2-TO-FHIR projects. It hasn't come up yet in any of the calls, as they are still working at a really low level. I don't think they have gotten even close to discussing lab results yet.

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

the narrative text can be a place for the specific product insert wording - whereas the fields in the instance data have the appropriate codes.

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

andrea said: "See page 8 Interpretation of Results Section for the allowed responses from this particular vendor.
One example of how the results might look:
2C92, 2C93 and VKORC1 3673 (-1639) variants interpretation (test result field: .................................. (test result value field) Wild Type, Homozygous, Heterozygous, or Indeterminate

Not sure what the problem is. A reporter could also fill in the correct sections of the CG WG profiles and use the generic LONC code as in the IG. The question is for labs to value filling in the CG IG profile. The same issues have kept the HL7v2 genomics work from being adopted. We can give guidance and then recipients of messages need to value receiving the message in a specific format. Also, there is nothing in the base FHIR spec from a system receiving the data in a precoordinated model (basic observation) and sending data to other systems with the more post-coordinated model ( CG IG).

HL7v2 is not law but a precedence...if it were perfect then why are we moving away from it?

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

@Kevin Power @Larry Babb