The EHRServer doesn’t provide a frontend solution in terms of clinical users. The frontend provided by EHRServer is for managing the EHRs, templates and queries in a visual way (without requiring you to create a client of the API).
For end user GUI you can check some of the test projects I have created for the EHRServer:
If you want to generate records, you can use the openEHR Toolkit, in which you provide a template and you can generate JSON or XML COMPOSITIONS https://toolkit.cabolabs.com/
And if you want to build you own frontend on different technologies, we have some clients of the EHRServer:
For PHP: https://github.com/ppazos/EHRClientPHP
For JS: https://github.com/ppazos/cabolabs-ehrserver-js
For Java/Groovy: https://github.com/ppazos/cabolabs-ehrserver-groovy
The toolkit have some functionalities to render XML documents based on XSLT (that looks awful IMO for it’s a start), but generating a nice view is not difficult with some code traversing a tree (XML/JSON) and mapping that to HTML.
About frontend GUI generation vs. designing custom GUI, I think both approaches have their use cases, here is my experience in that area:
Back in 2010 I designed the EHRGen which was an archetype based framework to build EMR applications and generated GUIs on the fly based just on archetypes https://github.com/ppazos/open-ehr-gen-framework
That was a painful approach because archetypes are too broad to based form generation just on their constraints, but technically it worked. One challenge was making those auto-generated GUIs look acceptable for humans to use, which is not easy tasks when things are auto-generated. Besides GUI generation, the EHRGen validates data based on archetype constraints automatically and stores valid data in the database, based on the RM. Then we had show and edit GUIs also auto-generated from the archetypes, and when data is accessed for showing or editing, the GUI is auto-populated.
In 2013 I tried to separate backend from frontend, building the EHRServer. Now I learned my lesson and the EHRServer uses Operational Templates, no more archetypes in software for me! https://github.com/ppazos/cabolabs-ehrserver
In the frontend area, also in 2013, I proposed a research project for students at my university, the goal was to create a GUI generator based on openEHR Operational Templates, which has the particularity of being able to generate GUIs for different technologies (HTML, Java Swing, iOS Layouts, Andorid Layouts, .NET XAML, …). The students created a nice prototype that was working, but the expression language for GUI definition they created was pretty basic. I later came back to those ideas to define and refine that language which I called the GUITemplate, basically another definition layer over OPTs that allows to express GUI metadata and constraints (like an archetype for GUIs) https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing
In the last couple of years I was working on small clinical recording applications, for which we chose to design specific GUIs, which allows to design better usability and user experience than auto-generated GUIs, but which require extra work and are not so maintainable.
Lately I refloated the idea of auto-generated GUIs and also the idea of providing them though an API from the openEHR Toolkit https://toolkit.cabolabs.com/
I think that might apply for fast prototyping projects.
Lastly there is the “component” approach for GUIs, which allows to generated components independently, and mix them together in a screen for a user to use. I think this approach, while some components could be auto-generated or auto-populated with openEHR data, and others could be designed ad-hoc, and both mixed together, could apply very well for clinical dashboards and clinical summaries.
Technically every option works, but we need to think about specific requirements to know which approach applies better to what we need. From your description it seems you are on a stage of fast-prototyping, so you might incline for auto-generated stuff.