# Which AOM2 release are AWB/Nedap using for exporting OPT2 to JSON? **Category:** [ADL](https://discourse.openehr.org/c/adl/40) **Created:** 2021-11-18 13:34 UTC **Views:** 1165 **Replies:** 32 **URL:** https://discourse.openehr.org/t/which-aom2-release-are-awb-nedap-using-for-exporting-opt2-to-json/2084 --- ## Post #1 by @borut.jures Are they using the latest AOM2 release? The release 2.3.0 has attributes marked as mandatory and they are missing in the JSON I get from AWB: - [OPERATIONAL_TEMPLATE](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_operational_template_class) - terminology_extracts (this is optional in the latest release) But even the latest release has some attributes marked as mandatory that are missing in the JSON: - [AUTHORED_ARCHETYPE](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_authored_archetype_class) - build_id - other_meta_data - [ARCHETYPE](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_archetype_class) - is_differential --- Nedap's VSCode extension generates OPT2 JSON that has some extra properties (they doesn't bother me) but uses [different names for boolean properties](https://discourse.openehr.org/t/where-to-find-aom2-bmm-for-the-latest-stable-release-2-3-0/2006/20) (I have renamed them in my test files): - mandatory (instead of is_mandatory) - specialized (instead of is_specialized) - is_generated does use is_ prefix - build_uid is missing - description.details.language.uri is missing (it is marked as optional in the latest BASE release but not in the openehr_base_110.bmm) --- Conclussions: I believe AWB and Nedap's VSCode extension are using the latest releases for AOM2 (and BASE). Can you confirm @thomas.beale @pieterbos ? I don't know how much time it takes to prepare AOM2 BMM for the "latest" release but if @thomas.beale is willing to do it I'll test it for all the little inconsistencies like I did with 2.3.0 :flushed: (most are found by the linter while it analyses the generated code) Since I generate everything from the BMMs (no manual editing of the source code) I can test many different AOM releases in parallel without extra work. I would be happy to test OPT2 JSON for AOM 2.3.0 if somebody can send them to me (or any other AOM release since 2.0.6). Same goes for Task Planner if I can get OPT2 JSON files for that. --- ## Post #2 by @borut.jures Maybe it is not the "latest" AOM2 but the "first": ``` "adl_version" : "2.0.6", "rm_release" : "1.0.4", ``` I guess "adl_version" is the same as AOM release? It looks so based on the [specifications](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_adl_version). --- ## Post #3 by @pieterbos VS code tool uses ADL 2.1.0, perhaps with some 2.2 features already. Archie master branch on GitHub is 2.2.0, should contain nearly all 2.3.0 features. Note that 2.3.0 has not been released yet, 2.2.0 nearly (?). I will update ADL version numbers in the Archie output later.. Those Json inconsistencies, the missing is_ plus a bit more, need to be addressed. Probably configurable to ease upgrading. Now that we have a 2.3.0 BMM, I can run the test that compares it with an implementation and see if I missed more. I hope to have a bit more time to address them and release the next major Archie version soon. Terminology extracts being mandatory, not sure if that should be the case. The Archie opt-creator never fills them in its current version. I will check build Id and language URI later, could very well be that they should not be mandatory. --- ## Post #4 by @thomas.beale [quote="pieterbos, post:3, topic:2084"] Note that 2.3.0 has not been released yet [/quote] Right - I am still adjusting that BMM. [quote="pieterbos, post:3, topic:2084"] 2.2.0 nearly (?) [/quote] It is (here), but if we find errors, they will get fixed on the branch. Any structural error will then get fixed in the BMM. [quote="pieterbos, post:3, topic:2084"] Terminology extracts being mandatory, not sure if that should be the case [/quote] Seems that that is an error in all the BMMs. I'll fix that now. --- ## Post #5 by @borut.jures My notes on learning to parse OPT2 JSON files. I used Nedap's JSON for "openEHR-EHR-OBSERVATION.blood_pressure.v2.0.8_opt.json": - "adl_version" : "2.0.6", - "rm_release" : "1.0.4", - "build_uid" : "54dfbb26-2c00-4001-b720-e0014a3dfb0f", Specifications: - [AOM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html) - [RM 1.0.4](https://specifications.openehr.org/releases/RM/Release-1.0.4) [details="Skip to later post for the list of changes to BMM files and JSON"] I had to change the BMMs for the following properties: - original_language - "Terminology_code" in openehr_base_104.bmm has "uri" as "is_mandatory=true". Changed it to "false". - [Latest online version](https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_terminology_code_class) has "uri" as optional. - archetype_id - "ARCHETYPE_HRID" in openehr_base_110.bmm has "namespace" as "is_mandatory=true". Changed it to "false". - [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_hrid_class) has "namespace" as optional. I had to rename the following properties: - generated => is_generated - differential => is_differential I had to add the following properties: - terminology - "ARCHETYPE_TERMINOLOGY" in openehr_base_110.bmm has "is_differential" as mandatory. Added property. - [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_terminology_class) has "is_differential" as mandatory. - terminology.term_definitions - "ARCHETYPE_TERM" in openEHR_am_206.bmm has "code" as mandatory. Added property: - Search: ``` ("[a-z]+\d+") : \{ "@type" : "ARCHETYPE_TERM", ``` - Replace: ``` $1 : \{ "@type" : "ARCHETYPE_TERM", "code" : $1, ``` - [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_term_class) has "code" as mandatory. - "ARCHETYPE_TERM" in openEHR_am_206.bmm doesn't have "text", "description", "other_items" properties. [/details] --- Edit: Please skip the rest. I forgot that this is only a template and not the "OBSERVATION" data that is sent to the CDR. I was stopped at the property "definition": - "OBSERVATION" in openehr_rm_ehr_104.bmm has "data" as mandatory. - [Online version](https://specifications.openehr.org/releases/RM/Release-1.0.4/ehr.html#_observation_class) has "data" as mandatory. - JSON has "data" as part of its "attributes" of a ["C_COMPLEX_OBJECT"](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_c_complex_object_class) - I was expecting that "data" will be part of the "definition" property. It is instead inside its "C_COMPLEX_OBJECT" attributes. This is different as other models above. - We know that "definition" has "OBSERVATION" from its "rm_type_name" : "OBSERVATION" property. - I was expecting to use the following code to read "definition" property as "OBSERVATION" from JSON (the same concept as for e.g. "ARCHETYPE_TERMINOLOGY", "Terminology_code" above): ![Screenshot 2021-11-20 at 11.18.35|690x227](upload://b92c0SYszGzIXOz0pZLNiHLhgTJ.png) Edit: "@type" is not needed after all since the "ARCHETYPE.definition" is of type "C_COMPLEX_OBJECT". The following two lines may be skipped: Edit2: "@type" is needed for the "attributes.children" properties. - This also means that the "@type" property in Nedap's JSON is needed. - AWB's JSON doesn't have "@type" property to indicate what descendant "C_OBJECT" type is an element of "attributes.children". I'll have to read "OBSERVATION" from the "C_COMPLEX_OBJECT" attributes and not as a first class object with its own properties. :thinking: I'll search for the explanation in the specifications why "OBSERVATION" is stored differently compared to e.g. "ARCHETYPE_TERMINOLOGY". --- ## Post #6 by @borut.jures Maybe to explain a bit more about my approach. "OBSERVATIONAL_TEMPLATE" determines a type of its "definition" property at runtime: ![Screenshot 2021-11-20 at 11.56.48|690x340](upload://gGwhYpT97noSv07UfU6GUALLdt8.png) The "fromJsonRuntime()" method: ![Screenshot 2021-11-20 at 11.58.01|690x285, 75%](upload://gF7i8erx5vYQkGqHMKGDs6BHkc4.png) The "_runtimeObjectFactories" that specify which object's fromJson() method is called based on the "rm_type_name" property in the JSON: ![Screenshot 2021-11-20 at 11.58.40|690x379](upload://3Fdn1LjMknugkV1oUoj9lneOCGc.png) Edit: I checked my generator for the “OBSERVATIONAL_TEMPLATE.definition” property. It skips the "C_COMPLEX_OBJECT.fromJson()" and goes directly to the runtime type specified by the "rm_type_name". I have to first read "C_COMPLEX_OBJECT.fromJson()" which will then call "OBSERVATION.fromJson()" based on the "rm_type_name". But I'll probably need "OBSERVATION.fromCComplexObjectAttributes()" since the "OBSERVATION" data is inside "C_COMPLEX_OBJECT.attributes" and not in the direct JSON form specified by "OBSERVATION". --- ## Post #7 by @borut.jures I can read my first OPT2 JSON :partying_face: ...and I have to write only a single line of code to do it: ![fromjson-convert|690x28](upload://4h7mNyqFmpU8nrxuruPRBy953TS.png) ...everything else is generated from the BMM files. When I started working with openEHR I hoped this could be done. 40 days later I know it can be done. All thanks to the computable specifications. I'm especially thankful to @thomas.beale and @pieterbos for their help. --- All the changes to the BMMs and JSON I had to do: Changed BMMs: - original_language - "Terminology_code" in openehr_base_104.bmm has "uri" as "is_mandatory=true". Changed it to "false". - [Latest online version](https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_terminology_code_class) has "uri" as optional. - archetype_id - "ARCHETYPE_HRID" in openehr_base_110.bmm has "namespace" as "is_mandatory=true". Changed it to "false". - [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_hrid_class) has "namespace" as optional. - constraint - "C_TERMINOLOGY_CODE" in openEHR_am_206.bmm has "constraint.type = <"String">. - "C_TERMINOLOGY_CODE" in openEHR_aom_206-generated.bmm (generated from Archie) has "constraint.type_def = (P_BMM_CONTAINER_TYPE). - [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_c_terminology_code_class) has "constraint.type = <"String">. - "C_STRING" in openEHR_am_206.bmm has "constraint.type" = P_BMM_CONTAINER_PROPERTY. - I changed "C_TERMINOLOGY_CODE.constraint.type" in openEHR_am_206.bmm to P_BMM_CONTAINER_PROPERTY like it is already used for "C_STRING". - "Iso8601_type" - "value" is missing "is_mandatory = True" in openehr_base_104.bmm and openehr_base_110.bmm. - [Online version](https://specifications.openehr.org/releases/BASE/Release-1.0.4/foundation_types.html#_iso8601_type_class) has "value" as mandatory. Renamed properties in JSON: - generated => is_generated - differential => is_differential - multiple => is_multiple Added properties in JSON: - terminology.is_differential - "ARCHETYPE_TERMINOLOGY" in openEHR_am_206.bmm has "is_differential" as mandatory. Added property "terminology.is_diffrential" to the JSON. - [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_terminology_class) has "is_differential" as mandatory. - terminology.term_definitions - "ARCHETYPE_TERM" in openEHR_am_206.bmm has "code" as mandatory. Added the "terminology.term_definitions.code" property to the JSON. - Search: ``` ("[a-z]+\d+") : \{ "@type" : "ARCHETYPE_TERM", ``` - Replace: ``` $1 : \{ "@type" : "ARCHETYPE_TERM", "code" : $1, ``` - [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_term_class) has "code" as mandatory. - "ARCHETYPE_TERM" in openEHR_am_206.bmm doesn't have "text", "description", "other_items" properties. Unnecessary properties (I skipped them): - "attributes" ("@type" : "C_ATTRIBUTE") properties have a "mandatory" which is not part of the specification. - "occurrences" ("@type" : "MULTIPLICITY_INTERVAL") properties have a "mandatory" which is not part of the specification. --- Now I can continue with a forms entry application based on an OPT :sweat_smile: Should I generate it from BMMs? :wink: --- ## Post #8 by @borut.jures [quote="thomas.beale, post:4, topic:2084"] [quote="pieterbos, post:3, topic:2084"] Terminology extracts being mandatory, not sure if that should be the case [/quote] Seems that that is an error in all the BMMs. I’ll fix that now. [/quote] Thank you for removing is_mandatory for "terminology_extracts". I missed one more in the original post: - component_terminologies are marked as mandatory in BMMs, but not in the specifications: - [AOM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_operational_template_class) - [AOM latest](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_operational_template_class) --- ## Post #9 by @thomas.beale [quote="borut.jures, post:8, topic:2084"] component_terminologies are marked as mandatory in BMMs, but not in the specifications [/quote] This is now fixed in the BMMs. Thanks for reporting it. --- ## Post #10 by @borut.jures One more but this one might be an error in the specifications (or my understanding of them). "other_meta_data" is marked as mandatory in the specifications and in the BMM (so BMM and specifications are in-sync): - [AM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_authored_archetype_class) - [AM latest](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_authored_archetype_class) Nedap's JSON has this as an empty map property: `"other_meta_data" : { },` This satisfies the validator but I (and my code) read the specifications as: "there must be at least one other_meta_data **element**". There is no need for the other meta data on some templates. Shouldn't a HashMap property (like "other_meta_data") that can be empty, be marked as is_mandatory = False? Or should I change the code to allow mandatory but empty hash map properties? --- ## Post #11 by @borut.jures [quote="borut.jures, post:7, topic:2084"] * “ARCHETYPE_TERM” in openEHR_am_206.bmm doesn’t have “text”, “description”, “other_items” properties. [/quote] @thomas.beale It looks like you missed this one in my long notes on AM 206 BMM. Please update the official BMM. [AOM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_term_class) --- ## Post #12 by @thomas.beale [quote="borut.jures, post:11, topic:2084"] It looks like you missed this one in my long notes on AM 206 BMM. Please update the official BMM. [/quote] Also done now....! --- ## Post #13 by @pieterbos One more: The expressions bmm does not include the base bmm. So the AOM bmm file fails to validate because it cannot find String :) --- ## Post #14 by @pieterbos Oh, and CONSTRAINT_STATUS is not part of a package, so that also fails to validate. --- ## Post #15 by @borut.jures I added an include to my local AM 206 BMM and also removed few classes: ``` -- 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. classes = <"C_COMPLEX_OBJECT", "C_PRIMITIVE_OBJECT", "C_PRIMITIVE_TUPLE", "C_SECOND_ORDER", "C_ATTRIBUTE_TUPLE", "C_ATTRIBUTE", "ARCHETYPE_SLOT", "C_OBJECT", "C_COMPLEX_OBJECT_PROXY", "C_DEFINED_OBJECT", -- "SIBLING_ORDER", "C_ARCHETYPE_ROOT", "ARCHETYPE_CONSTRAINT", -- "Cardinality", "Multiplicity_interval" "SIBLING_ORDER", "C_ARCHETYPE_ROOT", "ARCHETYPE_CONSTRAINT" > ``` --- ## Post #16 by @thomas.beale [quote="pieterbos, post:13, topic:2084"] One more: The expressions bmm does not include the base bmm. So the AOM bmm file fails to validate because it cannot find String [/quote] Well the AOM includes the base bmm directly anyway, so that wouldn't be right. But I see that the inclusions of base and expressions were around the wrong way - it should have been Expression including Base, not the other way round. This is now fixed, and should validate in Archie & @borut.jures 's framework as well. [quote="pieterbos, post:14, topic:2084, full:true"] Oh, and CONSTRAINT_STATUS is not part of a package, so that also fails to validate. [/quote] Yep - I have not finalised 2.3.0 in fact... [quote="borut.jures, post:15, topic:2084"] I added an include to my local AM 206 BMM and also removed few classes: [/quote] What you are doing here manually is what the ADL Workbench does internally with a bit more code. This is generally necessary, since in a graph of inclusions from some high-level model, things like base inevitably get included by more than one node in the graph. The only way to really do this properly is to process the separate BMMs into memory and handle duplicates there; trying to process the serial form into a equivalent single serial without going via the in-memory processing is pretty well impossible - you can't avoid doing the logic of the in-memory processing. I probably should re-engineer that piece of code from ADL Workbench into Java some day... --- ## Post #17 by @pieterbos [quote="thomas.beale, post:16, topic:2084"] Well the AOM includes the base bmm directly anyway, so that wouldn’t be right. [/quote] It validates expressions separately as well, which does not validate because of missing includes. It then tries to include a schema that did not pass validation, which is a separate error in itself, so AOM will fail to validate as well in Archie, unless the include is added of course. --- ## Post #18 by @borut.jures Thank you. One change is missing in the "openehr_base_104.bmm" and "openehr_base_110.bmm" and then I can use the standard ones: [quote="borut.jures, post:7, topic:2084"] “Iso8601_type” * “value” is missing “is_mandatory = True” in "openehr_base_104.bmm" and "openehr_base_110.bmm". * [Online version](https://specifications.openehr.org/releases/BASE/Release-1.0.4/foundation_types.html#_iso8601_type_class) has “value” as mandatory. [/quote] And another in "openehr_base_110.bmm": [quote="borut.jures, post:7, topic:2084"] * “ARCHETYPE_HRID” in openehr_base_110.bmm has “namespace” as “is_mandatory=true”. Changed it to “false”. * [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_hrid_class) has “namespace” as optional. [/quote] --- "openEHR_am_206.bmm" and later versions also depend on "openehr_expression_104.bmm" but use "openehr_base_110.bmm" instead of "openehr_base_104.bmm". I created a copy of "openehr_expression_104.bmm" that includes 110 instead of 104. Maybe there should be "openehr_expression_110.bmm" (110). --- I hope the last fix for the "openEHR_am_206.bmm": - "TERMINOLOGY_RELATION" is missing "members" property in "openEHR_am_206.bmm": - [AM 2.0.6](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_terminology_relation_class) --- ## Post #19 by @pieterbos Did an automated comparison. Results so far, apart from the missing is_ prefixes in Archie: version_last_translated is missing from AUTHORED_RESOURCE, both in spec and BMM, but present in AOM documentation and in Archie: https://specifications.openehr.org/releases/AM/latest/AOM2.html#_version_last_translated RESOURCE_DESCRIPTION_ITEM.copyright is missing in https://specifications.openehr.org/releases/BASE/latest/resource.html#_resource_description_item_class cardinality.is_ordered and is_unique should be mandatory, isn't in BMM RESOURCE_DESCRIPTION_ITEM.other_details C_SECOND_ORDER.members is not mandatory in spec, but is in BMM. Is mandatory in subclasses though, should probably be mandatory? It's possible that I will find more later, enough for today. --- ## Post #20 by @thomas.beale [quote="borut.jures, post:7, topic:2084"] Iso8601_type” * “value” is missing “is_mandatory = True” [/quote] Fixed. [quote="borut.jures, post:7, topic:2084"] ARCHETYPE_HRID” in openehr_base_110.bmm has “namespace” as “is_mandatory=true”. [/quote] Fixed [quote="borut.jures, post:18, topic:2084"] openEHR_am_206.bmm” and later versions also depend on “openehr_expression_104.bmm” but use “openehr_base_110.bmm” instead of “openehr_base_104.bmm”. [/quote] That is actually correct - the Expressions uses the related version of base (1.0.4). You can no doubt get away with allowing it to be base 1.1.0, but formally that is not correct - by BASE Release 1.1.0, that Expressions model is gone. [quote="borut.jures, post:18, topic:2084"] TERMINOLOGY_RELATION” is missing “members” property [/quote] Fixed. [quote="pieterbos, post:19, topic:2084"] version_last_translated is missing from AUTHORED_RESOURCE, both in spec and BMM, but present in AOM documentation and in Archie [/quote] It is actually in TRANSLATION_DETAILS; but was missing from the BMMs. Fixed. [quote="pieterbos, post:19, topic:2084"] RESOURCE_DESCRIPTION_ITEM.copyright is missing in [Resource Model](https://specifications.openehr.org/releases/BASE/latest/resource.html#_resource_description_item_class) [/quote] It is in RESOURCE_DESCRIPTION class; the BMM had an erroneous duplicate in RESOURCE_DESCRIPTION_ITEM, now removed. [quote="pieterbos, post:19, topic:2084"] cardinality.is_ordered and is_unique should be mandatory, isn’t in BMM [/quote] It was not in the Base 1.1.0 BMM; fixed. [quote="pieterbos, post:19, topic:2084"] RESOURCE_DESCRIPTION_ITEM.other_details [/quote] The error here was that the AOM2.0.6 and the BASE 1.1.0 BMMs had it as mandatory instead of optional; fixed. [quote="pieterbos, post:19, topic:2084"] C_SECOND_ORDER.members is not mandatory in spec, but is in BMM. Is mandatory in subclasses though, should probably be mandatory? [/quote] Yes - the BMMs are correct here. The UML is not quite correct on this. Not a bad haul for today ;) --- ## Post #21 by @borut.jures Great. Thank you! I tested it with my tools and it works. I can now use standard versions of: - openehr_expression_104.bmm - openehr_base_104.bmm - openehr_base_110.bmm --- Two things that were missed from the above: 1. "Terminology_code.original_language" in openehr_base_104.bmm has “uri” as “is_mandatory=true”. [The latest online version](https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_terminology_code_class) has “uri” as optional. 2. C_TERMINOLOGY_CODE: * “C_TERMINOLOGY_CODE” in openEHR_am_206.bmm has "constraint.type = <“String”>. * “C_TERMINOLOGY_CODE” in openEHR_aom_206-generated.bmm (generated from Archie) has "constraint.type_def = (P_BMM_CONTAINER_TYPE). * [Online version](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_c_terminology_code_class) has "constraint.type = <“String”>. * “C_STRING” in openEHR_am_206.bmm has “constraint.type” = P_BMM_CONTAINER_PROPERTY. * Shouldn't “C_TERMINOLOGY_CODE.constraint.type” in openEHR_am_206.bmm also have a P_BMM_CONTAINER_PROPERTY like it is already used for “C_STRING”? --- ## Post #22 by @thomas.beale [quote="borut.jures, post:21, topic:2084"] “Terminology_code.original_language” in openehr_base_104.bmm has “uri” as “is_mandatory=true”. [The latest online version](https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_terminology_code_class) has “uri” as optional. [/quote] I guess you just mean Terminology_code.uri - fixed to be optional in all 3 base BMMs. [quote="borut.jures, post:21, topic:2084"] “C_TERMINOLOGY_CODE” in openEHR_aom_206-generated.bmm (generated from Archie) has "constraint.type_def = (P_BMM_CONTAINER_TYPE). [/quote] This is an Archie thing I guess; the BMMs look correct to me. [quote="borut.jures, post:21, topic:2084"] Shouldn’t “C_TERMINOLOGY_CODE.constraint.type” in openEHR_am_206.bmm also have a P_BMM_CONTAINER_PROPERTY like it is already used for “C_STRING”? [/quote] No - see the [explanation in the documentation](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_c_terminology_code_class). 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. --- ## Post #23 by @borut.jures To build the "schema" I was using both: - "openEHR_am_206.bmm" and - "openehr_rm_104.bmm" 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? --- ## Post #24 by @thomas.beale [quote="borut.jures, post:23, topic:2084"] 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). [/quote] Yep you've got it now! [quote="borut.jures, post:23, topic:2084"] So all the DV_ types are not used then. Are they used only in CKM and are not needed after the OPT is prepared? [/quote] 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. [quote="borut.jures, post:23, topic:2084"] Should I remove RM from the AOM “schema” in the UML diagrams? And add a separate “schemas” only for RM? [/quote] Yes that would make more sense. --- ## Post #25 by @borut.jures Thank you for these explanations! 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. --- ## Post #26 by @borut.jures 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](https://wolandscat.net/2016/04/10/openehr-technical-basics-for-hl7-and-fhir-users/) but they should be eaten like Oreo cookies - one layer at the time. ![openehr_thats_it|441x500, 50%](upload://xd9ao2JLVGmMRrkfNuHJiik3awB.jpeg) --- 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. --- ## Post #27 by @thomas.beale [quote="borut.jures, post:26, topic:2084"] 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 [/quote] Yep you are correct - change uploaded now. --- ## Post #28 by @borut.jures With AM without RM I found one more inconsistency in "openehr_base_104.bmm". ["Iso8601_type"](https://specifications.openehr.org/releases/BASE/Release-1.0.4/foundation_types.html#_iso8601_type_class) should inherit from "Ordered" instead of "Any". --- ## Post #29 by @borut.jures ["ARCHETYPE_HRID"](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_hrid_class) 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): ``` ["definitions"] = < name = <"definitions"> -- 2021-11-25; bj; Added "VERSION_STATUS". -- classes = <"ADL_CODE_DEFINITIONS"> classes = <"ADL_CODE_DEFINITIONS", "VERSION_STATUS"> > -- 2021-11-25; bj; Added "ARCHETYPE_HRID". ["identification"] = < name = <"identification"> classes = <"ARCHETYPE_HRID"> > + VERSION_STATUS + ARCHETYPE_HRID ``` 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](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_hrid_class)? 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" ``` --- ## Post #30 by @thomas.beale [quote="borut.jures, post:29, topic:2084"] [“ARCHETYPE_HRID”](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_hrid_class) 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): [/quote] 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. --- ## Post #31 by @borut.jures [quote="borut.jures, post:29, topic:2084"] [“ARCHETYPE_HRID”](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_archetype_hrid_class) 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. [/quote] 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 :blush: I can continue using my hacked version so no need to spend time on this just for me :innocent: 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. [quote="thomas.beale, post:30, topic:2084"] I would recommend using the AM 2.2.0 or 2.3.0 BMM. [/quote] 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 :wink: --- ## Post #32 by @pieterbos I did some changes in Archie in this pull request: https://github.com/openEHR/archie/pull/372 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. --- ## Post #33 by @borut.jures I'm always amazed at the speed of your changes to Archie. Even when it means changing 52 files :sweat_smile: Thank you! I will test the VSCode extension when it is ready. --- **Canonical:** https://discourse.openehr.org/t/which-aom2-release-are-awb-nedap-using-for-exporting-opt2-to-json/2084 **Original content:** https://discourse.openehr.org/t/which-aom2-release-are-awb-nedap-using-for-exporting-opt2-to-json/2084