Update references to rm 1.0.4 to 1.1.0 since Archie supports the latest rm release.
At least in GitHub description and readme.

there were some changes to the OpenEHR AOM spec, see the openehr SPECAM Jira. They should be checked against Archie and probably implemented in Archie.

The BigArchetypeValidatorTest doesn't report any "did not validate but should" or "unexpected parser errors" when there are no "validated but should not".

This issue is a continuation of #208 .

The archetype id patterns in allow archetype now end in .v1 in ADL 1.4. This makes sense, as their archetype ids do not have any further version information.

In ADL 2, they do. We likely need to change these patterns so they become .v1.*. during conversion OR need to change the specification so this is optional.

When serializing and then deserializing a BinaryOperator, ForAllStatement or UnaryOperator using JacksonUtil.getObjectMapper().writeValueAsString and .readValue, the operands list is not filled.

At this time, one cannot remove a parameter from a BmmGenericClass. Doing BmmGenericClass.getGenericParameters() returns a copy of the collection so removing the parameter from the collection is not reflected in the class. I recommend adding a method called removeGenericParameter(BmmGenericParameter) to BmmGenericClass and perhaps removeGenericParameter(String paramName).

The duration values like P0DT1H are not being parsed correctly:

de.ehrbase.serialisation.UnmarshalException: Text cannot be parsed to a Period:P0DT1H (through reference chain: com.nedap.archie.rm.composition.Composition["content"]->java.util.ArrayList[1]->com.nedap.archie.rm.composition.Instruction["activities"]->java.util.ArrayList[0]->com.nedap.archie.rm.composition.Activity["description"]->com.nedap.archie.rm.datastructures.ItemTree["items"]->java.util.ArrayList[0]->com.nedap.archie.rm.datastructures.Element["value"]->com.nedap.archie.rm.datavalues.quantity.datetime.DvDuration["value"])
    at de.ehrbase.serialisation.CanonicalJsonTest.obs_inst(CanonicalJsonTest.java:457)
Caused by: com.fasterxml.jackson.databind.JsonMappingException: Text cannot be parsed to a Period:P0DT1H (through reference chain: com.nedap.archie.rm.composition.Composition["content"]->java.util.ArrayList[1]->com.nedap.archie.rm.composition.Instruction["activities"]->java.util.ArrayList[0]->com.nedap.archie.rm.composition.Activity["description"]->com.nedap.archie.rm.datastructures.ItemTree["items"]->java.util.ArrayList[0]->com.nedap.archie.rm.datastructures.Element["value"]->com.nedap.archie.rm.datavalues.quantity.datetime.DvDuration["value"])
    at de.ehrbase.serialisation.CanonicalJsonTest.obs_inst(CanonicalJsonTest.java:457)
Caused by: java.lang.IllegalArgumentException: Text cannot be parsed to a Period:P0DT1H
    at de.ehrbase.serialisation.CanonicalJsonTest.obs_inst(CanonicalJsonTest.java:457)

This is a snippet of the instance being parsed:

               "items": [{
                    "_type": "ELEMENT",
                    "name": {
                        "_type": "DV_TEXT",
                        "value": "duration"
                    },
                    "archetype_node_id": "at0003",
                    "value": {
                        "_type": "DV_DURATION",
                        "value": "P0DT1H"
                    }
                }]

The test archetype in tools/src/test/resources/adl2-tests/validity/specialisation/openEHR-EHR-CLUSTER.redefine_c_string.v1.0.0.adls is marked to PASS but it doesn't validate. This isn't reported because of #193.

Could you implementing revision_history section in the grammar?

Steps to reproduce

At the moment, Iso8601_duration is not fully supported at Archie level:

(extract from ehrbase/ehrbase#294)

The parsing of a DvDuration depends on its prefix and then is serviced by the JAVA api as follows:

"PT": Duration: 'A time-based amount of time, such as '34.5 seconds' see https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
"": Period: "A date-based amount of time in the ISO-8601 calendar system, such as '2 years, 3 months and 4 days'' see https://docs.oracle.com/javase/8/docs/api/java/time/Period.html

F.e. the expression: P12DT23H51M59S fails to be parsed (as a Period), however, an invocation of Java Duration returns a TemporalAmount as expected.

Expected result

Iso8601_duration should be fully supported as specified in https://specifications.openehr.org/releases/BASE/latest/foundation_types.html#_iso8601_duration_class

Thanks for Archie and the comprehensive documentation! But I found a behavior where I'm not sure if I miss a step or if it's unexpected.

Parsing a RM object via JacksonUtil allows the creation of instances that do not comply to the RM. For instance, parsing a JSON of an ItemStructure without name or archetype_node_id will work, but they are required by RM. Is that expected? If yes, is there a way to validate RM objects against the RM without archetypes?

For transparency, this is what I tried:

String input = "{\n" +
                "    \"@type\": \"ITEM_LIST\",\n" +
                //"    \"archetype_node_id\": \"at0001\",\n" +
                "    \"name\": {\n" +
                "        \"@type\": \"DV_TEXT\",\n" +
                "        \"value\": \"test\"\n" +
                "    },\n" +
                "    \"items\": []\n" +
                "}";
ItemStructure test;
try {
        test = JacksonUtil.getObjectMapper().readValue(input, ItemStructure.class);
} catch (Exception e) {
        return e.getMessage();
}

It doesn't yet. Not so hard to fix, but allows for much nicer/readable rules sections

The solution here is to fill the field, NOT to change the model, since this is a required field in all documentation + BMM models.

Code:

Specification says: 'only validate includes if an open excludes is present'
Code does: always validate includes.

So fix, perhaps in the same way as https://github.com/openEHR/adl-tools/blob/83171f135b4c12836d7e09b0c0a6770a47585a93/components/adl_compiler/src/validator/aom_validator.e#L86-L126

Could be java 11 specific.

I faced a problem using EHRBase SDK doing queries against our openEHR CDR. Some DV_DATE_TIME have many milliseconds. I.e: 2019-04-30T12:36:09.3893812+02:00

This fails. I think it's because there is a limit on 6 digits for milliseconds in the DateTimeFormatter:

.appendFraction(ChronoField.MICRO_OF_SECOND, 0, 6, false)

could be very useful to add other ways of input - such as inputstreams - in case our bmms are not on a file system.

The RM Model release is now automatically selected based on the rmRelease field in the archetype. However, sometimes you want to check archetypes developed against an earlier RM version with a newer or older version.

MetaModels.selectModel() has support for this. The Flattener and ArchetypeValidator should get support for this as well.

The ADL workbench allows configuration of available BMM models. I think we want to parse as many BMM models as we have, then allow a configuration of available model versions as argument to the Flattener and ArchetypeValidator.

Type: API enhancement request
Importance: low

The Archetype.isSpecialized() method is defined as follows:

public boolean isSpecialized() {
    return this.parentArchetypeId != null;
}

The name is confusing because, in this case, the archetype in question 'specializes' the parent and the parent is specialized by the archetype in question.

Suggest renaming isSpecialized() to specializes().

@pieterbos There is a bug that we found the other week while I was at Marand, but can no longer locate in the source which is where the parser wrongly instantiates component_terminologies from an OPT due to a simple error in the way the ODIN is converted to JSON and then instantiated. It is an error I made myself in the original Eiffel code, and the solution is a helper class that has a single attribute, component_terminologies.

If this error is fixed, it will allow correct reparsing of an OPT.

It's missing a Signature class definition, so it doesn't validate. Means we can't use FHIR until then.

If the constraint is an ac-code, it does not check the list of terms, just the terminology id. This is a problem.

I loaded in an InMemoryFullArchetypeRepository three archetypes: A, B, C where C specializes B which specializes A (meaning A is the root of the dependency hierarchy). In Archetype B, I define a value set ac0.2 in the terminology and term-binding sections of the archetype definition. Yet, that value set is never used in the archetype definition.

terminology
term_definitions = <
["en"] = <
...
["ac0.2"] = <
text = <"Finding statement topic code range value set">
description = <"Range for the associated finding SWEC attribute restricted to findings and observable entities subhierarchy">
>
>
>

term_bindings = <
	["snomed-ct"] = <
	        ...
	        ["ac0.2"] = <http://example.com/valuesets/finding_statement_topic_result_range_vs.v0.0.1>
    >
>

This leads to the following two errors:

Error: parent archetype not found or can not be flattened - archetype specialisation parent identifier validity. The archetype identifier stated in the specialise clause must be the identifier of the immediate specialisation parent archetype.
Warning: ac0.2 - codein terminology not used in archetype definition

Note that: (1) neither error above specifies which archetype is affected. I would suggest adding this information since it is very helpful for debugging. I fixed another set of errors in my archetypes but had to hunt for them since I was not informed by the result messages where the error was happening. (2) The second error results because the warning in archetype B prevents it from being flattened (flattening is skipped if messages.size() > 0 even if the message is a warning rather than an error) and thus flattened=null for the parent of archetype C preventing the flattening of archetype C itself. It might be helpful to support a strict mode and a relaxed mode where warnings don't stop the flattening process.

#242 is fixes in #245. However, that leaves out one piece of functionality: A couple of methods to help people with which archetypes to pick to fill slots. So:

• add a method to help get the recommended list of archetypes for an archetype slot

could be as simple as AOMUtils.isRecommendedForSlot(ArchetypeSlot, String archetypeRef);

Or perhaps also:

List<String> getPossibleArchetypesForSlot(ArchetypeSlot slot, List<String> archetypeRefs);
List<String>  getRecommendedArchetypesForSlot(ArchetypeSlot slot, List<String> archetypeRefs);

Or perhaps also a different return type, that can also say 'no limits here' or 'this is a limited list' next to the list itself?

It is currently possible to define new ac and at codes such as ac1.1 and at5.1 in child archetypes even though codes ac1 and at5 don't exist in the parent archetype.

Can we add a validation for this?

The JSON serialization of ForAllStatement contains the operands twice, once in path_expression and assertion and once in left_operand and right_operand. The data is therefore duplicated resulting in a unnecessarily large JSON object.

The VARCN validation also accepts id111 as a valid root node id. The used regex should be changed from "id1(.1)*" to "id1(\\.1)*".

I think it is just doing the oppositie thing one expects.

Anyway, I don't see how an attribute can be a leaf, but if the method is there it should work as expected.

Or do I misunderstand the concept of CAttribute?

Thanks for any comment.

This is possible in archetypes, but not in RM objects, apparently. Let's fix that - very simple indeed.

Type: API Enhancement request
Importance: Low

Suggest adding a getSize() method to InMemoryFullArchetypeRepository that returns the allArchetype.size() rather than having to write: archetypeRepository.getAllArchetypes().size()

Suggest doing the same for boolean isEmpty() and clear().

See mailing list discussion of today

isSingle and isMultiple is inherintly tricky. Stop using it here and rely on the model!

Context

When trying to get the most basic building block of the archetypes (e.g. the differential-form) we noticed that the parameter "differential": false, was set in the response.body.

This should be "differential": true

Solution

Set values to true in the following exitArchetype & exitTemplate codeblocks where setDifferential is used.

https://ckm.openehr.org/ckm/archetypes/1013.1.204/adl

ACTIOn.procedure

The ITEM_TREE under description should have node id id2. It appears to have id9000 instead, which is a synthesized one. Check why.

Mostly in the exam_ archetypes. EAsy to fix

I followed the instruction on the landing page with the following dependency (snapshot version adjusted - should be corrected on the site):

<dependency>
    <groupId>com.nedap.healthcare</groupId>
    <artifactId>archie</artifactId>
    <version>0.4.0-SNAPSHOT</version>
</dependency>

However, Maven cannot find this dependency as it cannot find a jar for the archie parent project.

However, the dependency to the child module:

<dependency>
            <groupId>com.nedap.healthcare.archie</groupId>
            <artifactId>bmm</artifactId>
            <version>0.4.0-SNAPSHOT</version>
</dependency>

is properly resolved. We might need to update the documentation.

in the rules section, the matches section doesn't support a variable, so the following does not work:

$woundtype matches {"something"}

Interestingly, the following is supported

$woundtype/defining_code/value matches {"something"}

it should probably also support:

1 + 6 matches {0..8}

I think it is just doing the oppositie thing then one expects.

Anyway, I don't see how an attribute can be a leaf, but if the method is there it should work as expected.

Or do I misunderstand the concept of CAttribute?

Thanks for any comment.

(sorry, I created this issue using the wrong account)

CDuration object has an assigned assumed value when the source ADL doesn't have it.
Can be reproduced with the openehr-TEST_PKG-WHOLE.primitive_types.v1.0.0.adls in the duration constraints from attribute 20 to 27.

Assumed value is set in line 26 from TemporalConstraintParser. It could be put as the default value if it really needed, or just removed

In addition to PR where things are fixed directly, a number of issues that cannot be fixed right away:

TERM_MAPPINGS.match should be a string, now a short unsigned int representing a character.

Consider adding DV_PARSABLE.size so at least old XML can be parsed

VERSIONED_OBJECT.versions: check if should be added or not

VERSIONED_PARTY not implemented?

URL in the form:

terminology:SNOMED-CT/247893243?subset=something

fails. At least because it expects a '.' in the host (SNOMED-CT) part, but also because of problems recognizing the query (unknown why).

Following the README.md. I tried to parse an ADL file

String adlFile = "Archetypes/cluster/openEHR-EHR-CLUSTER.ethnischer_hintergrund.v0.adl";
File file = new File(ClassLoader.getSystemClassLoader().getResource(adlFile).getFile());

// Adl file exists
assertThat(file).exists();

ADLParser adlParser = new ADLParser();
Archetype archetype = adlParser.parse(new FileInputStream(file));

raises

line 1:23 mismatched input '1.4' expecting VERSION_ID
line 2:1 mismatched input 'openEHR-EHR-COMPOSITION.encounter.v1' expecting ARCHETYPE_HRID

java.lang.NullPointerException
	at com.nedap.archie.adlparser.treewalkers.ADLListener.enterMeta_data_item(ADLListener.java:114)
	at com.nedap.archie.adlparser.antlr.AdlParser$Meta_data_itemContext.enterRule(AdlParser.java:1211)
	at org.antlr.v4.runtime.tree.ParseTreeWalker.enterRule(ParseTreeWalker.java:42)
	at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:25)
	at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
	at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
	at org.antlr.v4.runtime.tree.ParseTreeWalker.walk(ParseTreeWalker.java:28)
	at com.nedap.archie.adlparser.ADLParser.parse(ADLParser.java:95)
	at com.nedap.archie.adlparser.ADLParser.parse(ADLParser.java:78)
	at de.ukw.openehr.fiddle.TestArchie.testAdl2Parser(TestArchie.java:26)

Test code can be found here.

Does archie only work with ADL 2.0?

Changes made in SPECAM-47 should probably be incorporated.

Two issues:

1. Add some dependencies:
   compile 'javax.annotation:javax.annotation-api:1.3.2'
2. Javadoc generation fails due to a used doclet, that does not suppor the new doclet API. Oracle is moving way faster than dwvelopers are willing to keep up with, it seems. So, solutions:

• move back to html javadoc and remove doclet. Shouldn't be very hard
• wait until a markdown doclet is upgraded
• switch to asciidoctor syntax?

Very strange that I didn't notice this - but it really is missing.