Hi Ian, This sounds more sensible to me, I was always worried about the change in identifier when it got escalated to a higher PO.
I wonder if we can get a summary of the rest of the SNOMED namespacing scheme so that we can see if it is usable in its entirety. I have always been a supporter of the readable identifiers but I am now starting to see their limitations in reality. I think we should seriously consider an existing standard unique identifier scheme (UUID/GUID or OID) rather than trying to invent a new one. I understand that there are issues with using these existing schemes but I can't say that I am seeing that namespaced archetype ID helps these issues, the only benefit is some readability but this is countered by clashes in the wild and the governance overhead to get it controlled. The Archetype class has a UID attribute, I think we need to start using this as an object identifier, after all an archetype is an object. In the artefact maintenance area, we can start using the ObjectVersionId scheme to manage the PO (creating system) and revisions. Alternatively we can use a single OID to represent the PO with a root and the artefact ID as an extension. The issue with this suggested change is that we will have to work out how we make this work with the existing archetype IDs used in data or transition away from using existing archetype IDs. In the short term I think we need to concentrate on template identifiers as the problem is worse with many more organisations producing templates that overlap and less being reused between organisations. Therefore, we can try a standard UID approach for templates without the legacy and once we have this sorted we can look at integrating back into archetypes. Personally, I would like to propose the use of OIDs for controlled artefacts as it is an ISO standard and already used in health informatics for identifying such knowledge artefacts such as terminologies. I know OIDs are not liked due their length, unreadability and managed allocation, but to me it is a natural fit for this kind of artefact ID. Each publishing organisation can get an OID and manage the items that they produce, this can be done using a content management system automatically as is done by CKM. And to be honest, the new namespaced ID scheme is likely to be longer and requires management, and barely legible once we include the namespace and additional delimiters. We can also have a fallback to GUID for organisations that don't have an OID and a knowledge management system to maintain an OID. This would be the default when a new template is created in a template editor but can be upgraded to an OID once submitted to a knowledge management system. Regards Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Ian McNicoll Sent: Wednesday, 6 April 2011 1:21 AM To: For openEHR technical discussions 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/kn owledge_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 -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 10878 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110406/affd720a/attachment.dat>
