@NY_Frank I’m sure the prevailing advice is NOT to use relational structures for EHR. As I mentioned above, I was bored and wanted to gain a deeper understanding why not 
It turns out that it is possible to use plain SQL (and all the standard SQL tools) for openEHR. I’m using a widely used “Rapid Web App Dev Platform for Java Developers” to let non-openEHR developers work with low-code UI studio they are accustomed to and get ACL, DB migrations, integrated BPM engine and designer, search, reports, audit,… And the framework is open source too 
Here is an excerpt of a body temperature archetype:
The Studio is using EclipseLink (JPA) and an Entity Designer for quick data model design. All openEHR data types (like DV_CODED_TEXT) have their own types that are embeddable into other entities:
This approach makes openEHR just another “domain” that is solved using existing tools and frameworks. It remains a difficult domain, but we get the benefit of using the tooling that developers are used to and operations specialists can optimize for performance. Data is queryable with standard SQL.
Please let me know if you are interested in further details so that we don’t hijack this thread.