Stream: genomics
Topic: Modelling of 'affected' status
Andrew Patterson (Sep 18 2018 at 06:30):
We are just trying to model some inputs for a genomic test - and want to model the 'is affected' status that would be attached to a patient in the context of a familial test. So this is traditionally a boolean field that goes into a pedigree file, or is a boolean that is set in variant analysis tools. So worst case we can make an extension to patient that contains a boolean. But was interested in the groups thoughts?
Attaching a Condition resource, or a FamilyMemberHistory asserting this would be better - but the statement of 'is affected' is not normally accompanied by any actual clinical detail of what exactly affected by means - and in many cases it is inherently wishy washy - as what they are affected by is the unknown disease that is being tested for in the test!
Kevin Power (Sep 18 2018 at 14:43):
It seems like you would use the FamilyMemberHistory.condition list? I would guess if you add a condition to that list, they are affected? Or do we think they might list several conditions, but the 'is affected' is still important in the context of a familial test?
Another option is to use the FamilyMemberHistory.extension.obervation the CG group added to FamilyMemberHistory?
Andrew Patterson (Sep 18 2018 at 23:32):
Thanks. Yes - I think if it was clear exactly what the condition was that they were affected by - we could do some check if equivalent condition is listed in each FamilyMemberHistory. But in the diagnosing rare disease case I don't know what level of precision they mean when they say 'is affected' (has exact disease? shares phenotypes?). I will hunt down some of our clinical folk and try to get the bottom of exactly what they want to represent. Thanks again
Jennifer Ellison (Sep 30 2019 at 13:28):
Hi Andrew, did you get any further with this? We are looking at modelling this in the UK and have considered using the Observation or creating an extension to the condition backbone element. Our preference would be to align internationally so would be interested if you came to any conclusion.
Andrew Patterson (Oct 01 2019 at 05:51):
@Jennifer Ellison - not sure we are happy with it - but we ended up just using the SNOMED code for Patient affected (qualifier) - and an observation value of true.
{ "fullUrl": "urn:uuid:5eed5108-da9e-410c-b316-8dbaf0216915", "resource": { "code": { "coding": [ { "code": "103309006", "display": "Patient affected", "system": "http://snomed.info/sct" } ] }, "status": "final", "subject": { "reference": "urn:uuid:d9bdbe6e-d0a1-4a3f-a948-f7e33a37978e" }, "valueBoolean": true, "resourceType": "Observation" } }
Jennifer Ellison (Oct 01 2019 at 08:13):
Thanks for getting back, are you referencing this Observation from the extension within FamilyMemberHistory-Genetics? If so, are you limiting the condition backbone element to 0..1. I'm trying to understand how you know which condition it relates to in terms of a Family Member.
Andrew Patterson (Oct 02 2019 at 00:51):
No, because the observation only exists in the context of the 'order' being made (we have almost a 'order' compartment - though not officially one) - the implication is that the affected status is of the implied condition 'under test in the order'. I am not happy about that from a FHIR/modelling perspective but our source systems do not have any more details.. so it is just a stop gap until we can uplift some of the source/ordering systems. In fact our downstream variant curation tool also only has a boolean field called 'affected' (per patient) - with no reference to a condition either. So we are penned in at both ends!
Bret H (Oct 02 2019 at 11:49):
@Andrew Patterson are you modeling family history based on pedigree without known patient genetic variation? Or family history with genetic variation inferred based on a knowledge resource (i.e. unconfirmed genetic variation)?
Bret H (Oct 02 2019 at 12:33):
@Andrew Patterson maybe you already have all this information.
1) But https://www.hl7.org/fhir/familymemberhistory.html famlilymemeberHistory.condition is meant to be used for the related person who was affected but where you do not have access to an observation/report of the Condition. The condition.code value has the condition the patient's relative was reported as having. If a relation did not have the condition then the relation would not be coded with the condition. The FHIR instance will always be about a single patient, so the tree will have the patient as the point of reference for 'related person's relationship. There is condition.note where additional information can be placed such as level of certainty. But I can understand wanting to be able to document in a more computable fashion the degree of certainty. One would never trust the condtion.code as a presence of a diagnosis on a family member. It must be verified. But usually in pedigrees Genetic Counselors don't go much further than stated by someone (such as patient stated). I wonder if we can add an element to capture who the information was collected from? do you see an element available?
familymemeberhistory is for the context of capturing information on a patient's family history or communicating A patient's family history. But not intended to be a backend model for a pedigree. You can use it to communicate a pedigree from one patient's perspective (i.e. two siblings would have different perspectives of familyhistory as they would be the patient of their own instance, and all relationships in their instance would be based on the relationship to themselves). Not sure if that helps or is satisfying.
2) More importantly, http://hl7.org/fhir/StructureDefinition/family-member-history-genetics-observation provides an extension to link to recorded (tested) genetic variation (where an instance of Observation Variant is the target of the link). This is meant to be for electronic communication of testing results on a relative. But not for inferential inclusion where the presence of the variant is assumed based on knowledge of an association between a condition and disease. If you are relying on associations to presume presence of variants, there have been discussion about definitional DNA sequences based on Sequence Resource - i.e. where there is no specific patient observed to have the sequence but where the defintional DNA sequence is being used as a reference of some sort.
Architecture of knowledge beyond the specific patient, as you note, is not easily achieved in a messaging standard. There is work in the Clinical Decision Support working group to create more suitable artifacts for knowledge resources.
A little wordy but hopefully helpful, and please correct me if in error.
Andrew Patterson (Oct 02 2019 at 12:54):
For context - this is purely in an 'order' model - so not attempting to represent diagnosis or anything.. just allowing the diagnostic lab (in conjunction with info they get from the ordering clinician) to send in an order for genomic processing of a trio - which we structure as a set of Patient and Specimen (and FamilyMemberHistory + familymemberhistory-patient-record ext) to join them all up. So we need enough info in the order to make a PED file and to pass on to downstream tools - all of which just have a boolean associated with each patient of 'affected status'. So I know that is not modeled correctly - but I have both source and destination systems in the bioinformatics world our system lives in that have no more info to give me..
Bret H (Oct 02 2019 at 13:02):
@Andrew Patterson For a Trio can you take a look at http://build.fhir.org/ig/HL7/genomics-reporting/genomics-report.html and see what it looks like to model with a diagnostic genetics report? For the variation data you can report inherited diseases as annotations on the presence of a variant. We've treated a trio with genetic testing as a diagnostic report rather than collection of a Pedigree - as would be performed by a Genetic Counselor. The full draft IG for genetic testing reporting is here: http://build.fhir.org/ig/HL7/genomics-reporting/index.html (should be published relatively soon, so the base URL - build.fhir.org will change to the base url for the current published version of FHIR).
Bret H (Oct 02 2019 at 13:03):
@Nephi Walton tag you as I think this thread would be of interest.
Andrew Patterson (Oct 02 2019 at 13:17):
So our use here is all pre-diagnostic - which I had got the impression was currently out of scope of the genomics IG.. it is literally our labs telling us where the fastq files are that came off the sequencer for each person - and basically telling us enough details to run the pipelines and orchestrate the movement of data through our system.
Once the curated variants come out of the system (way at the other end) - that's where the genomics reporting profile is being used (we have done a partial implementation of this). But that will be reporting variation on just the proband even if the input data was a family.
Bret H (Oct 02 2019 at 13:33):
@Andrew Patterson I agree. I was confused. Are you then looking to use FHIR for backend systems communication?
Andrew Patterson (Oct 03 2019 at 12:37):
The 3rd party systems (pipelines, variant curation) we orchestrate between all have their own APIs - so we can't use FHIR there. All of the labs that are sending us orders have completely bespoke genomics systems (or LIMS systems that don't understand genomics so they've put some custom bits on the side). So we put a FHIR API on the interface between us and the labs that order through us - mainly because I didn't want to go 11 rounds with them arguing over bespoke clinical data structures.. instead we just point them to the FHIR spec and between us make all the obvious stuff align. Affected status was one of those ones that they had a clear (but poorly modeled) definition of what they wanted to say - that we just had to accommodate as best we could in FHIR.
(our system is already in production for 2 labs/hospitals - coming on a 3rd in the next month)
Bret H (Oct 04 2019 at 16:48):
@Andrew Patterson thanks, that is some heavy work! I think I'm finally on the same page as you. Sending FamilyMemeberHistory with condition populated is what you have available for something which was stated about a relative of the patient. It is not meant to be treated as hard clinical fact (not an obervation of a condition in the relation). If you have the actual observation, that would be referenced by the relevant instance of FamilyMemeberHistory . Is this what you see too? So, there's no affected status communication other than "relative X has been said to have condition Y" or NULL (meaning no mention of relative X with condition Y). Am I missing something? Your problem is that the lab wants to be able to say explicitly "mom is not documented with disease" (mother is affected status=NOT). Right?
Andrew Patterson (Oct 06 2019 at 05:13):
No, its even worse than that - the labs literally don't have a condition of any sort in which we could base any of the usual FHIR techniques (be that FamilyMemberHistory.condition or actual Condition). There is no Y recorded in your scenario. So whilst the clinician in their head must have some sort of suspected condition or phenotypical presentation - which they are asserting the mother or father has - in an information modelling sense we and the lab do not get told that. All they state is 'father affected', 'mother not affected'. It is the 'affected by Y' that we can't possibly write in any sensible FHIR form because we just don't know Y. And for the moment we have no prospect of them telling us that.
We are trying to flesh out our systems further back towards the clinical end so that we can start to insist that that is filled in as part of the order (in which case we would use the correct FHIR techniques of making Condition statements) - but that is a long road
Bret H (Oct 07 2019 at 02:36):
Does the test name give a clue as to what the condition might be? e.g. breast cancer risk prediction. I'm thinking a computable test description might help. I.e. if the test contains the context of the disease and the test description contains that computably in a observationDefinition, then use a link to that definition in an instance of FamilyHIstory...but you'd still need an extension to express 'affected - condition implied from test'.' I'm reaching. But this sounds similar to the practice of reporting risk of adverse event in pharamacogenomics without indicating computably with the risk is of...we're all ahead of a change in standard practice - FHIR's ability to communicate computably means we can adopt a better practice in terms of messaging (e.g. indicate what the 'affected status' refers to). @Andrew Patterson are you in any position to request a slight modification in practice to have the ordering system provide the 'what' for the what which 'affected ' refers to?
Last updated: Apr 12 2022 at 19:14 UTC
