I love the openEHR data modelling idea and I’m relatively new here. As a developer, I find it really hard to understand and implement BMMs in my code. I want to, create a javascript client to create composition instances and doing this is not very straight forward. All I’m concerned about is the structure of the data at this point. And I want to send it to an openEHR API endpoint. My question is, why not use something like protobuf that has well established tolling in almost all languages instead of BMM? As of now, I’m limited to using only Java as my language if I want to communicate with an openEHR REST interface (because Archie is in Java and all SDKs like EHRBase’s depend on Archie). There are other methods like the Flatform and copy-pasting the composition xml/json instance from tools like https://toolkit.cabolabs.com/. But all of this seems hacky.
To use something like protobuf to represent object models probably won’t work, because protobuf has no inheritance, generics (template types), and limited primitive types. For moving openEHR data, I would like to see it be used, and the mapping would need to be developed starting from one of the following:
- BMM of RMs
- JSON schemas
- UML XMI (can be obtained from inside mdzip files)
- XSDs
You will actually see protobuf in among the protocols mentioned in the service model.
Other people probably have better knowledge of using protobuf (including @Seref) and might have suggestions - e.g. using XSDs might actually be an easier starting point.
It would be great to get a protobuf expression of the openEHR RM created (even by hand), we’ll publish it officially on Github, and the authors will be famous 
protocol buffers is a serialisation format with some schema support. you could use it to persist and read back BMM models, replacing ODIN or JSON, but you’d still have to write quite a bit of code on top of that to make BMM helpful in the way Archie does.
No matter what language you choose, doing what Archie does by processing BMM will still need to be done by that language, again, by processing BMM…
If you’re unhappy with having to use Java, which you’re completely entitled to, here are your options:
- Rewrite parts of Archie in the language you want, using the serialisation format you want
- Ditch BMM and implement a custom metamodel, with less information.
I’ve actually done the latter in production code, around 2012 or so and that’s still running in prod. BMM is very expressive and can represent a lot of information about RM types, including methods etc.
When you’re after creating valid instances of openEHR compositions, you don’t need all that information. For example, the freely available Ocean Template designer generates XML schemas from templates, which you can then feed into various tools to generate code to build XML. You can then apply XSLT to that XML and end up with cannonical xml. None of this requires BMM and still helps you build openEHR data, albeit in XML.
I completely agree that it’d be nicer to have tools to help with creating openEHR data, just to pass to REST api etc, but these are not easy to write. Everyone uses tech and languages that works for them and Java is what works for Archie team. So we’re all left with the same options: use what someone else have built by spending their time and money, for free, or write it ourselves by spending our time and money.
Don’t get me wrong please, by the way. I’m not suggesting you’re demanding anything, it’s just that openEHR foundation is not a strongly funded entity that delivers software. On the contrary any software that’s out there is out there due to generosity of members of the community and this is not a widely known fact. I just want to make that point.
Out of interest - what are you trying to do? It sounds like you want to create an application data-set structure in a JS or TypeScript programming environment? It might help if you can explain a bit more what you want to do with a BMM, which is (usually) a full model representation (i.e. same job as XMI or schema languages).
Thank you for your answer. Completely understandable. Using open-source software is such an integral part of the development process, I rarely think about all the work that goes behind making it what it is. openEHR still has a long way to go and I’m grateful for all the tools available. On an unrelated note, Google recently open-sourced FHIR on protobufs. I sometimes fail to understand how FHIR is getting so much attention from tech giants while openEHR is just doing a better job quietly on the sidelines.
From my perspective, this is due to the fact that there was no openEHR reference implementation early on. There were some libraries (like the one mentioned by Thomas) but nothing that you could directly install and run. When I started working with openEHR around 2013/2014, it really took me lots of time and effort to get things started.
Since then, the situation has improved but there is surely more to be done to lower the barriers for adoption (including publically available tutorials and other education materials). I’m convinced that NOT using openEHR needs to become the more expensive decision for vendors that they would need to justify. It’s the same logic why not every software company creates their own database technology or web server.
BTW, I completely agree that a purely web-technology based approach would be the next step to take. With our SDK, we do what serves the needs of the partners involved regarding their way of building applications which is focused on having a spring boot based java application which takes care of the business logic. But that’s only one option. It can also serve as a lightweight middleware that only does the transformation from the DTOs to the backend formats like canonical JSON and XML.
For the very lightweight apps, the flat formats and web templates might actually be powerful enough to serve many use-cases but of course this does not include AQL and some other convenient functions.
Again, I would love to see a full-blown javascript library for openEHR and would encourage to push this topic!
PS. If I had to choose three languagues/technologies to implement the SDK, openEHR RM and AOM, I would choose Java, .Net and Javascript.
I love a good language war. So I’ll put
- Kotlin (to replace Java)
- F# for a .Net language
- Typescript (to replace JS)
I’m seriously considering rewriting a few things from Java to Kotlin in the new future. It’s a much better language.
Well, in the end you still have JVM, .Net and Javascript
Kotlin looks great but I’m not sure if it is still a bit too dependent on a single, relatively small company. With vanilla java I can be relatively sure that we can maintain it for the next 20 years
Yes, they’re the reason we need good languages, to hide these ancient things…
Well I can’t say anything about the dependency, but I think it is already too popular to die. I can write the same thing, more clearly in Kotlin than Java, and I’d guess saving about 30% total lines of code (no scientific proof yet, but a careful inspection of the languages promises something like that). So that’s maintainability that really interests me. Less is always more when we’re talking code…
I completely agree. From a utilitarian point of view, I think the Java implementation is enough for all backend system developers. People in the healthcare industry probably already need to work with Java projects like HAPI. It also covers Android development. For iOS developers and other backend systems already on .NET, a C# implementation would be needed. Although I’m not
a fan of the language (I love python and go lang), I think a Javascript implementation would satisfy the majority of needs. A JS implementation would mean that it can be run on the server using Node.js and in the browser. Developers could create apps for the web, iOS and android using hybrid app tooling like react native or ionic. And most developers today need to know javascript. This should be a priority over C#, Kotlin, Dart or other languages.
You just nailed it there mate.
Well, front-end developers … actually I don’t see any tension of ‘priorities’ between front-end and back-end development - they’re both essential, and require very different skills. A lot of front-end development is moving to no- and low-programming, with the skillset being more oriented to good UI/UX rather than classical programming, which is less needed due to smarter frameworks and UI builder tools.
I’d be well up for working on some Typescipt/JS libraries I am doing some of that anyway for some GraphQL experiments- @rtweed of Ripple already did some work at https://github.com/robtweed/qewd-hit-platform
I’m not sure I would set the goal of doing a full RM implementation. I think a more limited bit of work might give much wider value - a fair bit of RM is not needed unless you are into detailed CDR development or tooling.
Right - the ‘data subset’ is what would make sense. Data types, Data Structures, some of the Common spec, and the EHR (and demographics, if wanted). Ignore change control (version containers), and at least half the identifiers.
What is missing in BMM is a very simple representation to work with in frontends, that can be serialized to JSON.
So what we do to make BMM work in javascript is to define a very simple JSON representation of a fully processed BMM model, and send that to the clients. It’s just three classes, model, class and property, with only a limited number of fields and that’s enough to represent everything we need in our modelling tool frontend. I might be able to share the full model for the OpenEHR BMM files if anyone is interested. It’s not as fancy as the original model, but it’s simple, it works and it contains what you actually need, and not much more.
However when creating actual RM instances in javascript, we don’t bother with BMM, and just write the logic we need in that place. If you need typescript, there’s an openAPI spec + generator that should be able to generate everything you need, plus JSON bindings, at https://github.com/nedap/openehr-openapi .
Hi Pieter,
can you please post an example of the RM instance payload this approach expects? Would be really interesting to learn about this!
Birger
It would be interesting to know the definition of this BMM-lite - we could formalise that if it is useful for sharing the def, and that would enable a standard bit of code to generate the lite form from the standard (i.e. heavy) form of any model.
I’m interested to know what bits you leave out, because pretty well everything in BMM is there because it was needed by some concrete model construct in openEHR, ISO 13606, ISO 21090, or FHIR.
The BMM:
Pretty much a serialised form of BMM, references replaced by a simple string, without relying on any polymorphism for the properties and typing, ancestors and descendants present including ancestors of ancestors and descendants of descendants, properties of all ancestors directly available in the classes, without any of the include multiple files approach. Not enough for a full BMM, but enough for what you generally would need in your frontend without having to do any complicated processing before you can use it. The OpenEHR 1.0.4 model in this format: https://gist.github.com/pieterbos/5e7927798b817a801331ad7de42dc522
I must confess I had not found https://github.com/openEHR/specifications-ITS-BMM/blob/master/components/RM/Release-1.0.4/json/openehr_rm_ehr_1.0.4.bmm.json yet when I made this, although that one seems to be missing type ids in its serialized form.
I don’t have the definition right here in a shareable form, but I could easily share that later.
The RM instances: @birger.haarbrandt, do you mean the openAPI generated model? that’s just the standard JSON mapping of the RM. The same format that EHRBase supports as one of its serializations. If you want an example, open the visual studio code plugin, load an ADL 2 archetype, right click, then source actions -> generate example in json.
What’s much more interesting is the code it generates from the OpenAPI definition. I’m quite sure it works in java and typescript, but not sure if the type discriminator support is present in every language target, and that is really very much required to have polymorphism work, which OpenEHR relies rather heavily upon.
Ok - so this is a ‘compiled-form’ inheritance-flattened BMM. I have not gotten around to describing this transformation or the formal model or serialisation of the result, but it is good to see that it could be useful. It is indeed a simpler meta-model than the source form (which has to have all the inheritance etc), so it’s rather easy to describe. I can produce an official UML model of that if it is of interest.
I could even produce the BMM expression of the BMM itself, if people want to bootstrap that way 