Re: About parallel archetype editing
Won't have those new created nodes also a 'dotted' AT? This is the only way you can distinguish them from the parent ones 2010/7/13 Stef Verlinden <stef@vivici.nl>: > Hi Koray, > Thanks. I missed that rule for numbering specialized nodes, so that's > covered and I realize I meant something else > By overlapping I mean, and in that case I shouldn't call it a > specialized > but actually a locally extended archetype, is the following: for > example > within the archetype bloodpressure I want to be able to add more > parameters > than the community currently agrees on (f.i. average home blood > pressure > value). For the rest I would like to use the standard archetype > because it > would be silly to reinvent the wheel twice. > So my point is, if I add these extra parameters, how do I prevent that > somewhere in the future we get overlapping AT codes with the > official/ root > archetype? My suggestion is to let the AT nodes for these extended > parameters start with a codenumber of 1000 (of even 10.000) or > higher... > > Cheers, > Stef > > Op 13 jul 2010, om 08:34 heeft Koray Atalag het volgende geschreven: > > Hi Stef, there is already a rule for the numbering of specialised > nodes – > i.e. with dot notation. I don’t understand what you mean by > overlapping. > > Having said that I’d like the community to consider what you do with > the > ‘ordering of items in coded text values’. Currently there is no way to > determine the precise order of an item added either by editing an > archetype > or when specialising it. The need for ordering may be due to domain > knowledge or local requirements (i.e. frequency of appearance in drop > down > lists). Currently the only way I can handle this is inserting > placeholder > intervals in at codes (i.e. incrementing by 10 or more) in the > original > archetype and then when an item is added then I manually edit the at > code so > as to fit into a particular interval which corresponds to the > position I > want. > > If the requirement is to do with domain knowledge it needs to be > represented > in Archetypes – otherwise as I learned from Ocean development team > there is > no impediment to assign an ordinal in template level for precise > ordering. > The specs depict an ordered list as they say which should allow this. > So the > question is if/how to represent that in ADL? I reckon ADL 1.5 handles > this > neatly for individual nodes during specialisation (i.e. Before and > After > keywords) but not for value items…. > > Cheers, > > -koray > > From: openehr-clinical-bounces@openehr.org [mailto:openehr-clinical-bounces@openehr.org] On > Behalf Of Stef Verlinden > Sent: Tuesday, 13 July 2010 6:08 p.m. > To: For openEHR clinical discussions > Subject: Re: About parallel archetype editing > > Maybe it's also a good time (if that wasn't already done:-) to agree > on the > numbering is AT nodes in locally specialized archetypes. Ny > suggestion is > that any specialisation should have an AT node code of 1000 (or even > 10.000?) and higher. The point is that if the original archetype > evolves in > time and we don't do this it could occur that the 'official' AT code > number > start overlapping with the local specialization AT node codes. Which > it that > case makes that archetype worthless for local use. > > > Cheers, > > Stef > > > Op 13 jul 2010, om 07:15 heeft Hugh Leslie het volgende geschreven: > > Hi Igor > > The AT codes are ONLY unique within the archetype that they are > created in, > so AT0001 will appear in every archetype as the root node. Any proper > Archetype editor will make sure that when you edit an archetype, that > the > code in that particular archetype for any element stay the same. If > the AT > code for an element has to change for any reason, then the Archetype > will > require a new version and data created with the two archetypes will > not be > compatible. In general, you don't need to worry about the AT codes > as the > editors will look after that for you. > > When you are working on an archetype in a group (or any other type of > model > or software artifact) you need to put in place some type of version > control > system, like you would for any software project that a group was > working on, > so you are sharing the same models. We have lots of experience with > this > process if you would like to know more. > > Sharing archetypes is what makes openEHR work, and I would definitely > encourage you to have a look at the Clinical Knowledge Manager (CKM) > at www.openehr.org/knowledge which already has a whole lot of > archetypes > that you will need for your work. The CKM has version control built > in and > you will be able to see how archetypes are designed by people who > have been > doing it for years. While there are no Russian translations that I > know of, > the archetypes themselves have no primary language and can easily be > translated. This means, that a Russian translation can be added to > all of > the archetypes in the CKM and then the data can be shared even > internationally. > > regards Hugh Leslie > > On 13/07/2010 2:09 PM, Игорь Лизунов wrote: > Hi Everyone! > > We've regional openEHR project and now we develop archetypes for our > regional repository. > > My problem is: archetypes are developed by several organizations in > parallel. Because of IDs of archetype nodes are coded with increment > numbers > like 'atxxxx' parallel editing by two or more people is impossible. > > So, how parallel editing is realized in OpenEHR standart or why it is > not > supported? > > Best regards and thank you for your answers > Igor Lizunov > > > > _______________________________________________ > > openEHR-clinical mailing list > > openEHR-clinical@openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > > -- > > ________________________________________________ > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > Clinical Director > Ocean Informatics Pty Ltd > M: +61 404 033 > 767 E: hugh.leslie@oceaninformatics.com W: www.oceaninformatics.com > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > -- Diego Boscá Tomás <diebosto@fis.upv.es> <yampeku@gmail.com> Grupo IBIME Instituto ITACA - Universidad Politécnica de Valencia Acceso B Edificio 8G Camino Vera s/n 46022 VALENCIA (Spain) ext: 75277 http://ibime.upv.es _______________________________________________ openEHR-clinical mailing list openEHR-clinical@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical