RM Versions

[Tim_Cook2 (Tim Cook)]

This is really an implementer's question but I'd like opinions from
everyone on it.

ADL files carry the adl version as well as the reference model name that
the archetype was built against.

With the ARB starting on release 1.1 and it looks like there may be
changes that impact software. I wonder if we should raise a CR for 1.1
that adds the RM version number to the ADL as well?

While I know that the ARB will do everything possible to not break
backwards compatibillity. It could be useful for the software to be
able to tell which RM version an archetype was built against.

Cheers,
Tim

(attachments)

[thomas.beale]

Tim Cook wrote:

This is really an implementer's question but I'd like opinions from
everyone on it.

ADL files carry the adl version as well as the reference model name that
the archetype was built against.

With the ARB starting on release 1.1 and it looks like there may be
changes that impact software. I wonder if we should raise a CR for 1.1
that adds the RM version number to the ADL as well?

While I know that the ARB will do everything possible to not break
backwards compatibillity. It could be useful for the software to be
able to tell which RM version an archetype was built against.

Cheers,
Tim

*We thought about this a number of times over the last few years. The
problem is that many archetypes are completely compatible with multiple
versions of the reference model, because changes occur in other parts of
the reference model. So marking an archetype with "RM version 1.0"
doesn't tell you the most likely question you will ask, which is "is
this archetype compatible with R 1.0.2, that I am using in my system?"
The answer might be no or yes - it depends on the archetype, and what
things it references in the RM. The only solution I can see is to put
such compatibility information in the CKM and other similar tools, and
make the compatibility list available from service interfaces that
provide access to archetypes. The same goes for shared templates.

So I think that a RM version number indicator on an archetype is in
general not useful, and may even be misleading.

hope this helps

- thomas beale

[thomas.beale]

I meant to add: however, we should still raise a PR in openEHR Jira to
describe the problem of knowing the compatibility of archetypes with
respect to a given reference model. Tim - do you want to do this?

- thomas

Thomas Beale wrote:

[system]

*We thought about this a number of times over the last few years. The
problem is that many archetypes are completely compatible with multiple
versions of the reference model, because changes occur in other parts of
the reference model. So marking an archetype with "RM version 1.0"
doesn't tell you the most likely question you will ask, which is "is
this archetype compatible with R 1.0.2, that I am using in my system?"
The answer might be no or yes - it depends on the archetype, and what
things it references in the RM. The only solution I can see is to put
such compatibility information in the CKM and other similar tools, and
make the compatibility list available from service interfaces that
provide access to archetypes. The same goes for shared templates.

So I think that a RM version number indicator on an archetype is in
general not useful, and may even be misleading.

I agree, but on the other hand, an archetype is modelled according to a specific RM-version. And as the good work progresses, we probably will face changes in the RM.
Also, one could consider to have the RM-version depending on compatibility. In other words, one could keep the minor-comaptible.

So 1.0.1 would be compatible with 1.0.2
But it would not necessary be compatible with 1.1.1

I think, this gives a professional impression to version the RM on base of compatibility.

Bert

[Tim_Cook2 (Tim Cook)]

Yes. I'll do this in the coming days. I am thinking that it would be
a List attribute like:

rm_versions=['1.0.1','1.0.2']

That way the software can simply say is; my_rm_version in rm_versions.

The question is who validates the archetypes against each rm_version;
the original author?

--Tim

[thomas.beale]

Tim Cook wrote:

  

I meant to add: however, we should still raise a PR in openEHR Jira to
describe the problem of knowing the compatibility of archetypes with
respect to a given reference model. Tim - do you want to do this?
    
Yes. I'll do this in the coming days. I am thinking that it would be
a List attribute like:

rm_versions=['1.0.1','1.0.2']
  
That is what I would expect, or it may be from-version to-version

That way the software can simply say is; my_rm_version in rm_versions.

The question is who validates the archetypes against each rm_version;
the original author?
  
well it has to be tool driven, and the thing is that the answer will
clearly change over time, e.g. when Release 1.1 is published, some
archetypes, but not all, will have their compatibility updated from

['1.0','1.0.2']

to

['1.0','1.1']

I suppose it is conceivable that there could be incompatibilities in
intervening minor versions that disappear later on, if so, the list
representation would be needed.

I would say it needs to be constantly evaluated in an archetype service,
probably based on meta-data supplied from CKM or similar places.

- thomas

[thomas.beale]

Bert Verhees wrote:

*We thought about this a number of times over the last few years. The
problem is that many archetypes are completely compatible with multiple
versions of the reference model, because changes occur in other parts of
the reference model. So marking an archetype with "RM version 1.0"
doesn't tell you the most likely question you will ask, which is "is
this archetype compatible with R 1.0.2, that I am using in my system?"
The answer might be no or yes - it depends on the archetype, and what
things it references in the RM. The only solution I can see is to put
such compatibility information in the CKM and other similar tools, and
make the compatibility list available from service interfaces that
provide access to archetypes. The same goes for shared templates.

So I think that a RM version number indicator on an archetype is in
general not useful, and may even be misleading.
  

I agree, but on the other hand, an archetype is modelled according to
a specific RM-version.

actually, I would only agree at the level of major version - there are
archetypes around that started life when Release 1.0.1 was the latest,
and may not be finished until Release 1.0.2 is already issued. It most
likely makes no difference to the authors.

- thomas

[ian.mcnicoll]

Hi Thomas,

Whilst I agree that in most circumstances it would be of no interest
to authors, there may be circumstances where it is important to know
the exact RM version and revision, perhaps for safety-critical
archetypes, which the 'consumers' wish to check meticulously. I see no
harm in documenting the full RM version when an archetype is
published, even if in the vast majority of cases it is of no
importance.

Ian

[thomas.beale]

Ian McNicoll wrote:

Hi Thomas,

Whilst I agree that in most circumstances it would be of no interest
to authors, there may be circumstances where it is important to know
the exact RM version and revision, perhaps for safety-critical
archetypes, which the 'consumers' wish to check meticulously. I see no
harm in documenting the full RM version when an archetype is
published, even if in the vast majority of cases it is of no
importance.

*but which RM version? There will usually be more than one that the
archetype is compatible with, and the list keeps changing, so it doesn't
make sense to put that information in the archetype itself.

- thomas

[ian.mcnicoll]

Hi Thomas, I was suggesting the RM version be recorded when the archetype is officially published or revisioned and re-published. This is the only time when an archetype author can be expected to take some account of the underlying RM when designing or revising the model. It is not a perfect solution but it gives some estimation of the RM version that the author was working against when designing the archetype. The archetype tools could automatically record the RM version whenever an archetype lifecyle transitions to published or has its version/revision updated.

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
BCS Primary Health Care Specialist Group www.phcsg.org

2009/2/3 Thomas Beale <thomas.beale@oceaninformatics.com>

[system]

Thomas Beale schreef:

Bert Verhees wrote:

*We thought about this a number of times over the last few years. The
problem is that many archetypes are completely compatible with multiple
versions of the reference model, because changes occur in other parts of
the reference model. So marking an archetype with "RM version 1.0"
doesn't tell you the most likely question you will ask, which is "is
this archetype compatible with R 1.0.2, that I am using in my system?"
The answer might be no or yes - it depends on the archetype, and what
things it references in the RM. The only solution I can see is to put
such compatibility information in the CKM and other similar tools, and
make the compatibility list available from service interfaces that
provide access to archetypes. The same goes for shared templates.

So I think that a RM version number indicator on an archetype is in
general not useful, and may even be misleading.

I agree, but on the other hand, an archetype is modelled according to
a specific RM-version.

actually, I would only agree at the level of major version - there are
archetypes around that started life when Release 1.0.1 was the latest,
and may not be finished until Release 1.0.2 is already issued. It most
likely makes no difference to the authors.

Exactly what I mean, we must agree, which part of the version-number indicates a possible incompatibility concernig archetypes/RM-version.
Bert

[Tim_Cook2 (Tim Cook)]

Don't try to get too complicated. Just have a list that states that
this archetype has been validated against these RM versions. If my RM
version is in the list I okay. There aren't going to be too many RM
versions anyway.

--Tim

[thomas.beale]

Ian McNicoll wrote:

[Tim_Cook2 (Tim Cook)]

Exactly. Each time the archetype is touched the tools can look to see
if the current RM is in the list. The tool should probably know how to
invalidate previously valid versions as well.

--Tim

[system]

So you probably want two properties recorded?

One being
'was-created/revised-against-RM-version' with a single value

and the other being
'works-with-or-validated-against-RM-versions' of the list type

And recording these properties within the archetype seems to save time
in looking up this info; looking it up via the CKM will take much more time.

Roger

[Heath_Frankel3 (Heath Frankel)]

I think that we only need to record the RM version that was used to
create/save the Archetype. This is really just for information purposes
regarding the tool used to develop the archetype and not really used for
determining at runtime if this archetype is compatible with my system. Take
the Ocean Archetype Editor, currently it targets a r1.0.1 RM but will soon
targeting r1.0.2 (using ADL 1.4.1). There is minimal differences but useful
to know.

A full list of compatible RM versions can be maintained separately in CKM as
Thomas suggests. The question is, do we need a dedicated field in ADL to do
this if it for information purposes only, why not use the
description.other_details.

In addition I think we need a name and version of the tool used to generate
the archetype. Again the Ocean AE produces different output depending on
the Version of the tool, an old Archetype can be read by a new version of
the tool but the reverse is not always true.

Regards

Heath

From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Roger Erens
Sent: Wednesday, 4 February 2009 4:44 AM
To: For openEHR technical discussions
Subject: Re: RM Versions

> Ian McNicoll wrote:
>> Hi Thomas, I was suggesting the RM version be recorded when the
>> archetype is officially published or revisioned and re-published. This
>> is the only time when an archetype author can be expected to take some
>> account of the underlying RM when designing or revising the model. It
>> is not a perfect solution but it gives some estimation of the RM
>> version that the author was working against when designing the
>> archetype. The archetype tools could automatically record the RM
>> version whenever an archetype lifecyle transitions to published or has
>> its version/revision updated.
> *
> but then the previous releases that the archetype may or may not work
> with are lost, if it is being update to indicate the latest one it works
> with. And an archetype might not be touched for a long time (due to
> being perfect and so would never have this information updated. So I
> can't see how it is in any way trustworthy when written in the

archetype.

>
> - thomas

So you probably want two properties recorded?

One being
'was-created/revised-against-RM-version' with a single value

and the other being
'works-with-or-validated-against-RM-versions' of the list type

And recording these properties within the archetype seems to save time
in looking up this info; looking it up via the CKM will take much more

time.

[system]

Exactly what I mean, we must agree, which part of the version-number
indicates a possible incompatibility concernig archetypes/RM-version.
Bert

Don't try to get too complicated.  Just have a list that states that
this archetype has been validated against these RM versions. If my RM
version is in the list I okay.  There aren't going to be too many RM
versions anyway.

Excuse if I come back to something which is already discussed, I have a busy day to day, no time to read all, I do that later.
But I want to add some arguments to the discussion before the momentum has gone.

[system]

Hi All

I would suggest that we have a very strong backwardly compatible notion on
each reference model and do not do anything that would invalidate current
archetypes in RM 1.x

This would mean that we only had to record the highest level version that an
archetype was compatible with in the archetype RM 1.0 and leave it at that.

I am sure people working in the environment would like such an approach.

It means we have two rules:
All archetypes of the same version are compatible semantically
All archetypes work with the reference model version (1,2 etc) and go on
being compatible.

Cheers, Sam

[thomas.beale]

Sam Heard wrote:

Hi All

I would suggest that we have a very strong backwardly compatible notion on
each reference model and do not do anything that would invalidate current
archetypes in RM 1.x

This would mean that we only had to record the highest level version that an
archetype was compatible with in the archetype RM 1.0 and leave it at that.

I am sure people working in the environment would like such an approach.

It means we have two rules:
All archetypes of the same version are compatible semantically
All archetypes work with the reference model version (1,2 etc) and go on
being compatible.

Cheers, Sam
  

*I still have not see a solution to the basic problem that if we record
a compatibility release(s) _inside_ the archetype, then whenever a new
release of openEHR comes out, thousands of archetypes would be updated
to reflect the new release number. If this is not done, then those
archetypes will over time look as if they stopped being compatible with
later releases of openEHR. Making the modification means that every
archetype in every local repository would have to be modified this way,
as well as in central places like CKM. And it means that we are now
re-issuing archetypes when no update is needed to the content. I can't
see how this can work. I don't mind including the release number of
openEHR when the archetype was first released, but I don't see how it
can be useful information.

- thomas beale

[Tim_Cook2 (Tim Cook)]

Okay,

Maybe the subject line is a little melodramatic.

But we do have a situation and a good bit of this email (along with your
consultations) will be placed as a Problem Report (PR) on the
openEHR.org website.

My point of view is that we have a multi-level modeling environment and
therefore we have a multi-level problem solving environment. It must
ALL work together. Archetype designers and application developers.

I'll be a bit shallow in this email and will not look up specific
instances. But there are place(s) within the RM where the RM version is
recorded.

The archetype tools should record this information in the archetype
saying that this version of THIS archetype was built against a specific
openEHR RM version.

There are VERY specific guidelines as to what and what does not
constitute various archetype version changes. Maybe/maybe not these
should be reviewed in reference to RM versions?

Since we all have very good crystal balls.....
We can see a future where at RM version 2.5 there are significant
differences to RM version 1.0.2.

However; we have Mary in rural Montana USA, a patient a Dr. Jones's
office (believing strongly in future proof) and she moves to a new city;
let's say Atlanta, GA. Where Dr. Brown (ALSO! believing strongly in
future proof) has been on top of things and is now at RM version 2.5.

Well, Dr. Brown gets Mary's record from Dr. Jones and discovers that
some of the archetypes that were built 15 years ago in 1.0.2 RM just
simply do not display or worse yet cause unknown type errors and his
application(s) crashes.

Future Proof? Hardly!!!!!

Doesn't seem much different from the migrating SQL data base schema
problem does it?

So I believe that we as a community should take multiple courses. I
want to emphasize that we should take THEM ALL!

First: an archetype tool developer MUST record the RM that an archetype
was built against.

Let's say RM=['1.0.1']

(okay so I apologize for my Python syntax, but it's easy to read).

Second: An archetype is edited (whether it's version changes or not)
against a tool using RM 1.0.2.

The RM = is now RM=['1.0.1,'1.0.2]

At some point this archetype has now been validated against 2 RM
versions. It should work with both RM versions and the consumer
(application developer knows it).

Third: The application developer has a choice to make. Either read the
list and support backwards compatibility based on the last known RM
version or simply be NON-FUTURE-PROOF and reject the data.

At the very least, the archetype contains the information needed to let
the application know what it expects in order to be rendered and
processed.

So in essence, I TOTALLY disagree with Tom's statement:
   

> I don't mind including the release number of
> openEHR when the archetype was first released, but I don't see how it
> can be useful information.
>
>

Sorry Tom; if it's put in a list, I can see EVERY reason why it is useful information.

The openEHR documentation is VERY VERY VERY good. There is no reason that an implementer could possibly accommodate multiple RM versions.

Regards,
Tim