Stream: implementers
Topic: Extensions - Representation
nicola (RIO/SS) (Oct 12 2016 at 09:30):
I want to raise again the question about extensions representation (at least in JSON).
It is really convenient to represent extensions in JSON as object not array:
- Semantically extensions more key-value (dictionary, hash-map), then list - we want to access race like gender
- Easy to write profile's restrictions
- From UI perspective (binding attributes/elements to widgets) - no conversions from list to object and back
- From databases perspectives (access specific extensions by key, not by filter): resource.extension.race vs resource.extensions.filter(url: 'race')
Examples:
[
{"url":"http://hl7.org/fhir/ValueSet/v3-LivingArrangement","valueCodeableConcept":{....}},
{"url":"http://hl7.org/fhir/StructureDefinition/us-core-race","valueCodeableConcept":{...},
{"url":"http://hl7.org/fhir/StructureDefinition/us-core-ethnicity","valueCodeableConcept":{...}},{"url":"http://hl7.org/fhir/v3/EducationLevel","valueCodeableConcept":{...}},
{"url":"http://hl7.org/fhir/StructureDefinition/patient-adoptionInfo","valueString":"no"},
{"url":"http://narus.com/when-adopted","valueDate":"2010-09-03"},
{"url":"http://hl7.org/fhir/ValueSet/anzsco-occupations","valueString":"Telecommunications Engineer"},
{"url":"http://narus.com/fhir/date-married","valueDate":"1988-12-23"},
{"url":"http://narus.com/fhir/supportive-employer","valueString":"true"}
]
vs
{
"http://hl7.org/fhir/ValueSet/v3-LivingArrangement": { valueCodeableConcept":{ ... }},
"http://hl7.org/fhir/StructureDefinition/us-core-race": { valueCdeableConcept: { ... }},
"http://hl7.org/fhir/StructureDefinition/patient-adoptionInfo": {"valueString":"no"},
"http://narus.com/when-adopted": {"valueDate":"2010-09-03"},
"http://hl7.org/fhir/ValueSet/anzsco-occupations": {"valueString":"Telecommunications Engineer"},
"http://narus.com/fhir/date-married": {"valueDate":"1988-12-23"},
"http://narus.com/fhir/supportive-employer": {"valueBoolean": true}
}
Or with separation of schema and data:
{
$schema: {
livingArrangement: {url: "http://hl7.org/fhir/ValueSet/v3-LivingArrangement", type: 'CodeableConcept'}
race: {url: "http://hl7.org/fhir/StructureDefinition/us-core-race", type: 'CodeableConcept'},
adoption: {url:"http://hl7.org/fhir/StructureDefinition/patient-adoptionInfo", type: 'string'},
whenAdopted: {url:"http://narus.com/when-adopted", type: 'date'},
occupation: {url:"http://hl7.org/fhir/ValueSet/anzsco-occupations", type: 'string'}
marriedDate: {url:"http://narus.com/fhir/date-married", type: 'date'},
employer: {url:"http://narus.com/fhir/supportive-employer", type: 'boolean'}
},
livingArrangement: {coding: ...},
race: {coding: ....},
adoption: "no",
whenAdopted: "1980"
occupation: "Telecommunications Engineer",
marriedDate: "2001"
employer: true
}
Clark C. Evans (Oct 12 2016 at 12:47):
Nicola, I very much like the latter, separated. representation.
Grahame Grieve (Oct 12 2016 at 19:38):
we balloted a variation on the 2nd for DSTU2. It was soundly defeated at ballot.
Brian Postlethwaite (Oct 12 2016 at 21:42):
Not a dictionary either, as keys can be duplicated, and also need to extend extensions.
nicola (RIO/SS) (Oct 13 2016 at 08:49):
@Brian Postlethwaite In 80% of cases it is key/values, in case of collections it could be done like:
extension: {
someExt: [ 'value', 'value']
}
Nested extensions are good example how bad current representation is :) I would like to see something like:
extension: {
complexExtension: {
key1: '...',
key2: {
subkey: '....'
}
}
}
And the question is only how to represent schema for this situation.
Josh Mandel (Oct 14 2016 at 01:28):
Remember when we used to have:
{
"resourceType": "Patient",
"id": "123",
"http://mydomain/some-extension": [{
:-)
}]
}
I think I'm the only person who liked it ;-)
Grahame Grieve (Oct 14 2016 at 19:11):
you weren't the only one, but it was surprisingly less popular than I expected
Brian Postlethwaite (Oct 15 2016 at 01:20):
None of the code generators would have ever liked that property name ;)
Last updated: Apr 12 2022 at 19:14 UTC
