# 'Self-reported data' is ready for publication
**URL:** https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144
**Category:** CKM publication
**Tags:** archetype
**Created:** [7 November 2022 11:05 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144 "2022-11-07T11:05:39Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [7 November 2022 11:05 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/1 "2022-11-07T11:05:39Z")
Dear all,
The archetype ‘[Self-reported data](https://ckm.openehr.org/ckm/archetypes/1013.1.6343)’ 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
---
### Author:  [@vanessap](https://discourse.openehr.org/u/vanessap)
#### Post date: [7 November 2022 13:27 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/2 "2022-11-07T13:27:55Z")
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? 😅
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [7 November 2022 13:32 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/3 "2022-11-07T13:32:03Z")
> [@vanessap](#):
>
> 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?
---
### Author:  [@vanessap](https://discourse.openehr.org/u/vanessap)
#### Post date: [7 November 2022 13:38 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/4 "2022-11-07T13:38:01Z")
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
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [7 November 2022 13:39 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/5 "2022-11-07T13:39:47Z")
I don’t know of anything in the tooling. I’d be interested in hearing about it if you find something! 😊
---
### Author:  [@vanessap](https://discourse.openehr.org/u/vanessap)
#### Post date: [7 November 2022 14:04 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/6 "2022-11-07T14:04:16Z")
@borut.fabjan look here a ADL feature idea 👀 👀 👀
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [7 November 2022 14:47 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/7 "2022-11-07T14:47:46Z")
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?
---
### Author:  [@vanessap](https://discourse.openehr.org/u/vanessap)
#### Post date: [11 November 2022 11:42 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/8 "2022-11-11T11:42:40Z")
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 😄
---
### Author:  [@birger.haarbrandt](https://discourse.openehr.org/u/birger.haarbrandt)
#### Post date: [12 November 2022 20:43 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/9 "2022-11-12T20:43:39Z")
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
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [14 November 2022 09:01 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/10 "2022-11-14T09:01:04Z")
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.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [14 November 2022 10:00 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/11 "2022-11-14T10:00:02Z")
> [@siljelb](#):
>
> `provider` parameter doesn’t exist on the composition level
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.
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [14 November 2022 12:05 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/12 "2022-11-14T12:05:31Z")
> [@thomas.beale](#):
>
> 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.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [14 November 2022 12:19 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/13 "2022-11-14T12:19:25Z")
> [@siljelb](#):
>
> class level (whether it’s COMPOSITION or ENTRY) RM attributes can be constrained in AD, other than possibly changing their names
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 ?
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [14 November 2022 12:22 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/14 "2022-11-14T12:22:07Z")
> [@thomas.beale](#):
>
> 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.
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [15 November 2022 11:43 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/15 "2022-11-15T11:43:22Z")
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.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [15 November 2022 11:48 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/16 "2022-11-15T11:48:04Z")
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.
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [15 November 2022 11:57 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/17 "2022-11-15T11:57:16Z")
> [@thomas.beale](#):
>
> I think the tooling question should be investigated sooner rather than later
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.
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [15 November 2022 12:09 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/18 "2022-11-15T12:09:01Z")
Archetype published.
---
### Author:  [@vanessap](https://discourse.openehr.org/u/vanessap)
#### Post date: [19 April 2023 11:01 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/19 "2023-04-19T11:01:11Z")
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](https://discourse.openehr.org/t/the-good-the-bad-and-the-wat-of-current-simplified-flat-simsdt-openehr-exchange-format/3819/31)
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!
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [19 April 2023 11:06 UTC](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144/20 "2023-04-19T11:06:33Z")
I’m just waiting for people wiser than myself to agree on whether it’s a breaking change or not 🤷♀️
[Next page](https://discourse.openehr.org/t/self-reported-data-is-ready-for-publication/3144.md?page=2)