I am not understanding why an array of object is created where multiple languages are defined with preferred set to true or false for each. To me this doesn’t make any sense. How about one object with an array of additional languages?
{
preferred: {CodeableConcept},
additional: [ {CodeableConcept}]
}
why use this?
[{
language: {CodeableConcept},
preferred: <boolean>
}]
Doesn’t it makes sense that there’s only one preferred language? Why repeat preferred?
I could be wrong but it’s possible the thinking is that it is more flexible to have a structure that allows 0 or more entries (languages) of which each entry has a flag (true/false) to specify whether or not it is the preferred. As an implementer i guess it gives you the power to, in your implementation guide then specify constraints e.g. only one language can be preferred or you need at least one language marked as preferred for a Patient resource to be valid?
Perhaps you could pose your question on https://chat.fhir.org as well
There is no constraint that a patient can only have one preferred language - and some systems definitely support more than one. Also, if you don’t care about preference, it’s easier if you only need to check one element rather than two to see what languages are known.
My problem is with the data structure, I feel this is not optimal at all, it should be strings. Preferred and additionnal should be strings and additional an array of strings. Not an array with a boolean in it, you should only have one preferred language, no need for a boolean. What am I missing here?
You’re missing the use-cases of other systems. The design allows for multiple preferred languages because the implementer community has indicated that’s what they want. You are free to only expose one preferred language if that’s what your system supports, but you can expect to sometimes receive more than one from other systems. Typically in that situation, you’d just pick one as your ‘most preferred’ and ignore the others or require support for an additional extension that designated ‘most preferred’, putting the problem on the source system. In the worst case, you could treat multiple preferred languages as an error, but that wouldn’t be terribly interoperable/friendly.
All data structures in FHIR represent a compromise that may not always be optimal for a given system, but should be mapable to by most if not all systems.
Normally in this case I’d suggest submitting a change request if you feel strongly (using the ‘propose a change’ link). However, in this case, Patient is already normative. That means that breaking changes aren’t allowed anymore.
Ah, fair enough. I guess I saw it strictly from a developer’s perspective.
Tx