openEHRApplications Builder
Generated SDKs, APIs, forms, applications, schemas, libraries,... Flutter, TypeScript, Kotlin, C#, WebComponents, Vue, Angular, Blazor, GraphQL, OpenAPI,...
Generated SDKs, APIs, forms, applications, schemas, libraries,... Flutter, TypeScript, Kotlin, C#, WebComponents, Vue, Angular, Blazor, GraphQL, OpenAPI,...
AM / RM
Model classes are generated for all AM and RM releases.
Operational Templates (OPTs)
Classes are generated for working with OPTs.
Forms / Applications / CDRs
Forms and other client applications can be generated.
Generated Applications
All the generated code can be run on a client side (web, iOS, Android, Windows) or server side. This allows for scenarios such as:
All the code is generated automatically from the selected meta models and templates.
Approach
From my experience, modern applications cannot be written by hand anymore. There are 100s of similar forms (in web forms sense - not OPT forms) and components to write (and all the plumbing that is needed). Even if a team writes them, they are hard to maintain and the application usually remains on an old framework versions even before it is released.
When I was reading the openEHR Architecture Overview I couldn't stop thinking there is a better way. I have taken a similar approach on previous projects but never had "computable specifications" available before.
Application builder costs less than a single developer but produces more code than a team of developers.
Builder generates upgraded code for a new openEHR release in seconds. Humans usually stick with the release they started and are never willing or able to move to newer versions.
When I started working with openEHR I hoped this could be done. 40 days later I knew it can be done - I've done it. All thanks to the computable specifications.
Idea
The requirements in this thread are clear -
make it as simple as possible for the developers to use openEHR.
Simplified openEHR Forms Management
Even a simple openEHR operational template (OPT) has too many elements for a human to program into a web form or as an integration interface. Forms and SDKs should be generated instead.
Simplified openEHR Data Management
I’m still putting together my thoughts but I guess there will be a (GraphQL?) middleware server that will sit on top of openEHR CDR. It will be a proxy between the CDR and applications that need to interact with it.
Application developers would get a library (in their programming language) that they would use to store/retrieve documents from the CDR using GraphQL (or REST). They would not need to know anything about the openEHR (although I add all the possible documentation for the interested ones to the generated schema/code).
Generators
AM / RM Generator
AM / RM Generator generates classes in a target programming language.
OPT Generator
OPT Generator uses generated AM classes and in-memory model of the OPT to generate an OO representation of the OPT.
Forms Generator
Forms Generator uses generated OPT SDK classes and generates their equivalent UI classes (and plumbing).
The result is a working forms application that runs on web / iOS / Android / Windows / Ubuntu.
Computable Specifications
Learn more about openEHR AM / RM generator
openEHR SDK
Learn more about openEHR SDK generator
Programming Language
Learn more about languages supported by the openEHR SDK generator
Would you like to use some other language than Java for your openEHR project?
Would you like to generate openEHR:
Please contact me if you are interested