Stream: genomics / eMerge Pilot
Topic: Variant Data Type Proposal
Larry Babb (Jun 18 2019 at 19:34):
@Lloyd McKenzie the eMERGE group has a requirement to support the sharing of structured "variant-centric" knowledge. These are clinically assessed, patient-independent, approved and frequently re-evaluated statements that are directly used to provide findings or results to case level variants found during clinical genetic testing.
The importance of these variant-centric knowledge statements (and gene-centric, etc...) is to allow clinical quality knowledge to be used directly or after-the-fact with reported results. Thus, allowing the evolving clinical-grade knowledge changes to inform EHR-level records without the need to necessarily re-report or at a minimum to notify clinicians that there may be new information that is worth investigating (i.e. recontacting the original reporting lab for an update).
In any case, we support this workflow in the custom messaging approach we are using in eMERGE and would like to do the same with FHIR.
I believe that we need at least one data type (complex data type? or special use data type?) to help communicate the definition of these "reference-able variants" on which knowledge or clinical-grade annotations are made.
My question is...
Is it possible (and reasonable) to define an extension that behaves and operates like a Complex Data type. This would allow us to provide demonstrable structures to serve this need. We could then use this to define the simple and more complex variation types needed for defining statements. I know this isn't everything we need to fulfill the requirement, but if you could share with me whether it is even a possibility to create custom Complex Data types and how that would be helpful.
(BTW - I also looked at the Measure Resource which seemed like a potential candidate for profiling into the various Variation classes we might need, but it didn't seem like it would support the longer term vision.)
Your assistance as always is greatly appreciated.
Jamie Jones (Jun 18 2019 at 21:07):
As far as complex data type extensions, I've seen them but have been cautioned against them to ease implementation and adoption. I think we would ideally iron out where this level of data needs to be represented (and from there, where it needs to be represented in FHIR). If it's mainly an internal workflow thing, I don't think it needs to be in FHIR as an instantiated Resource. Being able to reference an external knowledgebase by a code system (likely a grammar here!) should be enough. This puts extra work on the tool that queries the knowledgebase and then spits out the evidence into FHIR but I could see it coming together fairly quickly. Just my initial thoughts.
Lloyd McKenzie (Jun 19 2019 at 01:05):
I'd look at the draft evidence based medicine resources. I'd also chat with the Clinical Decision Support work group and BR&R who are working on a set of resources around indications, contraindications and other clinical knowledge statements. However, if your needs are shorter term or aren't available in the version of FHIR you're implementing, then complex data types (or even Basic) are reasonable options. They're less attractive and less implementable than something that's purpose-designed (and this is a space where I'd expect we'll eventually have something purpose-designed), but have the advantage that they're available now and will work with existing tools.
Bret H (Aug 21 2019 at 03:17):
The Guidelines Resource might be what you are looking for @Larry Babb check it out.
Larry Babb (Aug 21 2019 at 12:14):
@Bret H not seeing a "Guidelines" resource. If you are referring to the "ImplementationGuide" resource then I'm still a bit lost on how it can help with establishing a VariantDefinition type resource or set of datatypes to help define variation that is then referenced by observations.
Bret H (Aug 21 2019 at 18:27):
Not resource, sorry, but profile. It is being balloted as part of another WG. I'll give you some details in a moment
Last updated: Apr 12 2022 at 19:14 UTC
