Hello! Just some experience on update cycle frequencies, as they have stabilised over years of evolution in organisations that successfully survived the challenge of large scale implementation among many countries, companies and healthcare organisations:
- IHE has a strict yearly update cycle that works. - The Continua Health Alliance is now closing in on a strict yearly (or was it twice a year?) cycle. - The Austrian insurance card system (15000 GPs, 100 or so hospitals, about 100 vendors) updates twice a year on average, and everybody is happy. An attempt on the mechanisms of the "fittest" update frequency might look as follows: Anything that is faster than twice per year: vendors and care organisations will have no chance to implement. Anything that is slower than once per year will not meet clinical requirements fast enough. Anything that is in some kind of stable synchrony to the calendar year helps: "Oh it is January, we can throw in new requirements and start discussing." "Oh it is August, now let us look at the new specs/archetypes and start implementing." Greetings from Vienna, Stefan Sauermann Acting Program Director Biomedical Engineering Sciences (Master) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: +43 1 333 40 77 - 988 M: +43 664 6192555 E: stefan.sauermann at technikum-wien.at I: www.technikum-wien.at/mbe I: www.healthy-interoperability.at Ian McNicoll schrieb: > 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 > <mailto:ian.mcnicoll at oceaninformatics.com> > > Clinical Modelling Consultant, Ocean Informatics, UK > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > <http://www.openehr.org/knowledge> > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org <http://www.phcsg.org> > > > > On 27 April 2011 06:28, Diego Bosc? <yampeku at gmail.com > <mailto: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 > <mailto: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 > <mailto: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 > <mailto:ian.mcnicoll at oceaninformatics.com> > > > > Clinical Modelling Consultant, Ocean Informatics, UK > > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > <http://www.openehr.org/knowledge> > > Honorary Senior Research Associate, CHIME, UCL > > BCS Primary Health Care www.phcsg.org <http://www.phcsg.org> > > > > > > > > On 27 April 2011 02:38, Diego Bosc? <yampeku at gmail.com > <mailto: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 <mailto:openEHR-technical at > openehr.org> > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org <mailto:openEHR-technical at > openehr.org> > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org <mailto: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 <mailto:openEHR-technical at openehr.org> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
