Stream: genomics / eMerge Pilot
Topic: Associated Phenotype Component element in Inh. Disease Patho
Mullai Murugan (Mar 18 2019 at 02:51):
Regarding the Associate Phenotype Component element in the Inherited Disease Pathogenicity profile, there are instances when we have multiple phenotypes associated with a pathogenic/Likely Pathogenic variant. Can the cardinality of 0..1 be expanded to 0..* to accommodate these use cases?
Also, is there a planned valueset to be used for the associated phenotypes? The current draft lists this as unbound.
Kevin Power (Mar 18 2019 at 13:28):
I think making it 0..* makes sense. You could also send multiple Observations as well, one for each phenotype - but that seems clunkier.
We discussed possible value sets for phenotypes, but it seems there are multiple options. Do you have suggestions?
Lloyd McKenzie (Mar 18 2019 at 15:23):
I think it'll need to be a distinct Observation. The other notion of whether it's pathogenic/likely pathogenic/uncertain/etc. could presumably be different for each phenotype?
Kevin Power (Mar 18 2019 at 18:52):
It would only make sense if the pathogenicity applies to all of the phenotypes. But I think that could happen?
Bret H (Mar 19 2019 at 15:49):
As Llyod said, you need one phenotype value per variant. Otherwise how do you know which phenotype goes with which variant. @Mullai Murugan can you expound on an example. how would you use multiple phenotype
Kevin Power (Mar 19 2019 at 17:58):
If you have a Variant observation, and that variant is Pathogenic for 3 phenotypes (assuming that is possible right?) - the question is is that 4 observations (1 variant, 3 inherited disease path (IDP) that all .deriveFrom() the variant )? Or 2 (1 variant, 1 IDP that lists all 3 phenotypes and .derivesFrom() the variant)?
Mullai Murugan (Mar 20 2019 at 19:47):
@Bret H @Kevin Power yes, that is correct. A pathogenic variant in the gene KCNQ1 causes Long QT syndrome 1 and Jervell and Lange-Nielsen syndrome 1 Screen-Shot-2019-03-20-at-2.46.42-PM.png . I was leaning more towards option 2 (as proposed by Kevin) but would appreciate more feedback.
Jamie Jones (Mar 25 2019 at 16:32):
I think it has to be option 1 (i.e. keep phenotype 0..1 and use multiple pathogenicity observations) as the links will potentially have different levels of evidence to keep track of.
Kevin Power (Mar 25 2019 at 16:36):
Hmm, good point. Is that important @Mullai Murugan ? Seems like it would be?
Larry Babb (Mar 26 2019 at 19:01):
It is true that the reporting lab could report this as two separate assertions or interpretations, but there will always be folks that need to use multiple phenotypes to characterize the "condition" that the pathogenic interpretation is related too. Pragmatically, there will be labs that aggregate multiple diseases/phenotypes because the evidence is nearly the same and the outcome interp is the same for several diseases (as in the case above). We need to allow labs to report it as they're systems are capable of doing so. So, changing the cardinality of the "associated phenotype" component fro 0..1 to 0..* seems quite necessary.
Bret H (Mar 27 2019 at 15:02):
@Larry Babb what do you see as the worst potential outcome if IDP can have 0..* phenotypes? One concern was that the levels of evidence might differ.
Larry Babb (Mar 27 2019 at 18:56):
@Bret H I'm not sure I understand what you mean by levels of evidence. I don't think there's a terrible outcome if folks pass multiple phenotypes/diseases for a given variant interpretation in a diagnostic observation. We will absolutely need it in situations where there isn't a perfect single id for the phenotype or disease or condition being assessed (yes, it happens). Sometimes geneticists or assessments are made and the best the reporting lab can do is offer a set of phenotypes or a couple of diseases that may be an either-or or a both-and situation for the interpretation.
I think we could add some comment to the profile's field that says when you use multiple phenotypes you are assuming to state that all of the phenotypes together identify the condition being assessed or interpreted, they are not intended to be mutually exclusive or separate. If so, then you should consider providing two separate interpretations, one for each separate disease (even if the evidence and final interpretation is identical).
Bret H (Mar 27 2019 at 19:08):
@Larry Babb "one for each separate disease" Kevin P suggested: "4 observations (1 variant, 3 inherited disease path (IDP) that all .deriveFrom() the variant )" Each of the inherited disease path profiles would be specific to one disease. Sounds like that will work for you.
Larry Babb (Mar 27 2019 at 20:25):
No, it won't work all the time. We definitely will need to allow for the situation where a single IDP has multiple Diseases or Phenotypes.
Kevin Power (Mar 27 2019 at 22:01):
@Larry Babb regarding the "multiple levels of evidence", we have a couple of things that are associated with all our "implication" profiles:
http://build.fhir.org/ig/HL7/genomics-reporting/obs-implication-definitions.html#Observation.component:evidence-level
http://build.fhir.org/ig/HL7/genomics-reporting/obs-implication-definitions.html#Observation.extension:relatedArtifact
To be transparent, we have some work to do around the 'evidence-level' component - in concept it is fine, but not sure how successful we will be finding a common way to represent it.
Also @Larry Babb -- Regarding the different IDP instances for each Phenotype, I am not sure why you would say it won't work all the time? It may not be ideal, but it would work in that you would be able to structure what you need to send right? You just have to send as multiple Observations (1 per phenotype), and keep everything else the same. Or am I missing a point?
Having said all that, making it 0..* adds flexibility, and if everything else is the same for multiple diseases, we should allow it. Mullai posted an example (Mar 20 in this thread).
Larry Babb (Mar 28 2019 at 12:35):
Thank you for the pointers to the evidence-level component. I am trying to sort out how that would work for the var pathogenicity interps being reported. (I may need to speak with you guys on this as I am not quite understanding it from the links you sent.)
In regards to the phenotype issue, I think there's still a miscommunication going on. Here it is...
Occasionally, there are situations where a single phenotype term does not exist to define an acceptable representation of the condition that is caused by a given variant. If you look in ClinVar you will find a number of interpretations that have multiple conditions/phenotypes/diseases (all the same thing - for our purposes here). When this occurs we need to allow the reporting lab to group more than one phenotype to create a custom composite condition that best represents the condition that the variant is associated with. If you break this up into separate observations it would be perceived as independent assertions that the variant causes each phenotype without a dependency on the other, when in fact the reporting lab wants to be able to say "this set of phenotypes occur all together in relation to the causality of the variant".
I realize that the example we provided from Baylor may be the case where Baylor simply lumped two different conditions that are essentially the same thing because they found evidence for each independently related to the same variant. So, this may be causing the confusion. Folks will continue to provide a list of "similar" or "independent" items, but we should add guidance (as ClinVar does on its submission) to break up the assertions based on the independently assessed conditions, whether they be a single term or a collection of co-occurring terms.
Kevin Power (Mar 28 2019 at 15:30):
If you break this up into separate observations it would be perceived as independent assertions that the variant causes each phenotype without a dependency on the other, when in fact the reporting lab wants to be able to say "this set of phenotypes occur all together in relation to the causality of the variant".
...
but we should add guidance (as ClinVar does on its submission) to break up the assertions based on the independently assessed conditions, whether they be a single term or a collection of co-occurring terms.
Ahh, I get it now. I think you have convinced me.
Kevin Power (Mar 29 2019 at 18:14):
Based on the feedback here, I have proposed making GF#20552 Persuasive. If anyone disagrees, comment here or we can discuss during a meeting.
Jamie Jones (Mar 29 2019 at 18:41):
Sounds good to me after the clarification
Bret H (Apr 01 2019 at 23:36):
@Larry Babb @Kevin Power @James Jones Umm, this does not seem right. "this set of phenotypes occur all together in relation to the causality of the variant". give me a hard example please
Larry Babb (Apr 02 2019 at 11:52):
you can wade through clinvar to find many examples of individual assertions/submissions/interpretations made by clinical testing labs that have multiple phenotypes. Here are a couple I identified for you to peruse
https://www.ncbi.nlm.nih.gov/clinvar/variation/523247/#clinical-assertions
https://www.ncbi.nlm.nih.gov/clinvar/variation/523257/#clinical-assertions
https://www.ncbi.nlm.nih.gov/clinvar/variation/52953/#clinical-assertions (LA Children's hospital chose to list phenotypes instead of assert LongQT - who are we to tell them that they can't do this?)
probably the best example is here from the LMM
https://www.ncbi.nlm.nih.gov/clinvar/variation/53685/#clinical-assertions (SCV000271348.2)
To read the lab's full text interpretation which should provide evidence that the clinical lab wants to convey an alternative or milder form of Cystic Fibrosis (no single disease/pheno code) when interpreting a finding for this pathogenic variant in a patient
go to this tab on the clinvar variant page https://www.ncbi.nlm.nih.gov/clinvar/variation/53685/#summevdesc1
and click on the "Full description" link in the rightmost column labeled "Description" for the "Laboratory for Molecular Medicine, Partners HealthCare Personalized Medicine" row.
I do agree that this is not super common, but it happens enough that we need to allow for it. If not then we have to have a much bigger discussion with the clinical lab folks to get them all to agree that they will never need to classify a causal interpretation on more than one phenotype at a time (seems unrealistic).
Bret H (Apr 04 2019 at 14:34):
@Larry Babb Thanks. I'll take sometime today and respond to each example.
Bret H (Apr 05 2019 at 13:23):
@Larry Babb @Kevin Power @James Jones I think within the following response you can see why I am cautious about changing the cardinality. https://www.ncbi.nlm.nih.gov/clinvar/variation/523247/#clinical-assertions Generalized development delay with Generalized Hypotonia VERSUS Gen. Development delay AND Gen Hypotonia I see two possible ways to model this depending on clinical intent. The 'AND' is the classic use of the IDP but the first model would be a further specification on Generalized developmental delay – we do not have a type of relationship. Not clear which is intended. This record would be sent with two independent diseases.
https://www.ncbi.nlm.nih.gov/clinvar/variation/523257/#clinical-assertions Same as above. No way to tell if intent is that the conditions listed are modifiers or independent.
https://www.ncbi.nlm.nih.gov/clinvar/variation/52953/#clinical-assertions Interesting. Submission accession is a grouper, but again how the conditions relate to each other within a submission is not clear.
If we allow * (multiple) then all of the items need to share the same attributions, such as evidence, annotator. Or as in above the submission accession. see comments at end
Regards listed values, these are unbound
https://www.ncbi.nlm.nih.gov/clinvar/variation/53685/#clinical-assertions (SCV000271348.2) A major caveat, is that the attempt is to relate knowledge about the variant. This is not about what conditions the patient has but what conditions have been associated with a change at a specific position in some patient's genome. So, we need a model for knowledge. ClinVar includes evidence, and the summary page has several fields that are useful. Also, the entries demonstrates a need for a model of inherited condition that includes inheritance pattern. These fields exist in the profile but are linked to a specific phenotype by the use of cardinality of 1 for the phenotype component.
If we change associated phenotype to have * then we should move inheritance pattern, dr-relatedArtifact, evidence into the component. OR we need to provide guidance that one should only put in multiple phenotypes/conditions if all the attributes of source and evidence are the same.
Note the LOINC code for the component is 81259-4, it has not restrictions on what value set can be used for “the possible phenotype associated with the genetic variant found in this study” Also the LOINC code is in trial, might be able to get the wording to be clearer.
Larry Babb (Apr 05 2019 at 13:53):
@Bret H I'm still confused (I think).
When reporting molecular diagnostic interpretations, folks often confuse the notion that the lab is providing a diagnosis or making a direct statement about the condition of the patient/subject. It isn't. It IS saying that a clinically significant variant has been found in the patient based on the regions sequenced and analyzed by the diagnostic methodology used. But to arrive at the point where the lab determines to report on an identified variant found in the sequencing portion of the test (that is to say it is either "clinically significant" or "uncertain as to its significance" or even "benign but interesting because its novel"), the lab will research the variant independent of the patient to gather evidence that can support or refute its pathogenicity for a genetic condition (well defined or specific) that is in the same domain as the indication for testing. It may not be a condition that the patient has. The "molecular interpretation" or "inherited disease pathogenicity" result is a related assertion about the variant that happened to be found in the patient. It is not stating that the patient has the disease or will have the disease/condition.
The labs that create their own assertions (like those that they submit to ClinVar) reuse this patient independent information to share with providers when a patient is found to have that variant and a related indication.
So, we need to be able to allow the labs to convey a "genetic condition" in any form they want. While its a nice idea to restrict them to OMIM or Orphanet or DOID or MeSH or UMLS or SNOMED or other coded diseases, these genetic conditions aren't always cleanly defined and available. So, from time to time, the clinical lab feels more comfortable reporting a set of disease/phenotypes to lump or split the available options. There is a continual domain level effort going on in ClinGen and the community to allow expert groups to lump and split diseases and request that the authoring systems like omim, mondo (monarch initiative), doid, orphanet, etc... will generate codes when they are needed. But the state of genetic conditions is still quite volatile.
This is one of the main reasons we can't simply say "let's use snomed codes for genetics" or "let's just use OMIM".
I realize that folks will misuse it, but I don't think that's our concern. We are a "guide" and a specification to "enable" the ability to report what is needed to be reported.
In the end, I'm fine if you leave it as a cardinality of 1. We can always provide our own extensions if necessary in order to get the job done.
Bret H (Apr 05 2019 at 15:31):
@Larry Babb I do think there is some confusion. First are we talking about the same profile? http://build.fhir.org/ig/HL7/genomics-reporting/obs-inh-dis-path.html
The component Associated phenotype does not have a specific value set.
Kevin Power (Apr 05 2019 at 19:13):
We don't have the best of examples for the IDP profile (maybe no examples). I think those ClinVar entries would make for some really interesting examples to create. @Bret H - would you be able/willing to take a crack at it?
BTW - Regarding Bret's ClinVar examples, I think I agree with his comment:
OR we need to provide guidance that one should only put in multiple phenotypes/conditions if all the attributes of source and evidence are the same.
Larry Babb (Apr 07 2019 at 23:33):
Yes we are talking about that profile. I'm fine that the valueCodeableConcept is not bound to a value set. I think it is presumed to contain coded terms or non-coded text terms for phenotypes and/or disease.
Bret H (Apr 09 2019 at 15:11):
@Larry Babb So you understand that the profile allows use of OMIM, or DOID or other coded diseases etc... correct?
@Kevin Power yes, would be a good idea. on it.
Larry Babb (Apr 09 2019 at 17:00):
@Bret H yes I understand. I'm not focused on the value set. I'm more concerned about the restriction of the cardinality to a max of 1 ( 0..1 ).
Our first emerge report example has 2 and I'm confident there will be many others with more than one. So we will need to either create our own extension if the profile cannot be changed.
Bret H (Apr 11 2019 at 13:20):
It is early in the discussion to talk about creating an extension (so far the count in this chat is 3 -1 -0 in favor of increasing cardinality :slight_smile: ), besides I would recommend slicing on the component associated phenotype over an extension. @Larry Babb Let's talk through the elements in the profile first. What is in common about the multiple phenotypes you would report? Do they share the same inheritance pattern? This get's back to the comment "we need to provide guidance that one should only put in multiple phenotypes/conditions if all the attributes of source and evidence are the same." What are your thoughts on this guidance? Would it matter for the receiving system?
Bret H (Apr 11 2019 at 13:23):
for example referring to: possibly adding supporting evidence for the phenotype-variant link with related artifact (http://build.fhir.org/ig/HL7/genomics-reporting/obs-inh-dis-path-definitions.html#Observation.extension:relatedArtifact )
AND
modes of inheritance http://build.fhir.org/ig/HL7/genomics-reporting/obs-inh-dis-path-definitions.html#Observation.component:mode-of-inheritance
and
Are all the phenotypes secondary findings
http://build.fhir.org/ig/HL7/genomics-reporting/obs-inh-dis-path-definitions.html#Observation.extension:secondaryFinding
Larry Babb (Apr 11 2019 at 15:03):
This is way out of my league. I would have to defer to the clinical geneticists that report these interpretations based on sets of phenotypic features/diseases.
@Bret H what is the harm in allowing multiple phenotypes? It seems that i most of the modeling work we air on the side of flexibility to cover a broad set of use cases (some would argue so broad that it begins to loose the simplicity needed for adoption - but I digress).
I'm unclear as to why this is a sticking point. If we can cite 100s of records in ClinVar with interpretations that are developed and used by clinical testing labs that have multiple diseases/phenotypes, then why isn't that sufficient evidence to loosen the 0..1 constraint?
At this point, I'm fine with the decisions that the CG IG group makes and am not likely to continue spending additional time and effort on this issue as we are in a place that we need to do something that deviates from the draft model, so we will find a way to do it.
I do appreciate your thoughtful and in depth responses and requests for more clarity. I would defer to other resources that may have opinions or insights on this matter. If they do not concur with how ClinVar allows interpretations to have multiple diseases/phenotypes on a single record or feels that ClinVar is not a representative model for how clinical reporting of genetic interpretation then I would say that this issue should be closed.
Bret H (Apr 15 2019 at 11:54):
@Larry Babb I don't think anyone on this chat is resistant, just a recommendation to include guidance (again if this zulip were a vote, there would be 3 asking for a change and 1 caution, seems clear that the recommendation would be to extend the cardinatlity @Kevin Power @James Jones, care to comment ). Please consider the components mentioned in the previous post. If you have an instance with multiple phenotypes then you would want be sure the values for those components were all the same. For example, if you had two diseases A and B, and the level of evidence linking the diseases with the related variant observation was different, then you would need two separate instances of the inherited disease profile.
PS I'm still working on an example based on one of the ClinVar Records.
Larry Babb (Apr 15 2019 at 12:59):
@Bret H thanks for the clarification. And, I agree with your concern regarding combining diseases with combined observations that are different. I'm pretty sure that is not the case. It is much more likely that some/most of the multiple disease assertions are situations where both diseases satisfy the single interpretation and it should be two separate interpretations. However, lots of folks struggle with the number of disease authorities and potential for similar or nearly similar diseases, so they tend to put multiple to make sure that all groups understand that either is appropriate for their interpretation.
Bret H (Apr 15 2019 at 13:05):
no problem. the change means one would be able to send one profile instance with multiple entries for each database (system), or one could send each database reference in a separate profile instance. I'm almost done with some examples, hope you will comment on them.
Kevin Power (Apr 15 2019 at 13:56):
This tracker is in the block vote this Tuesday:
GF#20552 Associated+Phenotype+Component+element+in+Inherited+Disease+Pathogenicity+Resource (Mullai Murugan) Persuasive
Bret H (Apr 29 2019 at 16:12):
I lost track of examples. will post late this evening. But looks like we have resolution.
Bret H (Apr 30 2019 at 17:12):
@Larry Babb @Kevin Power example based off of https://www.ncbi.nlm.nih.gov/clinvar/variation/53685/#clinical-assertions The first entry in the GERMLINE table was used.
idhExample04152019.xml
The pubmed references are added as related artifact, as well as the clinvar page.
Kevin Power (Apr 30 2019 at 19:48):
Thanks @Bret H - This aligns with what I was expecting.
Larry Babb (May 07 2019 at 13:15):
@Bret H Thanks for the example.
I have a question about the relatedArtifact.
I see in the FHIR docs that "type" is required, but you use "reference" which I presume is how you deal with the "resource" attribute in the RelatedArtifact . In any case, I think type should be used and it should probably be any one of (justification|derived-from|citation). I also presume you lumped the comma separated list of pubmed ids so that you did not have to write out all 10 references. I don't think the comma-delimited list would be considered a single reference (if you disagree please discuss). Finally, for precision, in case others are using this. I would have made the "clinvar" reference a type='justification' for sure and used a url that would have more precisely linked it to the SCV record SCV000271348.2 with version so that it clearly points to the LMM submission and is not mistaken for the entire set of assertions associated with variation ID https://www.ncbi.nlm.nih.gov/clinvar/variation/53685/#clinical-assertions.
Bret H (May 21 2019 at 16:18):
@Larry Babb The data-type is reference meaning a refering to an URI or URL. The pubmed ids were in the URL as a commadelimited list - so it's a valid URL string (which just so happens to eliminate the need to use multiple URLs - thanks pubmed). Can you point me to the 'type' you mean? I think you don't mean data-type, right?
Bret H (Aug 21 2019 at 02:51):
@Larry Babb is correct. The example needs the Type field with a value of 'citation' for the pubmed reference in the related artifact elements. Agree with the use of type=justification. Good catch on the Clinvar reference, you are correct we're only describing the LMM entry.
Bret H (Aug 21 2019 at 02:52):
@Kevin Power @James Jones note that the example of related artifact needs the type field. Just noticed this post Larry hadn't replied but I did some digging and think I found what he was referring to. With the addition of type and changing to the specific clinvar reference then we have a good example. @Larry Babb agree? Thanks for looking
Bret H (Aug 21 2019 at 03:06):
@Larry Babb can you help with the reference to SCV000271348.2 in ClinVar? how would you reference it? I'm leaving the reference I have as a citation. but it would be great to have a reference to SCV000271348.2 with type justification.
Bret H (Aug 21 2019 at 03:06):
Larry Babb (Aug 21 2019 at 12:07):
@Bret H I guess you won't be able to use RelatedArtifact for the SCV reference since it requires a URL. It does raise an interesting point if you'd like to be able to relate an artifact that is not dereference-able with a URL you will be out of luck. I think the SCV could be treated as a coding type with a system and value of "ClinVar" and "SCV000271348.2" but that does not help us with RelatedArtifact. Maybe this is a case where some RelatedArtifacts are simply general pointers that contain the true source of "justification" that the producer of the record is trying to reference. I suppose this approach runs the danger of consumers of the information reading too much into what is meant by the relatedArtifact, but then that would be a consumer issue I suppose.
On a related note, we (ClinGen and GA4GH) are continuing to sort out standards around linking structured evidence that supports assertions (like statements of pathogencity) where supporting and (refuting) evidence is more precisely communicated. I think this is likely out of scope for FHIR at this time (maybe the CDS or CQI workgroups will be tackling this eventually).
Bret H (Aug 21 2019 at 18:26):
@Larry Babb is there no way to access the SCV record? you don't need to use a url. The document could be attached or use the link in the related artifact to a profile that has the details of where the record is. Regards statements of pathogenicity - I do hope you'll look at the components in the observation example for inherited disease. The components are quite useful and are meant to cover the area. But based on what you are describing, a profile for guidlines might fit the bill. But the profile is meant to be used as part of clinical pathways, so it might not be perfect. Totally agree that CDS and CQI groups could benefit from input in creating knowledge artifacts for genetic knowledge - be really awesome if the NLM took on the responsibility of maintaining a repository of public knowledge. We'll have to get used to not including the evidence in the documentation sent to the EMR - references in FHIR are awesome (check out URIs in the FHIR spec - you specify the endpoint, profile name and ID). If ClinGen used that for their records then using SCV000271348.2 would be a snap. It would be better than having to use components to accomplish the task. What you will get is a link from the observation to the supporting knowledge artifacts. Love to see EMERGE at the connectathon or at a break-out session. Do you know if anyone is coming?
Larry Babb (Aug 21 2019 at 18:46):
@Bret H RE: SCV access
the SCV record is accessed on the aggregate variant page (in the list at the bottom) for which you already have the URL. ClinVar has no url that isolates only a single SCV record, the SCVs full data can be accessed in the table at the bottom and by selecting the Evidence details link shown by the red arrow. But no isolated page per SCV.
Larry Babb (Aug 21 2019 at 19:16):
@Bret H RE: emerge at Connectathon... Neither Mullai or I are intending to attend. Sorry.
RE: components of inh-dis-path and obsVariant profiles (and others)...
I have looked them over very carefully. I do think that they offer tons of flexibility in allowing users to represent complex observations using a broad group of attributes that can be stitched together in a multitude of ways. However, this flexibility conflates the challenge of building higher order Observations that then deriveFrom them (e.g. ObsHaplotype or ObsGenotype derivedfrom ObsVariant). In any case, I'm likely getting off topic.
RE: a profile for guidelines...
I think I've lost the original context of what this is referencing. I thought this reference was something you made originally from my post of Variant Data Type Proposals which was more about providing a definitional representation of variants (independent of Observation) but then useful for referencing in the Observation.valueXXX section so that we don't have to use a mixed bag semi-conditional attributes to craft a variant in a "structured" way. It would also enable us to use these definitional resources or data types to build more complex and standard variant structures and avoid the ObsGenotype derivesFrom ObsHaplotype derivesFrom ObsVariant situation which is not useful in moving in the direction of computationally reliable and clinically accurate genetic test result findings.
The term guidelines to me is more about the methods and SOPs defined by groups like ACMG, CAP, AMP, ASCO, etc.. that provide standards for how the assessment of variation is to be performed in a consistent and useful manner to support clinical practices. I think I'm confused on what you're meaning of guideline is here. I do not see any Resource called guideline and am not picking up the context from your reply. Sorry for my thickheadedness.
BTW - thanks for your patience with me and all my requests etc...
Last updated: Apr 12 2022 at 19:14 UTC
