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
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
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
Isn’t the convention that in a specialised archetype newly introduced nodes get an at code à la at0.x , e.g. at0.1 for the first?
In specialisation of a specialisation it would be at0.0.1.
For specialisation an existing node at0001 it would be at0001.1, (or at0001.0.1 if it was specialised in a specialiation of an specialised archetype), etc.
With this you don’t have to decide on the number of required node codes in the parent in advance.
Cheers
Sebastian
Stef Verlinden wrote:
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
My question was about parallel adding of next one field in archetype.
For example, I have an archetype MyArch (cluster) wich contains several items (ELEMENTs) at0001…at0007.
Now I and my colleague need to change this archetype: I need to add new DV_TEXT ELEMENT ‘Comments’ and my colleague needs to add other field CLUSTER ‘Contacts’.
In this case both my and his fields would have same IDs ''at0008". So probably it could be automatically merged to 2 different nodes both with ‘at0008’ ids ==> error.
So, I need to lock archetype everytime I’m editing it.
2010/7/13 Hugh Leslie <hugh.leslie@oceaninformatics.com>
Koray,
you can split up the archetypes in small ITEM_TREE’s. Each develop team works with his own ITEM_TREE archetype. In the main archetype you create slots. The slots you can fille later on with the ITEM_TREE archetypes. This way you avoid, that diffrent develop teams, use the same atxxxx codes.
Alessandro
2010/7/13 Игорь Лизунов <i.lizunov@infinnity.ru>
Hi Igor
I understand what you mean. There is no simple way to do this - in software development, when you are editing the same segment of code in a group it nearly always comes down to a human making a decision.
The important thing is to have version control in place, so you can roll back if necessary and try to commit often and always get the latest version before you commit anything. What we tend to do in building archetypes is use a higher level tool such as a mindmap editor (see xmind as an example) to agree on the concepts and their relationships and then build the initial archetype which is then about 80% right. Then the archetype will go into the CKM where a group can comment and discuss with only a small number of people (often only one) making the changes as needed. Then there are further review rounds until there is agreement and its published as a version one archetype.
Hope this helps.
regards Hugh
Hi Koray,
The current issue with ordering of internal lists is actually a ‘feature’ of the Ocean Archetype editor, which always re-organises the list alphabetically. In an upcoming release, this is corrected so that the designed order remains untouched and can be adjusted via up/down controls. It also adds the ability to copy list contents from an external tab-separated list and to use the same facility to easily copy/paste between lists, where the list content is very similar.
I am not sure exactly when this will be released but it is currently undergoing testing.
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk
Clinical Analyst Ocean Informatics
Honorary Senior Research Associate, CHIME, University College London
openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
this is correct - all specialise at-codes are created at their depth of specialisation, i.e. with the requisite number of ‘.’ separators. It is mathematically impossible to get mixed up between specialised at-codes and at-codes of the parent archetypes from which they were derived.
Hi Igor,
I would very much agree with Hugh. We tend to do a great deal of preparatory mind-mapping as a joint exercise, prior to doing any real archetyping. We also try hard to avoid do any parallel archetype development, partly for the reasons you stated, but also because it is important for a single person to have a coherent picture of the archetype and ‘editorial contyol’.
If the archetype is so big that this feels impossible, it is quite likely that it is simply too big in the first place and should be broken down into smaller components. Alessandro’s suggestion is also helpful at times, though you would normally use CLUSTER archetypes, rather than ITEM_TREE archetypes which are less granular.
You should definitely use some sort of version control. CKM is purpose-built for this kind of activity but Subversion can be used successfully as long as clear rules are applied.
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk
Clinical Analyst Ocean Informatics
Honorary Senior Research Associate, CHIME, University College London
openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
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
Won't have those new created nodes also a 'dotted' AT? This is the
only way you can distinguish them from the parent ones
Hi Stef,
the identification system proposed for archetypes and templates (see http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf) in the future includes namespacing, in the same way as for software, which ensures there is no confusion about multiple ‘competing’ modifications to the same original archetype.
Hi Stef,
Thomas beat me to it!!
Namespacing will be crucial to resolving this kind of issue but we will also have to enable some very effective communications between development teams so that as new ideas are added locally, they can be disseminated quickly where they have universal appeal. We have a number of ideas to help with this
Federating CKMs so that local changes are flagged up to participating developers
A pre-CKM space where developers can share archetypes and ideas in a much less rigid environment than is required for the formal CKM publishing activity.
This is a very challenging area, technically and ‘socio-technically’ where the right blend of communication and control will be essential;. We need to be able to share developing ideas quickly, rather than in isolation, before these become enshrined in actual implementation ,and therefore difficult to align. In contrast, we also need to have complete control over the exact versions archetypes, templates and termsets in our working systems , and in our design environments. This is where ‘Release Sets’ will become invaluable.
Any ideas would be very welcome
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk
Clinical Analyst Ocean Informatics
Honorary Senior Research Associate, CHIME, University College London
openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland