Hi Stefan,
This is very helpful.
As you suggest, it is not easy to reconcile the different speeds and
requirements from all parties The next major upgrade of CKM due pretty soon
will include a much more complete implementation of Release Sets which I
think will help address this issue. In the real world vendors and developers
will almost certainly work from pre-packaged Release Sets, rather than
individual archetypes, particularly as we start to see much more complex
inter-dependencies between archetypes, their specialisations, slotted-in
components and termsets etc. The paradigm is of a library of related
software components, rather than stand-alone documents. In line with your
update cycle comments, I would foresee the openEHR CKM having once or twice
yearly 'official' Release sets. At national level, things may be quite
different with a number of different project-focused Release Sets being
available to developers.
The 'first draft' of an archetype, where one can expect considerable churn
is something of a special case, particularly as it is likely to introduce
'breaking' change and I can understand Diego's concern but it is difficult
to envisage a better solution.
Would calling first draft archetypes .v0 help to highlight their fragility?
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 08:47, Stefan Sauermann <sauermann at technikum-wien.at>wrote:
> Hello!
> There are two flavours:
> A - You freeze everything, and enjoy a safe and stable set of
> archetypes. These of course do not cover a lot of functionality right now.
> B - You have dynamic response to new requirements, and will never be
> sure that two versions interoperate.
>
> A is what a clinical environment needs to stand a chance of surviving
> risk management and project deadlines.
> B is the creative chaos that the clinical community needs to develop
> opinions and agreements.
>
> I have the feeling that these flavours do not fit into the same set of
> versioning policies.
>
> It seems that the idea of "published" versions as Heather described it
> is a very appropriate way to handle this.
> I guess the best we can do is to be aware of this issue and support the
> work that Heather describes:
>
> "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."
>
> Being in the middle of a project to develop a national laboratory report
> template, I briefly went through CKM and tried to map what I find there
> with our Austrian requirements. I have the feeling that the
> harmonisation process is definitely doable. However to me this still
> needs a few rounds in the "creative chaos" level. It still might take a
> substantial and focused effort to get it done.
>
> Looking forward to meet you again, 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
>
>
>
> Diego Bosc? schrieb:
> > 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-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-technical_lists.openehr.org/attachments/20110427/c8cab272/attachment.html>
