poor version management in archetype editor

Clinical (archive)
1

Dear all,

Currently underway in making archetypes using the Ocean archetype editor we encounter a major flaw in the tool.

It is impossible to maintain version management, which leads to many inconsistencies in the archetypes.

Also, while participating in the review of archetypes such as blood pressure, the old (before review) and the new (after review) have the same version.

I think this is a very urgent matter to solve, otherwise we will end up with heaps of archetypes on the same subject that are different.

In particular a requirement is that an author, while developing, is able to have a versioning structure that allows going back to earlier versions, or work on improvements while not changing an existing version directly.

In other words: missing versioning is making it hard to produce archetypes.

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

2

In particular a requirement is that an author, while developing, is able
to have a versioning structure that allows going back to earlier versions, or
work on improvements while not changing an existing version directly.

This sounds like there should be integration with something like Subversion.

But even without integration using a well-developed VCS is possible - after all
text files lend themselves very well to that approach.

Karsten

3

A combination of a good version management tool and an internal configuration management policy works well for us, I would be happy to discuss this with others.

We use subversion as our version management tool and find it indispensible for us.. I would be interested to hear what other archetype/template authors use for their configuration management.

regards
Richard Kavanagh
Head of Interoperability Specifications
Data Standards and Products
NHS Connecting for Health
Tel : +44 (0)113 397 4398
Mob : +44 (0)7770 644449
Richard.Kavanagh@nhs.net
www.connectingforhealth.nhs.uk

NHS Connecting for Health supports the NHS in providing better, safer care by delivering computer systems and services which improve the way patient information is stored and accessed.

4

In a message dated 28-11-2008 10:23:59 W. Europe Standard Time, richard.kavanagh@nhs.net writes:

A combination of a good version management tool and an internal configuration management policy works well for us, I would be happy to discuss this with others.

We use subversion as our version management tool and find it indispensible for us.. I would be interested to hear what other archetype/template authors use for their configuration management.

regards
Richard Kavanagh
Head of Interoperability Specifications
Data Standards and Products
NHS Connecting for Health
Tel : +44 (0)113 397 4398
Mob : +44 (0)7770 644449
Richard.Kavanagh@nhs.net
www.connectingforhealth.nhs.uk

NHS Connecting for Health supports the NHS in providing better, safer care by delivering computer systems and services which improve the way patient information is stored and accessed.

I understand that subversion is used as more or less external software from the archetype editor tool.

That is fine, but still leaves the need to be able to save an archetype as:

body temperature draft v01.adl

and after making changes and update and redistribution,

body temperature draft v02.adl

and when all parties agree it is finished

body temperature draft v1.adl

However, as I understand, such a simple version policy is not possible with the archetype editor, because it makes from scratch on only v1 of all variants.
I agree with mr Hilbert that this is a feature of a simple program, e.g. notepad does it already.

If this is what mr. Kavanagh calls configuration management, that is fine with me, as long as the archetype editor allows us to do this.

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

5

Hi William,

I would agree that some sort of versioning/ rollback facility is a definite requirement. The only issue is whether this is best achieved within the Archetype Editor itself, or by a separate, purpose designed utility.

As Richard and Karsten have suggested, Subversion has proved an excellent tool for this purpose and the NHS have their version management and configuration working extremely well.

Richard, I am sure there would be considerable interest in knowing more about the CfH/NHS approach.

One of the downsides to Subversion is the need to install and configure the server software, which though not particularly difficult, does require some technical skills. I have successfully used Unfuddle www.unfuddle.com for personal and professional hosted Subversion support. There are both low-cost and no-cost options available. This is particularly valuable for team-based modelling. The subversion Tortoise client is easy to use and once a few simple operational rules are estabished, it is pretty easy for users to pick up the various update and commit operations required.

An alternative approach is used by the Clinical Knowledge Manager http://www.openehr.org/knowledge/ where the revisioning and re-versioning and version control is handled internally, though actual archetype editing is currently handed off to the archetype editor via a download/checkout process

There is quite a bit of work being done on clarifying other governance requirements, in particular publisher identifiiers and revision numbers (which are not currently supported by the archetype editor) and this should be coming out quite soon.

There is also an interesting philosophical question!

Part of the reason for the lack of inbuilt version management is that archetypes can be seen as software artefacts i.e programming code, gnerally now managed by within a version control environment, as opposed to human requirements documents, which tend to have support for the version within the filename/file itself. The strength of the archetype approach is that they are BOTH software artefacts AND human information requirements documents, and perhaps we need to reflect this duality in our approach to version control.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

2008/11/28 Richard Kavanagh (NHS Connecting for Health) <richard.kavanagh@nhs.net>

6

I understand that subversion is used as more or less external software
from the archetype editor tool.

That is fine, but still leaves the need to be able to save an archetype
as:

body temperature draft v01.adl

and after making changes and update and redistribution,

body temperature draft v02.adl

and when all parties agree it is finished

body temperature draft v1.adl

Well, the scheme here (using subversion) could be to

- check in a first version of "body temperature"
- create a branch "draft"
- checkout, modify, checkin
- when satisfied tag as "v0.1", "v0.2", ...
- when satisfied with the draft branch merge it back into the main branch

Or similar approaches.

Basically it is more of a policy question. Versioning as such probably should not be the
genuine job of the Archetype Editor in itself. However, if that editor *understood* versioning
and could access/integrate an external tool that would make proper use of versioning
a lot easier, particularly for users not yet familiar with that sort of thing.

Karsten Hilbert

7

I agree with William, because there is already version-support in the archetype ID, it would be good to have that to the functionality of an archeype-editor.
A tool which could handle this well is the ADL-workbench, because it works with a repository, and, thus has knowledge about other archetypes, and can propose a version-part of the ArchetypeID

Archetypes which do not work with repositories still can check the current directory, or the already loaded archetype.

This is really something different than SVN, which has no knowledge of ArchetypeID-versions, in SVN a archetype-version (with the same ArchetypeID version) can have more versions, but that is on file level.
I think it is good to distinguish that.

or am I wrong

bert

Ian McNicoll schreef:

8

(sorry, done some necessary corrections to amke this understandable)

I agree with William, because there is already version-support in the archetype ID, it would be good to add that to the functionality of an archetype-editor.
A tool which could handle this well is the ADL-workbench, because it works with a repository, and, thus has knowledge about other archetypes, and can propose a version-part of the ArchetypeID

Archetype-editors which do not work with repositories still can check the current directory, or the already loaded archetype.

This is really something different than SVN, which has no knowledge of ArchetypeID-versions, in SVN a archetype-file-version (with the same ArchetypeID version) can have more versions, but that is on file level.
I think it is good to distinguish that.

or am I wrong

bert

Ian McNicoll schreef:

9

The tool on its own does not do version management - just as Word does
not version manage the documents you create with it. This is not to say
that the way revisions and versions are managed inside the tools could
not be improved, and there is a forthcoming proposal for governance of
archetypes and template that will deal with these issues. Community
input will be welcome. This proposal wont change the need for tools like
Subversion, and will provide guidance on how to use it to support a
repository of archetypes, and merging archetypes from multiple sources.
Richard Kavanagh's group have already created a good methodology within
the NHS and he mentions he would be happy to share it.

- thomas beale

Williamtfgoossen@cs.com wrote:

10

Governance of archetypes and templates is very topical in a number of
circles at present;-) And so it should be.

The 3 main things that I learned in the NHS work that I participated in
last year were governance, governance and governance, and what I saw
then was pretty simple compared to where the pools of archetypes and
templates have evolved to now.

Your comments and questions are actually well timed as this is all under
significant scrutiny and investigations and discussions are being led by
Thomas Beale. I'm sure they will be posted and shared for community
comment as soon as they are in a cohesive state.

And the need and priority for this is increased with every archetype
produced and every template using the archetype. It is definitely not a
trivial task to maintain any number of either artefacts but it is also
incorrect to say that this is not being addressed.

There are a combination of mechanisms required - those at the
international repository level, and filtering down to national programs,
local projects or individual author pc level. There is no 'one solution
fits all', and the final solution is not complete but there is
significant work being done to solve the issue, and this involves a
combination of people-dependant processes and technical solutions.

And of course it is not as simple as managing archetypes, but also
templates, and terminology subsets; perhaps release sets of archetypes
as well. We need to be sure that the archetype that the modeller
intended is the one that is used in a template, and that the content
that gets implemented in an application is therefore as intended at
design time.

11

Thomas Beale schreef:

The tool on its own does not do version management - just as Word does
not version manage the documents you create with it. This is not to say
  

As a matter of fact, Word has (kind of) version-management in it.
Previous versions of a document are, in that case, stored in the current
document.
However, this solution I would not propose as a solution for archetypes,
it would make them hard to read.

Bert

12

A part of version-management is version-numbering.

One should be able to distinguish major versions and minor updates.

A major version would, for example, be another concept to achieve the same medical purpose, for example (not real life) add some more ways to take bloodpressure, f.e. a new tool/way to do this.
Minor versions would be, for example, removal of small-errors typo’s etc.
For the minor versions I would recommend to use an extern version tool like SVN
For the major-versions, I would like to propose new features to archetype-editors, and a change of the version-part of the ArchetypeID.
But a change of a path-ID, even if it is repairing a typo, would be a major-version, because it possibly effects the retrieval of data in the OpenEhr-system (by AQL).

Bert

Bert Verhees schreef:

13

A part of version-management is version-numbering.

One should be able to distinguish major versions and minor updates.

A major version would, for example, be another concept to achieve the same
medical purpose, for example (not real life) add some more ways to take
bloodpressure, f.e. a new tool/way to do this.
Minor versions would be, for example, removal of small-errors typo's etc.
For the minor versions I would recommend to use an extern version tool like
SVN
For the major-versions, I would like to propose new features to
archetype-editors, and a change of the version-part of the ArchetypeID.
But a change of a path-ID, even if it is repairing a typo, would be a
major-version, because it possibly effects the retrieval of data in the
OpenEhr-system (by AQL).

Actually changes that narrow down the constraints in the current
version should lead to a new version of the archetype. It should be
possible to specify these rules formally and implement them in
archetype editor so that "minor" changes would not accidentally
invalidate data previously created with the same archetype.

Regards,
Rong

14

Bert Verhees wrote:

15

Hi Tom,

This looks good!

My only question here is that if BPv1 and BPv2 are not compatible, they are probably 2 different concepts. The idea to use concept as the identifier is fine.
Using Snomed CT here would be excellent.

then we can have openEHR-EHR-Observation-SnomendCTConceptNameSNomedCTconceptId87654321.

If the concept is non existing in Snomed CT, there are procedures to ask for the addition.

Due to fine grainedness of SNomed CT to a high level it is probably a lot that can be handled with this, also avoiding the same concept used for 2 different archetypes.

I agree with the world wide management of this, but then again the ISO / CEN / HL7 / CDSIC DCM approach (IHTSDO invited) would be helpful.

If we move this way and identify the concept as such, we can have the clinical material specified, modeled in different formats but DCM-Concept-conceptID, OpenEHR-Concept-ConceptID.adl, and HL7templateIDConcept-ConceptID.xml would be identified as clinically exactly the same information, but technically fitting to another reference information model and technology, each with the peculiarities necessary to have it work for purpose.

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

16

Thanks Thomas, for taking action on this

I come back to this later, too busy, right now.

Bert

Thomas Beale schreef:

17

Williamtfgoossen@cs.com wrote:

Hi Tom,

This looks good!

My only question here is that if BPv1 and BPv2 are not compatible,
they are probably 2 different concepts. The idea to use concept as the
identifier is fine.
Using Snomed CT here would be excellent.

well, we hope obviously that they will be very close - when I said 'not
compatible' I only meant that purely automatic processing using BPv2 of
data built with BPv1 won't quite work 100% correctly. This is why there
is a rule in openEHR (open to debate of course) that each new 'version'
(BPv1 -> BPv2 -> BPv3 etc) has to carry with it a little conversion
algorithm (at least an xslt converter) that can be used by systems. It
will be a while before we get this properly standardised, but I think
people can see intuitively how it might work - either for once-off data
migration or for on-the-fly processing.

I would hope to be able to convince IHSTDO to think about Snomed (or
Snomed-like) concept ids for archetypes.

then we can have
openEHR-EHR-Observation-SnomendCTConceptNameSNomedCTconceptId87654321.

yes, that's the idea.

If the concept is non existing in Snomed CT, there are procedures to
ask for the addition.

Due to fine grainedness of SNomed CT to a high level it is probably a
lot that can be handled with this, also avoiding the same concept used
for 2 different archetypes.

I agree with the world wide management of this, but then again the ISO
/ CEN / HL7 / CDSIC DCM approach (IHTSDO invited) would be helpful.

Personally I think it should be IHTSDO - this organisation has been set
up for just this purpose and has the right people. The other standards
don't have the same board membership model and have historically been
far too diffuse with respect to terminology. I still don't quite get
what way DCM is going - I thought it was going with archetypes, based on
the meeting a year ago, but in any case, I think the job of
standardising clinical models must be done by clinical people, and on a
far more agile basis than any of the official standards organisations.

- thomas

18

Hi William

Thomas’ point here is very important – the data compatibility and the clinical concept continuity are not mutually dependent. If it is a new clinical concept then we need to have a new name for it (and therefore a new id).

So the first important point is that the ontological ID must remain true to the clinical concept that is being modelled even if the data associated with that might change or evolve and at times even become incompatible with old data (remember this is a formal mathematical consideration – not a loose worded thing). So even making something that was optional mandatory (something we would hope to see with time) will make prior data incompatible and require a new version of an archetype.

The second issue I have is using the terminology space as the anchor of meaning beyond value set content. Blood pressure is an ideal thing to consider for this purpose. We all know if you ask 99% of clinicians on the planet what a blood pressure observation is they will tell you that it is a measure of the person’s systemic arterial pressure (they might say it another way).

The blood pressure archetype has all the data points, lots of descriptions and other metadata. It is highly recognisable to clinicians.

The term blood pressure in SNOMED is defined by relationships with other terms. It may even be primitive (ie have no defining characteristics). If you look at the terms that are children of blood pressure (ie they are a blood pressure) you will find many things that most clinicians will argue are not blood pressures.



Abnormal blood pressure (finding)

|

If you look beneath these you will find things that are even less related to blood pressure from a clinicians view point. You then have the idea of invasive and non-invasive all mixed in. Pressures are not invasive – the methods of measuring them are.

The problem for terminologists is that they have had to differentiate terms from other terms in a theoretical space and have made decisions in a context free environment (pure). As content for health record items these definitional characteristics are useful – but they are not knowledge in the traditional sense.

Take for example the idea of Pneumonia and the idea of Streptococcal pneumonia. To differentiate these terms, it has been decided to create an intermediate term Baterial pneumonia. This term is differentiated by the causal agent bacteria. Now streptococcal pneumonia can be seen as a type of bacterial pneumonia that has cause Steptococcus. This is immensely useful when you want to query for bacterial pneumonias. But it does not tell you the causes of pneumonia. Some Streptococci do not cause pneumonia (or have not done so yet) and many that do cause pneumonia have no such relationship.

The net result of these definitional relationships and overloaded use of them in theoretical statements about the uses of terminology is that we have to be absolutely clear what we are talking about. The result is that an id of an archetype is not the same as the words used to describe things in medicine. We should allow it to be what it is – link it to terminology but not confuse the recordings of something with its names. As Satre said (perhaps while intoxicated) “Belief is confusing things with their names”.

An archetype – with an id x – records information about some things which may exist more or less in one or more terminologies. If we are to have archetype ids in SNOMED then they must have a unique code – for that archetype. But using a meaningless id for an archetype has major consequences that must be considered,

One such consideration is the utility of specialisation. Computing has come a long way by giving classes names and understanding the relationship between a class and a specialisation. The number of archetypes shared in the international community will be the determinant of whether we should use extended ids for specialisations. If we do not then we need to keep registers of all archetypes ever used anywhere – something that makes me sweat a little.

Not many people yet understand the pragmatic approach to health information representation that is required for as yet humble computers to really offer us assistance. We need to ensure that it can work in practice.

Cheers, Sam

19

Hi All,

While I read every email on this list I do not usually get involved in
the conversations.

However, this reply from Sam Heard so very concisely, yet completely
captures all of the components of the difficulty in using computers to
record health care information.

While the specifics of archetype Ids may not be appropriate for all
venues, IMHO, it should be turned into an article for publication or at
the very least a guest blog post somewhere in the health informatics
space. I know that Sam's time is limited (like many of us) but I
believe that this would be WELL worth the effort.

--Tim