Hello everyone,
I’ve been experimenting with an openehr implementation based solely on BMM, this strategy comes to provide an implementation that supports as many versions of openehr using single code and make more stable across many updates. This can be achieved using metaprogramming, like using metadata of class attributes to validate data based on it, and using runtime function dynamic dispatcher that checks typing of arguments at runtime(the internal implemented using the programming language).Moreover, this can make implementation of expression language an easier task (with simple JIT or interpreters on top).
The problem is that BMM files(and P_BMM formalism itself) doesn’t have function metadata which doesn’t support fully building computable BMM graph
so my questions are;
is there an experimental version of BMM files that support
if there’s none at the time, I want to ask how are are bmm files generated, is it manually or is there script to convert it from UML or eiffel, to create experimental files until official one drop.
yes, openEHR is replacing UML with BMM as the source of truth for the specifications’ models.
@sebastian.iancu has created BMM files that export most/all information from the current UMLs. This includes functions. I believe it’s currently in a private repo by Sebastian, of course it will be public in the future, ask Sebastian if you want it sooner. These files have properties, like functions, that are not currently formally supported by BMM. So there’s a need by the spec to update BMM to support this. There’s some discussion in the SEC on how exactly to do this. Some details here: (and in older call minutes) https://openehr.atlassian.net/wiki/spaces/spec/pages/3148251137/2025-10-14+SEC+Face2face+Meeting+Barcelona
Btw @borut.jures has done something similar, generate code from BMM. Check this forum for more info or reach out to him to share experiences in case you’re interested.
Thank you for your great work:
I noticed that BMM is now splitted into two version v3 and 2.x, with v3 being Paused, If I may ask is there any roadmap a plans regarding the v3, because I read that Paused:
denotes that the specification will not undergo further changes unless exceptional circumstances arise; specifications with this state are not recommended for new implementations, but may still be in use.
So does it include that the BMM files that follows these ANTLR grammars, similar to the one that Mr Beale mentioned here will be paused also ?
I get that it is hard to suddenly change the BMM version due to tooling that already implements it, and that is why they were split and that 2.x is the maintained version now, but in v3 I am experimenting with it in a way, trying to use BMM v3 as an Abstract Syntax Tree + MetaModel to traverse it using an Interpreter.
The split was necessary, because there are in-use tools implementing v2, which they are not yet on v3 - and in the same time the v2 specification was not captured correctly in a formal release. So in theory is not really a split, just highlighting a version that was buried around 2018 under new developments.
Also, v3 is in some way uncertain if is completed or final, the main implementation not actively planning to move forward, neither to maintain it as a spec. There is already a potential v4 explored separately by Thomas as Splash. All these contributed to decision to label it as Paused - meaning is not actively maintained or developed. That might change, if future situation is changing, but for now is a fair representation of the current state - to manage expectations.
I have already made some interesting modifications, and have a working implementation of the latest version in Kotlin. I’ll put that out OS when it has been tested a bit more. It has significantly better Antlr grammars as well.
Looking forward to it,
If I may ask the following:
1- will v4 be and addition or upgrade to the v3, like will it use same sematics to describe classes, typing, literals, expression and statements etc. or different sematics, like total redesign, when I started experimenting with implementing it as a programming language. I felt that it is so rich and it really was really good to build a simple Domain specific language based on it, so will it its fundamentals change?
2- will v4 be part openEHR or seperate as SPLASH, because I had a fast read of SPLASH article, based on what I read in there and in BMMv3, if I am getting it right the future trajectory for this is that new BMMv4 files will be the source of truth for the Core classes metadata including primitives and RM etc, and it would support importing models with BMM_MODEL::used_models, from there SPLASH would be an extension on openehr to add new classes (like standard libraries in programming languages). are my assumptions right ?
3- if my assumptions is right this would make implementations of openEHR(on the long run) rely mainly on BMM schemas(source of truth), which would make openEHR be more flexible to additions and updates. Because implementers wouldn’t be taking classes from BMM and implement them as Archie is doing that for each class by mapping it to the Spec , eg class Interval<T>, instead of implementing a Java class exactly as it is described, they would only implement the logic like provide implementations for function like Interval<T>::intersects(other: Interval) since the metadata is already fully availabe in memory as BMM_CLASS, and that would make openEHR more implementation agnostic and flexible. Am I right ?
