Discussion: Null key retention

[ir4y]

By default we remove all null values, but in some cases we need nulls (JSON PATH body is one of the examples).
So we introduce {{+ +}} template wrapper. That saves null.
The {{+ +}} syntax could be replaces by something more obvious, but we don't have a better solution yet. 

More details you can find in the readme: https://github.com/beda-software/FHIRPathMappingLanguage?tab=readme-ov-file#null-key-retention

[ruscoder]

Hi. I believe the purpose of FPML is to generate FHIR resources. A patch is only one use-case of usage null-retention. Patch is not valid as part of the transaction Bundle (according to the spec, entry.resource must be a valid FHIR resource, but patch in some cases might produce an invalid resource). However, some FHIR servers, e.g. Aidbox, support PATCH with invalid resources as transaction bundles. There are better options to do patching in the bundle - https://build.fhir.org/fhirpatch.html.

So, since it's a very limited use case, I don't think we should spend time on it, and let's just leave this operator as a hack.

[dkapitan]

@ir4y @ruscoder

I think FPML is also useful for mapping non-FHIR APIs (i.e. any REST API that outputs json) to FHIR. In practice, source systems often use sentinel values such as 999 to indicate missing values or other inferred 'flagged values'. I often find that sentinel values need to be interpreted differently from a null or blank value. So if at all possible, it would be good to support handling of sentinel values on the input side.

On the output side I have too little understanding for PATCH or any of the other mechanisms on null-retention, so I defer to your good judgement.

[ruscoder]

I just found an another use-case of null-retention, for FHIR primitive extensions. It's described here #30