Will an openEHR implementation provide UI to create and render records based on a template?

Dear community,

I’m working on a medical project and I need to store EHRs in the system. I have some basic questions about the regular flow to store, retrieve, and render records with openEHR.

As I understand an openEHR implementation like EHRServer or EtherCIS provides both frontend and backend solutions. After I install an implementation and upload a template from CKM there, will it provide any UI like a form to create records based on the template? Or I will need to create the records using the REST API like https://specifications.openehr.org/releases/ITS-REST/Release-1.0.1/ehr.html#composition-composition-post and specify the template ID in the request?

And after the records are in the system, will the implementation render them automatically based on the template?

What if I want to use my own UI to create and render the records, what will be my steps?

Whether the application provides a UI when presented with just a template will depend on the specific implementation. Some implementations do this.
Others build a specific UI for a specific application. The two approaches can be mixed, with the default UI as a fallback when a specific one is not available.

For developing on the REST API, the EHRbase github contains a rather nice SDK that could be of use, as well as a CDR for the backend.

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.