IMHO to have a vs. there should be an overlap in scope, for me the overlap between messaging standards and ISO/EN 13606 is clear, but the overlap between FHIR and openEHR is yet to be found.
All I can see today, because it’s part of my daily work, is implementing both FHIR and openEHR in the same platform to support different areas of requirements. Right now I’m working for HiGHmed and we defined a FHIR broker on top of the openEHR backend CDR. I think it’s clear that FHIR is not for storing clinical information, besides that FHIR CDR people want to push that, is not for that. Either way we are using some parts of the FHIR storage to store information about audit logs, which I think suits perfectly if an ESB is not in place (since ESBs have their own logging system). So the data comes in FHIR, it is translated to openEHR and stored in the openEHR backend for usage. That usage happens at the openEHR API level getting compositions or using AQL. I think this architectural approach is the best of the two worlds: information interchange + information management and usage.