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. David 2011/4/5 Ian McNicoll <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 > > Clinical analyst, Ocean Informatics, UK > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > > _______________________________________________ > openEHR-technical mailing list > 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110405/b5523d2a/attachment.html>
