openEHRApplications Builder

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.

Introduction

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:

  • Reading OPT2 (ADL) on a client.
  • Executing rules on a client while entering data into a form.
  • Validating forms data on a client before generating JSON for the CDR.
  • Validating received JSON on the server.
  • Migrate CDR data from one RM release to another (e.g. RM 1.0.4 to RM 1.1.0).
  • Convert archetypes to a newer ADL release (e.g. AOM 2.0.6 to AOM 2.3.0).
  • High throughput validation and insertion of data into CDR received from connected devices.
  • Integration middleware.

All the code is generated automatically from the selected meta models and templates.

  • Schema-Select the models to include in the schema (e.g. RM release 1.1.0, Task Planning release 1.5.0).
  • Operational Template-Select the operational templates (OPTs) to include in the application.
  • Generate- Objects, types and enumerations are generated automatically. Serialization and deserialization of the objects is also generated.
  • Any target- Any target is supported: GraphQL, OpenAPI, TypeScript, Kotlin, Flutter, C#, WebComponents, Vue, Angular, Blazor, Swift,...
  • Versatile- I used my builder to generate UML diagrams in just 5 days (and another 10 days to finalize them ;-). You really can generate anything you wish.

Why?

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.

Read about my progress...

What

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).

Learn more about openEHR SDK...

How

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.

Learn more about openEHR generators...

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:

  • model classes in your language
  • forms for your frontend
  • integrations with other systems
  • ...

Please contact me if you are interested