So the code system code be a parameter on the definition and composition and query apis.

This in my view is a much better idea than trying to make he formal archetype specs somehow control which coding convention is in use. BTW, you want to call this at-id code choice thing ‘coding convention’ or similar, but not ‘code system’ because that means things like Snomed, LOINC etc, in the HIT world.

I agree on the first part. Except I think we shouldn’t specifically preclude mixing at and id coded archetypes in a single system. Because that would unnecessarily hinder a migration to the other system. It would also help the strategy of using API’s to separate the two. So the code system code be a parameter on the definition and composition and query apis. Where ‘the api’ may support either or both and a conversion between the two. But still CDRs and clients and queries need to be compatible in order to work together. I’m strongly in favour of saying (at least for the time being) openEHR versions of those artefacts should be/support at-coding.

Ah ok, you mean runtime references. I’d say the same thing: any environment should know what coding convention it is based on - runtime or design-time. So the archetypes and templates loaded in a particular deployment of the Nedap or Better etc server should always be coherent. Maybe setting some global config var or similar is useful so that running tools and services can double check.

I think the simplest and clearest thing to put in the specs is:

• it is assumed that design-time references to other archetypes due to use_archetype statements will always resolve to archetypes using the same coding convention as the current archetype

• it is assumed that runtime references from data (within LOCATABLE) to generating archetypes will resolve to artifacts using the same coding convention as the data.

• these specifications do not try to formally enforce this, since it is a matter of ensuring that any design-time or runtime environment is configured correctly to use only one coding convention.

Aside: the best design approach for an ADL2 system using the at-code convention would have been to keep the at-coding inside only, and translate everything to id-coding through the APIs. already worked out the right algorithm a long time ago. I think that the current direction is going to ultimately block anyone ever using id-coding (which is not just about id-codes, but about regular computable codes which the old at-codes are not) in openEHR. It’s also creating a lot of work - I’m watching the number of mods to Archie to do legacy at-coding. That’s a real pity, because the separating of ‘about’ codes (id codes) and value codes (at & ac codes) is the basis of modern terminology. Maybe we can only finally fix it in openEHRv2, if that ever happens

yes. And for (all) openEHR environments it’s specified to be at coded. So I’m talking about references to archetypes from a locatable.node_id/archetype_details, so I’m not talking about a reference from other archetypes. Though that’s a good point as well. I’d suggest to put your rule into the spec as well.

And come to think of it, it also makes sense as a rule for references from data: assuming the system can detect wether the locatable is at or id coded, that coding is also the coding for the version of the archetype that is referenced. E.g. if the locatable is at coded the archetype reference in its node id references the at coded version of that archetype. It would be a more elegant way to solve this then my proposal to say locatable always references at coded archetypes. And it would probably allow mixing codering systems in a CDR if someone wants this. So this is all about RM. The trickiest part may still be in the AQL.

I agree in the AM it doesn’t make sense to state use_archetype always references at coded, that would unnecessarily brake a key feature for id coded archetypes.

I don’t want to allow at-coded archetypes to reference id coded archetypes specifically. We might want to clarify that this is impossible.

How do you feel about the statement that at and id coded archetypes with the same HRID are considered different representations of the same archetype? Because between adl1.4 and 2.x ‘versions’ of the same archetype ‘concept’ I remember you saying they are to be considered different archetypes. e.g. downloading an adl2 archetype converted from the CKM blood pressure 1.4 archetype is to be considered a different archetype. I think it makes sense computationally, but clinically it’s a little confusing, because clinically it’s all different technical representations of a singular clinical concept blood pressure. So I’d like to be extra clear on this.

Whether at- or id-coded archetypes are being used should be an environment question. Any references to other archetypes will resolve to archetypes using the same form of coding as the current archetype. If that is not the case, that’s a problem in the model environment setup.

So there’s nothing special needed in archetype identifiers or LOCATABLE nodes to achieve this.

Stating somewhere that a use_archetype_ref (slot filler) always points to an at-coded archetype is a bad idea. Any tool that does that will break instantly on id-coded archetypes (like the ones we use).

Unless you really want to allow at-coded archetypes to point to id-coded archetypes, which I don’t imagine anyone wants.