Hi Diego,
I will be interested in other opinions but I don't think that is really
feasible for first draft archetypes. The only 'official' archetypes in CKM
are those that are published. The remainder will definitely change, some
quite substantially, as a result of clinical review and local implementation
experience with the drafts. If we follow the same strict versioning
arrangements that you suggest, and we agree are absolutely necessary for
published archetypes, we very quickly run up the version number (it would
have been at v3 /v4 by now just for the 2 reviewed demographics archetypes
and these are comparatively simple).
Any projects, including our own, that are using 'draft' archetypes must
accept that these are subject to change and have to be regarded as local
copies.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
On 27 April 2011 06:28, Diego Bosc? <yampeku at gmail.com> wrote:
> I am OK with all that, my only problem is that new iterations should
> make new versions if changes are enough (even in draft status). If not
> all current projects using archetypes will be just wrong with the
> 'official' current archetype in CKM
> The situation of two incompatible archetypes with the same archetype
> identifier is one of the main things we should avoid
>
> 2011/4/27 Heather Leslie <heather.leslie at oceaninformatics.com>:
> > Hi Diego,
> >
> > CKM's role is threefold. It acts as a central library for the openEHR
> > artefacts in all stages of their lifecycle - from draft through to
> published
> > and it is also the place for collaborative review of each artefact, and
> for
> > governance of the published artefacts.
> >
> > Archetypes in draft status on CKM are deemed to be a sound starting
> point,
> > ready for collaborative review. This certainly implies that there could
> > still be significant changes based upon broad feedback by clinicians,
> > informaticians, terminologists, software engineers etc throughout the
> review
> > process.
> >
> > Those in team review status are undergoing a review process and therefore
> > very likely to change in the next iteration. While we endeavour to upload
> > initial archetypes that we consider reasonably mature, we use the crowd
> > sourcing approach of team review to ensure that the archetypes are safe
> and
> > fit for purpose - this is without doubt a very valuable quality process,
> but
> > the outcome cannot be predicted at the outset. This is a very important
> > differentiator - that the models have extensive and domain expert review,
> as
> > I'm sure you'll agree.
> >
> > Only published archetypes are considered stable. Yet even then they may
> need
> > to be updated. Once published, strong governance will be applied to
> ensure
> > that implemented archetypes are revised appropriately when backwardly
> > compatible, and re-versioned when there are breaking changed etc to
> support
> > downstream implementation. To enable this, there is considerable ongoing
> > work on release sets to support implementers manage versioning through
> this
> > process.
> >
> > Hope this helps clarify the situation
> >
> > Heather
> >
> >
> > On 27/04/2011 12:38 PM, Diego Bosc? wrote:
> >
> > So do you mean that only 23 (everything that is not draft) of the
> > current 270 archetypes on the CKM are 'safe' to be used? Everything
> > else could be completely changed in the next revision of the draft :(
> >
> > 2011/4/27 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>:
> >
> > Hi Diego,
> > For those who are not aware, Diego is referring to a slew of updates to
> the
> > Demographic archetypes, most in response to Review comments to the Name
> and
> > Address archetypes.
> > In many cases there have been significant structural changes and if any
> of
> > these archetypes had been published, I would absolutely agree that we
> should
> > have given them new versions. However because they are still in draft
> and
> > have never been published, we need to have the flexibility to make
> > significant changes to structure and content in response to review
> > comments.Once these archetypes are published we will strictly follow the
> > rules about revisions and new versions, and CKM provides very powerful
> > validation checking to help us know when an archetype is no longer
> backward
> > compatible.
> > Unfortunately because of other commitments,We have discussed the
> possibility
> > of adding another publishing status to archetypes to distinguish between
> > archetypes that are in early draft (like alpha code and therefore
> volatiile)
> > and those that are effectively Release candidates - would this be
> helpful.
> > Regards,
> > Ian
> > PS Enjoyed your Japanese presentation.
> >
> > Dr Ian McNicoll
> > office +44 (0)1536 414 994
> > +44 (0)2032 392 970
> > fax +44 (0)1536 516317
> > mobile +44 (0)775 209 7859
> > skype ianmcnicoll
> > ian.mcnicoll at oceaninformatics.com
> >
> > Clinical Modelling Consultant, Ocean Informatics, UK
> > openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> > Honorary Senior Research Associate, CHIME, UCL
> > BCS Primary Health Care www.phcsg.org
> >
> >
> >
> > On 27 April 2011 02:38, Diego Bosc? <yampeku at gmail.com> wrote:
> >
> > Hello,
> >
> > With the latest Demographic archetypes updates on the CKM I think we
> > have to be careful with archetype versioning. The new archetypes seem
> > quite different of the ones that were uploaded some time ago. They are
> > different on structure but the version of the archetype has not been
> > improved (and the last archetype is just missing from the CKM).
> > Shouldn't a change on the archetype structure create a new version
> > (v2) of the archetype?
> > I think changes like "significant update, simplifying structure",
> > "Updated for alignment with altered parent", "Significant re-working"
> > must generate new versions.
> > For all the changes, I think only "Constraint loosened" ones are the
> > only ones that won't need to generate new versions, but everything
> > else should.
> > We should be more careful with this kind of things.
> >
> > Regards
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> >
> > _______________________________________________
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> >
> > --
> >
> > Dr Heather Leslie
> > MBBS FRACGP FACHI
> > Director of Clinical Modelling
> > Ocean Informatics
> > Phone (Aust) +61 (0)418 966 670
> > Skype - heatherleslie
> > Twitter - @omowizard
> >
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110427/c7a85f82/attachment.html>
