Extensions representation

[niquola]

Problem

Extensions representation is essentially driven by statically typed implementations and XML. Both of have troubles with custom key-value objects and force to represent extensions like a collection. Such representation again forces constraint on collections, unnecessary order, complexity with incidental accessing such attributes and expression in JSON schema. But for JSON-like data-structures more natural would be use object representation - just compare:

{
  resourceType: "Patient",
  extension: [{
      url: "ombCategory",
      valueCoding: {
        "system": "http://hl7.org/fhir/v3/Race",
        "code": "2106-3",
        "display": "White"
      }
    },....
  ]
}

pt.extension.where(system=...).valueCoding.code

{
  resourceType: "Patient",
  extension: {
    "omb/race": {
       $type: "Codding",
       coding: {
         system: "http://hl7.org/fhir/v3/Race",
         code: "2106-3",
         display: "White"
       }
    }
  }
}

pt.extension["omb/race"].coding.code

Notes

Problem with polymorphic elements and extensions is solved very nice in json-ld by context. So, may be we could use json-ld with some constraints/conventions as primary format for FHIR JSON.

Also Grahame published manifest proposal, which is similar solution - http://www.healthintersections.com.au/?p=2626