Expansion of hgvs ValueSet about genomics-reporting

[patrick-werner]

Hi! (very cool to get another German participating in the IG, welcome and greetings from Mannheim).

We discussed this issue in the past weeks. Yes HGVS is a grammar and not a finite enumeration of codes, in FHIR this is still considered to be a CodeSystem. (Look at FHIR handling ucum, similar case: grammar expressed as CodeSystem).

What benefit do you see in setting this to extensible?
Extensible means: You can choose another CodeSystem (not HGVS) if HGVS can't express a HGVS code. Doesn't make much sense.

From an Implementer perspective a HGVS Validator Module connected to the FHIR Java Validator would be nice. Currently there isn't a Java bases Java ValidatorModule.
The work group would like to have such an module for HGVS, but currently there is none. Technically this could be implemented like the ucum service, implemented here:
https://hapifhir.io/hapi-fhir/docs/validation/validation_support_modules.html (10.3.8CommonCodeSystemsTerminologyService )

[nr23730]

Hi! (very cool to get another German participating in the IG, welcome and greetings from Mannheim).

Thank you! Greetings from the baltic sea!

We discussed this issue in the past weeks. Yes HGVS is a grammar and not a finite enumeration of codes, in FHIR this is still considered to be a CodeSystem. (Look at FHIR handling ucum, similar case: grammar expressed as CodeSystem).

I'm not too familiar with UCUM but to me it looks like a good comparison!

What benefit do you see in setting this to extensible?
Extensible means: You can choose another CodeSystem (not HGVS) if HGVS can't express a HGVS code. Doesn't make much sense.

On my site (HAPI 5.2.0) the server accepted the code with a warning after switching to extensible.

From an Implementer perspective a HGVS Validator Module connected to the FHIR Java Validator would be nice. Currently there isn't a Java bases Java ValidatorModule.
The work group would like to have such an module for HGVS, but currently there is none. Technically this could be implemented like the ucum service, implemented here:
https://hapifhir.io/hapi-fhir/docs/validation/validation_support_modules.html (10.3.8CommonCodeSystemsTerminologyService )

From a technical standpoint this would of course be a very clean solution. But can it be expected that other servers adopt and implement this?

[patrick-werner]

Ah!
Yes hapi is wrong ;-) Not beeing able to validate a code never should be an error, probably a warning would be correct.
Will address this in the hapi validation module soon, as i also can't live with this bug.

Will leave this issue open, and close it as soon the hapi part is fixed.

[bheale]

I disagree that it would be very clean. It would enable inappropriate use of the extensible modifier...but that's me being a purist. The problem lies in HGVS being a syntax and not an actual coding system. We could seek to change the component to be a string-value with a component.code for HGVS. But this makes it hard from a vocabulary perspective as well. So, here we are. We can't really use extensible and we can't really use strict. Can you think of a third alternative? we might need to revisit using the terminology approach for this component to communicate where the value can be evaluated...short of building an HGVS syntax checker into the standard FHIR server builds... PS awesome to have someone comment. It is comments and hard work like yours which will make this thing actually be useful. +1

[bheale]

I think I might have misunderstood the fix @nr23730 - are you talking about changing to warning over error? (apologies for my exuberance if I addressed the wrong fix).

[patrick-werner]

The problem lies in HGVS being a syntax and not an actual coding system.

@bheale same for ucum or ICD-10-GM or CodeSystems allowing post-coordination. This is still a CodingSystem, but hapi ist reporting an error on this, which is a bug. The Java Validator only throws a (correct) warning.

So the fix is: report/fixing the bug in hapi & double checking if the java validator still reports a warning.

[nr23730]

I think I might have misunderstood the fix @nr23730 - are you talking about changing to warning over error? (apologies for my exuberance if I addressed the wrong fix).

My initial proposal was to go from strict to extensible as I was expecting a warning instead of an error. As @patrick-werner mentioned that this is the desired behavior, but the issue is related to HAPI and not the definition of this IG I'm dropping this and of course would like to see this fixed in HAPI.

With clean I meant the idea of a dedicated validator, as this is probably the best way to validate against the rules of HGVS. At the same time I raised concerns about having such special snowflakes in the validation component, that each server would have to validate. But when I see that there should be no error and just a warning if such a validator is not present, I'm okay with that.

As my issue is not related to this IG I will close this.