Note that in the SNOMED case, there are two identifiers in play: the concept identifier (which contains the namespace ID) and a module identifier. The idea is that ye namespace in the concept identifier will remain fixed and thus indicate the entity that originally introduced the concept, while the moduleId used associated with the defining entries in the release files changes to indicate the entity currently maintaining that concept.
michael From: Ian McNicoll <Ian.McNicoll at oceaninformatics.com<mailto:[email protected]>> Reply-To: For openEHR technical discussions <openehr-technical at openehr.org<mailto:openehr-technical at openehr.org>> Date: Wed, 6 Apr 2011 01:51:05 +1000 To: For openEHR technical discussions <openehr-technical at openehr.org<mailto:openehr-technical at openehr.org>> Subject: openEHR artefact namespace identifiers 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>
