On 05/04/2011 19:16, David Moner wrote:
> Hello,
>
> I like that approach regarding namespaces, it will be needed sooner
> than later.
>
> Related to archetype identifiers there is another problem still to be
> solved. How they deal with RM evolutions? Current openEHR RM release
> is 1.0.2 but it can change in the future. Nowhere at archetypes is
> said which RM version was used to define them. This information should
> go, at least, at the archetype header, but probably should also be
> represented at the archetype id. Otherwise we will not be able
> to differentiate between an archetype for one version of the RM and
> the same archetype (modified if it is the case) for a different one.
It should go in the archetype, that is for sure - but it should be
understood only as 'the RM version used when this archetype was authored
/ quality assured etc' - rather than 'the RM version for which this
archetype is valid'. The reason is easy to understand: for some
particular archetype, authored at RM 1.0.2 let's say, it may be valid
for many RM revisions after that, even RM 2.x, and not only that, it
might be perfectly valid for prior revisions e.g. 1.0, 1.0.1, even 0.95
- it can depend a lot on what parts of the RM the archetype happens to
use. This is the reason I argued against including the RM version in the
archetype id, because it doesn't tell us anything about validity. (We
had a long discussion about this on the technical list last year or 2009
I forget which).
Now.. if the RM changes, let's say to 2.0.0, then we might assume that
there are one or two breaking changes, and that a few archetypes could
break. The only way I can see to deal with this is:
* we stick with the rule that minor RM change numbers never break
archetypes (or indeed existing data), i..e 1.0.1 -> 1.0.2 -> 1.0.3
etc is guaranteed safe
* we say that a major RM version change, i.e. 2.x, 3.x etc that
includes breaking changes there has to be a validity test run on
all archetypes.
o any that don't pass, i.e. are compromised by the change need
to be marked in some way, maybe a header field with the
meaning 'valid up to RM release xxx' or so.
o such archetypes would themselves then have to be versioned
(xxxx.v1 => xxxx.v2)
It should be remembered that we can undertake many innovations and
'fixes' that don't break anything on the RM, and therefore don't require
a major release. So openEHR 2.x, 3.x etc are likely to be extremely rare
events.
- thomas
>
> David
>
>
>
> 2011/4/5 Ian McNicoll <Ian.McNicoll at oceaninformatics.com
> <mailto:Ian.McNicoll at oceaninformatics.com>>
>
> Hi,
>
> About a year ago Thomas published a draft of some detailed
> artefact identification proposals at
>
> http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf
>
> to help with the rapidly approaching scenario of having to cope
> with similarly named artefacts being published by different
> authorities. We are starting to see this scenario emerging in
> real-world projects and whilst potential collisions can be managed
> informally for now, we will need a formal mechanism before long.
>
> I would like to raise one aspect which I think might need
> re-thought on the basis of recent IHTSDO proposal for SNOMED
> covering the same ground.
>
> In the pdf Thomas says
>
> " When an archetype is moved from its original PO (e.g. a local
> health authority, or a specialist peak
> body) to a more central authoring domain (e.g. a national library,
> openEHR.org) its namespace will be
> changed to the new domain, as part of the review and handover
> process. The archetype's semantic
> definition may or may not change. In order for tools to know that
> an archetype was not created new
> locally, but was moved from another PO, an explicit reference
> statement can be made in the archetype
> in the description section of an archetype as follows:"
>
> id_history = <?se.skl.epj::openEHR-EHR-EVALUATION.problem.v1?
>
> The IHTSDO proposals cover the same scenario i.e a SNOMED code
> originally authored in one namespace subsequently being managed in
> a new namespace. A good example might be a SNOMED term which is
> originally used t a national level but is then adopted
> internationally. They suggest that the term keeps its original
> authored namespace, and it is the namespace of the managing entity
> that changes, arguing that this is much less disruptive to systems
> that are using the term concerned.
>
> I think we should consider adopting the same approach for openEHR
> archetypes, as otherwise the formal identifier of an archetype
> will change if a locally developed archetype becomes promoted to
> international use, a relatively common occurrence.
>
> We would then need to record the current publisher so that the
> agency with current responsibility could be identified
> current_publisher = <?se.skl.epj?>
>
> Thoughts would be welcome as I think we need to start making these
> (or alternative) specifications formal to enable tooling and
> application support to go ahead.
>
> Ian
>
> Dr Ian McNicoll
> office +44 (0)1536 414994
> 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 analyst, 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>
>
>
> _______________________________________________
> 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
>
>
>
>
> --
> David Moner Cano
> Grupo de Inform?tica Biom?dica - IBIME
> Instituto ITACA
> http://www.ibime.upv.es
>
> Universidad Polit?cnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
> Valencia ? 46022 (Espa?a)
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*
Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110406/282c622c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110406/282c622c/attachment.jpg>
