Heavy?
This reality.
Who said that real life is simple?
To provide for these three real life processes takes the correct set of
attributes per artefact.
What is so complex about that?
Gd
Sent from my iPhone
On 10 sep. 2011, at 01:14, Sam Heard <sam.heard at oceaninformatics.com> wrote:
> Hi Gerard
>
> I think this will be too heavy a process - I would go for candidates in the
> first phase. Mind you for local archetypes, replicating the central process
> seems appropriate if there is a sufficiently large user group.
>
> Cheers Sam
>
> Sent from my phone
>
> On 10/09/2011, at 4:37 AM, Gerard Freriks <gfrer at luna.nl> wrote:
>
>> Hi all,
>>
>> There are (at least) three artefact production processes:
>> - one for the author('s) designing unripe artefacts. This is the initial
>> design, authoring phase.
>> - one for public, more ripe, draft artifacts that are shared with others.
>> This is the reviewing, QA, phase.
>> - one for active published artifacts, This is 'official' published artifact
>> phase.
>>
>> Each of these processes has their own 'state model', meta-data attributes,
>> rules, etc, that must be managed by any artifact repository via a
>> standardized interface.
>>
>> GF
>>
>> Gerard Freriks
>> +31 620347088
>> gfrer at luna.nl
>>
>>
>>
>>
>> On 8 sep. 2011, at 11:14, Diego Bosc? wrote:
>>
>>> As I said before, I am perfectly fine with archetypes being volatile,
>>> unstable, and whatever you want. What I don't like is archetypes
>>> disappearing into the 'limbo'. Ignoring the versioning may be OK when
>>> you are just completing the archetype (missing terms, etc.), but
>>> surely is not OK for archetypes with big structural changes (even if
>>> they are draft).
>>> I'm not telling you to show it in the same way that current 'up to
>>> date' archetypes. Hide it to most users, mark it obsolete, deprecated,
>>> put a red flag... there are a lot of alternatives. Having the obsolete
>>> archetypes available also helps you to understand why the new version
>>> was needed on the first place.
>>>
>>> I don't really see the point of leaving the drafts out of the
>>> versioning process (why don't they have any 'official' status in the
>>> first place? incomplete concepts are still concepts). Archetype status
>>> (drafts, published, team review, etc.) and versioning (SemVer?) should
>>> be two completely separated things
>>>
>>> There is another thing I think I haven't quite understand from your
>>> post. Is 'editing' process made by reviewers or is an additional
>>> process to the 'review' process made by a team of editors? If the
>>> editors are all the reviewers (currently more than 200 regarding CKM
>>> statistics) then the real challenge is to involve them (as seems like
>>> most of them are inactive users)
>>>
>>> Diego
>>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110910/ca2b88e7/attachment.html>
