Re: ADL 1.5 - relaxing a conformance rule - feedback sought

[Ian McNicoll <Ian.McNicoll@oceaninformatics.com>]

I think I am mostly with Sebastian here. 

We know that one of the lessons learnt from the early Template .oet definition is that it can be difficult to separate re-naming of nodes for semantic reasons vs. redifintions simple local synonyms 'displayname' in CDA speak.

I agree, too, that maintaining a specialised node at the end of the chain, allows for further specialisation, without a major version change.

A relaxation that might be worth considering is for 'occurrences' . I am not sure whether we would lose much if these did not need specialisation if redefined? They are likely to be the most common sort of redefinition, in Templates, constrained down to 0..0. In comparison name and datatype redefinitions will be comparatively rare.

So, I would prefer to keep the original rule for name and datatype redefinitions but relax it for occurences.

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 openEHR Archetype Editorial Group

Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland

On 21 May 2010 10:08, Sebastian Garde <sebastian.garde@oceaninformatics.com> wrote:

Hi Thomas,

A few concerns that come to my mind - I am not so sure that removing/changing this rule is a good thing:

• It puts an additional burden on tools to support both ways of creating a specialised node wither with or without specialised at code.
  
• It puts an additional burden on users that need to decide whether a specialised node should be created because the semantics have changed - I don't think this decision is always that clear cut.
• What if the non-semantically specialised node is LATER redefined into multiple children? Then a new version of the archetype is needed instead of just a revison?
• With the stricter rule it a lot easier to recognize what has changed from parent to child archetype (this may not apply to 1.5 source ADL, but to the flat files anyway)
• In general, I believe that these validity rules should be simple and straightforward, rather than complex "if this and that and then this, you need a specialised code"-statements.
  

Sebastian

Thomas Beale wrote:

I am in the middle of ADL/AOM 1.5 testing. There is a validity rule I defined in the current draft specficatich reads as fllows:

VSONIR: specialised archetype object node redefinition: if it exists, the node identifier of an object node in a specialised archetype must be redefined into its specialised form if either reference model type or occurrences of the immediate object constraint is redefined.

Translation: change of occurrences or change of RM type (e.g. redefine into descendant type) requires a specialised at-code, e.g. at0002 --> at0002.1 or similar.

In processing real archetypes and creating new templates, I am inclined to remove this rule, and say that the at-code only has to be specialised if the archetype author wishes to do so for semantic reasons OR if the parent node is redefined into multiple children (e.g. a node at0013 meaning 'panel item' gets specialised into at0013.1 (serum sodium), at0013.2, (serum potassium), at0013.3, etc).

I will experiment with removing this rule for the moment, and see if anything bad happens, but as far as I can see, nothing will. If we throw it away, it means that at-code specialisation really is only for semantic reasons, which would be nice and clean.

I am interested in any opinions on this.

By way of news: I am very close to a working implementation of AOM/ADL 1.5, and will release a new version of the ADL Workbench soon/

- thomas beale

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical