Grahame is talking about “interoperability” and “intraoperability”, as different design philosophies for creating standards for system that “work together”. I feel not too competent to comment on the openEHR vs. HL7 aspects of this discussion, but it might be interesting to look at other examples of both.
Most of the internet and web protocols are really built around the idea of interoperability (as defined above): vendors, academia, others, get together, define how the network facing interfaces and protocols are supposed to look like (syntax) and – for the more succesful ones – also what they mean (semantics). This works exceptionally well, especially in environements where the semantics are simple (well defined, not too many elements and/or variations, etc.).
For the “intraoperability” I have really a hard time finding useful examples. To some extent, the SPARC consortium would come to mind, or one might view some of the JEE and other APIs standards as attempts to narrow how a system should be built. However, for most vendors the temptation to add a few “value-add” extensions (a.k.a. vendor lock-in functions) is just too enticing. Note that this has also been seen with “interoperability”, where too many important fields where left for the implementer to define (NT-PAC data in the authorization field, anyone?).
As such I think that – while certainly problematic for high complex data models – “interoperability” seems to be the only realistic approach to get systems somehow to talk to each other.