OPT2 JSON files generated from Nedap’s VSCode extension are using the latest AOM2 release 2.3.0. This is a Stable release.
@pieterbos has generated an AOM2 BMM file for release 2.0.6 which I’m currently using (it is 5+ years old release).
It would be great to have all stable BMM files in the ITS-BMM repository. @thomas.beale offered to write the latest AOM2 BMM in another thread. I didn’t dare asking him to do it
Since people are busy and don’t have time to keep everything in sync, I tried the route suggested by Pieter in another thread and went to the ITS-XML to generate AOM2 BMM from XML (or did he recommend OpenAPI?). No luck - the latest XML is for the release 2.0.6.
I found AOM2 release 2.2.0 in ITS-JSON.
However 2.2.0 doesn’t have the structure generated by the Nedap VSCode extension (additional attributes for “path” and “logical_path” in their “definition” nodes).
Example:
C_ATTRIBUTE has only optional “differential_path” property according to the specifications.
OPT2 JSON file has additional “logical_path” properties in C_ATTRIBUTE. This property is defined in ARCHETYPE.
“path” is in ARCHETYPE_CONSTRAINT.
Even ITS-REST is only up to AOM2 release 2.0.6.
Finally I found AM UML.
The “logical_path” is part of the ARCHETYPE in this file (I unzipped it and looked through the “com.nomagic.magicdraw.uml_model.shared_model” file) as it is in the AOM2 release 2.3.0. My eyes are
Is this the file I’m looking for (and writing a novel about my journey to find it)
Has somebody already generated BMM files from the UML?
I’m willing to generate the missing BMM files myself (or use the alternative formats if this is the direction of openEHR).
I hope somebody with better knowledge and understanding of openEHR will direct me in the right direction of getting AOM2 release 2.3.0 BMM.
I thought that BMM files are the basis for everything in openEHR. I can’t understand how alternative formats (XML, JSON) are available for newer releases and BMMs are not.
This text enthused me about openEHR (https://openehr.org/about/what_is_openehr):
- Tools that machine-convert domain models into technical forms that can be used to build:
- applications (e.g. screen definitions);
- interoperability components (message definitions) and
- be consumed by platform implementations at runtime (data set definitions).
- Interoperability is solved in a way commonplace outside of the healthcare domain, which is by machine-generation of schemas and software components from models, rather than by hand-building of point-to-point messages or document definitions, the historical approach in e-health. Where messages or documents are an integration requirement, a significant degree of automated openEHR model-based mapping is available.
- In a similar way, the difficulty of application development is greatly reduced via machine-generation of application software and UI components. Using specialised tools, the building of some UI applications directly by clinical professionals is now possible.
@thomas.beale I hope I’ve proven my willingness to do this task without burdening somebody else before I ask for help. May I please ask you to write the offered AOM BMM release 2.3.0