Error parsing ADL 1.4 Archetype

I’m parsing an ADL 1.4 archetype:

 private Archetype load14(InputStream stream) throws ParserConfigurationException, SAXException, IOException, ADLParseException {
    ADL14ConversionConfiguration conversionConfiguration = new ADL14ConversionConfiguration();
    ADL14Parser parser = new ADL14Parser(BuiltinReferenceModels.getMetaModels());
    Archetype archetype = parser.parse(stream, conversionConfiguration);
    return archetype;
  }

I get this error:

model for openEHR.EHR version null not found

It was working, and I don’t think I’ve changed anything? Any hints what I should look at?

Hello Grahame,

Is it possible to have a look at the archetype? I assume you are using archie to load an ADL 1.4 archetype

here: openEHR-EHR-OBSERVATION.blood_pressure.v2.adl (221.0 KB)

And yes, load an ADL 1.4 archetype

The error is thrown here: archie/aom/src/main/java/com/nedap/archie/rminfo/MetaModels.java at 0bc2087de9631b1f5a9a666774b04c108e8f7c66 · openEHR/archie · GitHub

if(selectedModel == null && selectedBmmModel == null) {
   throw new ModelNotFoundException(String.format("model for %s.%s version %s not found", rmPublisher, rmPackage, rmRelease));
}

The rmRelease is null. The ADL grammar has rm_release meta tag in the archetype header. This is missing in your archetype (but it is also missing for all archetypes downloaded from CKM). I’m used to specify it explicitly:

archetype (adl_version=2.1.0; rm_release=1.1.0)

It looks to me that overriddenVersion is null and the rm_release from the archetype is used (but is not found in ADL) resulting in the null for the rmVersion argument:

public void selectModel(Archetype archetype) throws ModelNotFoundException { ;
    String overriddenVersion = getOverriddenModelVersion(archetype.getArchetypeId().getRmPublisher(), archetype.getArchetypeId().getRmPackage());
    selectModel(archetype, overriddenVersion == null ? archetype.getRmRelease(): overriddenVersion);
}

There were recent PRs that might have broken using a default rm_version: ADL14Converter.java

3 Likes

thanks. I’m not familiar enough with the code base to figure out what’s going on with the default version but I can work around it by injected the rm_release into the archetype. Is 1.1.0 the right version for ADL 1.4 too?

It’s independent from adl. It depends on the archetype. If you view the adl2 representation it shows it’s rm 1.1.0. So try that one. or maybe try a newer version of Archie, I think v3.13.1 reverts the changes borut mentions.

1 Like

Doesn’t look like v3.13.1 fixes them, but I can work around this by injecting the rm_version into the archetype on the fly - thanks

1 Like

@MattijsK want do you think is going on regarding archie?

Hey all,

We’ve looked into this a bit and we can’t seem to reproduce this error at all with your code and given archetype @grahamegrieve. Archie seems to be able to handle an adl 1.4 archetype without rm_release just fine. Are we missing something?

The code changes mentioned by @borut.jures also don’t touch the parsing of 1.4 archetypes (only the conversion to adl 2) and also on older versions of Archie we can’t seem to reproduce this.

@borut.jures, you mention that you specify the rm_release specifically, is this because of the same reason? Is this something you can reproduce?

1 Like

I don’t know - as I said, it worked before. My code is here: fhir-ig-publisher/org.hl7.fhir.publisher.core/src/main/java/org/hl7/fhir/igtools/openehr/ArchetypeImporter.java at master · HL7/fhir-ig-publisher · GitHub

is it because I try to load it as 2.0 first?

@grahamegrieve did you try the adl-parser from GitHub - openEHR/java-libs: Standard Java libraries for Java implementations of openEHR ?

I use that and it works perfectly.

I didn’t find it, that’s why. If I can’t get this sorted, I’ll look at that

Just in case you use it, this is the code you’ll need to parse an ALD 1.4 archetype

1 Like

Hey Grahame, we put some more time into this and tried running your exact code and on our side it still works without any problems. So hopefully you can manage to find and fix it yourself, or otherwise you can indeed use the other option given in this thread.

That’s weird because it’s still happening, and it originally didn’t. I don’t know the code - is there anything in particular I should look for when I debug?

Very strange indeed. We ran exactly this piece of code with the archetype that you provider earlier in this thread:

public void checkArchetype(InputStream stream, String name) throws ParserConfigurationException, SAXException, IOException, ADLParseException {
    byte[] cnt = FileUtilities.streamToBytes(stream);
    try {
      archetype = load20(new ByteArrayInputStream(cnt));
    } catch (Exception e20) {
      try {
        archetype = load14(new ByteArrayInputStream(cnt));
      } catch (Exception e14) {
        if (e20.getMessage().equals(e14.getMessage())) {
          throw new FHIRException("Error reading "+name+": "+e20.getMessage(), e20);
        } else {
          throw new FHIRException("Error reading "+name+". ADL 1.4: "+e14.getMessage()+"; ADL 2: "+e20.getMessage(), e20);          
        }
      }
    }
  }

If you are indeed also using the latest Archie version and that exact archetype, then I’m not sure what else you can do to debug. Other than actually starting a debugger, running the code and finding the exact place where the exception is thrown and giving us more information about the variables at that point.

@MattijsK Discourse stopped sending me updates 8 days ago (2nd time this year) and I just saw your question:

I didn’t mean to write that “I” specify the rm_release. It is only that almost all archetypes/templates I’ve received in the past had the rm_release meta tag in their headers.

Also note that I don’t use Archie – I just try to build my implementation to match the high standards that Archie provides :blush:


p.s. It is still strange to me that the rm_release meta tag is missing when exporting from CKM :thinking: Will everybody have to agree to the same implicit default RM release if someday we have RM 1.x and RM 2.x? Wouldn’t it be better if CKM added explicit rm_release meta tag?

1 Like