It appears that for simplicity's sake, the languages that a patient understands has been implemented as a CodeableConcept (list). Where a patient is a native speaker, the specification sets the expectation that there is Patient.communication ought to be kept empty. This will likely be a large percentage of exchanges of the patient resource.

When Patient.communication is provided, however, I believe that a user of a client application that is querying a FHIR server may not be able to use the Patient.communication data in a meaningful way because of the absence of information regarding the patient's proficiency level with speaking the native language.

We should consider enhancing Patient.Communication to track proficiency level and/or "needs interpreter" information as I believe that the majority of the systems that would track a patient's languages would also track this information.

Places where patients language is tracked along-side other "modifier" about that language:

HL7v2 LAN segment: LAN-2 = language, LAN-3 = Ability Code, LAN-4 = Proficiency Code

UK national EMPI service -> "Language Communication" object contains the language along with "Interpreter required indicator".

I don't know of systems that track whether or not the patient can read vs. write the language that is being recorded. I do know of systems that explicitly track "needs interpreter". I'm thinking that the later might be something worth including as part of Patient.communication (and thus it would need to be expanded from being just a CodeableConcept).

Submitting for discussion at the next available PA group meeting.