# ASSERTION in openehr\_expression\_104.bmm is not in accordance with the specifications
**URL:** https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203
**Category:** BMM/Expressions
**Tags:** template
**Created:** [16 December 2021 10:29 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203 "2021-12-16T10:29:28Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [27 December 2021 20:39 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/21 "2021-12-27T20:39:54Z")
> [@borut.jures](#):
>
> Should the OPERATOR\_DEF\_BUILTIN inherit from BUILTIN\_OPERATORS?
`op_table` is static, so it acts like a singleton object. The owning class just populates the table at startup time. You could also use the GoF Singleton pattern to achieve the same effect (which doesn’t use inheritance). In most languages these days you don’t need to inherit, you can just reference `BUILTIN_OPERATORS.op_table`(or in Java - `BuiltinOperators.opTable()`.#
It’s not an enumeration though, it’s a table of the form:
```auto
|"plus" | "+ "
|"multiply" | "*", "."
etc
```
Any logical operator might have a number of alternative symbols.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [27 December 2021 22:28 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/22 "2021-12-27T22:28:15Z")
I sometimes forget how inexperienced I must sound with such questions 😳
We both know that BUILTIN\_OPERATORS is a singleton just by looking at the model.
However I’m asking for a friend - my generator 😉
The generator knows only what is in the computable specifications - the BMM files.
I posted the question because there is no information that BUILTIN\_OPERATORS is a singleton or that op\_table is static in the BMM.
BUILTIN\_OPERATORS is the second ancestor of the OPERATOR\_DEF\_BUILTIN.
OPERATOR\_DEF\_BUILTIN “extends” OPEREATOR\_DEF and “implements” BUILTIN\_OPERATORS.
Since the BUILTIN\_OPERATORS.op\_table is not marked as static it needs to be “implemented” in OPERATOR\_DEF\_BUILTIN. The only way I know how to “implement” a property from an ancestor is by adding it to the OPERATOR\_DEF\_BUILTIN class (I tried with mixins but that didn’t work out).
BUILTIN\_OPERATORS.op\_table is marked as mandatory in BMM which means it must be present for every OPERATOR\_DEF\_BUILTIN instance.
A solution would be to add “is\_im\_singleton” and/or “is\_im\_static” to the BMM classes/attributes. Then BMMs would have the same information as we. I’m not sure if that is a realistic expectation?
So I have two options with the current BMM:
- remove BUILTIN\_OPERATORS as the second ancestor of OPERATOR\_DEF\_BUILTIN
- remove “is\_mandatory” for BUILTIN\_OPERATORS.op\_table so that the “fromJson()” doesn’t report an error if it is missing in OPT2 JSON.
* * *
I’m aware of only one other class that has to “implement” properties found in its ancestors. It is where AUTHORED\_ARCHETYPE “extends” ARCHETYPE and “implements” AUTHORED\_RESOURCE which has mandatory properties.
The generator can handle this scenario even for reading the OPERATIONAL\_TEMPLATE from JSON.
Edit:
The problem is setting mandatory properties at the instantiation of OPERATIONAL\_TEMPLATE instance:
- OPERATIONAL\_TEMPLATE constructor can call its ancestor’s constructor in AUTHORED\_ARCHETYPE.
- AUTHORED\_ARCHETYPE constructor can call its ancestor’s constructor in ARCHETYPE.
- AUTHORED\_ARCHETYPE constructor cannot call its second ancestor’s constructor in AUTHORED\_RESOURCE.
- Thus AUTHORED\_RESOURCE’s mandatory properties cannot be set when creating an instance of OPERATIONAL\_TEMPLATE.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [28 December 2021 15:10 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/23 "2021-12-28T15:10:44Z")
> [@sebastian.iancu](#):
>
> Is this not rather `_type` ?
Yes, it should be. In Archie this is configurable because of when I built it, it was not yet standardised as `_type`, I must have used the wrong configuration in the vs code extension. Will create an issue and fix later
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [28 December 2021 15:22 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/24 "2021-12-28T15:22:38Z")
> [@borut.jures](#):
>
> “openehr\_expression\_104.bmm” has [EXPR\_BINARY\_OPERATOR](https://specifications.openehr.org/releases/AM/latest/AOM1.4.html#_expr_binary_operator_class). I used this type for the ASSERTION.expression
Is this just for the archetype slots? Then it can be simplified and all archetypes I have seen will just parse.
If it is for the rules section, then you need more than just a binary operator.
By the way, it looks like I can make Archie and the VSCode plugin easily output JSON as in the model in that diagram generated from the BMM for archetypes and OPT 2s, configurable to switch to the new version. Just the operator def might be different, as that is an enum in archie. Even the new model looks mostly possible, but will be more work to do.
i will try soon if it’s possible. It will still all just parse to the same model in Archie that I will not change right now.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [28 December 2021 16:17 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/25 "2021-12-28T16:17:40Z")
> [@pieterbos](#):
>
> Is this just for the archetype slots?
Yes.
* * *
Since my OPERATIONAL\_TEMPLATE fromJson() method is generated from AM BMM the OPT2 JSON must be in exactly the structure of the AM specifications.
I didn’t know if you will have time to add the required changes to Archie so I wrote OPT2 to JSON converter.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [28 December 2021 16:23 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/26 "2021-12-28T16:23:40Z")
There appear to be more differences, unfortunately.
Differences between the model in Archie and [Expression Language (EL)](https://specifications.openehr.org/releases/BASE/Release-1.0.4/expression.html#_assignment_class) that are not simple renames that I found so far:
- EXPR\_FUNCTION.function\_def is of type FUNCTION\_DEF. It is EXPR\_FUNCTION.function\_name as a string in Archie. There is no function\_def class in Archie.
- OPERATOR\_DEF\_BUILTIN is an enum in Archie (renames are easy, parsing/serialization slightly more tricky)
- EXPR\_TYPE\_DEF is the enum EXPRESSION\_TYPE in archie (renames are easy, parsing/serialization slightly more tricky)
- there is no ASSINGMENT in Archie, just variable declaration, not even in the grammar.
- the for all statement is missing in the specification. It cannot be expressed as a simple binary operator, and in archie is a separate class inheriting from operator with variable\_name, left\_operator (the expression pointing to a collection of values) and right\_operand (the expression to be evaluated as an assertion for every member of the collection)
- **precedence\_overridden** is in binary operator in the spec, in expression in Archie. Minor, in archie it’s possible to store more places where `()` can appear in the grammar, but they are pretty much meaningless in execution if not around an instance of OPERATOR
I might find more later.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [28 December 2021 19:11 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/27 "2021-12-28T19:11:26Z")
> [@borut.jures](#):
>
> The generator knows only what is in the computable specifications - the BMM files.
>
> I posted the question because there is no information that BUILTIN\_OPERATORS is a singleton or that op\_table is static in the BMM.
Right, now I get where you are coming from. Sorry for the basic info (but quite often we have newbies visiting these posts as well, so us experienced folk should not hold back on simple explanations).
All the issues you point to in the BMM are addressed in the new form, i.e. the one that is not yet quite ready. I’ll have to have a think about what we can do in the short term…
Skimming your ideas - they sound ok to me - definitely you can remove the inheritance for the operator table, that’s not a modern way to access a singleton object. I’ll have to ponder the rest though for a bit longer.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [30 December 2021 12:05 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/28 "2021-12-30T12:05:58Z")
My conclusion is that this is a bit of a mess. Archie has an exact implementation as the model was specified when I implemented it. The only deviations in the serialisation are the missing EXPR\_ prefixes to the type names, and missing op\_ prefixes for the operator enum, and the addition of a modulo operator that was missing from the class definition. This matches exactly with the serialisation in the AOM 1.4 specification, at least for the archetype slots.
For at least the archetype slots, I can add a configurable rename so it will output the literals as EXPR\_LITERAL (they were called LEAF before!) or the old version. The operator\_def is tricky. If I have to make a sort of possibility of a migration path, I can output and accept both operator (enum, so a string), and operator\_def (object with identifier). The operator\_def seems very strange to me in a serialisation format. I think the op\_table does not belong in the json as it has no meaning there, and certainly cannot be changed from outside a system.
Then if we decide to switch to the BMM\_ASSERTION, everything will change again, the operator def will change to a rather complicated function\_def. That will be a much harder migration path, probably with some way to accept and generate both versions of the formats. note that this is not just for the rules section, also the archetype slots, although that is just a subset of the entire language.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [30 December 2021 15:01 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/29 "2021-12-30T15:01:09Z")
First attempts gives the following json for an expression in an archetype slot. This is a bit different than @borut.jures s example - this one has the following differences, which I consider to follow the spec:
- `EXPR_ARCHETYPE_REF` for the path reference
- right operand is a `EXPR_CONSTRAINT` instead of a literal.
And where it still deviates from the standard, but I think the standard needs a correction:
- `EXPR_ARCHETYPE_REF` has no ‘item’ field, since it does not make sense to add it (why and what should it be filled with?)
- no op\_table, since it makes no sense to include at all.
- both operator, operator\_def and symbol for reasons stated above
- some convenience fields such as path added, that are very useful in javascript. I could easily add an option to get rid of them, as I have done in the RM.
```auto
"expression" : {
"_type" : "EXPR_BINARY_OPERATOR",
"type" : "BOOLEAN",
"precedence_overridden" : false,
"operator" : "op_matches",
"symbol" : "matches",
"left_operand" : {
"_type" : "EXPR_ARCHETYPE_REF",
"precedence_overridden" : false,
"path" : "archetype_id/value"
},
"operator_def" : {
"identifier" : "matches"
},
"right_operand" : {
"_type" : "EXPR_CONSTRAINT",
"precedence_overridden" : false,
"item" : {
"_type" : "C_STRING",
"rm_type_name" : "string",
"node_id" : "id9999",
"constraint" : ["/openEHR-EHR-INSTRUCTION\\.medication\\.v1/"],
"attributes" : [],
"logical_path" : "/",
"allowed" : true,
"required" : false,
"prohibited" : false,
"path" : "/"
}
```
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [30 December 2021 16:01 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/30 "2021-12-30T16:01:45Z")
> [@pieterbos](#):
>
> My conclusion is that this is a bit of a mess. Archie has an exact implementation as the model was specified when I implemented it
If that is true, it must be that I am working off the wrong version (there is no obvious version to work off, because there was no release). But since I have created the BASE 1.0.4 branch to capture the intended version, we’ll keep mutating that until it matches the implementations.
> [@pieterbos](#):
>
> For at least the archetype slots, I can add a configurable rename so it will output the literals as EXPR\_LITERAL (they were called LEAF before!)
Hm I must admit I don’t even remember that, must have been a very old version - I have had a habit of using the ‘expr\_’ prefix for over 20y!
> [@pieterbos](#):
>
> If I have to make a sort of possibility of a migration path, I can output and accept both operator (enum, so a string)
I think we should mutate the branch version of the spec, not your implementation. Let’s not create more work.
> [@pieterbos](#):
>
> The operator\_def seems very strange to me in a serialisation format. I think the op\_table does not belong in the json as it has no meaning there, and certainly cannot be changed from outside a system.
Correct, that is like including a constant in a data serialisation - not useful and not part of the data.
> [@pieterbos](#):
>
> Then if we decide to switch to the BMM\_ASSERTION, everything will change again, the operator def will change to a rather complicated function\_def
We won’t do that in this branch version. The new Expression Language will do that, but that’s a completely different thing.
I’ll start having a look at some of the things you have listed. But remember - whatever version you originally worked off, it was incomplete, and contained errors, so what we specify now will necessarily be some upgrade on that original.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [30 December 2021 21:35 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/31 "2021-12-30T21:35:53Z")
> [@thomas.beale](#):
>
> Hm I must admit I don’t even remember that, must have been a very old version - I have had a habit of using the ‘expr\_’ prefix for over 20y
Sorry, the expr\_ prefix was in the zpecification, that omission was my mistake - I mean the original literal was called EXPR\_LEAF. This means I have to do some renames anyway, which is annoying but fine.
I have time to respond to the rest tomorrow.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [31 December 2021 09:06 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/32 "2021-12-31T09:06:15Z")
> [@pieterbos](#):
>
> - `EXPR_ARCHETYPE_REF` for the path reference
> - right operand is a `EXPR_CONSTRAINT` instead of a literal.
I wanted to use these two in my JSON this morning and found out they are missing in the BMM files (that is probably why I used EXPR\_LITERAL - I have to learn to always check the web specifications and compare them with the BMMs). They are in the specifications for [AOM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_class_descriptions_2) and [AOM 2.2.0](https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM2.html#_class_descriptions_2).
@thomas.beale Can they be added please? Pieter also made a comment about the EXPR\_ARCHETYPE\_REF.item field:
> [@pieterbos](#):
>
> `EXPR_ARCHETYPE_REF` has no ‘item’ field, since it does not make sense to add it (why and what should it be filled with?)
* * *
BUILTIN\_OPERATORS in OPERATOR\_DEF\_BUILTIN:
> [@thomas.beale](#):
>
> definitely you can remove the inheritance for the operator table, that’s not a modern way to access a singleton object.
> [@thomas.beale](#):
>
> Correct, that is like including a constant in a data serialisation - not useful and not part of the data.
@thomas.beale Can the BUILTIN\_OPERATORS as the second ancestor of OPERATOR\_DEF\_BUILTIN be removed from the BMMs?
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [31 December 2021 10:34 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/33 "2021-12-31T10:34:49Z")
> [@thomas.beale](#):
>
> Hm I must admit I don’t even remember that, must have been a very old version - I have had a habit of using the ‘expr\_’ prefix for over 20y!
The expr\_ prefix was definitely there, I for some reason did not implement it. Looks like I implemented [specifications-AM/docs/AOM2/AOM2.html at 5addcf864d9ab0f1439cf86ac12311c4fbf7b72b · openEHR/specifications-AM · GitHub](https://github.com/openEHR/specifications-AM/blob/5addcf864d9ab0f1439cf86ac12311c4fbf7b72b/docs/AOM2/AOM2.html) .
Modification I made that I do not know the reason for:
- instead of a LIST\, I added a RULES\_SECTION class, with LIST\ and a string content. Not sure why.
Modifications I had to make to make this work:
- added a FOR\_ALL\_STATEMENT class, because it does not fit in BINARY\_OPERATOR (missing the variable declaration), see [archie/aom/src/main/java/com/nedap/archie/rules/ForAllStatement.java at master · openEHR/archie · GitHub](https://github.com/openEHR/archie/blob/master/aom/src/main/java/com/nedap/archie/rules/ForAllStatement.java)
- ASSERTION does not have a variables attribute. Does not make sense to have, and the class wasn’t defined in the spec back then.
- EXPR\_ARCHETYPE\_ID\_CONSTRAINT is implemented, but never used, since at grammar level, this cannot be easily instantiated - a normal Constraint with a C\_STRING is used in these places.
- MODEL\_REF has a variableReferencePrefix attribute in Archie, to indicate the path starts with a variable (as used in for\_all)
- OPERATOR\_KIND has op\_module added
- added FUNCTION to implement the function calls specified in the language spec, which was missing in the object model, with attributes:
```auto
String functionName;
List arguments;
```
So, what I can relatively easily change:
- renaming of classes, probably even parsing both and generating only the new ones, configurable to not break older clients
- adding new attributes, like operator\_def, next to the existing one
- making the ARCHETYPE.rules attribute return a LIST\ again, configurable to support older clients.
- changing inheritance of FOR\_ALL\_STATEMENT to binary operator instead of operator.
And one for readability:
- OPERATOR\_KIND is an enum, but not an integer - it uses the string name, so op\_eq, etc. Well actually in archie for some reason, just ‘eq’, but that can be changed.
So, what should we change, and in archie or the specification?
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [31 December 2021 19:48 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/34 "2021-12-31T19:48:30Z")
I’ll need a few days to get onto this, but let’s change that BASE 1.0.4 spec as much as coherently possible - if it is to be useful, it might as well be reverse-engineered from your Nedap implem - which we know works. If we get stuck (probably we will on some detail), we’ll work out a solution.
I am not in favour of you having to do more work in your implem - the reason for this branch EL spec is to provide a spec that your implem is based on. So let’s get as far as we can before you start making any Archie changes.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [4 January 2022 15:22 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/35 "2022-01-04T15:22:04Z")
Pull request to do the rules changes in [Fix json rules by pieterbos · Pull Request #377 · openEHR/archie · GitHub](https://github.com/openEHR/archie/pull/377) . Mostly configurable to be able to upgrade archie without too much trouble, and parsing is backwards compatible for easier upgrading.
Most work there is the configuration and the mechanism, not the renaming. I made it a draft pull request. So, @thomas.beale , are the names in [Fix json rules by pieterbos · Pull Request #377 · openEHR/archie · GitHub](https://github.com/openEHR/archie/pull/377/files#diff-1632ab74a28cca19f1a29a15e9b0afb5d4a87ee8c722ec0b776a2572929d6684R40-R61) as they should be?
I will add tests of course. After this is done, next week we hope to merge all this and be able to release a major archie release soon. Since it’s not fully compatible with Archie 1, will likely be 2.0.0 (semver).
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [4 January 2022 15:32 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/36 "2022-01-04T15:32:07Z")
The changes look right to me - I wonder if you are making things too configurable however? The Archie code will break for sure but I suspect your (i.e. Nedap) system is the only user of that code so far - EhrBase doesn’t have any rule logic in its templates as far as I am aware - so dealing with the breakages locally is pretty trivial.
You could arguably consider this change a patch-level change to Archie if we agreed consider the missing name prefixes an ‘error’ - not casting aspersions within this group, I’m just thinking about how it looks from the outside / under semver logic.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [4 January 2022 15:46 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/37 "2022-01-04T15:46:01Z")
There are more changes that break things, also to the API of Archie, so it’s a major release.
No, not too configurable. We have android apps parsing these rules with Archie, and we need to be able to update both our server and our apps without waiting for all apps to be updated. This means we need a proper migration path where this configurability is absolutely necessary.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [4 January 2022 15:50 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/38 "2022-01-04T15:50:08Z")
> [@pieterbos](#):
>
> we need to be able to update both our server and our apps without waiting for all apps to be updated
Good point - what is in the JSON matters, and if you don’t want to be chained to doing some sort of magic whole-of-system instant update, then you have to allow both.
I do wonder though if the config settings can be dispensed with in a later ?minor version - to reduce complexity a bit, and also not to give new Archie users the idea that there really is an intentional choice available here?
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [4 January 2022 16:09 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/39 "2022-01-04T16:09:32Z")
Yes, some of these config settings (not all!) can be removed in a later version. I could mark the configuration settings as deprecated right from the start. But actually removing them will be a major version no matter what, even if they are deprecated, since it changes the behaviour considerably and will break apps if it is still used.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [4 January 2022 17:58 UTC](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203/40 "2022-01-04T17:58:06Z")
Great update Pieter!
* * *
> [@pieterbos](#):
>
> @thomas.beale , are the names in [Fix json rules by pieterbos · Pull Request #377 · openEHR/archie · GitHub](https://github.com/openEHR/archie/pull/377/files#diff-1632ab74a28cca19f1a29a15e9b0afb5d4a87ee8c722ec0b776a2572929d6684R40-R61) as they should be?
@thomas.beale
- EXPR\_CONSTANT
- EXPR\_CONSTRAINT
- EXPR\_ARCHETYPE\_ID\_CONSTRAINT
- EXPR\_ARCHETYPE\_REF
are missing in “openEHR\_am\_206.bmm” (and 210, 220, 230).
[AOM 2.0.6](https://specifications.openehr.org/releases/AM/Release-2.0.6/AOM2.html#_class_descriptions_2)
[Previous page](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203.md?page=1)
[Next page](https://discourse.openehr.org/t/assertion-in-openehr-expression-104-bmm-is-not-in-accordance-with-the-specifications/2203.md?page=3)