FHIR Chat · How to represent Gene pathologies · implementers

Stream: implementers

Topic: How to represent Gene pathologies


view this post on Zulip Joshua Bell (Feb 19 2018 at 16:50):

We currently collecting molecular pathology for a given sequencing test with one or more genes. We are trying to store the following in fhir: Gene, mutation, interpreted result, as well as a raw result score. Has anyone done this in fhir and have an example of where this all goes?

We currently have an observation for each gene and are saving our interpreted result in the interpretation codeable concept (which we have codes that are not in the extensible list), and then the mutation string in the valueString field. At this point, we want to also include the raw result score but you can only have one value. I would assume we should use the component array but seems like we are just putting things in Obersvation sort of randomly and can't find an example of someone else doing this.

We don't have the raw sequencing data, just the end gene pathology results. So Sequencing object seems useless to us with the data we have, but I could be wrong about that.

view this post on Zulip Lloyd McKenzie (Feb 19 2018 at 17:32):

The clinical genomics work group is actively working on a set of profiles intended to support use-cases like this. It's in rather draft form at the moment, but you might find it helpful - and we'd certainly welcome feedback on it: http://build.fhir.org/ig/HL7/genomics-unified/index.html

view this post on Zulip Joshua Bell (Feb 19 2018 at 17:54):

Sort of an off-topic question, but in cases like this where we are in need of saving this data right now. Should we just sort of put it wherever feels right and then be expected to migrate this data later? I often run into this issue using fhir, where we save info somewhere in fhir that seemed right, but then later some spec or new field is added that is more appropriate. Then we have to do a huge migration in order to realign everything. We want to use FHIR in storage rather than maintaining our own model along with a complicated conversion between that model and FHIR (as this is what we do now and it poses severe limitations to our process and development, it would be much better if we could easily iterate on things using fhir directly)

view this post on Zulip Lloyd McKenzie (Feb 19 2018 at 19:35):

There's certainly a challenge in working with a specification while it's still under development. My recommendation is to look at the current official version of the spec, the version under development and to ask the community. Those three steps reduce the amount of change you're likely to see (and make it more likely your solution will work in general). But you should definitely design to allow future transformation so you can interoperate with newer versions - and eventually the final version - of the standard.


Last updated: Apr 12 2022 at 19:14 UTC