Parsing drops extensions on primitives

[jmandel]

Documenting a known issue: parsing FHIR resources with extensions on primitives silently drops the extensions. For example:

{
  "resourceType": "Patient",
  "gender": "male",
  "_gender": {
    "extension": [{
      "url": "http://test-extension",
      "valueString": "with extra data"
    }]
  }
}

[p2]

Yes, thanks! Also to have it documented: the Swift-FHIR framework now solves this by providing custom classes/structs for primitives. Those can handle extensions (and ids), as opposed to the native strings/numbers used by the Python client.

[dajaffe]

Hi - I just ran into this trying to return back resources which are using string extensions for language translations and attempting to as_json the resource, i.e.:

"item": [
  "text": "hello",
  "_text": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/translation",
         "extension": [
           {
             "url": "lang",
             "valueCode": "fr"
           },
           {
             "url": "content",
             "valueString": "bonjour"
           }
         ]
      }
    ]
  }
]

Is being able to support this planned in the future?

[mikix]

It is definitely something we ought to do. And as Pascal says above, one reasonable approach would be custom types. Something as simple as the following might work:

class StringType:
  value = None
  extensions = None

But... that's a big change, and a breaking one. There are also backwards-compatible options, like adding underscored fields that shadow all the primitives in the model classes.

I dunno, I haven't thought about it much yet.

But it's a direction we'd want to go and worth doing. Patches appreciated if folks have thoughts / time for it. But note that patches like that should be done in fhir-parser first, then ported here.

[p2-apple]

This should be possible without changes to fhir-parser, just updates to the Python-specific templates like fhir-parser-resources/template-resource.py

[mikix]

Yes it's possible for sure. But if we can keep the two repos in rough sync, that'd be nice - since this change isn't specific to fhirclient and all consumers of fhir-parser would appreciate the improvement.

[p2-apple]

We already do support extensions on primitive types in https://github.com/smart-on-fhir/Swift-FHIR (and https://github.com/apple/fhirmodels), with the current version of fhir-parser. We have a mappings.py override file for each FHIR release that we support, which contains classmap (and other properties). This is used to map the FHIR types to the type of our own library, you could do the same here.

See https://github.com/smart-on-fhir/Swift-FHIR/blob/master/fhir-parser-resources/mappings.py