Hi! I like the Erik's idea of having a global and unique URI to reference each archetype (also for templates). This will help to build a global archetype server, and the domain of the URI can act as the namespace of the archetype. And, if those domains really exist (like openehr.org), an archetype URI can be equal to real working URL :D, so we can request any archetype directly from the server via HTTP requests.
And it'll be great to build automated archetype tests to check the validity of an archetype against a version of the RM, as Thomas said. It'll be great to have this functionality integrated with the archetype editor. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Wed, 6 Apr 2011 23:11:42 +0100 From: [email protected] To: openehr-technical at openehr.org Subject: Re: openEHR artefact namespace identifiers 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. 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. 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> 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 -- Thomas Beale Chief Technology Officer, Ocean Informatics Chair Architectural Review Board, openEHR Foundation Honorary Research Fellow, University College London Chartered IT Professional Fellow, BCS, British Computer Society Health IT blog _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110407/f1db58e5/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/20110407/f1db58e5/attachment.jpg>
