I try to figure out what your reply has to do with the text you quote.
Maybe you try to formulate a sales-argument? Because that is what I am looking for and I was writing about.
Maybe I misunderstand the advantage of OpenEHR, and is what I think that is an advantage, in your opinion is a another way to a disaster.
Because you cannot just create an archetype for every something new that comes up.
I have done some thinking about this.
I wrote before on this list about a large hospital which developed its own information system, which grew to 7000 tables in 20 years, because all the time new therapies, new innovations, not only medical, but also organizational come up, how many people in a room, new insurance-requirements, new diseases, many things change in a large organization, many changes are not for medical purpose, but can have medical effect, and the software must support it all.
A friend worked in a telephone company, and they had their customer-information in a blown up database of 1200 tables, and he had to bring it back to, let's say, 100 tables. After a year, he was able to remove a third of it, and also repaired the according code, and then he was happy to find another job.
This is how software in a large organization, can explode to something which is very expensive to maintain, and in the end no-one really can understand what is going on in all details. Documentation often is unreadable 15 years after writing, and it often presumes knowledge of other details, which again brings you to many pages of the similar misunderstanding.
It are spaghetti databases, mostly surrounded by spaghetti code. Like a large building which grows without control. There are parts which you cannot go, some parts you can only go when you are very careful, there maybe machinery, some of it is running but no one knows in all details for which purpose.
I think OpenEHR can under circumstances avoid this spaghetti, because in the kernel, it remains simple, but it does not avoid chaos out of the box.
Archetypes can also become information-labyrinths. This will surely happen when the number grows to ten-thousands in 20 years. They have the advantage of having implicit documentation and context. There are no Codd myriads of tables, where dependencies of normalizations can spread to unexpected parts, but there are only archetyped object instances.
But still, there can be chaos, which archetype were we using for that situation in 2003, there may be five of them, depending on who used it and some other factors? There is the chaos, you don't know in which paths information is, so it may also be an exploded information system, with lots of information no one can find.
So, what I understand is, it is to define those 50.000 data points, and give them a unique path. Then when there is, for example a drug description, it will always be on the same path, and you don't need to know the purpose of a specific archetype when you want to list all drugs a patient has got in his lifetime, or if he had had a specific lab-test and what the result was.
But if this is the point, we have, indeed, the problem of semantical scalability. Good word for that.
50.000 data-points is not that much. We (not me, I am only the piano-player) need to give up the standards-war and work together on this.
And in the meantime, the advantage of using OpenEHR is limited? There is still the advantage of implicit documentation and context, which is a lot, and it is open for migration when the datapoints are standardized, which can be a phased process.
Maybe this is all very common knowledge in health-informatics. I should find a sponsor which pays for my trips to HIMSS, etc. 
Thanks for reading
Bert
