I guess you just mean Terminology_code.uri - fixed to be optional in all 3 base BMMs.
This is an Archie thing I guess; the BMMs look correct to me.
No - see the explanation in the documentation. It will contain just a code like “at24” or the id of a value set like “ac3”. The latter case refers to a TERMINOLOGY.value_set, which takes care of the multiplicity of possibilities.
This is where I was doing it incorrectly and I should omit the “openehr_rm_104.bmm”. Only AM + BASE is needed (something you explained to me before but I didn’t understand at the time).
So all the DV_ types are not used then. Are they used only in CKM and are not needed after the OPT is prepared?
p.s.
Should I remove RM from the AOM “schema” in the UML diagrams?
And add a separate “schemas” only for RM?
DV_XXX types are part of the openEHR RM. They (and any RM type names, even from a completely different RM) are only mentioned as strings in actual archetypes, i.e. instances of AOM.
BUT… if you are building a smart form generator for data capture based on OPT (i.e. archetypes), you will most likely want to have the BMM of the specific RM available at runtime of building the form, and certainly of executing it so that all features of the type are available - don’t forget, many attributes of RM types are not constrained at all in an archetype, they are runtime only - e.g. nearly all dates and time fields, names, etc.
Especially the BUT… part. This was the reason why I didn’t get it the first time - I couldn’t imagine how the forms could be built without the information in the RM model. It all makes sense now.
I can now use all standard BMMs. No need for my fixes meant to join AM and RM in the same memory model. They may form a sandwich but they should be eaten like Oreo cookies - one layer at the time.
BUT… please check if “openEHR_am_206.bmm” is correctly including “openehr_base_1.0.4”.
I believe it should include “openehr_expression_1.0.4” instead (which includes “openehr_base_1.0.4”). There are 3 types from expression that the AM 2.0.6 needs.
“ARCHETYPE_HRID” is in AOM specifications but not in the “openEHR_am_206.bmm”. It is however in “openehr_base_104.bmm” but with a different structure.
I copied ARCHETYPE_HRID and VERSION_STATUS from “openehr_base_110.bmm” to “openEHR_am_206.bmm” (similar to “Cardinality”, “Multiplicity_interval” from BASE):
This didn’t work as my validator treated them as duplicates.
I guess “openehr_base_104.bmm” cannot be changed to include ARCHETYPE_HRID needed for AOM 2.0.6? Is there some other way to get the correct ARCHETYPE_HRID for AOM 2.0.6?
I ended up changing back to including “openehr_base_110.bmm” for “openEHR_am_206.bmm”:
includes = <
["1"] = <
-- 2021-11-15; bj; Use base_110 to get correct "VERSION_STATUS" and "ARCHETYPE_HRID".
-- id = <"openehr_expression_1.0.4">
id = <"openehr_expression_1.0.4b"> <== This includes "openehr_base_110.bmm"
>
>
-- 2021-11-15; bj; Removed duplicate classes found in openehr_base_110.
-- classes = <"AUTHORED_RESOURCE", "TRANSLATION_DETAILS", "RESOURCE_DESCRIPTION", "RESOURCE_DESCRIPTION_ITEM", "RESOURCE_ANNOTATIONS">
-- 2021-11-15; bj; Removed duplicate classes found in openehr_base_110.
-- "Cardinality", "Multiplicity_interval"
You could do that privately, but the BMMs represent the actual releases of the corresponding abstract specs. I would recommend using the AM 2.2.0 or 2.3.0 BMM.
Please try adding the above to the BMM. I guess your validator should also complain. Now it doesn’t since “ARCHETYPE_HRID” from the base is used (which uses different structure as in the specifications or in OPT2 JSON).
At the moment AM 2.0.6 works “on paper” as specified in the specifications but I believe the BMM is broken (it doesn’t compute).
I used my private “hack” so that I can continue with my project.
I hoped you would find a proper solution
I can continue using my hacked version so no need to spend time on this just for me
If the release process allows, these approaches could be used to fix the BMM:
A new “openehr_base_105.bmm” (<=105) that would be used for AO 2.0.6 and include “ARCHETYPE_HRID”, “Cardinality”, “Multiplicity_interval” that are in “openehr_base_110.bmm” for AO from 2.1.0 forward.
Or using base_110 instead of base_104 for AM 2.0.6.
Edit: Or another release: AM 2.0.7.
As soon as I get OPT2 JSON for these versions.
This thread started because I tried to use AM 2.3.0 with OPTs generated with AM 2.0.6
Work in progress, but that allows the JSON OPT to comply to the specifications. I think I added everything there that I could found. I have not yet built the visual studio code extension with these changes.
