Dear all,
The archetype ‘Self-reported data’ has been through two review rounds, and the editors recommend it for publication.
If any objections or comments, please add them here in due time for planned publication on November 14th.
Kind regards on behalf of the editors,
Silje Ljosland Bakke
Hi, I am using this archetype but i downloaded it 2 weeks ago. I will see if i can have translations in french and german during this week or next. I will need to update all the templates with this and it can take some time.
Is there an quick way of changing a composition archetype without having to rebuild the whole template? 
I haven’t tried it, but I guess hacking the oet or json template file could work?
I was thinking through tooling, some kind of feature that would do this automatically, not editing the code. But I will try to check it out
I don’t know of anything in the tooling. I’d be interested in hearing about it if you find something! 
@borut.fabjan look here a ADL feature idea 
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?
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 
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
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.
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.
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.
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 