ISO 639-1 creates a bunch of 2 character codes for active languages.
ISO 639-2 creates 3-character codes for major languages, active or not.
ISO 639-3 creates 3-character codes for all languages.
These codes are incomplete, because while they describe language, they do not address dialect, which can be critically important to interpretation. Just ask anyone from the country where English originated ;-)
RFC 4646 is the coding system that is commonly used to encode languages on the web, and the first part of the code is the shortest ISO-639 code for the language. That means a 2-character code if it's in 639-1, or a 3-character code from 639-2 or -3 if not. It also happens to support dialect. Just about everyone uses these in web applications to identify languages, and there's quite a bit of software that knows how to deal with it.
In CDA (including Consolidated CDA and QRDA), the patient's preferred language is recorded in the languageCommuncation structure:
It just happened that ISO 639-1 is a legal subset of RFC 4646, and so it was not really a problem when they specified that in Meaningful Use. But now they've gone and changed it to 639-2, and it does create an interesting kerfuffle.
Here are the relevant comments in the Final Rule as to why they changed it:
Comments. Some commenters expressed support for the ISO 639-1 standard. One commenter recommended the ISO 639-3 standard as being more comprehensive. Another commenter suggested adopting the 2009 IOM recommendations on how to ask for language data. Multiple commenters suggested that we should use ISO 639-2. The HITSC clarified in their comments that their recommendation to ONC was that preferred language should be expressed by constraining 639-2 to those that are in ISO 639-1, noting that 639-1 includes only active languages, while 639-2 includes languages no longer in use. A few commenters asked for clarification as to whether all languages listed in the standard must be visible for a customer to select.
Response. We agree with the clarification provided by the HITSC. Accordingly, we are adopting ISO 639-2 constrained by ISO 639-1. This will constrain ISO 639-2 to only the active languages in ISO 639-1, but will permit the use of the alpha-3 codes of ISO 639-2. As such it is a better approach than adopting solely ISO 639-2 or 639-1. We believe that ISO-639-3 exceeds the baseline we seek to specify for certification and have not adopted it. Last, in response to the commenters request for clarification, EHR technology is not required to display all the languages of the standard to meet the certification criteria. But, it must be capable of recording a patient’s language according to any of the languages in the standard.
Note the underlined text: This will constrain 639-2 to ONLY the active languages of 639-1, but will permit the use of the alpha-3 codes of 639-2.
I'm not sure the use of these 3-character codes is an improvement. The final rule broke (modestly, and arguably in a way that won't matter much, and is certainly still implementable) one of the standards, in order to make a change in another that has the ONLY effect of changing the code values, not the semantics.
Why change it at all? They really aren't clear as to the value of 639-2, especially given that they've limited it to those codes found in 639-1. And in fact, RFC 4646 is more widely used, and has greater value, in that it allows reporting of a particular dialect.
This is something that can be fixed, but something has to change. Either the final rule, or the HL7 CDA Standard as used in the US. I'd rather the final rule was fixed, but could be convinced it's easier to adapt HL7 CDA as it is used in the US. That latter part is going to be a wee challenge, because right now, we don't have a US Affiliate with the capability to do so, but I'm sure HL7 could find a way to adapt to this. It's really a shame we have to do either.
Even so, I'm still pretty please with the Final Standards rule. It's hard to get nearly 500 pages of text right all the time.
-- Keith
0 comments:
Post a Comment