medizininformatik-initiative / fhir-ontology-generator

3 stars 3 forks source link

Make optional values and attributes configurable #112

Closed juliangruendner closed 2 weeks ago

juliangruendner commented 2 weeks ago

It should be configurable via the ontology query metadata whether or not a value or attribute is optional or not (true, false).

For this the following attributes should be added to the querying metadata:

for the value:

"value_optional": true

for each attribute:

TODO: discuss @paulolaup, @Frontman50 .

the current attribute is fully defineda s follows:

"attribute_defining_id_type_map": {
    "Encounter.class":  "",
    "Encounter.serviceType.coding:Fachabteilungsschluessel": "",
    "Encounter.serviceType.coding:ErweiterterFachabteilungsschluessel": "",
    "Encounter.type:Kontaktebene": "",
    "Encounter.type:KontaktArt": ""
  }

where the part after the id allows you to define the id type, e.g.

"attribute_defining_id_type_map": {
    "((Specimen.extension:festgestellteDiagnose).value[x]).code.coding:icd10-gm": "reference",
    "Specimen.collection.bodySite.coding:icd-o-3": ""
  }

the information could be potentially added in an extra attribute as follows "attribute_optional": ["Encounter.class", "Encounter.serviceType.coding:Fachabteilungsschluessel", "Encounter.serviceType.coding:ErweiterterFachabteilungsschluessel" ]

alternatively one could extend and change the attribute_defining_id_type_map as follows:

attribute_map:{
"Encounter.class":  {
"type": "",
"optional": true"
}
"Encounter.serviceType.coding:Fachabteilungsschluessel": {
"type": "",
"optional": true"
}
...
}

The result of setting the optional in the query metadata should lead to an update in the ui profiles as follows:

for value:

"valueDefinition": {
        "allowedUnits": [],
        "max": null,
        "min": null,
        "optional": false,
        "precision": 1,
        "referencedCriteriaSet": null,
        "referencedValueSet": "http://hl7.org/fhir/ValueSet/administrative-gender",
        "type": "concept"
    }

for attribute:

{
            "allowedUnits": [],
            "attributeCode": {
                "code": "class",
                "display": "class",
                "system": "http://hl7.org/fhir/StructureDefinition",
                "version": null
            },
            "max": null,
            "min": null,
            "optional": true,
            "precision": 1,
            "referencedCriteriaSet": null,
            "referencedValueSet": "http://fhir.de/ValueSet/EncounterClassDE",
            "type": "concept"
        }
paulolaup commented 2 weeks ago

I'd prefer the second option, i.e having some JSON object with further attributes for the defining attributes.

paulolaup commented 2 weeks ago

I assume there is currently some hardcoded default or implicitly assumed value?

If so should we change these defaultsfor each attribute once the optionality is configurable via the querying metadata files? For instance, if I would define for each defining attribute in the Fall QueryingMetadata definition whether its optional or not, does it then at that point make sense to treat them differently?

juliangruendner commented 2 weeks ago

I assume there is currently some hardcoded default or implicitly assumed value?

If so should we change these defaultsfor each attribute once the optionality is configurable via the querying metadata files? For instance, if I would define for each defining attribute in the Fall QueryingMetadata definition whether its optional or not, does it then at that point make sense to treat them differently?

@paulolaup default is always "true" - if configurable the default can still be "true". whether or not the optional can then be missing i have no strong opinion about - either works in my opinion