Hi Sam, Pablo and everybody else!
We started archetype development in the NHS using Subversion and it got in a real mess very quickly.
It would be interesting to know why it got into a mess and what the alternatives were at the time. Was subversion the problem or was it the development process and lack of tooling? If you put raw subversion or software-developer-targeted tools in the hands of clinicians I find it very likely to get messy…
What I was proposing included…
“4. Clinician-friendly GUIs with CKM-like functions that
hides/incorporates layers 1,2, and 3 to end users that want CKM.”
I do not suggest quitting the use of the current CKM until an equal or better alternative is available (including functions corresponding to the CKM today).
So if the CKM works today I do not see why changing storage backend from the current (commercial) asset management system to a DVCS based system would create any more “mess”. Sticking with several instances of uncoordinated CKMs (running at Netha, openEHR, SKL etc) will probably slowly get us into a real merging mess, but perhaps not recognized at first.
For EHR data the current openEHR RM versioning system described in the specifications is based on DVCS principles instead of logically disconnected EHRs that just exchange extracts, messages or distributed searches from time to time. That makes initial design more complicated than for traditional monolithic EHRs, but it makes later connection and cooperation a lot easier. I don’t see why archetyping would be so very different in this sense.
As Pablo says the version and dependencies are not the same as in code.
EHR content is not “code” either, but in openEHR we use DVCS principles for handling it anyway.
I’d guess the long-time requirements for trying to merge and cross-pollinate global archetyping assets to achieve real semantic interoperability is a complex problem that is closer to the global Linux development and merging efforts than to an asset management system designed for a single organisation. Archetypes and sets of archetypes/templates are supposed to be coherent and computable and might from a management point of view be closer to code than you think.
Everyone is of course allowed to have their own beliefs, now I have stated mine. 
I think we need to consider what are the tools that are needed now to make openEHR more attractive to clinical application developers, and what are the functions of those tools.
Agree. Now we have the CKM let’s use that.
Once you have done a couple of big merge effort of archetypes from different CKMs then a need for more coherent backend versioning semantics and merging/synchronization system might become more obvious, but I might be wrong of course.
Let’s ensure that businesses can thrive working in the openEHR environment and make sure we try and fill the gaps as the first priority.
Sure. Use the CKM now, but don’t discourage discussions of future backend enhancements just because that is not the priority of a certain business or company right now.
On Thu, Feb 2, 2012 at 18:19, pablo pazos <pazospablo@hotmail.com> wrote:About using some version control system (VCS), I don’t think this is a good solution because the semantics of “archetype version” are not the same semantics as in “plain text versioning” (here changing one character will create a new version of the artifact).
Since archetypes can be digitally signed, changing a single character may actually create the need for a new version technically. That does not mean that every little change will need to change the version number field inside the archetype file if the DVCS system can be used for such “between-internal-version-number-tracking” instead (for those that use bleeding edge archetypes that are not formally released). Manual version numbering (that we discussed in an earlier thread) is a separate issue having more to do with official releases or merging into some official release branches.
With VCS you can handle local/internal evolution of an archetype in development, but for a global/public archetype versioning system, IMO this is not the right tool to handle archetype versions (and other artifact versions).
If you keep the issues of manually assigned version numbers (inside files) and technical versions (labelled by checksums in GIT) separate, would that make the solution more attractive?
A DVCS is great for distributed (and temporarily disconnected) cooperation and distribution of artifacts (including complete version history available at all places that may want it).
Now I don’t see that these problems could be solved by combining some available tools,
Not all problems. A CKM-like GUI is one of the things that needs to be added.
I think we need to define something new.
For some parts probably yes, but using available components is always a help.
I hope others can convince otherwise, but this is how I feel right now.
I am trying.
Lets hope we get more input from many others before rushing into implementation. My belief is that the global future change-tracking and merging problem needs to be considered at an early stage, but I am sure that I don’t see the whole picture or all problems myself yet, so let’s think together.
Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
