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.
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.
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.
Right - I am still adjusting that BMM.
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.
Seems that that is an error in all the BMMs. I’ll fix that now.
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”:
Specifications:
I had to change the BMMs for the following properties:
I had to rename the following properties:
I had to add the following properties:
("[a-z]+\d+") : \{
"@type" : "ARCHETYPE_TERM",
$1 : \{
"@type" : "ARCHETYPE_TERM",
"code" : $1,
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”:
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.
I’ll have to read “OBSERVATION” from the “C_COMPLEX_OBJECT” attributes and not as a first class object with its own properties.
I’ll search for the explanation in the specifications why “OBSERVATION” is stored differently compared to e.g. “ARCHETYPE_TERMINOLOGY”.
Maybe to explain a bit more about my approach.
“OBSERVATIONAL_TEMPLATE” determines a type of its “definition” property at runtime:
The “fromJsonRuntime()” method:
The “_runtimeObjectFactories” that specify which object’s fromJson() method is called based on the “rm_type_name” property in the JSON:
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”.
I can read my first OPT2 JSON
…and I have to write only a single line of code to do it:
…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:
Renamed properties in JSON:
Added properties in JSON:
("[a-z]+\d+") : \{
"@type" : "ARCHETYPE_TERM",
$1 : \{
"@type" : "ARCHETYPE_TERM",
"code" : $1,
Unnecessary properties (I skipped them):
Now I can continue with a forms entry application based on an OPT
Should I generate it from BMMs?
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
This is now fixed in the BMMs. Thanks for reporting it.
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):
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?
- “ARCHETYPE_TERM” in openEHR_am_206.bmm doesn’t have “text”, “description”, “other_items” properties.
@thomas.beale It looks like you missed this one in my long notes on AM 206 BMM. Please update the official BMM.
It looks like you missed this one in my long notes on AM 206 BMM. Please update the official BMM.
Also done now…!
One more: The expressions bmm does not include the base bmm. So the AOM bmm file fails to validate because it cannot find String
Oh, and CONSTRAINT_STATUS is not part of a package, so that also fails to validate.
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"
>
One more: The expressions bmm does not include the base bmm. So the AOM bmm file fails to validate because it cannot find String
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 & @NeoEHR 's framework as well.
Oh, and CONSTRAINT_STATUS is not part of a package, so that also fails to validate.
Yep - I have not finalised 2.3.0 in fact…
I added an include to my local AM 206 BMM and also removed few classes:
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…
Well the AOM includes the base bmm directly anyway, so that wouldn’t be right.
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.
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:
“Iso8601_type”
- “value” is missing “is_mandatory = True” in “openehr_base_104.bmm” and “openehr_base_110.bmm”.
- Online version has “value” as mandatory.
And another in “openehr_base_110.bmm”:
- “ARCHETYPE_HRID” in openehr_base_110.bmm has “namespace” as “is_mandatory=true”. Changed it to “false”.
- Online version has “namespace” as optional.
“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”:
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 Resource Model
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.
Iso8601_type”
- “value” is missing “is_mandatory = True”
Fixed.
ARCHETYPE_HRID” in openehr_base_110.bmm has “namespace” as “is_mandatory=true”.
Fixed
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”.
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.
TERMINOLOGY_RELATION” is missing “members” property
Fixed.
version_last_translated is missing from AUTHORED_RESOURCE, both in spec and BMM, but present in AOM documentation and in Archie
It is actually in TRANSLATION_DETAILS; but was missing from the BMMs. Fixed.
RESOURCE_DESCRIPTION_ITEM.copyright is missing in Resource Model
It is in RESOURCE_DESCRIPTION class; the BMM had an erroneous duplicate in RESOURCE_DESCRIPTION_ITEM, now removed.
cardinality.is_ordered and is_unique should be mandatory, isn’t in BMM
It was not in the Base 1.1.0 BMM; fixed.
RESOURCE_DESCRIPTION_ITEM.other_details
The error here was that the AOM2.0.6 and the BASE 1.1.0 BMMs had it as mandatory instead of optional; fixed.
C_SECOND_ORDER.members is not mandatory in spec, but is in BMM. Is mandatory in subclasses though, should probably be mandatory?
Yes - the BMMs are correct here. The UML is not quite correct on this.
Not a bad haul for today
Great. Thank you!
I tested it with my tools and it works.
I can now use standard versions of:
Two things that were missed from the above:
“Terminology_code.original_language” in openehr_base_104.bmm has “uri” as “is_mandatory=true”.
The latest online version has “uri” as optional.
C_TERMINOLOGY_CODE: