Here’s another angle that complements yours. Assume you have lots of money, either as a gov org or as a tech company and you want to hire great staff. What’ll you do when engineers do not want to work with openEHR because it is such a big divergence from the safe career path?
This is happening to us at all levels of hiring. Technical staff keep an eye on where they’re going from a tech-stack perspective, and they want to make sure what they’ll be working on will improve their prospects in the industry a few years down the line. So in the interviews they ask us if they’ll be working with Spring Boot, Asp.net core, microservices, DDD, GraphQl, REST, OpenAPI etc. Don’t even get me started on explaining what we do to recruiters, without whom you can’t deal with the signal/noise ratio of the candidate pool.
If you fail to isolate the engineering complexity and very specialised tech aspects of openEHR to a degree, you can’t grow the technical capability you need, even if you have the money. This is why I keep repeating “off the shelf tech, off the shelf developers” for years: narrow and extreme specialisation becomes a sustainability problem, not only for the customers, but even for the vendors
I’ve been working on one healthcare platform company or another for 20 years now, and based on that I’d say you’ll always have a technical pyramid where you have a few core platform people at the top, and you’ll only grow the delivery capability by growing the base of the pyramid, where you have abundantly available developers working on whatever the trend is at the moment. FHIR absolutely nailed extending that base by pushing the whole spec as REST, which is what every line of business application developer knows.
If you insist on people having to conquer the complexity, and don’t focus on extending the base of your tech pyramid, you’ll end up with an ivory tower of tech.
Gary’s points and other feedback here would serve to extend the base of the pyramid.