For someone with your background, the answer would be: FHIR is an interface specification strongly coupled to REST over HTTP. openEHR is a system specification for what may potentially sit behind the interfaces.
I think we have different views of DDD. FHIR would sit even outside of Application Services, let alone Aggregates in a DDD design if I was the one doing it. As I indicated, it is an interface spec, not a system spec. openEHR is not bound to a specific technology, it is mostly a heavily Object Oriented shared kernel if you want to map these two concepts to DDD. If you disagree, let’s just agree to disagree please because I have no time to discuss angels on pinheads when it comes to DDD.
You’ll have N people and N + M perspectives as a response with a question like that: too subjective. I can see from your questions you’re expecting openEHR as a technology just to “fit” into your comfort zone, which appears to be JSON and REST. That’s OK, nothing wrong with that. Except it would not. In fact, neither does FHIR. You say you have 15 yrs of experience in healthcare, then you won’t find it difficult to agree that healthcare breaks everything when it comes to mainstream tech. Both FHIR and openEHR specification groups and implementers find it challenging to use mainstream data serialisation formats and architectures challenging. You have a more compartmentalised view of a domain in a REST interface, so data representation is a problem with a smaller scope with FHIR, which helps a bit more compared to openEHR, but there are still some issues. openEHR is heavily OO and especially implementation inheritance centric, so that leads to challenges when it comes to representing it with an interface data format such as json.
You should assess openEHR’s design choices in a system design context, not in an interface design context. In order to understand the problem with your question, ask yourself “can you share your perspective on how FHIR’s design choices enhances the functionality and usability of FHIR when you implement a whole hospital information system with FHIR, using it to process every type of data in the system”
You need to start with a requirement. Don’t try to grasp as a whole. Take your requirement, try to implement it with openEHR and ask questions related to that task and approach. You’ll almost certainly get lost and frustrated if you try to learn it otherwise. Certainly possible, but much harder.
I’m assuming you don’t intend to do it but that sounds like trolling. Is there an unopinionated spec out there? FHIR says “you shall do REST”. It is in the name of the thing (R). I’d say that’s on opinion. I’d rather have opinionated design decisions in health specs tbh, because in this space I’d see unopinionated as clueless. Once again: personal view.
A late edit: it is possible to ‘swap’ these two specs for pretty much all the tasks. You “can” implement a HIS with FHIR. You “can” exchange messages with openEHR between systems. It is a matter of choice, which always depends on the context. You can see from my responses above that I’m trying to put your questions into context in my answers. That’s the crux of decision making when it comes to choosing standards: context.