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.
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
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?
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.
Sorry, I was focused just on the identification package (OBJECT_ID et. al.)
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.