For years the openEHR specs were not widely accepted in the US, part of it could be because the UK centric aspects of the current spec. Besides the specs being born and developed in the UK, some terms, spelling and modisms in the specs are not used in the US, like organiSation or null_flavoUr. Though I’m not a native Ensligh speaker, I have worked with a lot of US based companies and I write and talk US biased English
My general question would be if it does make sense to allow, specially for the models (classes, attributes, relationships), US-based names? For instance an archetype modeling tool would create an archetype for ORGANIZATION or a constraint for ELEMENT.null_flavor
This might seem an insignificant thing, but I think language is the initial barrier for adopting any new idea. Even though this is not really about “language” but about spelling and local terms.
When I used to go to a lot of CEN (and a few ISO) standards meetings in Europe, if we accidentally had any US English term on a slide or model, the Europeans criticised us for not using International English (it’s not UK English - there’s no such thing, and ‘British English’ is more about idiomatic expressions).
Anyway, a few things to say about this…
we started European (GEHR, and various EC funded follow-on projects) and using British / International English spelling was standard for all docs produced by all countries, in the English translation (or original, for us in the UK) - so we’re talking about the English of all countries except the US
we had very little interest from the US for most of openEHR’s history, I think mainly because of CDA being seen as a good enough equivalent, and in any case healthcare money in the US isn’t generally focussed on community or GP shared care, but on hospitals and HMOs (Kaiser etc); also we didn’t have any academic partner there;
we have actually thought about this issue before, but because modelling tools like UML and all programming and data languages (AFAIK) have no built in name aliasing that would allow software and e.g. Xpaths to just work with aliasing… there’s no obvious technical way to do it
exception: languages we control, i.e. AQL, ADL, BMM. Hence, ADL supports both ‘specialise’ and ‘specialize’ keyword (since 2003 from memory). I’d have to check whether there are any candidates in AQL, but if there are, US alternatives are easy to add.
we make a general assumption that although the software of any openEHR CDR or other tool will (usually) be written in English, in the international spelling flavour, what appears on the UI is completely a local question, and US English is really no different than a Norwegian or Spanish language (or … Catalan) UI.
openEHR is starting to get some interest in the US in recent times, but I have not heard anyone mention or notice the question of International English spellings in the models. If it became an issue, I guess spelling-translated forms of at least the UML models and open source software could be generated, but it seems like a low value and painful thing to do.
We’d probably all just use US English spelling in the anglo world, and we do use some words, but not generally spellings that break rules. E.g. British English: ‘modelling’, US: ‘modeling’. The latter breaks the standard rule of a double consonant following a short vowel. BR: ‘ageing’ (e follows g rule to keep the ˈeɪdʒ sound); US: ‘aging’. And ‘Aluminum’ is missing a whole syllable - and it’s the name of a chemical element! All those 'z’s are there because a certain Mr Webster just like the letter zed (which of course he renamed). The removal of letters from words like ‘colour’, ‘catalogue’ etc doesn’t really matter much but I doubt we’ll change. Interestingly, the spelling mix in Canada is about halfway between US and British English.
The real problem for us in medicine is that both spellings of words containing vowel diphthongs like paediatric / pediatric (e.g. see here), foetal / fetal (e.g. here), haemorrhage / hemorrhage and so on are regularly used in English language medical documents, as the names of departments and products and so on, outside the US. Same goes for words like programme / program, and catalogue / catalog.
Words like ‘paediatric’ and ‘haemorrhage’ could easily appear in AQL or X-paths, using the modern web template way of representing data. The basis for making sure these can work in the US is already built into ADL archetypes, where you can override the [“en”] descriptions of terms with [“en-us”] alternatives (just like with [“es”] and [“es-uy”]), so a priori, tools should be able to accommodate US spellings where it counts.
I guess that depends from which shore you look at it similar thing happens with the units of measure.
That is kind of an issue, isn’t it? I mean, working on an international specification and explicitly having a part of the world segregated from it it’s kind of a bad strategy (even more when that part of the world is so meaningful in many aspects).
It depends, if people just read the executive summary of openEHR or people really going at the detailed specs for implementation guidance. I think these terms could generate some friction, could be minimal, but it’s still there. But I can only talk for me: for instance, each time I need to write ORGANISATION I need to fix my spelling.
I don’t think the content is an issue, since it’s a localization thing (or localisation? hehe). I’m talking about the specs themselves.
Anyway, I just wanted to raise the discussion to check what others think.
It is and isn’t I guess. US is HL7-dominated. The OMG (owner of a couple of small standards like UML, BPMN, etc) has had 3 attempts to produce health IT standards, and they get almost no traction - and they’re mainly US-based.
I think the thing that will take openEHR to the US is the dawning realisation that the patient-centric EHR still isn’t solved and potentially, process automation and/or CDS (i.e. GDL, Task Planning etc). But HL7 is always a factor - it always re-invents rather than working with other SDOs.
Interesting. The minor differences between US and International English creates “feelings” of not being relevant for own culture. Makes the 100 years dispute in Norway of Norwegian Bokmål vs Norwegian Nynorsk look very profound and important.
On this subject, I define my position as neutral. Will buy popcorn and watch the discussion.
No, no, no. Don’t get me wrong. From a social and psychological point of view I understand the question. It’s about having a sense of being included and represented. And maybe an element of rivalry between the empire and its past colony and an inherited need for having one’s own identity. It’s the same for Norwegian bokmål and Norwegian nynorsk.
Seeing a familiar language adds value, even though most reviewers in Norway would understand the English original language and it’s the reason we translate archetypes to Norwegian, Swedish, etc.
On element name, I thought it was the at code that matters. If correct, why not translate all International English archetypes to US English, if someone is willing to do that.
That was the trigger for the initial question. I don’t even have a point or strong opinion about this, just wondering what others think. I don’t think you will find any strong discussions here or any concrete changes for the specs or guides. For most people, this is not even something interesting to discuss, but maybe for a small group this is something that they will consider as substantial. On the other hand, I know maintaining something in multiple flavours of language is difficult. (see what I did there? sorry I couldn’t resist)
