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