Question about template ID format in current baseline spec

[pablo (Pablo Pazos)]

In AM 2.2.0 there is a specification for the template ID format with some suggestions Archetype Object Model 2 (AOM2)

In the same baseline spec version, in the Base Types 1.2.0 the TEMPLATE_ID type has no comment about the specific format for the ID value Base Types

Shouldn’t the TEMPLATE_ID type be consistent with the AM spec in that something about the value should be mentioned? Also in the AM spec, maybe something about that the TEMPLATE_ID type is used to represent those uk.nhs.clinical::openEHR-EHR-COMPOSITION.t_encounter_report.v1.0.0 template ID values would be useful.

[thomas.beale]

@pablo

In the same baseline spec version, in the Base Types 1.2.0 the TEMPLATE_ID type has no comment about the specific format for the ID value Base Types

That TEMPLATE_ID type was created a long time ago when we only had ADL 1.4 and I had not yet developed ADL2 templates as just another kind of archetype, that doesn’t need a separate type for its identifiers (i.e. ADL2 template ids are just ARCHETYPE_HRIDs).

We could use that TEMPLATE_ID type to formalise the ids of today’s (OET-based) templates, if we can ever agree on them

[pablo (Pablo Pazos)]

So the ARCHETYPE_ID type isn’t used in ADL2?

[thomas.beale]

You can see here.

ARCHETYPE_HRID is a multi-field object; ARCHETYPE_ID is just a String.

We probably should add a method to ARCHETYPE_HRID that will output an ARCHETYPE_ID.

[pablo (Pablo Pazos)]

Thank you, I guess ARCHETYPE_ID and TEMPLATE_ID are not mentioned at all in AOM2/ADL2 specs, and that the types used in AOM2 are defined in the same model, in contrast to AOM1.4 where some types are defined by the common/base models, like the xxx_ID. It’s king of a different approach to modeling: more normalized model separating by “modules” vs. one model contains all the pieces needed.

I’m not familiar with AOM2 at all, but for people searching for implementing the specs, seeing 1.4 vs 2.0 in the same spec name, they would turn to 2.0 just for the higher number. Is there any document that compares AOM 1.4 and 2.0 maybe noting the different approaches to how models are organized?

@thomas.beale

ARCHETYPE_HRID is a multi-field object; ARCHETYPE_ID is just a String.

The internal representation is String in ARCHETYPE_ID, but it has methods to get each part of the multi-axis ID. This is not the case of TEMPLATE_ID which is a String internally and doesn’t have any methods or multi-axis ID.

Base Types

[thomas.beale]

@pablo

the types used in AOM2 are defined in the same model, in contrast to AOM1.4 where some types are defined by the common/base models, like the xxx_ID. It’s king of a different approach to modeling: more normalized model separating by “modules” vs. one model contains all the pieces needed.

Not quite true: AOM2 relies on the following:

• primitive types from BASE (shown here in AOM2)
• the Resource Model, including AUTHORED_RESOURCE and related classes, which supplies all the meta-data.
• the original expression language, recently renamed Basic Expression Language (BEL)

Probably ARCHETYPED_HRID needs to move to base.base_types.identification as well.

@pablo

Is there any document that compares AOM 1.4 and 2.0

Quite a lot on the wiki - particularly this page.

@pablo

The internal representation is String in ARCHETYPE_ID, but it has methods to get each part of the multi-axis ID. This is not the case of TEMPLATE_ID which is a String internally and doesn’t have any methods or multi-axis ID

Right - when I defined the type TEMPLATE_ID in the model, there were no described rules for template ids (i.e. of the OET/OPT kind) - it was a placeholder class. Later I realised it wasn’t even needed for ADL2.

[pablo (Pablo Pazos)]

@thomas.beale

Not quite true: AOM2 relies on the following:

Sorry, I was focused just on the identification package (OBJECT_ID et. al.)

@thomas.beale

Right - when I defined the type TEMPLATE_ID in the model, there were no described rules for template ids (i.e. of the OET/OPT kind) - it was a placeholder class.

Yep, it’s been quite tricky to formalize that on my implementation and ended proposing my own format for the TEMPLATE_ID.value which I later relaxed since most tools don’t enforce any format, because I needed the IDs to be controller in some way, and free text is not reliable for an ID.