@Martin_Koch had to “re-invent the wheel” to get a reference model as JSON.
We have what he is looking for in the BMM files. Since BMM files require a parser (which scares away many), I added a serialized version of the parsed (and processed) BMM files in easy to use JSON.
I hope the computable specifications we have available in the form of BMM files will be embraced by people working on openEHR. There is no reason to write (most of) the code for AM and RM. Just write a code generator for the BMM specifications.
openehr_rm_110.bmm.schema.json (453.0 KB)
openEHR_am_210.bmm.schema.json (215.3 KB)
3 Likes
This is excellent thanks. Are ‘descriptions’ in the original BMM and is this derived from BMM or P_BMM, and where can we go to simplify this whole chain?
One thing that Thomas has added in the Workbench, is some notion of what qualifies as a purely technical attribute vs. what can be considered as being relevant to the overlying archetype clinical domain. Is this something that could be usefully added to BMM?
Descriptions are not (yet 
) in BMM fiels. I get descriptions (and variants and methods) from GitHub - openEHR/specifications-AM: openEHR Archetype Model specifications and GitHub - openEHR/specifications-RM: openEHR specifications - Reference Model. BMMs are from GitHub - openEHR/specifications-ITS-BMM: BMM schemas for use with openEHR systems and tools.
With “technical attributes” I believe you are referring to “is_computed”, “is_im_runtime”, “is_im_infrastructure” attributes which are already part of the BMM (and are also included in the above JSON files).
@ian.mcnicoll I don’t understand what you mean by “where can we go to simplify this whole chain”.
The same JSON could be created using Archie. Its Bmm...classes already implement Serializable. Maybe we can come to an agreement on the canonical version of the processed BMM schema JSON and make it part of the specifications. I can generate Open API schema for these JSON files.
2 Likes
To add to what @borut.jures said, machine-extracting the descriptions would not be much work, it’ can be done by adding a new (pretty simple) back-end that extracts the documentation elements from the UML, same as is already done for the .adoc files (the blue class tables in the specs), except that this new extractor would write it out in structured JSON or similar so it can easily be integrated into the BMMs.
Borut is undoubtedly achieving exactly this, but with some more annoying code that has to cross map between the .adoc files and the target representation, i.e. BMMs-with-doc-text.
We should. I have in mind a full BMM3 syntax that’s much easier to read and write for humans, as well as JSON of the BMM3 meta-model. The JSON will surely come first.
2 Likes
This is JSON with data extracted from Asciidoc files:
asciidoc_rm110.json (182.1 KB)
1 Like