I don’t know of anything in the tooling. I’d be interested in hearing about it if you find something! 
1 Like
Couple that up with the AD template comparison facility and that would be a great feature i.e create a new temporary updated template using the V1 version and see what changes/breaks?
2 Likes
Hi, a collegue from my workplace kindly translated this archetype today to french. For who translated it to german during this week, my many thanks, saved me some time 
1 Like
Hi all,
is there an overview of the rationale for this archetype? I would have assumed, that setting the composer (or provider) fields in the RM are the sufficient.
Cheers
1 Like
The provider parameter doesn’t exist on the composition level, only on the ENTRY level. As for composer, template building tools in common use don’t allow us to constrain RM parameters.
Well that field is on a per-Entry basis - each Entry in a Composition could easily have its own information provider.
The archetype has this in its ‘use’ documentation:
Use as a generic container to record information provided by an individual, to support clear separation of patient-generated from clinician-generated health data.
That’s exactly the purpose of the ENTRY.provider and COMPOSITION.composer attributes, which are part of the RM, and are therefore guaranteed to be distinguishable by any openEHR software, regardless of any archetype. These fields are not typically constrained, since they will be set at run-time, but they can be, and there are even examples in the specifications of constraining ENTRY.provider to ‘self’ (= patient).
Moving the basic distinction between patient- and professional-generated data to archetype level does not sound like a good idea I have to say, and is contrary to the basic design of openEHR.
NB: current software using the current RM attributes will no longer retrieve data correctly with this change.
If either of these fields needs to be constrained at design time, I would strongly recommend doing so in the tools. I am not sure why these fields would be any more difficult to constrain than any other.
1 Like
In practice, none of the class level (whether it’s COMPOSITION or ENTRY) RM attributes can be constrained in AD, other than possibly changing their names. This is the same for a lot of element level RM attributes.
There’s no technical difference between the attributes that you can constrain in the tools (like name, ELEMENT.value, items in a CLUSTER etc) and these attributes - they’re all RM attributes.
I think either CKM and/or the tools are using some informal classification of attributes to make them constrainable or not. At least in Archetype Designer, this should just be a trivial operation to change the classification of any such attribute to make it constrainable. @borut.fabjan ?
That would be amazing.
Until the ability to constrain the relevant RM attributes is available in AD, we’ll publish and use this archetype. We can always deprecate it later if and when the necessary tooling changes are available.
Well I think the tooling question should be investigated sooner rather than later. Using archetypes that create different and unexpected patterns in data (contrary to the specifications) are going to confound querying and applications, since most will never be programmed to look for data in any place other than the ones documented in the specs. Plus this kind of archetype as far as I can see adds unnecessary structural complication to the data.
2 Likes
I agree, and I’m pretty sure we’ve asked about this a long time ago. The requirement is already long overdue, and we can’t wait any longer for tooling changes which may or may not come any time soon.
2 Likes
Archetype published.
Hi @siljelb ! There is a discussion regarding some issues on this archetype with some elements that were wrongly introduced by adl designer: The good, the bad and the "Wat?" of current simplified FLAT/SimSDT openEHR exchange format - #31 by erik.sundvall
Is it possible to have a look? Seems a new change request has been open on ckm and the fixed version of the archetype is available there.
Many users are using this archetype (me included ) and would be really good to have this available asap so we can rebuild the templates.
Thanks!
I’m just waiting for people wiser than myself to agree on whether it’s a breaking change or not 
I’ve just checked that the ‘canonical’ data that is recorded is unaffected by this issue.
So from a CDR POV this is not a breaking change.
There is an argument that because it will break changes in Web-template paths and related artefacts like FLAT examples, that this merits popping it up to V2.
The counter-argument is that this archetype is very new and probably those who are/were about to use it (and use FLAT) are already aware of the issue, and in any case it is more of a local problem needing any FLAT format compositions to be tweaked in any case.
I don’t have a strong view either way - going to V2 is probably cleaner though.
I don’t think we at Karolinska have any strong opinions on exact versioning (even though I brought it up) but we very much would like to see a corrected version of the archetype published as soon as possible.
Another unrelated note bit relevant to the thread:
Setting the COMPOSITION.composer to PARTY_SELF is another option to distinguish a whole composition as self reported. Does that seem sensible to @thomas.beale and others?
This archetype is not a tooling workaround, it is needed anyway, not for detection of provider/composer, but because there are no other composition archetypes suitable for a combination of self reported things (e.g. questionnaires and measurements - often combined) if you look at the purpose of existing ones. Most of them are explicitly declared as meant for different clinical settings.
After a fair bit of internal discussion and advice from Swedish colleagues. @sebastian.garde and I agree that we should just clock up the fixed version as a minor revision i.e v1.1 and not go to v2.0.
Arguments
- Technically this is not a semantic breaking change in any patient data - the faulty atCodes never appear there.
- Tooling that makes use of atCoded node names on RM attributes may be affected (as per the Web template generation) but arguably should not do this, at ;least for run-time artefacts like FLAT JSON compositions.
- We suspect very few implementers have been affected, and of those they may well have applied workarounds, and in any case the issue can be corrected easily by regenerating the template with the updated composition and a tiny bit of editing to the template json file.
- Going to V2 is way more disruptive for implementers
We will work up some clear guidance and post as a separate Topic, so that anyone affected understands what to do to the fix the issue. In the mean time, we think the fixed composition should be committed in CKM as v1.1 @siljelb
3 Likes
Republished as v1.1.
3 Likes