Also, some of the restrictions of the identifier name seem arbitrary, like minimum number of characters or what characters can you put.
2011/4/6 David Moner <damoca at gmail.com>: > 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) > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
