Stream: genomics
Topic: Genetic Impact
Kevin Power (Feb 27 2018 at 17:13):
@Bret H put together the following to consider GuidanceResponse as a possible way to deliver the 'Impact'. Anyone wishing to comment is welcome.
Kevin Power (Feb 27 2018 at 17:13):
https://docs.google.com/document/d/1qyqKQ1hOJcin1QwwB2aJOTnWJsWCAz7t1ktjX26iTLA/edit?ts=5a732113
Kevin Power (Feb 27 2018 at 17:16):
Question for @Bret H - Based on your comments during the call today, are you thinking this is a better option than Observation now? The document was framed as "examining the structure to see what to add to observation", but you seemed very opposed to using Observation to deliver the 'impact' data? Can you clarify your thinking?
Kevin Power (Feb 27 2018 at 17:34):
Wanted to add the following examples that were uploaded:
https://drive.google.com/open?id=1o1oyqrGaVC4AbuR0CJxvBG4tEgr53FX1
https://drive.google.com/open?id=1Ung6sH9jW7iQZlvApu5Is0iem3BwUhZj
https://drive.google.com/open?id=1ZjvhYOw7gfUja1wm0xaB8NFC5H5nIvmH
Bret H (Mar 04 2018 at 14:24):
Mainly, I want to clarify that the proposed information goes beyond the purview of pure genetic sequence data. I do not want us to be in the trap of modeling phenotype effect - this has already been done by reachable sources such as ClinGen, OMIM, PharmGKB, etc..
Getting labs/LIS's to implement is tricky business, which I is one reason I do support Clem's work to have a structure easily mapped from HL7v2 (including the LRI). Just gotta be clear where we've had to go beyond the more natural scope of genetics data to that.
From here I go into a Medication Impact example, but please apply the thinking around "what is clinical decision support implementation guidance and what is not" to other Impacts being described in the proposed profiles.
For example, Medication Impact is a piece of clinical decision support. The reason to create such a profile is an effort to provide labs with guidance on how to send information which labs currently send today (semantically modeled correctly or not, there is a perceived business value in the information. However, access is not streamlined, at least not in what I've seen - several clicks required to download an external PDF). While useful, I am unclear weather we would include this in a Standard for genetics. It is implementation guidance to lab adopters - not standard genetics information.
Why is genetic clinical decision support so special as to have a specific profile pre-configured with elements of clinical decision support? We have Diagnostic Report to place interpretations and supporting evidence and such.
Think on this, what drug/dose form of a medication will a lab include in their message?
Will the message refer to Plavix or Clopidogrel? or will all versions of a medication need to be sent? You see, this quickly becomes an implementation issue.
There are other mechanisms that can be used by labs. Some examples include:
1) provide their clients with a FHIR app which can interact with the EMR to provide CONTEXT specific guidance. The most useful!
2) Sending an pre-configured infobutton link is as effective as the more complex structure presented. If one must send variant specific but not clinical context specific guidance. Specifically, PharmGKB provides an infobutton complaint API which includes such information as the Clinical Pharmacogenomics Implementation Consortium.
Finally, we will need to have the Clincal Decision Support WG bless the construction of profiles that are pre-configured with CDS. Also, I wonder if the FHIR management group needs to accept the precedent (or do they already have such, somewhere).
Thanks for your patience. Especially those who have worked hard on these profiles. We are in the final stages : ^ } hang in there. Take my critical comments as a compliment to the importance of the work and the nearness to completion.
Lloyd McKenzie (Mar 04 2018 at 15:20):
Thanks for continuing the conversation.
Lloyd McKenzie (Mar 04 2018 at 15:21):
I don't think Infobutton is a terribly practical solution here because I don't think most labs are set up to support REST-based delivery of information. Their data will all need to come back encapsulated in the report - whether as a FHIR document or message or some similar Bundle. (Or at least whatever solution we provide will have to support that sort of delivery.)
Lloyd McKenzie (Mar 04 2018 at 15:23):
I don't think there's an issue with us stepping into profiling the CDS space for genetic reporting - if that sort of information is included with genetic reports. And my read is that genetic reports are pretty useless to most clinicians without it.
Lloyd McKenzie (Mar 04 2018 at 15:24):
It's absolutely true that we'll need to engage with the CDS work group about this content. The FMG requires formal review of IG profiles by the work group responsibile for the resource being profiled before an artifact can hit FMM 3. And if we don't end up profiling a CDS object like GuidanceResponse, we'd still involve them in the process.
Lloyd McKenzie (Mar 04 2018 at 15:29):
The problem with GuidanceResponse is that it's a geneic parameter-based response to an arbitrary specific question. The output parameters could contain anything under the sun and the meaning of them is totally tied to what CDS operation was invoked. The clinician wouldn't have any insight into that. Also, what we're providing back isn't really a decision support response, it's the knowledge that would support the CDS response. What we're doing is the equivalent to what the FDA does when they model the assertion that "drug A and drug B are contraindicated together". GuidanceResponse might be used to respond to a specific CDS invocation of "is this med I'm prescribing ok?", but it would never be used as a way of maintaining the knowledge definition about the contraindication linkage between the two medications.
Lloyd McKenzie (Mar 04 2018 at 15:34):
Overall, we need to focus on what labs do return now and allow them to express that in a discrete way that's semanticly appropriate. Our standard isn't about trying to change what information labs return or to change practice, but just to standardize where information is exposed so clinical systems can take advantage of it better than a PDF. Work to improve practice becomes possible only once we've achieved the first step of getting systems to encode their data in the first place. (And improving practice through standards is a dicey process if you don't have regulation on your side - if the business model dynamics don't work, you can define standards until you're blue in the face and they'll just be ignored.)
Lloyd McKenzie (Mar 04 2018 at 15:43):
After talking with Bryn, we think there's going to be a need for a resource that can represent various types of "knowledge assertions" that CDS systems can use as inputs - indications, contraindications and some of the things we've got in the genetic space where we sort of have an "if/then" clause - "if [subject has variant X], then [subject is (assertion of confidence) high metabolizer of drug Y]".
Lloyd McKenzie (Mar 04 2018 at 15:44):
The trick will be balancing making it generic and making it useful/comprehensible to implementers
Joseph Kane (Mar 04 2018 at 18:36):
Larry Babb presented a structured knowledge artifact data framework on our call on 12/13/17 referencing the SEPIO ontology outlined here:
https://github.com/monarch-initiative/SEPIO-ontology/wiki
If we're going to push for a FHIR resource to report structured knowledge (which I think we should), it would be a good place to start.
Joseph Kane (Mar 04 2018 at 18:58):
The powerpoint for his presentation can be found here:
Joseph Kane (Mar 04 2018 at 18:58):
Lloyd McKenzie (Mar 04 2018 at 20:16):
The CDS work group has adopted a set of data elements that capture many of these notions, though not in exactly the same linkage. They can be seen in resources like http://build.fhir.org/plandefinition.html, primarily through relatedArtifact. If we were going to do something more sophisticated, we'd want it to be consistent across all knowledge artifacts (and some of it might need to be handled through extensions)
Kevin Power (Mar 05 2018 at 03:06):
@Bret H - I feel @Lloyd McKenzie said it best with "improving practice through standards is a dicey process if you don't have regulation on your side" - I have experienced that first hand. You are probably right when you say we might run into some implementation questions with this approach. However, my feeling is we will be fewer issues than if we were to try require the delivery of this important information through a completely different mechanism. Plus I am also a bit concerned about the workflow in current systems to support such a different model.
Bret H (Mar 05 2018 at 03:19):
Sorry. I think you missed the point.
I have not proposed any model. I have described what was done. In fact, I specifically stated I want us to avoid going the route of describing phenotypic knowledge. Further, I offered 2 simple alternatives, there is no modeling there (I know for a fact that implementing a Infobutton request to PharmGKb is straightforward)
By adding clinical decision support in the profile on observation this is a departure from a simple model.
Is there a precedent know by the FHIR FMG?
Does the CDS WG agree with the complex structure e.g. medication impact?
What medication wpuld it be in response too?
I would like to see responses to the concerns I have raised in the previous msg here.
Lloyd McKenzie (Mar 05 2018 at 04:18):
The plan is to drop the Observation profiles and move to the new resource. There's a need to represent phenotypic knowledge - and knowledge in general - in FHIR. Insofar as the lab community currently returns such information, our specification needs to provide a place for it in the resources. If all labs did was provide a URI to an external source, then that's what we'd do. But that's not what they do, therefore we can't ignore the requirement and tell them to change their practice.
The medication codes used would be whatever the lab chooses - in an international standard, we can't really give much guidance there. Presumably we'd encourage the choice of high-level generic classes rather than specific manufactured products wherever possible.
I'm not clear on what precedent you're referring to in terms of the FMG or what concerns I haven't responded to. (I was trying to address everything, but undoubtedly missed something.)
Kevin Power (Mar 05 2018 at 14:44):
So, to help summarize, I can see three options:
1 - Move forward with the Genetic Impact Observation profiles.
2 - Create new recommendations for delivering the Genetic Impact data via InfoButton links, SMART apps, CDS Hooks, etc.
3 - Wait for the CDS WG to define a new set of knowledge resources and leverage those in the future.
Does anyone see other options?
Bret H (Mar 05 2018 at 19:56):
After speaking with Kevin on the phone.
I agree that for the kind of interpretive guidance mentioned above, as of today, the structure proposed is the best that FHIR currently offers to provide the knowledge in a computable manner (i.e. Genetic Medication Impact where the information is consider part of the observation message sent by a lab).
This will be a win. I do not think it will be difficult (relatively) to transition from populating the Genetic Medication Impact FHIR profile to some other knowledge structure in the future, when there maybe better ways, in FHIR, to express knowledge and utilize CDS.
Looking forward to CDS WG approval...
Lloyd McKenzie (Mar 05 2018 at 22:40):
To clarify, are you endorsing the current proposed structure (Observation) or the proposed new structure (new resource)?
Kevin Power (Mar 06 2018 at 00:49):
@Bret H can confirm, but after we chatted for a bit I think he was agreeing the current proposed structure would suffice as long as we continue to work towards a better representation of knowledge.
Bret H (Mar 06 2018 at 03:27):
Yes. The new proposed structure with Genetic Medication Impact.
Until we have better knowldege artifacts in FHIR, it seems a good way to present interpretive guidance. And I think the transition to a future knowledge artifact will be fairly straightforward.
But, we will seek agreement from the CDS WG with the structure, right? If so, then I endorse.
Lloyd McKenzie (Mar 06 2018 at 15:40):
"new" isn't a good term because both the current model and the proposed new resource are "new". Bryn, who leads most of the CDS work, as well as a couple of others from that work group have signed off on the notion of a new resource. My guess is they'd end up being the owners of it and we'd just be users of it.
Aziz Boxwala (Mar 06 2018 at 16:35):
@Lloyd McKenzie : Could this be an enhancement of or profile on DetectedIssue. This use case is not too far off from other use cases for which DetectedIssue was developed.
Lloyd McKenzie (Mar 06 2018 at 16:43):
Possibly. That's an interesting idea. We'd need to add a few extensions to convey the discrete data needed. I'll do some playing with the notion next week.
Last updated: Apr 12 2022 at 19:14 UTC
