This thread is a branch from another GraphQL-related thread:
In discussions with developers at Karolinska that consider building some combined openEHR and non-openEHR application functionality using GraphQL, we considered the possibility of an openEHR contribution builder that uses the “web template” form of template definitions as a base to auto-create template/application specific GraphQL schema/definitions based on the “simplified” structure and naming of the templates.
Maybe an interesting student project? Or an evening hack by people like @Sidharth_Ramesh
In the old 2013 REST-paper mentioned above, the subsection titled “Contribution Builder” describes a design ideas and table 2 descirbes some possible endpoints and operations using REST. This was a couple of years before GraphQL had was publicly released. Today a contruíbution builder exposing both GraphQL and some or the REST end points woud likely be more interesting.
The “Future work” subsetion of the paper mentions that “Operational Transfromation” would be nice to explore for shared contribution builds
I just discovered okdb.io that might be an example of a nice framework for experimenting with simultaneous multi-user contribution builder implementations, it supports both GraphQL and operational transformation.
The real value IMO is in constructing a simple object that hides much of the complexity, not unlike FLAT/|STRUCTURED objects but in a familiar syntax plus you might be able ot fold in some simple but high-value querying.
I have played a little with this but not enough to really get into the weeds.
I’ve read @erik.sundvall 's paper and this post about the “contribution builder”.
It took my brain cells 3 days to “tell me” that the “contribution builder” is my “toJson()” method on an OPT class (e.g. BloodPressure.toJson()). It has a reverse format of the “fromJson” on the AM’s “OperationalTemplate” class that loads the OPT.
Maybe I should rename it to “toContribution()”
It prepares the canonical JSON that is part of the openEHR specifications. The JSON is then sent to the CDR’s REST API. I hope I got this part right (I still have some reading to do about contributions/compositions).
This way I can skip all the other intermediary formats (FLAT, SDT).
The RM classes are also generated and are imported in the first line of the first screenshot above. The RM release (e.g. 1.1.0 in this case) is taken from the OPT.
p.s. Erik and I were discussing this via email but Erik asked to move it to the forum
These look very much like the c# classes the Ocean Template Designer generates, which has been used in their openEHR production solutions for 10 years. In addition to the application specific template objects that were generated there was a middleware component that took any instance of this and generated the openehr composition and retrieved it again.
To be honest my favoured approach had moved on from this but It would be great to revisit this in the context of modern js-based frameworks.
Have you got the middleware part of this built also?
I am really interested in the graphQL part of this and how it can work for contributions and in conjunction with AQL.
Look forward to speaking with you more.
I know I’m not the first one who generates code from OPTs. I’m just happy I can join the club of those with such a tool
I’m currently working on the “middleware component” that will prepare the COMPOSITION. Since I have the COMPOSITION and related classes generated, I expect to be able to generate the “middleware component” too. At least that’s how it worked so far. For example I was able to generate the reading part for the OPERATIONAL_TEMPLATE (and related classes) from the BMM files. No hand coding and with strict type checking.
Those who started 10 years ago had to build their solutions “by hand”. BMM files weren’t available to them.
Since I just started working with openEHR I can use the BMM files to generate classes for the AM/RM releases. It would be interesting to know if others are using or considering this approach?
I wrote my first line of openEHR related code exactly 2 months ago (on 10.10.2021). Please give me one more week to finish the middleware
this seems impressive and highly relevant for the discussions. But I’m struggling to understand the modelling part. I see an opt (operationalised template, right?). But I see only a blood pressure OBSERVATION. Usually the opts combine selected elements from different entries and are of type composition. (There are niche uses for templates on entries). Could you share more of the files please? E.g. archetypes, opt, and the whole files for the graphql spec please? It would help me better understand what it is you build.
The operational template (OPT) for blood pressure has only OBSERVATION as its starting point. I have only one OPT that is for a COMPOSITION. I’ll probably use that one for preparing a COMPOSITION.
I just remembered that all my sample OPTs are in my local Nedap folder - they should be familiar
I’m using “openEHR-EHR-OBSERVATION.blood_pressure.v2.0.8_opt.json”.
I’ll use “openEHR-EHR-COMPOSITION.report.v1.0.0_opt.json” next.
I still have to learn about COMPOSITIONS so maybe my modeling is wrong.
The idea is to have native classes that can be used by developers without requiring them to know anything about openEHR.
Instead of giving them OpenAPI schema and asking them to send data to the CDR, I’m experimenting with simple classes they are used to (SDK). These classes take care of everything openEHR related.
It is similar to EHRbase SDK but one that can be used in “frontend” languages that web developers are used to.
I don’t know what CKM you’re referring to? But never mind:) As shared in this post I think the value is in generating code from templates on compositions. Technically just adls (in adl2) so it may not matter for code generation.
Some good example opts:
p.s. Please don’t hesitate to ask for help if you would be struggling to understand compositions. It may help to view it as the smallest unit of commit to the CDR. Data not recorded as part of a composition has too little meaning:)
I have generated my first COMPOSITION operational template that prepares a JSON that is sent to the openEHR REST API.
This code can be used on:
server (in the Dart VM or Node.js)
web, iOS, Android
desktop
It can be used for UI and for integration. It enables a non-openEHR developer to convert e.g. lab’s messages to compositions without knowing anything about the openEHR. They get a JSON they can send to their openEHR REST API.
An example usage (the last, empty array is for ARCHETYPE_SLOT that is not shown):
