Question about Ocean's Archetype Editor

[Mattias Forss]

Hello,

I'm trying to figure out which reference model Ocean's achetype editor follows. 
I have an example regarding the data type Quantity, see below. There seems to 
be great differences depending on what reference model the archetypes follow.

Background:
I'm trying to figure out how to get the property of a quantity but this doesn't 
seem to be supported by the java kernel I'm using, so I'm asking if anyone has 
a good idea on how to support this in other ways.

The current problem is that the java adl parser returns a CQuantity object 
whenever it recognizes the string "quantity", but when it's something else, 
e.g. C_QUANTITY, it returns a CComplexObject.

Idea:
I could solve this by looking up the RM type names and the attribute names to 
figure out if the ComplexObject represents something that can be interpreted as 
a Quantity data type. In this way I can support the various known structures of 
the data type that currently exist. Any suggestions?

By the way, shouldn't the property attribute represent a CODED_TEXT object that 
can be linked to a local or external terminology? This seems to be the case 
according the specifications and it goes all the way back to version 0.9 that I 
think the current version of the java kernel supports (partly at least). I 
would really like to know what RM Ocean's archetypes follows.


Ocean Archetype Editor archetype:

C_QUANTITY < 
 property = <"Acceleration"> 
 list = < 
  ["1"] = < 
   units = <"cm/s2"> 
   magnitude = <|< 0.0|> 
   > 
  ["2"] = < 
   units = <"ft/s2"> 
   magnitude = <|>= 0.0|> 
   > 
  > 
 >
>

Ref impl java kernel archetype:

QUANTITY matches {
 magnitude matches {|<0.0|}
 units matches {"cm/s2"}
}

Acode ADLParser test achetype:

REAL_QUANTITY matches {
 property matches {"Acceleration"}
 units cardinality matches {1} matches {
  UNIT matches {
   unit_string matches {"cm/s2"}
   magnitude matches {|< 0.0|}
  }
  UNIT matches {
   unit_string matches {"ft/s2"}
   magnitude matches {|>= 0.0|}
  }
 }
}


Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051114/6a5af7f2/attachment.html>

Question about Ocean's Archetype Editor

[Mattias Forss]

- Original Message - 
From: "Thomas Beale" 
To: 
Sent: Monday, November 14, 2005 6:15 PM
Subject: Re: Question about Ocean's Archetype Editor


> Mattias Forss wrote:
>
>> Hello,
>>  I'm trying to figure out which reference model Ocean's achetype editor 
>> follows. I have an example regarding the data type Quantity, see below. 
>> There seems to be great differences depending on what reference model the 
>> archetypes follow.
>
> I pretty sure that the reference model is the same in all cases. There is 
> only one definition of DV_QUANTITY in the openEHR reference model, and as 
> far as I know, only one assumed in archetypes.

Thank you for your answer Thomas,

I bet the reference model is the same, but do the Ocean archetype editor 
fully conform to the reference model? Take a look at the ITEM_TREE class 
definition for example. You will see that the correct attribute for the 
physical representation of the tree will be either "representation" for 
version 0.9 of the specifications or "root" for version 0.95+ of the 
specifications. However, the Ocean archetype editor does not use neither of 
these attributes, instead it uses "items" but maybe this is correct if the 
editor conforms to an earlier version of the specifications than 0.9. Anyone 
who knows about this?

> However, it may look different. There are two ways of representing 
> constraints on Quantity in an archetype. One is to use the 'standard' 
> method of creating C_COMPLEX_OBJECTs which mimic the sructure of the 
> QUANTITY class; the other is to use an instance of C_QUANTITY, which is a 
> custom replacement type which provides a better model of the possible 
> constraint on QUANTITY (while still assuming the same underlying 
> definition of QUANTITY).

This is interesting, but I'm getting slightly confused about the naming 
here. Could you explain more and tell me the difference between QUANTITY, 
C_QUANTITY and C_DV_QUANTITY. It is probably a lot easier to grasp for 
someone like you.

I believe the C_QUANTITY corresponds to the CQuantity (inherits from 
CDomainType) class in the java reference kernel, and the parser gives me 
this object if the archetype looks like Q1. Nevertheless, I'm starting to 
think that this isn't right and that the parser instead should give me the 
CQuantity object if the archetype looks like Q2. What do you think? By the 
way, should there exist a class called Quantity in the java kernel or maybe 
it is sufficient with the CComplexObject (that mimics the structure of the 
QUANTITY class)?

Q1:

QUANTITY matches {
 magnitude matches {|<0.0|}
  units matches {"cm/s2"}
}

Q2:

C_QUANTITY <
  property = <"Acceleration">
  list = <
   ["1"] = <
units = <"cm/s2">
magnitude = <|< 0.0|>
>
   ["2"] = <
units = <"ft/s2">
magnitude = <|>= 0.0|>
>
   >
  >
>


>> Background:
>> I'm trying to figure out how to get the property of a quantity but this 
>> doesn't seem to be supported by the java kernel I'm using, so I'm asking 
>> if anyone has a good idea on how to support this in other ways.
>
> the property attribute is defined only in the type C_QUANTITY. It provides 
> a convenient way to capture the constraint that you want only length or 
> pressure, without saying which unit. If only the property is set in the 
> C_QUANTITY in the archetype, then when the kernel checks to see if an 
> instance of DV_QUANTITY conforms to the C_QUANTITY in the archetype, it is 
> up to the C_QUANTITY to carry out this check in sensible way, i.e. by 
> determining what property the actual units measure.

I'm not getting this... as an example, do you mean that a C_QUANTITY with 
its property set to "length" is supposed to check if "meters" or "inches" in 
the DV_QUANTITY conforms to this C_QUANTITY? How is it supposed to do that, 
it seems to me that the C_QUANTITY then must know what allowable units there 
can be for the length property. Where are those units supposed to be stored 
if only the property is set in the C_QUANTITY?


>> By the way, shouldn't the property attribute represent a CODED_TEXT 
>> object that can be linked to a local or external terminology?
>
> this is true; we watered it down to make people in CEN and HL7 happy, but 
> I no longer believe such compromises are sensible. We will probably change 
> this to a CODED_TEXT.

Ok, I suppose you're referring to the Ocean archetype editor now?



Regards,

Mattias


>
> hope this helps
>
> - thomas beale
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org 


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Missing references in documentation

[Mattias Forss]

Hello,

I cannot find the references specified in section 2.1 of this document, can 
anyone help me find these please?

Purpose of Archetypes and Templates Archetype Definitions and Principles
Rev 0.6 
http://svn.openehr.org/specification/BRANCHES/Release-1.0-candidate/publishing/architecture/am/archetype_principles.pdf

Content:
"2 Purpose of Archetypes and Templates

   2.1 Purpose of Archetypes
   Archetypes are created for a number of purposes (described in detail in [1] 
and [3]), summarised here"


Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051129/116d3407/attachment.html>

Questions about archetype definition

[Mattias Forss]

Hello,

I have some questions about the archetype definition. Currently, I am using the 
java parser to get an archetype object and from that object I get the archetype 
definition, which is a CComplexObject. I then pass this object to a recursive 
function of mine to get hold of some node id's, reference model type names, 
reference model attribute names and so on. In the function I first get the 
attributes of the complex object, then I get the children of each attribute and 
finally I also get some of the children's actual values in the case they aren't 
complex objects that have to be passed to the function again.

Sadly, I haven't found another way to get the children's actual values, than 
doing a lot of type casting, i.e. to get the value of an object of the type 
DvBoolean I first have to check if the child is a CPrimitiveObject to get the 
CPrimitive and then I have to check if the CPrimitive is a CBoolean to get the 
DvBoolean and finally I can get the actual value of the boolean. I think this 
is rather tedious, and I would be glad if anyone knows an easier way to do this.

In the recursive function I've just described I also try to build a tree 
structure of the java type DefaultMutableTreeNode in order to to display the 
archetype definition in a swing object called JTree. I have almost got it 
right, but I have problems with the levels of the nodes because I cannot simply 
do recursion over the CComplexObject that represents the definition since I 
have to get its attributes and the attributes' children (e.g. to see if the 
children are another CComplexObject), and thus this gets complicated and the 
assembled final tree is somewhat messed up. I would be glad if anybody had any 
ideas or advice about this problem and I hope my questions aren't too stupid.

Regards,

Mattias Forss (MSc student)

Medical Informatics group at the Department of Biomedical Engineering
Link?pings universitet, Sweden
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050928/48a98e02/attachment.html>

Question about Composition archetypes

[Mattias Forss]

Yes they are still 0.97 archetypes, but shouldn't they contain EVENT_CONTEXT 
according to the old 0.9 specifications? Anyway, I'm glad that the release 1.0 
archetypes are being published soon. I've had a look at some of the new 
COMPOSITION archetypes and they seem to follow the specifications better.

Thanks,

Mattias
  - Original Message - 
  From: Sam Heard 
  To: openehr-technical at openehr.org 
  Sent: Wednesday, April 12, 2006 2:27 PM
  Subject: Re: Question about Composition archetypes


  Mattias
  The Ocean archetypes are still 0.97 - we have updated all of them and will 
have the release 1.0 tools and archetypes available very shortly. 
  The editor, alpha, on the Ocean site will create them in the release 1.0 form.
  Cheers, Sam

  Mattias Forss wrote: 
Hello, 

I've just compared some Composition archetypes from Ocean Informatics with 
the specifications at openEHR.org and I have some questions. The specifications 
from 0.9 to 1.0 all agree about one thing for COMPOSITION classes and that is 
that the attribute "context" in the COMPOSITION class should point to a class 
called EVENT_CONTEXT. 

However, this is not the case for the archetypes I've seen so far. Instead, 
the "context" attribute in the archetypes matches subclasses of ITEM_STRUCTURE 
e.g. ITEM_TREE. These classes should instead be referred by an optional 
attribute called "other_context" inside the EVENT_CONTEXT class. Can anyone 
please explain to me why this is the case? 

Regards, 

Mattias 




  -- 

  Dr. Sam Heard
  MBBS, FRACGP, MRCGP, DRCOG, FACHI
  CEO and Clinical Director
  Ocean Informatics Pty. Ltd.
  Adjunct Professor, Health Informatics, Central Queensland University
  Senior Visiting Research Fellow, CHIME, University College London
  Chair, Standards Australia, EHR Working Group (IT14-9-2)
  Ph: +61 (0)4 1783 8808
  Fx: +61 (0)8 8948 0215



-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060412/86e6edde/attachment.html>

New alpha of release 1.0 archetype editor

[Mattias Forss]

Hi Sam,

I've been looking at the openEHR archetype profile specification and I can
see that for the C_DV_QUANTITY class the property attribute should be a data
type called DV_CODED_TEXT. However, I haven't seen the [terminology::code]
representation of a coded text in the archetypes that are packed with the
latest version of the archetype edtior on the Ocean site. Also, I haven't
found a version called 1.0 that you say, the latest I could find is 0.99.5b.


Instead of the [terminology::code] representation I have seen a string
representation of the property e.g. "pressure". I think it would be good if
the properties are coded according to the openEHR support terminology (
http://svn.openehr.org/specification/TAGS/Release-1.0/publishing/architecture/computable/terminology/terminology.html)
so that they become more language independent.

Hope you can give me some clarity in this issue.

Cheers,

Mattias

 Hi Everyone

I have posted a new exe of the release 1.0 archetype editor on the Ocean
site with sample archetypes.a little more to do but it is getting very
close. I would appreciate testing and comments back via the reporting menu
item on the editor.

Cheers, Sam
--
   Dr. Sam Heard
MBBS, FRACGP, MRCGP, DRCOG, FACHI

CEO and Clinical Director
Ocean Informatics Pty. Ltd.
 Adjunct Professor, Health Informatics,
Central Queensland University
Senior Visiting Research Fellow, CHIME, University College London
Chair, Standards Australia, EHR Working Group (IT14-9-2)
*Ph: +61 (0)4 1783 8808*
*Fx: +61 (0)8 8948 0215*
-- next part --
An HTML attachment was scrubbed...
URL: 

Activity class

[Mattias Forss]

Hello,

I read that the ACTIVITY class of an INSTRUCTION is LOCATABLE meaning that
it can have a runtime name, but why isn't this supported in Ocean's
archetype editor? Have I missed something. I assume that since an archetype
defines a model of the list of activities we cannot have several activities
with different names, i.e. ACTIVITY[at0001], ACTIVITY[at0002] for the
container attribute, but we should at least have the possibility of
modelling runtime names for the activity, since several instances can exist
in the EHR data. Any comments on this?

I would also be pleased if someone also could answer my previous questions
about composition attributes. Should it be possible to have several
categories for a composition? Should the category attribute always be
present in a composition archetype?

Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060807/8ea56d5e/attachment.html>

OBSERVATION.state attribute

[Mattias Forss]

Hi all,

I have found out that the observation archetypes at the openEHR archetype
repository are not following the specifications for the attribute
OBSERVATION.state.

This attribute is supposed to be a HISTORY with existence
set to optional (i.e. 0..1), but for the archetypes at the repository the
state attreibute is of the type ITEM_STRUCTURE which make it equal to the
CARE_ENTRY.protocol attribute. I believe all the observation archetypes that
have the state attribute will have to be fixed...

Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060808/92bfc4fd/attachment.html>

Archchetype editor on Linux --help

[Mattias Forss]

There is already a Java-based archetype editor available here:

http://svn.openehr.org/knowledge/archetypes/dev/index.html

Regards,

Mattias Forss

2006/8/27, minreddy minreddy :
>
> Hello
>
> I'm thinking to port Archchetype editor to Linux.
> (As myself  don't run windows at all)
>
> Are there any other dependencies other than ADL parser? (adl_java_lib.dll)
>
> Any help will be greatly appreciated!
>
>
> rgds
> minreddy
>
> --
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
> starting at 1?/min.
> <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060828/a5a888f0/attachment.html>

Archchetype editor on Linux --help

[Mattias Forss]

number of reasons we did this, the most obvious was that we wanted to enable
a structured overview of an archetype and this is why the different views in
the editor was created. This was an obvious way to make it easier for a user
to know what part of an archetype he/she is editing. In retrospect, the
current GUI design is not optimal and it could have been designed in several
different ways but we didn't want to compromise the usability of the
program. For example if the entire archetype could be edited in a single
view it could be to many things (buttons, floating toolbars, popup menus,
commands, etc.) to keep in mind for the user.

We have many plans for the editor and there had been discussions of adding
another view in which the user can edit large parts of archetypes in a
completely different manner compared to the current editing process.
Probably a lot of things will happen in the future when other programmers
can join an open source Java archetype editor project.

Regards,

Mattias


These are only some suggestions from a rainy day in region of the South
> Central France
>
> regards
> Bert Verhees
>
> >
> > Regards,
> >
> > Mattias Forss
> >
> > 2006/8/27, minreddy minreddy :
> >>
> >> Hello
> >>
> >> I'm thinking to port Archchetype editor to Linux.
> >> (As myself  don't run windows at all)
> >>
> >> Are there any other dependencies other than ADL parser?
> >> (adl_java_lib.dll)
> >>
> >> Any help will be greatly appreciated!
> >>
> >>
> >> rgds
> >> minreddy
> >>
> >> --
> >> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great
> >> rates
> >> starting at 1?/min.
> >> <
> http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com
> >
> >>
> >>
> >
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060828/bd6ed46b/attachment.html>

Archchetype editor on Linux --help

[Mattias Forss]

 the
> GUI, but eventually decided to design it like Ocean's GUI. There are a
> number of reasons we did this, the most obvious was that we wanted to
> enable
> a structured overview of an archetype and this is why the different
> views
> in
> the editor was created. This was an obvious way to make it easier for
> a
> user
> to know what part of an archetype he/she is editing. In retrospect,
> the
> current GUI design is not optimal and it could have been designed in
> several
> different ways but we didn't want to compromise the usability of the
> program. For example if the entire archetype could be edited in a
> single
> view it could be to many things (buttons, floating toolbars, popup
> menus,
> commands, etc.) to keep in mind for the user.

>>Yes I understand, the GUI as it is is very obvious, it is hard to think
>>about a better GUI, but different people have different ideas. Making
>>the
>>tool open source could allow experimenting with GUI's and produce
>>results
>>which are for us, now, unthinkable of.

>>There is a VB-Archetype Editor, but I know there are many more
>>java-programmers then there are VB.NET programmers.

>>Good luck with your product, I hope it will be open sourced soon.

I hope so too...

Regards,

Mattias



>>regards
>>Bert Verhees

>
> We have many plans for the editor and there had been discussions of
> adding
> another view in which the user can edit large parts of archetypes in a
> completely different manner compared to the current editing process.
> Probably a lot of things will happen in the future when other
> programmers
> can join an open source Java archetype editor project.
>
> Regards,
>
> Mattias
>
>
> These are only some suggestions from a rainy day in region of the
> South
>> Central France
>>
>> regards
>> Bert Verhees
>>
>> >
>> > Regards,
>> >
>> > Mattias Forss
>> >
>> > 2006/8/27, minreddy minreddy :
>> >>
>> >> Hello
>> >>
>> >> I'm thinking to port Archchetype editor to Linux.
>> >> (As myself  don't run windows at all)
>> >>
>> >> Are there any other dependencies other than ADL parser?
>> >> (adl_java_lib.dll)
>> >>
>> >> Any help will be greatly appreciated!
>> >>
>> >>
>> >> rgds
>> >> minreddy
>> >>
>> >> --
>> >> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.
>> >> Great
>> >> rates
>> >> starting at 1?/min.
>> >> <
>> http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/*http://messenger.yahoo.com
>> >
>> >>
>> >>
>> >
>>
>>
>>
>

Composition attributes

[Mattias Forss]

Hi all,

I'm currently upgrading the Java Archetype Editor (can be found at
http://www.imt.liu.se/mi/ehr) to support the newest COMPOSITION archetypes
that are available on the openEHR website. For this upgrade I have come upon
a question about some attributes.

The attributes I'm wondering about are the ones that have occurrences 1..1,
meaning they are mandatory. Here I'm interested in the attributes
COMPOSITION.composer and COMPOSITION.category. The composer attribute is of
the type PARTY_PROXY and the category is a DV_CODED_TEXT. Now to my
questions.

Should COMPOSITION archetypes always contain these attributes, e.g. with at
least a line "the_attribute matches {*}" in the ADL or can these mandatory
attributes be discarded completely in the archetypes? Actually this question
goes for ENTRY subclass archetypes as well, because the
ENTRY.subjectattribute is also mandatory.

If mandatory attributes always should be present in archetypes, it would
mean that attributes such as COMPOSITION.territory also would be modeled but
I believe some of the mandatory attributes aren't supposed to be put in
archetypes as of yet. At least I haven't found this attribute in any
archetypes at the openEHR website.

The reason for this question is actually because I saw that the category
attribute is only modeled with one category code at a time in Ocean's
archetype editor. I think that the attribute could be modeled with several
category codes to chose from when creating the EHR content. I'm not sure if
it's good in a user perspective, but I don't see a reason why it shouldn't
be possible. Any comments?

Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060804/b3c8ecd2/attachment.html>

[Norton AntiSpam] Re: DV_QUANTITY_RATIO - remove from specification

[Mattias Forss]

2006/12/8, Thomas Beale :
>
>  Mattias Forss wrote:
>
> Does this mean that the ratio constraint could as of now be removed from
> the archetype editors? Will the DV_RATIO class be removed from the
> specifications as well? If not, should the editors change the current ratio
> constraint to be of a DV_RATIO instead of a DV_QUANTITY_RATIO?
>
> this is the expected approach. I know it is annoying for us to make this
> software change, but we cannot escape the fact that there were some
> categories of clinical data that were not properly addressed by the current
> data types.
>

Not sure what your answer is here, can the ratio constraint be removed from
the editors or not?

I think that the new DV_PROPORTION class could be used instead of
> DV_QUANTITY when there are no units, e.g. only the property 'Qualified
> real' and the empty string as a unit or a missing unit attribute in the item
> list of C_QUANTITY and only a magnitude attribute. The current ADL parser
> doesn't expect empty or null units which is correct according to the
> specification of C_QUANTITY_ITEM in the archetype profile package. Hence,
> there should always be a unit specified for each item in the item list of
> C_QUANTITY in archetypes and it cannot be empty because quantified data with
> no units could be represented with the DV_PROPORTION data type, right?
>
> DV_COUNT will take care of countable things - also with no units.
> Otherwise, anything else with no units I think will end up being a
> DV_PROPORTION - is we think of "proportion" as the idea of "relative
> amount", "how much of a total", then it is quite a wide concept that is
> likely to cover many situations. Sam and I believe your assumption is pretty
> safe at the moment.
>

Understood, the proportion data type makes a lot more sense than the
DV_QUANTITY_RATIO which allowed a lot of different quantifiable data types.
There is no need to make things more complicated than they are and the
simplification with DV_PROPORTION is great.

If you have a look at the blood film archetype (here:
> http://my.openehr.org/wsvn/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.blood_film.v1.adl?op=file&rev=0&sc=0)
> you will see that the elements named 'Packed cell volume (PCV)' and
> 'Plateletcrit' are quantity data types with empty units, but maybe they
> could be changed to proportion data types instead? If not, then the
> specification of C_QUANTITY_ITEM must be changed.
>
> Sam - I imagine this is right - can you check this?
>
> Although we have not yet uploaded cleaner archetypes with all the changes
> everyone wants, we have nearly done all the changes to the tools, and the
> next generation of archetypes on the openEHR website should address
> everything. After that we should be able to proceed faster, since I think we
> will have removed all the anomalies in tools with respect to the
> specification, and also fixed a few anomalies in the specfication.
>

It would be great if the archetypes could be updated soon. Could I get a
listing of the changes so I can update the Java archetype editor
accordingly?

Regards,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061208/32ffad79/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Suggestions re Term binding in Archetype Editor

[Mattias Forss]

Hi Ian,

Archetypes are designed to be loosely coupled with terminology so that they
can be used when there are no terminology resources available.

If we have comments of the bindings, we get another problem because if the
definition of the binding changes (for example a translated term is
redefined in a terminology) the comment will be obsolete.

We currently have to rely on the archetypes' local terminology to get the
approximate rubrics when there are no terminology resources available.

Regards,

Mattias

2006/12/18, Ian McNicoll :
>
> Hi Sam,
>
> I appreciate the "language" difficulty here, given the ontology separation
> in ADL. However, in the UK context, the ability to document bindings to
> Snomed-CT with clear documentation, thereof, will be crucial to promoting
> OpenEHR. The design philosophy for DV_CODED_TEXT is that the raw term is
> never sent without the rubric, and I think somehow this needs to be
> extended
> to the binding terms as it is by no means certain that access to a
> terminology server will be a given in all the environments where ADL is
> being used as a design / documentation language. Would it be possible to
> allow the term bindings to be commented with the term name in the native
> authored language(as the current dADL entries are commented with the node
> name )? The current editor seems to strip out the any comments from the
> term
> bindings. This would at least let the rubrics be captured and displayed in
> any documentation.
>
> Ian
>
>
>
>
> From: Sam Heard [mailto:sam.heard at oceaninformatics.biz]
> Sent: 18 December 2006 00:22
> To: For openEHR technical discussions
> Subject: Re: Suggestions re Term binding in Archetype Editor
>
> Version 1 candidate does this and will be out soon Ian - it does not
> include
> the SNOMED text as this will be different in different languages.
>
> Sam
>
> Ian McNicoll wrote:
>
>
>
>
> Hi,
>
>
>
> I am currently working my way slowly through the Scottish Cardiac dataset,
>
> converting it to archetypes as proof-of-concept, using the OE editor.
>
>
>
> Term binding (to SNOMED) will be a crucial aspect from our perspective,
>
> especially binding local (interface) terms to SNOMED concepts.
>
>
>
> This would be much easier within the editor if the Term bindings screen
>
> displayed the node name as well as the Node ID, as it is easy to forget
>
> which local term you are trying to bind by the time you have rummaged
> around
>
> in Snomed for a bit!!. The "Choose Nodes" dialog might also be a little
>
> easier if the Node parent name and Node name were included. When only the
>
> node name is visible this can cause confusion if similar local terms are
>
> used for different nodes e.g. "Not known".
>
>
>
> Finally in the ADL, I think it would be very helpful to be able to include
>
> the text of the Bound term text as well as its code. This would allow much
>
> easier checking for errors and documenting
>
>
>
> I have done this by enclosing the bound term text in [] for now.
>
>
>
> e.g.
>
> term_binding = <
>
> ["SNOMED-CT"] = <
>
> items = <
>
> ["at"] = <[SNOMED-CT::229819007
> [Tobacco
>
> use and Exposure]]>
>
> ["at0006"] = <[SNOMED-CT::?Non Tobacco
>
> user]>
>
> ["at0009"] = <[SNOMED-CT::]>
>
> ["at0011"] = <[SNOMED-CT::[Ex-smoker]
>
> 8517006]>
>
> ["at0012"] = <[SNOMED-CT::[Current
>
> non-smoker] 160618006]>
>
>
>
> Regards,
>
>
>
> Ian
>
>
>
> ___
>
> openEHR-technical mailing list
>
> openEHR-technical at openehr.org
>
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
>
>
> --
>
> Dr. Sam Heard
> MBBS, FRACGP, MRCGP, DRCOG, FACHI
> CEO and Clinical Director
> Ocean Informatics Pty. Ltd.
> Adjunct Professor, Health Informatics, Central Queensland University
> Senior Visiting Research Fellow, CHIME, University College London
> Chair, Standards Australia, EHR Working Group (IT14-9-2)
> Ph: +61 (0)4 1783 8808
> Fx: +61 (0)8 8948 0215
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Suggestions re Term binding in Archetype Editor

[Mattias Forss]

2006/12/18, Ian McNicoll :
>
>  Hi Mattias,
>
>
>
> I do appreciate these difficulties but if the definition of the binding
> changes the binding itself may be obsolete.
>
If the binding changes so much in the terminology that it may be obsolete in
the archetype it would probably lead to a new term that is created in the
terminology and the old one is kept... but that doesn't matter in this
discussion - just wanted to point it out.

I agree the comment idea is less than satisfactory, it would be better if
> the term binding contained the rubric as well as the term code for exactly
> the same reasons that the rubric must always accompany the term code in
> DV_CODED_TEXT.
>

I don't know why the DV_CODED_TEXT is designed this way. I have thought
about it and the only reason why this is done is probably to get a faster
access to the rubric and maybe also when there are no translations for the
term in a specific language in order to get a 'default' rubric at all times.

Maybe you're right, the definitions could be added as comments, but for
proprietary terminology like SNOMED CT this will mean that these kind of
archetypes can only be distributed to people that have paid the license.

Regards,

Mattias

> Managing Snomed-CT is going to be a very tricky exercise. Using archetypes
> + bindings offers a very powerful way of managing Snomed where semantic
> precision is very important e.g. decision support. Having tools that will
> let us design and document these bindings will be a powerful way of
> persuading those who have yet to understand the value of the archetype
> approach. Having the term rubrics available is an important part of
> cross-checking that the correct binding has been applied, both for the
> original author (where terminology services might well be available) and
> when the archetype and bindings are reviewed by a wider clinical audience
> (when such services may not be available).
>
> Regards,
>
>
>
> Ian
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: Re: Suggestions re Term binding in Archetype Editor

[Mattias Forss]

2006/12/19, Williamtfgoossen at cs.com :
>
> In een bericht met de datum 18-12-2006 18:00:54 West-Europa
> (standaardtijd), schrijft mattias.forss at gmail.com:
>
>
> Maybe you're right, the definitions could be added as comments, but for
> proprietary terminology like SNOMED CT this will mean that these kind of
> archetypes can only be distributed to people that have paid the license.
>
>
>
> Sorry, but Snomed CT cannot be considered a proprietary terminology given
> the formal international SDO status from January onward.


We'll see about that. Read about the issues with SNOMED and LOINC here
http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html

Mattias

Further, most English speaking countries (Cnd, UK, US, Aus, Nw Zealand)
> already have a national licence allowing everyone to use it for health
> purposes.
>
> William Goossen
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: DV_QUANTITY_RATIO - remove from specification

[Mattias Forss]

2006/11/30, Sam Heard :
>
>  Dear All
>
> We have been working on the data types as we have known that there is a
> need to deal with fractions, ratios and percentages when the idea is of
> proportion - ie there is no units. Since the DV_QUANTITY_RATIO points to
> anything Quantified (ie count, date_time, duration) there are many
> non-sensible possibilities and although it has been around since the GEHR
> days, we have not used it for anything other than the idea of the new
> DV_PROPORTION type (which will be available in 1.0.1).
>

Hi Sam,

Does this mean that the ratio constraint could as of now be removed from the
archetype editors? Will the DV_RATIO class be removed from the
specifications as well? If not, should the editors change the current ratio
constraint to be of a DV_RATIO instead of a DV_QUANTITY_RATIO?

I think that the new DV_PROPORTION class could be used instead of
DV_QUANTITY when there are no units, e.g. only the property 'Qualified real'
and the empty string as a unit or a missing unit attribute in the item list
of C_QUANTITY and only a magnitude attribute. The current ADL parser doesn't
expect empty or null units which is correct according to the specification
of C_QUANTITY_ITEM in the archetype profile package. Hence, there should
always be a unit specified for each item in the item list of C_QUANTITY in
archetypes and it cannot be empty because quantified data with no units
could be represented with the DV_PROPORTION data type, right?

If you have a look at the blood film archetype (here:
http://my.openehr.org/wsvn/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.blood_film.v1.adl?op=file&rev=0&sc=0)
you will see that the elements named 'Packed cell volume (PCV)' and
'Plateletcrit' are quantity data types with empty units, but maybe they
could be changed to proportion data types instead? If not, then the
specification of C_QUANTITY_ITEM must be changed.

Another issue not at all related to the above:
The Ocean editor writes other_contributors = <> in the description part when
there are no other contributors, but since the attribute is not mandatory,
garbage like this should be removed from the archetypes. If the attribute
exists, then it should contain something as well. I would like this to be
fixed, because it makes the Java ADL parser fail...

Regards,

Mattias

I have filed a change request which explains how the perceived requirements
> for this type have largely been dealt with in archetypes:
>
>
> http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/227/base_view?portal_status_message=Your%20changes%20have%20been%20saved.&fieldset=issuedata
>
> Tom will let you know about the DV_PROPORTION class.
>
> http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/144/base_view?portal_status_message=Your%20changes%20have%20been%20saved.&fieldset=issuedata
>
> Interested in comments and queries...
>
> Cheers, Sam
>
>
> --
> Dr. Sam Heard
> MBBS, FRACGP, MRCGP, DRCOG, FACHI
>
> CEO and Clinical Director
> Ocean Informatics Pty. Ltd.
>  Adjunct Professor, Health Informatics,
> Central Queensland University
> Senior Visiting Research Fellow, CHIME, University College London
> Chair, Standards Australia, EHR Working Group (IT14-9-2)
> *Ph: +61 (0)4 1783 8808*
> *Fx: +61 (0)8 8948 0215*
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

dictionary

[Mattias Forss]

- Original Message - 
From: "Bert Verhees" 
To: 
Sent: Tuesday, February 07, 2006 11:32 PM
Subject: dictionary


> Hi,
>
> I have a question, maybe a stupid question, don't hesitate to tell me (I 
> can handle that), as long as you give the answer with it.
>
> Today I had the opportunity to have a good look at HealthOne, a GEHR 
> system, many on this list will know it.
>
> One thing looked smart to me.
> They have a kind of Dictionary with 6000 words, (also these words are 
> possibly related to each other, that makes it an extra strong feature). 
> The relationship between the words is not hard coded and is not stored in 
> medical-records, so if the relationship changes, nothing breaks, even if a 
> word from the dictionary will be deleted (which will not easily happen), 
> nothing breaks.
>
> The advantage is that always the same word is used when storing something, 
> f.e. "Weight"
>
> Maybe OpenEhr has such a feature also. or does it depend on archetypes to 
> force the same semantics. This seems dangerous to me, because when 
> exchanging medical information, in an other Archetype weight can be 
> defined as another word, a synonym, f.e. "Bodyweight"
>
> If one has an archetype which calculates the BMI (body mass index), it 
> could not work on another OpenEhr system that has used (some time) another 
> archetype to store the "Weight".
>
> Or am I completetely misunderstanding the issue, and is it in fact a 
> non-issue.
>
> Please explain to me.
>
> Thanks in advance
>
> Kind regards
> Bert Verhees
>

Hi Bert,

I don't think this is a big issue. The important thing in openEHR archetypes 
is the structure of them. As long as there is a structure that is equal for 
both "Weight" and "Bodyweight", it shouldn't be a problem. The allowed 
information model structures in archetypes is what really matters and the 
terms can always be bound to external terminologies to create a mutual 
understanding.

Regards,

Mattias Forss 

dictionary

[Mattias Forss]

Hi Philippe,

Well I started in the domain 20 weeks ago and I didn't know anything
back then (in the old days). I'm currently on my way of finishing my
master's thesis, so I cannot say I have the experience to answer your
questions ;-)

PS. Your questions are sensible though, no offense

Cheers,

Mattias

> Hi Mattias,
> 
> The more I work on medical information systems, and the less I 
> believe 
> that the structure is more important than the terminology.
> 
> To be a little bit more accurate, my opinion is that any health 
> information system is there to "tell stories".
> I started in the domain 20 years ago with endoscopy reports : the 
> story 
> to tell was a 10 to 20 minutes medical act. Now, for many reasons 
> (but 
> it would be too long to explain it there), the "big thing" is 
> continuity 
> of care, and the challenge is to be able to tell someone's whole 
> medical 
> journey.
> 
> So, how can we tell these stories (from a 10 minutes encounter to 
> the 
> whole life and the fighting strategies to remain as healthy as 
> possible) ?
> The answer is rather simple (at least to express) : we need to make 
> "sentences". And to make sentences requires a grammar (the 
> discourse 
> structure) and a vocabulary (to populate the discourse structure).
> 
> Is it possible to have a discourse structure that can "host" any 
> terminology ?
> My personal answer is 'no', but maybe I try to tell more complex 
> stories 
> than you intend, or maybe you have a more powerful technological 
> solution.
> At large, I can ask you a question : do you think that you could 
> communicate using the english grammar and let people choose any 
> other 
> language's vocabulary to populate it ?
> You can answer that natural language is more complex that formal 
> language, but I can say that the more complex the story you intend 
> to 
> tell and the closer they need to be.
> 
> Regards,
> 
> Philippe
> 
> > The important thing in openEHR archetypes is the structure of 
> them. As 
> > long as there is a structure that is equal for both "Weight" and 
> > "Bodyweight", it shouldn't be a problem. The allowed information 
> model 
> > structures in archetypes is what really matters and the terms can 
> > always be bound to external terminologies to create a mutual 
> > understanding.
> >
> > Regards,
> >
> > Mattias Forss
> >
> >
> >
> 
> 

About the Archetype lifecycle state

[Mattias Forss]

Hi David,

The lifecycle field is optional in the archetype identifier, see
http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/archetype_system.pdf
.

However, this document is under re-development so I don't know more about
the identifier than what's in the document. Another thing worth mentioning
is that the Support terminology document is not in line with Ocean's editor
and that is why they have more life cycle states than specified. This
probably depends on shortage of specified states, so I guess Ocean just
added a couple of their own. The computable Support Terminology in XML
format should be updated to follow the specifications...

Regards,

Mattias

2006/6/16, David Moner :
>
> Hello everybody,
>
> I have a question about the archetype lifecycle state. This may not be a
> fundamental question, but it is important to formalize all the aspects
> regarding to an archetype system. This is what I have found about this topic
> reading through all the documentation.
>
> First, at the ADL2 document, the section related to the Archetype
> Identifier references to the Archetype System document. There we can find a
> clear description of the Multiaxial Archetype Identifier. Well, clear except
> the life_cycle field. Reading the provided examples we get two possible
> values:
> * draft
> * in_test
>
> Looking for a more formal definition I read the Version Lifecycle State
> section at the Support Terminology document. Although it seems that is
> referred to another question (the revision of an archetype item), it is the
> only mention to the lifecycle in the entire document. This is what appears
> there.
> * complete: Item is complete at time of committal.
> * incomplete: Item is incomplete at time of committal, in the view of the
> author. Further editing or review needed before its status is set to
> "finished".
> * deleted: Item has been logically deleted.
> * draft: DEPRECATED.
> * active: DEPRECATED.
> * inactive: DEPRECATED.
> * awaiting approval: DEPRECATED.
>
> Finally, for my surprise, it is the case of the Ocean Archetype Editor
> (Version 0.99.5c Alpha). We can define with it something called
> "Authorship lifecycle" with these possible values:
> * Not set(en)
> * Initial(en)
> * Author draft(en)
> * Author draft(en)
> * Committee draft(en)
> * Organisation draft(en)
> * Submitted(en)
> * Candidate(en)
> * Approved candidate(en)
> * Published(en)
> * Rejected(en)
> * Obsolete(en)
>
> Furthermore, these values are recorded at the 
> description.lifecycle_statefield of the ADL but make no change at the 
> archetype identifier (maybe a
> bug?).
>
> This is the situation that I have found when studying in depth such a
> simple thing as the lifecycle state of an archetype. As I said at the
> beginning, this may not seem a fundamental problem at this stage of
> development, but it should be revised in order to get a more coherent
> archetype system and really useful archetype repositories (to assure that
> the archetype that they contain are reliable).
>
> This takes me to a more interesting question. Is it defined any policy for
> archetype management related to their lifecycle state? I haven't found
> anything about this topic. For example, this could be a very simple policy.
>
> * initial: The archetype is still in an embryonic stage. It makes no sense
> to validate it because its definition is not finished.
>
> * draft: Syntactically correct (from a direct ADL editing point of view or
> just with all the definition tree finished), but not semantically correct
> according to the reference model or its parent archetype (that is, the
> archetype doesn't respect the reference model or parent archetype
> constraints). It may also lack of terminology bindings.
>
> * test: Syntactically and semantically correct in the terms stated before.
> State for testing whether the EHR extracts based on it are what we want or
> need. In other words, at this state we are testing if the archetype fulfils
> the clinical concept that it is being defined.
>
> * final: Only an archetype in its final state should be stored at a public
> archetype repository. It is a valid archetype approved by a commission of
> experts and its ready to be used by any institution.
>
>
> This would be an interesting point for a deeper study.
>
>
> --
> David Moner Cano
> ITACA - BET - Grupo de Inform?tica Biom?dica
> http://gim.upv.es
>
> Universidad Polit?cnica de Valencia (UPV)
> Camino de Vera, s/n, Edificio G-8, Acceso 3, 3? planta
> Valencia ? 46022 (Espa?a)
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Public release of Java Archetype Editor v0.3

[Mattias Forss]

Dear all,

With this message I am happy to announce that the Java Archetype Editor has
been publicly released and is available to download from
http://www.imt.liu.se/mi/ehr. Please read the release notes before
installing the editor.

Feedback about the editor is welcomed, both positive and negative.

Open source distribution of the editor will not take place yet, but the
source code will be released as soon as we feel it's mature enough.

The Archetype Editor was developed within the framework of the EU-funded
Network of Excellence entitled Semantic Interoperability and Data Mining in
Medicine. Read more about Semantic Mining at http://www.semanticmining.org.


Best regards,

Mattias Forss via the Medical Informatics Group,
Department of Biomedical Engineering,
Link?ping University, Sweden
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060629/6c981363/attachment.html>

Question about Composition archetypes

[Mattias Forss]

Hello,

I've just compared some Composition archetypes from Ocean Informatics 
with the specifications at openEHR.org and I have some questions. The 
specifications from 0.9 to 1.0 all agree about one thing for COMPOSITION 
classes and that is that the attribute "context" in the COMPOSITION 
class should point to a class called EVENT_CONTEXT.

However, this is not the case for the archetypes I've seen so far. 
Instead, the "context" attribute in the archetypes matches subclasses of 
ITEM_STRUCTURE e.g. ITEM_TREE. These classes should instead be referred 
by an optional attribute called "other_context" inside the EVENT_CONTEXT 
class. Can anyone please explain to me why this is the case?

Regards,

Mattias

Specification of ITEM_TABLE

[Mattias Forss]

Hello,

I'm trying to add support for ITEM_TABLE in the Java Archetype Editor and I
have looked at the only archetype I've found that contains a data structure
like this. It is openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and
it can be found here http://oceaninformatics.biz/archetypes/. When I
compared the attributes for the ITEM_TABLE in the data structures
specifications (found here
http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf)
with the ones that existed in the archetype I saw that the attributes had
nothing in common. Maybe someone can explain to me how the ITEM_TABLE look
like once and for all :-)

The archetype looks like this:

ITEM_TABLE[at0003] matches { -- structure

 COMMENT: The attributes below adhere to the ITEM_TABLE that you get
when you create a table structure in the Ocean Archetype Editor, but I
haven't seen any of these three attributes specified anywhere. I would be
glad if anyone could point them out to me.

rotated matches {True}
number_key_columns matches {|1|}
rows cardinality matches {0..1; unordered} matches {
CLUSTER[at0050] occurrences matches {0..2} matches { -- row
items cardinality matches {7; ordered} matches {

 COMMENT: This first element has a CODED_TEXT which contains coded terms
that are represented as columns in the Ocean Archetype Editor.

ELEMENT[at0012] occurrences matches {0..1} matches { --
row_head
value matches {
CODED_TEXT matches {
code matches {
[local::
at0011, -- Left
at0013] -- Right
}
}
}
}

 COMMENT: This element and all succeding elements are represented as rows
in the Ocean Archetype Editor.

ELEMENT[at0004] occurrences matches {0..1} matches { --
Biceps
value matches {
ORDINAL matches {
value matches {
...
}
}
}
}
-


But in the specification the ITEM_TABLE it looks like this:

CLASS ITEM_TABLE
Purpose
Logical table data structure, in which columns are named and ordered. Some
columns
may be designated 'key' columns, containing key data for each row, in the
manner of relational tables. This allows row-naming, where each row
represents
a body site, a blood antigen etc. All values in a column have the same data
type.
Use Used to represent any data which is logically a table of values, such as
blood
pressure, most protocols, many blood tests etc.
MisUse Not used for time-based data, which should be represented with the
temporal
class HISTORY. The table may be empty.

Entry type.
Inherit ITEM_STRUCTURE
Attributes
0..1 columns: List
Physical representation of the table
as a list of CLUSTERs, each containing
the data of one column of the
table.


Hope someone can help me.

Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060511/d69c8b7c/attachment.html>

Specification of ITEM_TABLE

[Mattias Forss]

2006/5/12, Sam Heard :
>
>  Mattias
> This is a mistake in the 1.0 specification and it is has been updated on
> the website 1.0.1 specs. The attribute of a table is rows - each row is a
> cluster of elements (it was mistakenly documented as columns).
>

Hi Sam,

I looked at this document
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/data_structures_im.pdfand
it says that ITEM_TABLE.columns attribute has been changed to rows in
the amendment record (CR-000207). However, the change hasn't actually been
commited in the document, so maybe the change was lost somehow...

rotated is an archetype only attribute which allows rotated tables to be
> displayed - this is like a pivot table in Excel.
>

Is this attribute documented somewhere? I don't really understand why this
attribute is allowed under ITEM_TABLE when it is not specified for the
actual data structure.

Number of key columns is in the new specifications.
>

This attribute is also missing in the document I mentioned above. By the
way, could you explain this attribute to me? Should the users of an
archetype editor be able to change the existence and/or contents of this
attribute with some GUI component or should it be done automatically
whenever new columns are added that contain actual data (ELEMENTs)?

Cheers,

Mattias

Hope this is OK.
>
> Cheers, Sam
>
>
>
> Mattias Forss wrote:
>
> Hello,
>
> I'm trying to add support for ITEM_TABLE in the Java Archetype Editor and
> I have looked at the only archetype I've found that contains a data
> structure like this. It is
> openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and it can be
> found here http://oceaninformatics.biz/archetypes/. When I compared the
> attributes for the ITEM_TABLE in the data structures specifications (found
> here
> http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf)
> with the ones that existed in the archetype I saw that the attributes had
> nothing in common. Maybe someone can explain to me how the ITEM_TABLE look
> like once and for all :-)
>
> The archetype looks like this:
>
>  ITEM_TABLE[at0003] matches { -- structure
>
>  COMMENT: The attributes below adhere to the ITEM_TABLE that you get
> when you create a table structure in the Ocean Archetype Editor, but I
> haven't seen any of these three attributes specified anywhere. I would be
> glad if anyone could point them out to me.
>
> rotated matches {True}
> number_key_columns matches {|1|}
> rows cardinality matches {0..1; unordered} matches {
> CLUSTER[at0050] occurrences matches {0..2} matches { -- row
> items cardinality matches {7; ordered} matches {
>
>   COMMENT: This first element has a CODED_TEXT which contains coded
> terms that are represented as columns in the Ocean Archetype Editor.
>
> ELEMENT[at0012] occurrences matches {0..1} matches { --
> row_head
> value matches {
> CODED_TEXT matches {
> code matches {
> [local::
> at0011, -- Left
> at0013] -- Right
> }
> }
> }
> }
>
>  COMMENT: This element and all succeding elements are represented as rows
> in the Ocean Archetype Editor.
>
> ELEMENT[at0004] occurrences matches {0..1} matches { --
> Biceps
> value matches {
> ORDINAL matches {
> value matches {
> ...
> }
> }
> }
> }
> -
>
>
> But in the specification the ITEM_TABLE it looks like this:
>
> CLASS ITEM_TABLE
> Purpose
> Logical table data structure, in which columns are named and ordered. Some
> columns
> may be designated 'key' columns, containing key data for each row, in the
> manner of relational tables. This allows row-naming, where each row
> represents
> a body site, a blood antigen etc. All values in a column have the same
> data type.
> Use Used to represent any data which is logically a table of values, such
> as blood
> pressure, most protocols, many blood tests etc.
> MisUse Not used for time-based data, which should be represented with the
> temporal
> class HISTORY. The table may be empty.
>
> Entry type.
> Inherit ITEM_STRUCTURE
> Attributes
> 0..1 columns: List
> Physical representation of the table
> as a list of CLUSTERs,

Specification of ITEM_TABLE

[Mattias Forss]

2006/5/16, Sam Heard :
>
>  Mattias
>
>  I looked at this document 
> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/data_structures_im.pdf
> and it says that ITEM_TABLE.columns attribute has been changed to rows in
> the amendment record (CR-000207). However, the change hasn't actually been
> commited in the document, so maybe the change was lost somehow...
>
>  rotated is an archetype only attribute which allows rotated tables to be
> > displayed - this is like a pivot table in Excel.
> >
>
> Is this attribute documented somewhere? I don't really understand why this
> attribute is allowed under ITEM_TABLE when it is not specified for the
> actual data structure.
>
> If a table is rotated it means that the values in one column become
> columns headings, with the columns becoming rows. E.g.
>
> Reflexes:
> laterality   knee ankle
> left   ++ +/-
> right ++
>
> When this is rotated it becomes:
>left right
> knee ++ +
> ankle +/-+
>
> This is called a pivot table and allows rows of the same data type rather
> than columns which is the usual. This is more than display although the
> semantics are not effected. Infact, all tables in the editor are rotated at
> the moment as this is by far the most common way of presenting data in
> medicine.
>

Thanks for your answer Sam,

I have another question about this rotated attribute. Why do we need it when
it is only a question of how to display the actual data contents? Shouldn't
that be decided by an actual user rather than an attribute? I don't think
the ADL contents and underlying structure of an ITEM_TABLE should change
even if it were possible to switch between pivot tables and ordinary tables.

Now to the important question that I'd been thinking about. The
specifications of ITEM_TABLE say that the rows attribute should have a
List as children but I don't see the point with this. Why do we
need several clusters as rows since a table with rows that each have
different column headings is impossible to create? If the rows attribute had
List as children it would make much more sense. Also, It wouldn't be a
bad idea to have rows and column headings as separate attributes instead of
having the column headings of the table in the first element under the rows
attribute.

By the way, I don't think it's usable to show the table data types as
columns since that would probably only confuse the user compared to how tree
and list are displayed. So for this part I agree with you.

Number of key columns is in the new specifications.
> >
>  This allows unique keys and means that the values of the combined keys
> have to be unique - if this is not set then there is no restriction on
> uniqueness.
>

Why is this attribute's leaf value an integer? I don't understand this part.
Does this mean that if the user creates two rows with the same name, for
example "knee" then the uniqueness wouldn't be preserved and then another
key column would have to be added... Maybe the table should always have an
extra column that contain unique keys (as for the ordinal constraint).

Hoping for a quick answer.

Cheers,

Mattias

> This attribute is also missing in the document I mentioned above. By the
> way, could you explain this attribute to me? Should the users of an
> archetype editor be able to change the existence and/or contents of this
> attribute with some GUI component or should it be done automatically
> whenever new columns are added that contain actual data (ELEMENTs)?
>
> Tom will be getting to this I think as I did an edit some time ago..Sam
>
>
> Cheers,
>
> Mattias
>
>  Hope this is OK.
> >
> > Cheers, Sam
> >
> >
> >
> > Mattias Forss wrote:
> >
> > Hello,
> >
> > I'm trying to add support for ITEM_TABLE in the Java Archetype Editor
> > and I have looked at the only archetype I've found that contains a data
> > structure like this. It is
> > openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and it can be
> > found here http://oceaninformatics.biz/archetypes/. When I compared the
> > attributes for the ITEM_TABLE in the data structures specifications (found
> > here 
> > http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf
> > ) with the ones that existed in the archetype I saw that the attributes
> > had nothing in common. Maybe someone can explain to me how the ITEM_TABLE
> > look like once and for all :-)
> >
> > The archetype looks like this:
> >
> >  ITEM_TABLE[at

Specification of ITEM_TABLE

[Mattias Forss]

2006/5/16, Sam Heard :
>
>  Mattias
>
> Quick response..
>
> If a table is rotated it means that the values in one column become
> > columns headings, with the columns becoming rows. E.g.
> >
> > Reflexes:
> > laterality   knee ankle
> > left   ++ +/-
> > right ++
> >
> > When this is rotated it becomes:
> >left right
> > knee ++ +
> > ankle +/-+
> >
> > This is called a pivot table and allows rows of the same data type
> > rather than columns which is the usual. This is more than display although
> > the semantics are not effected. Infact, all tables in the editor are rotated
> > at the moment as this is by far the most common way of presenting data in
> > medicine.
> >
>
> Thanks for your answer Sam,
>
> I have another question about this rotated attribute. Why do we need it
> when it is only a question of how to display the actual data contents?
>
> Well, we do not think it is only a matter of display - although it could
> be seen as such. If the attribute is not present then it is not possible to
> determine whether to display it as a pivot or not. The property of
> DV_QUANTITY is only in the archetype as well and determines valid units - it
> is a similar sort of issue.
>

Hi again Sam,


I wouldn't mind to ignore and not save this attribute until the different
display modes are supported in the Java archetype editor. A missing rotated
attribute should probably not cause errors for the Ocean archetype editor?

Now to the important question that I'd been thinking about. The
> specifications of ITEM_TABLE say that the rows attribute should have a
> List as children but I don't see the point with this. Why do we
> need several clusters as rows since a table with rows that each have
> different column headings is impossible to create? If the rows attribute had
> List as children it would make much more sense. Also, It wouldn't be a
> bad idea to have rows and column headings as separate attributes instead of
> having the column headings of the table in the first element under the rows
> attribute.
>
> Well, each row is a set of elements (as a cluster) - the table is a
> special case in that each cluster can only have elements (invariant). Each
> row is a cluster - which is in effect the definition of each column. So you
> need a list of clusters to get rows.
>

So then I guess the ADL is constructed according to how the first table
looks like in your example above (since pivot should not affect the
structure)? In that case I believe that the ITEM_TABLEs that are created by
the Ocean editor aren't following the specifications, since no matter how
many rows (e.g. left, right) you add, they will only be contained within one
cluster only. There is accordingly no way to create an ITEM_TABLE that has
more than one cluster under the rows attribute. Furthermore, each row that
is added should create a cluster that has an at-code with its name and in
the pivot display mode the clusters names will be the column headings.
Right?

Hope we can sort this out.

Regards,

Mattias

PS. You forgot my question about key columns. See below.

By the way, I don't think it's usable to show the table data types as
> columns since that would probably only confuse the user compared to how tree
> and list are displayed. So for this part I agree with you.
>
> We can take this a lot further with time and more power in the archetype
> editor. Cheers, Sam
>
>
> Number of key columns is in the new specifications.
> > >
> >  This allows unique keys and means that the values of the combined keys
> > have to be unique - if this is not set then there is no restriction on
> > uniqueness.
> >
>
> Why is this attribute's leaf value an integer? I don't understand this
> part. Does this mean that if the user creates two rows with the same name,
> for example "knee" then the uniqueness wouldn't be preserved and then
> another key column would have to be added... Maybe the table should always
> have an extra column that contain unique keys (as for the ordinal
> constraint).
>
> Hoping for a quick answer.
>
> Cheers,
>
> Mattias
>
> >   This attribute is also missing in the document I mentioned above. By
> > the way, could you explain this attribute to me? Should the users of an
> > archetype editor be able to change the existence and/or contents of this
> > attribute with some GUI component or should it be done automatically
> > whenever new columns are added that contain actual data (ELEMENTs)?
> >
> > Tom will 

Specification of ITEM_TABLE

[Mattias Forss]

2006/5/16, Thomas Beale :
>
> Mattias Forss wrote:
> >
> >
> > 2006/5/16, Sam Heard  > <mailto:sam.heard at oceaninformatics.biz>>:
> >
> >>
> > Well, we do not think it is only a matter of display - although it
> > could be seen as such. If the attribute is not present then it is
> > not possible to determine whether to display it as a pivot or not.
> > The property of DV_QUANTITY is only in the archetype as well and
> > determines valid units - it is a similar sort of issue.
> >
> yes, but that's only because we have an explicit custom type called
> C_QUANTITY that supplies the "property" attribute in the archetype.
> Otherwise this would not be possible
> >
> > Hi again Sam,
> >
> >
> > I wouldn't mind to ignore and not save this attribute until the
> > different display modes are supported in the Java archetype editor. A
> > missing rotated attribute should probably not cause errors for the
> > Ocean archetype editor?
> This cannot work as explained above - either the attribute has to exist
> in the RM class or else we have to create a custom type like
> C_ITEM_TABLE for it. That's the general rule.


Hi Tom,

I agree with you. Either the rotated attribute is removed from the
archetypes or added in the ITEM_TABLE or a custom type C_ITEM_TABLE.

>
> >> Now to the important question that I'd been thinking about. The
> >> specifications of ITEM_TABLE say that the rows attribute should
> >> have a List as children but I don't see the point with
> >> this. Why do we need several clusters as rows since a table with
> >> rows that each have different column headings is impossible to
> >> create? If the rows attribute had List as children it would
> >> make much more sense.
> >
> I don't understand thatthe current specification says that each row
> is logically a CLUSTER (of ELEMENTs). Of course there are more efficient
> ways to represent tables, but we have stuck to the tree structure used
> in CEN EN13606 - it is interoperable and simple to understand.


Yes, I guess we're stuck for a while then...

So you shouldn't worry that this structure could technically allow different
> column names on different rows, the software will not allow that. You
> get a bit of redundancy in using sub-optimal structures for
> interoperability purposes.


I think we keep flipping around things here. I take it from the point of
creating the actual RM data. What I think you mean is that if someone is
clumsy it would be quite easy to create two rows with the same column name
(not heading), e.g. "Left"? This is quite a flaw but as long as the software
(kernel) won't allow this creation it's acceptable.

>
> > So then I guess the ADL is constructed according to how the first
> > table looks like in your example above (since pivot should not affect
> > the structure)? In that case I believe that the ITEM_TABLEs that are
> > created by the Ocean editor aren't following the specifications, since
> > no matter how many rows ( e.g. left, right) you add, they will only be
> > contained within one cluster only. There is accordingly no way to
> > create an ITEM_TABLE that has more than one cluster under the rows
> > attribute.
> In the archetype you would only have one row, since it is a model for
> numerous rows in the data...does that answer the question?


Yes it does, but not how the column names/headings (depends what you mean if
it's displayed as a pivot table or not) are modelled in archetypes, e.g.
"left", "right" for a reflexes archetype. They are modelled as the first
ELEMENT in Ocean's archetypes and it contains a CODED_TEXT that constrain
the headings. Is this the best way to represent headings? I don't understand
the logic behind it since they can be mistaken for actual table data which
comes after the first element. However, column names/headings are table data
too but it's bad design to assume this comes first in order to show the
table in an archetype editor. Maybe I could take a different approach than
actually showing a real table in the GUI...


> Furthermore, each row that is added should create a cluster that has
> > an at-code with its name and in the pivot display mode the clusters
> > names will be the column headings. Right?
> this is getting mixed up between rows in an archetype (don't forget an
> archetype is not data, it is a model of data) and the actual data that
> conform to the archetype - which will of course have >1 rows in general.


No I haven't forgotten about that but sometimes it's easy to think a step
ahead. :-)

Regards,

Mattias

- thomas
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060516/e546a52f/attachment.html>

Specification of ITEM_TABLE

[Mattias Forss]

2006/5/17, Thomas Beale :
>
> Sam Heard wrote:
> > Mattias
> >
> > This is a good discussion with some issues that need to be taken
> > further. The problem I face as a clinician is that tables in medicine
> > are often presented with the same data types across the row - and with
> > the values in the first column as column headings. This is a standard
> > pivot table in Excel or Access and is a common data presentation issue
> > - which SQL can perform.
> I don't have a problem with the rotate idea - if clinical people want it
> and it makes sense, then it is needed. But - most likely need add an
> attribute to the reference model. Here's the problem if we don't:
> - archetypes only constraint data that is created
> - whether a table is rotated or not becomes important at display /
> interpretation time of the _data_, not the archetype.
> - so any mention of the rotate attribute in the archetype must lead to
> some flag being set in the data in order to get the behaviour at runtime
>
> The only way out  of this is that we take the line that the archetype
> must always be available at the time the data are used, in whatever
> circumstance. Technically it isn't hard to engineer this in nice
> controlled OO environments, but consider that the data might be
> processed into various kinds of good-quality or not-so-good quality XML,
> HTML, PDF, other custom formats, where the corresponding archetypes
> might not be easily available or needed. I would guess that many
> applications should be able to process e.g. path results as openEHR
> structures without needing to look up the archetype. So my conclusion is
> that we should always ensure that the data can stand alone and remain
> meanggul.


I cannot agree more with that, so the best thing to do is probably to
include the attribute into the RM class if there is a need for a rotated
attribute. However, at this point I don't see that there is a huge need for
it since the data could always be presented in a pivot table but then some
might disagree with me, I'm not the clinician here.

Now - in the case of reflexes, visual acuity and other tabular data, one
> (presumably) could argue that the data are perfectly comprehensible even
> with no 'is_rotated" flag set; others might argue the opposite. I
> personally don't see a problem with including a flag in the RM
> ITEM_TABLE class, but we need to do it now.
> >
> > I do not believe it is possible to determine from data alone when it
> > is appropriate to rotate a table for presentation. This is why I have
> > pushed to have it in the editor. I think a lot of clinicians will find
> > it difficult to accept information in unrotated form as it is not how
> > they do it now for many situations. There are many situations where
> > this is not the case as well.
> >
> > I agree that the right thing to do is put this in ADL if we want to -
> > we could just say we leave it to the display - but I think this will
> > mean clinicians find it hard to build the tables they need. We can
> > experiment some more with this as it is an ADL issue rather than a
> > reference model issue. I would suggest that you ignore it if you like
> > for the moment (with the result of frustrating the clinicians) or take
> > the attribute as it is and agree to put it into ADL.
> do you mean the reference model Sam - it can't be "put into ADL" unless
> we create a C_ITEM_TABLE type, which I don't think we should have to
> do


There should probably be enough to use the attribute in the ITEM_TABLE. What
I don't see at this point is if the most common way to display table data is
pivot tables, then will there ever be cases when the data must explicitly be
shown in an unrotated form?

But what about the other problem Mattias pointed out - we don't have an
> attribute "key-columns" in ITEM_TABLE either. Previously we specified
> that if there was a "(key)" in the name string of a column, it would be
> a key column, but this is open to abuse by buggy software. The
> alternative is to add another attribute into ITEM_TABLE that contains a
> list of key column indexes or names. But I would like to be sure that
> this feature is really needed in table archetypes...is it?


If one thinks about an ordinary SQL query to some database that contains an
inventory of for example some equipment, then there might occur several
records of the same name and therefore these must be separately identifiable
with unique keys in order to get the specific equipment from the database.

Then what options are there in ADL? If we know that an ITEM_TABLE always has
some column that is uniqe then that should be mentioned as the key so that
the process of creating the RM data will not allow creation of data that
don't have uniqe identifiers. It might even be the case that there have to
exist several keys but not as long as there isn't a need for column headers
with the same name.

Regards,

Mattias

- thomas
>
> --
>
> _

Archetype questions

[Mattias Forss]

Hi,

I'm currently working in a group that has been evaluating archetypes and
they found out that there in archetypes may be needed to add external nodes
from other archetypes instead of only adding complete archetypes as slots.
Does the current ADL specification allow that external parts from other
archetypes can be included? I think the openEHR templates allow to cut off
parts in a slot, but I'm not sure if they can exclude everything except a
single item.

The group also found out that there is a need to deduct certain answers
depending on previously answered questions. For example if we previously
answered that the blood pressure was above 160, then another question about
hypertension should be answered automatically. Is this possible to do in
archetypes?

Another issue is about computation. For example we could want a quantifiable
magnitude to be the result of two previously entered values. Is this
possible to do in archetypes? Perhaps in the declaration section or the
invariant section? I've seen that these sections should contain some kind of
first-order predicate logic, but I'm not sure of the scope and
limitations/possibilities of these ADL sections. Also, the declaration
section is actually not even described in the ADL 1.4 document, it is only
shown in an example overview figure.

Another feature is value reporting, which should work when we use several
archetypes in an openEHR template. For example if some question was answered
in one archetype, then another archetype that has the same question should
get the value reported from the previous archetype. Is this possible? I
guess this has to do with external references as I mentioned in my first
question.

We would also like to ask if there is a way of specifying validity for
questions depending on previously answered questions. E.g. if a certain
answer was given from a multiple alternative question (coded_text), then and
only then, some other group of questions will be valid. Is this possible to
do in archetypes? Perhaps it's possible with invariants?

Finally is there a way of specifying the relevance of answers in archetypes.
Say for example that if some laboratory results are too old, could an
archetype contain some restrictions that make it illegal to answer certain
questions because the material that the answers are based upon is too old?
I'm not sure if this is related to DSS or something else.

Regards,

Mattias, via the Link?ping Team.
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: Archetype questions

[Mattias Forss]

2006/11/3, ognian.pishev at oceaninformatics.biz <
ognian.pishev at oceaninformatics.biz>:
>
> I believe that in answering this series of questions one has to
> distinguish
> among:
> 1. what archetypes do - they define valid data based on the constraints of
> a
> clinical concept model;
> 2. what needs to be done by decision support systems that rely on
> archetypes,
> that is, to make sense of results recorded using archetypes; and
> 3. what a template builder can do using archetypes to introduce business
> logic
> and dependenices into the template one needs for specific purposes.
>
> As you can see, archetypes do not address all the issues listed in 1-3.



Hi Ognian,

These are exactly the points I have tried to explain to the group I am
working with, I just needed to verify them on this list since there are more
experienced people here. The group have been comparing "templates", in their
sense meaning archetypes from openEHR and templates based on the HL7 RIM,
but they are hard to compare since not archetypes alone can address all
issues.

Many of the points the group has come up with in their evaluation are in
openEHRs case more about what a template builder can do, rather than what an
archetype editor can do. There were also many requirements on doing
computations and decision support like things in archetypes. I find that
there may exist some basic computation and DSS in archetypes but it is part
of R&D as Gerard pointed out.

Regards,

Mattias

Ogi Pishev
>
> P.S. As for the ...v3 stuff, I'd like to see computing systems that
> machine
> process those... (And I don't mean Excel).
>
>
>
> Quoting Williamtfgoossen at cs.com:
>
> > "Mattias Forss"  wrote:
> >
> > Hello Mattias,
> >
> > these are exactly the questions, issues I have been working on for 3
> years
> > now. All I can specify in the HL7 v3 Care Provion Domain model, that is
> > basically why I apply this method for the time being, waiting for a
> better
> > tool to do this. Below specific answers after each question.
> >
> > >Hi,
> > >
> > >I'm currently working in a group that has been evaluating archetypes
> and
> > >they found out that there in archetypes may be needed to add external
> nodes
> > >from other archetypes instead of only adding complete archetypes as
> slots.
> >
> > I agree, in the care provision we therefore have included the organizer
> class
> > that allows you to start with atomic items, link them via an organiser
> code
> > to a higher level item (e.g. blood pressure is part of vital signs,
> mobility
> > is part of activities of daily living, potasium is part of electrolytes
> > etc.). I work bottom up because of another question of you below.
> > This is possible in ADL I believe / am told, but have not seen
> > operationalised yet. However the template specifier does this, but I am
> not
> > sure how the formal links work. In organiser we can code the higher
> level
> > rubrics.
> >
> >
> > >Does the current ADL specification allow that external parts from other
> > >archetypes can be included? I think the openEHR templates allow to cut
> off
> > >parts in a slot, but I'm not sure if they can exclude everything except
> a
> > >single item.
> > >
> >
> > We break down such care information models in two parts if there are use
> > cases where only a part is used. So we make 2 slots instead of one.
> >
> > >The group also found out that there is a need to deduct certain answers
> > >depending on previously answered questions. For example if we
> previously
> > >answered that the blood pressure was above 160, then another question
> about
> > >hypertension should be answered automatically. Is this possible to do
> in
> > >archetypes?
> > >
> >
> > We can relate HL7 obs classes to each other, including if a value of Obs
> 1 >
> > 160, then Obs gets default hypertension.
> > However, there is no agreed formalism in HL7 v3 to do this. Arden syntax
> an d
> > Gello are often named in this area, but I have no examples. I just use
> plain
> > english for the time being.
> >
> > >Another issue is about computation. For example we could want a
> quantifiable
> > >magnitude to be the result of two previously entered values. Is this
> > >possible to do in archetypes?
> >
> > We apply this a lot in the HL v3 care information models. Basically most
> > scales have a kind of sum up feature of say 10 observations (Barthel)
> each
> > gets a numeric score and obs 11

Archetype questions

[Mattias Forss]

2006/11/6, Sam Heard :
>
>  Hi Mattias
>
> I'm currently working in a group that has been evaluating archetypes and
> they found out that there in archetypes may be needed to add external nodes
> from other archetypes instead of only adding complete archetypes as slots.
>
> Not sure what you mean = only parts of archetypes e,g, Hb only from Blood
> count?
>

Hi Sam,

I will provide you with some examples from one of the group members.

Reusing nodes: It would be reusing single nodes from archetypes, as your
example above, and here are two more examples.

Example 1. If the blood pressure measurement archetype allowed recording
average 12h blood pressure (protocol) it would be important to be able to
record the arousal state of the patient during the measurements (awake or
asleep). This node ("state of arousal: awake / asleep") would also be useful
in an archetype for electroencephalographic results, and hence one could
want to reuse it.

Example 2. If there is a blood pressure measurement observation archetype
without the current treatment in the patients state, there must be another
observation archetype to record the current treatment, because this
information is mandatory to interpret blood pressure results. In this
"current treatment" archetype, one could wish to record the pharmacological
class of each hypertensive drug (quite long list). This list could be reused
in a "treatment history" evaluation archetype, that would record when every
drug has been started and stopped and why.

Is it possible, by one way or another, to reuse a single node defined in a
first archetype when building another archetype? when building a template?
Does the current ADL specification allow that external parts from other
archetypes can be included?

> This is done in templates at present = need some examples
>

So I need to know if we could remove everything but a single node (ELEMENT)
from for example an OBSERVATION slot.

I think the openEHR templates allow to cut off parts in a slot, but I'm not
> sure if they can exclude everything except a single item.
>
> You can exclude all archetypes - again need more specificity!
>

Vide supra

The group also found out that there is a need to deduct certain answers
> depending on previously answered questions. For example if we previously
> answered that the blood pressure was above 160, then another question about
> hypertension should be answered automatically. Is this possible to do in
> archetypes?
>
> I think this is application space - I do not think you can express this in
> an archetype...probably better if there is more detail.
>

Example:
If the blood creatine value is included an archetype, it could be useful to
state that if the result is more than a given upper value, then the default
value to the following boolean node "renal failure" has to be "yes".

It might be that this always is in application space and probably a task of
a template builder (user-interface business logic building).

Another feature is value reporting, which should work when we use several
> archetypes in an openEHR template. For example if some question was answered
> in one archetype, then another archetype that has the same question should
> get the value reported from the previous archetype. Is this possible? I
> guess this has to do with external references as I mentioned in my first
> question.
>  Again difficult to know what you mean = sounds like application space
> though.
>

Example:
In an observation archetype having the body weight as one of its nodes, it
could be useful to state that the default value for this node is the last
previously entered value through this same archetype or even through another
archetype.

The latter might be easier to achieve in the runtime system if there could
be some way of having external references (pointers) but archetypes could
more easily be broken if they reference non-existing items. Anyway, this
shall be dealt with on the user-interface level. For example, values could
be linked together by some value map that has the related archetype paths
that share values which allows the user-interface to know if values have
been previously added (and when).

We would also like to ask if there is a way of specifying validity for
> questions depending on previously answered questions. E.g. if a certain
> answer was given from a multiple alternative question (coded_text), then and
> only then, some other group of questions will be valid. Is this possible to
> do in archetypes? Perhaps it's possible with invariants?
>
> Perhaps = but we see this as application space unless it is an absolute
> fact - then it the other values could become mandatory based on the value of
> another value.
>

Example:
It could be useful to state that the cluster node "smoking habits" is not
valid (and not displayed to the user) if the value of the node (which
doesn't neccessarily have to reside within the cluster) "current smoker" is
No.

Again, this can probably be considered as appl

Archetype questions

[Mattias Forss]

Hi Thomas,

Thank you very much for your answers. They were quite clear and easy to
understand as they often are. I have some more questions below...

2006/11/7, Thomas Beale :
>
>
> I'll just provide some formal answers below.
>
> Mattias Forss wrote:
>
> Hi,
>
> I'm currently working in a group that has been evaluating archetypes and
> they found out that there in archetypes may be needed to add external nodes
> from other archetypes instead of only adding complete archetypes as slots.
> Does the current ADL specification allow that external parts from other
> archetypes can be included? I think the openEHR templates allow to cut off
> parts in a slot, but I'm not sure if they can exclude everything except a
> single item.
>
>
>- by the use of slots, which you already know about. Use this when
>you want to define reusable semantic units (i.e. more archetypes).
>Archetypes and slots can be defined at any level - including at low levels.
>However, the downside is potentially "too many little archetypes" for
>effective management and governance
>
>

Yes,  too many small archetypes would probably make the archetypes hard to
maintain etc.


>- in some cases, most likely what is really needed is to be able to
>reduce the work required to build archetypes in the authoring tool
>environment - in other words cut and paste, or smarter things than that. So
>- what is smarter than cut and paste? We can consider that there are
>"archetype fragments" which are stored and indexed in a sophisticated
>authoring environment. These would not be separate archetypes as such - 
> just
>pieces of archetypes that have been identified as re-usable in the 
> authoring
>environment, but otherwise not sensible self-standing semantic units. Think
>about it this way - in some cases, you are not after another archetype, you
>just want to make sure that you build the little piece of the current
>archetype inn the same way as you did last time, without missing a term.
>
>
Agree, but shouldn't there be some way to link the "copies" with each other,
because they _will not_ be the same data if they don't have the same
archetype path? How should we know if we already entered similar values in
another archetype, possibly even found in another template than the current
one? There should be some way of linking values together. Can it be done at
the template level or must it be done at an even higher level, i.e. in
business logic of the GUI in the EHR system?

I will probably make it possible in the Java archetype editor to copy
definition nodes between different instances of the program, but that is
just a start. The ideal would be to support imports of nodes found in the
definition of several selected archetypes...

the first "exists" is only needed if the systolic value node is optional;
> the above statement in a real archetype would not necessarily be exactly as
> above, but the idea is clear. HOWEVER: in clinical terms, this sort of
> condition may not be considered as globally applicable as the rest of the
> archetype - it might only apply in your hospital. In this case, the same
> kind of statement should be added to a template instead.
>

Yes, this condition would of course only be added in the template since it
is not a global requirement (however there may be such also), but the
invariants seem to have a lot of potential and would significantly aid
decision support.


> Another issue is about computation. For example we could want a
> quantifiable magnitude to be the result of two previously entered values. Is
> this possible to do in archetypes? Perhaps in the declaration section or the
> invariant section?
>
> this can also be done in the invariant section using a statement of the
> form:
>
> exists(/path1/value) and exists(/path2/value) implies /path3/value =
> /path1/value + /path2/value
>

Though it certainly is useful, this is only to constrain the allowed value
and not to compute it. Some business logic in the EHR system would have to
use the invariant to compute the allowed value so that the clinician doesn't
have to do that (and risk to enter the wrong value and break the data entry
process if the value is invalid according to the archetype).

I also noticed that archetypes may become ambiguous by using invariants. For
example if the cADL says that the value must be > 10 and the invariant says
that the value is 5. I guess there is a need for an archetype validator that
checks all kinds of things, conformance to RM class names and attributes,
existing codes in the ontology section, invariants conforming to cADL, etc,
etc.


Another feature is value reporting, which should work when we use several
archetypes in an 

Archetype questions

[Mattias Forss]

2006/11/8, Mattias Forss :
>
>
> We would also like to ask if there is a way of specifying validity for
> > questions depending on previously answered questions. E.g. if a certain
> > answer was given from a multiple alternative question (coded_text), then and
> > only then, some other group of questions will be valid. Is this possible to
> > do in archetypes? Perhaps it's possible with invariants?
> >
> > same general form as the first one, where the exists() quantifier can be
> > used with operators like "implies" to state the required conditions.
> >
>
> Does this mean that the invariant allows something like
> "path/to/coded_text/defining_code = at0003 implies /some/path[at]
> occurrences.min = 1" can be used for the group of questions (cluster) we
> want to be valid?
>

Oops, I meant it probably should be something like:

invariant
exists(/some/path[at]) implies path/to/coded_text/defining_code =
at0003


//Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061108/d2cddeb8/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Archetype questions

[Mattias Forss]

Hi Thomas,

2006/11/12, Thomas Beale :
>
> Mattias Forss wrote:
> >
> >
> > * in some cases, most likely what is really needed is to be
> >   able to reduce the work required to build archetypes in the
> >   authoring tool environment - in other words cut and paste,
> >   or smarter things than that. So - what is smarter than cut
> >   and paste? We can consider that there are "archetype
> >   fragments" which are stored and indexed in a sophisticated
> >   authoring environment. These would not be separate
> >   archetypes as such - just pieces of archetypes that have
> >   been identified as re-usable in the authoring environment,
> >   but otherwise not sensible self-standing semantic units.
> >   Think about it this way - in some cases, you are not after
> >   another archetype, you just want to make sure that you build
> >   the little piece of the current archetype inn the same way
> >   as you did last time, without missing a term.
> >
> >
> > Agree, but shouldn't there be some way to link the "copies" with each
> > other, because they _will not_ be the same data if they don't have the
> > same archetype path? How should we know if we already entered similar
> > values in another archetype, possibly even found in another template
> > than the current one? There should be some way of linking values
> > together. Can it be done at the template level or must it be done at
> > an even higher level, i.e. in business logic of the GUI in the EHR
> system?
> not sure what you mean here. If I make a copy of a piece of an archetype
> that is in some "archetype fragment library" into archetype A and
> archetype B, these two archetypes will have the correct archetype paths
> according to where the fragment was put. When you say "data" and
> "values" are you talking about when the archetypes are used at runtime
> to create EHR data?


Archetype A and archetype B will have 'correct archetype paths according to
where the fragment was put', but will they refer to the same paths? When I
talked about data I meant what was stored in the EHR system and when I
talked about values I meant what was entered in the template.

I tried to ask if there is some way to make two or more archetypes
manipulate exactly the same data in an EHR system, meaning that the
archetypes probably must refer to the same paths - otherwise the data will
be manipulated at different places and the system must know that the data at
the different places are actually the same. Consider this example:

Archetype A is used in a template to create data about a patient's weight
and archetype B is used in another template and will also create data about
the weight. However, if the weight data was already entered in the EHR
system, is there a way (to create archetypes) which make the system know
that it deals with the same data no matter if it came from archetype A or
archetype B and fetch the last entered value to any of the templates that
need the weight information?

>
> > I will probably make it possible in the Java archetype editor to copy
> > definition nodes between different instances of the program, but that
> > is just a start. The ideal would be to support imports of nodes found
> > in the definition of several selected archetypes...
> it might - but I wouldn't rush with too much new functionality. There
> are other priorities in my opinion, such as:
>
> * getting a testing programme going, and getting user feedback
> * connecting the editor to openEHR and other terminologies (such as
>   an instance of the Ocean Terminology Server, designed specifically
>   for archetype linking to Snomed and other terminologies)


Yes, of course there are more important things like these to prioritise
first.

> Yes, this condition would of course only be added in the template
> > since it is not a global requirement (however there may be such also),
> > but the invariants seem to have a lot of potential and would
> > significantly aid decision support.
> they will, but they are harder to process - we need to get more people
> using the tools for now with the basic functionality, and invariants
> developing more slowly as the user community starts to understand what
> it really wants to do with them.


Agree. I also must point out that I meant data entry support above, and not
decision support.

>> Another feature is value reporting, which should work when we use
> >> several archetypes in an openEHR template. For example if some
> >> question was answered in one archetype, then 

Archetype questions

[Mattias Forss]

2006/11/13, Rong Chen :
>
>
> I am not sure if it's safe to allow cross-use of internal archetype nodes
> for data entering. A better approach in my view is to separate the common
> archetype node into a standalone archetype and include it in other archetype
> or template.
>
> For read-only purpose, DV_EHR_URI is perhaps a solution.
>

Good answer Rong. There should probably only exist one archetype for data
creation of specific nodes and URIs can be used to get certain values if
needed, for example if the BMI is entered with another template that uses
weight data of a patient. However, some archetype authors might not
understand this idea and must probably be trained in archetype modeling. The
higher quality archetypes there exist, the better the EHR systems will
perform.

Mattias

Cheers,
> Rong
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Archetype questions

[Mattias Forss]

2006/11/13, Thomas Beale :
>
>
> Hi Matiass,
>
> Mattias Forss wrote:
> >
> > Archetype A and archetype B will have 'correct archetype paths
> > according to where the fragment was put', but will they refer to the
> > same paths? When I talked about data I meant what was stored in the
> > EHR system and when I talked about values I meant what was entered in
> > the template.
> >
> > I tried to ask if there is some way to make two or more archetypes
> > manipulate exactly the same data in an EHR system, meaning that the
> > archetypes probably must refer to the same paths - otherwise the data
> > will be manipulated at different places and the system must know that
> > the data at the different places are actually the same. Consider this
> > example:
> >
> > Archetype A is used in a template to create data about a patient's
> > weight and archetype B is used in another template and will also
> > create data about the weight. However, if the weight data was already
> > entered in the EHR system, is there a way (to create archetypes) which
> > make the system know that it deals with the same data no matter if it
> > came from archetype A or archetype B and fetch the last entered value
> > to any of the templates that need the weight information?
> Ah, I understand where you are coming from now. Archetypes and templates
> don't know anything about which data instances they have created; it is
> the other way round. A given template could be used to create 20
> measurements of weight of the patient, which might be reasonable if the
> patient happens to be an infant, the measurements might be every few
> weeks from birth for say 18 months. The data of each of those 20
> measurements (Observations inside distinct Compositions) knows that such
> and such an archetype and template was used to create the data. So if
> the application retrieves one of the older measurements, the kernel will
> know which archetypes and template to apply, However, this would not
> occur unless someone was correcting wrongly entered values; normally
> previous data are just viewed, e.g. in a graph or similar, which doesn't
> require the kernel, just archetype-aware display components.


Yes, I knew that. There seems to be some options when archetypes need to
reference the same kind of information to be entered in an EHR, e.g. slots,
specialisations, etc. Some EHR data should probably be limited to be created
in only one archetype if it's concerning the same finding context in a
domain. In addition, if data spreads over several areas of findings, single
nodes from archetypes should probably not be reused and instead they should
exist in several archetypes since finding procedures may change in certain
domains and make the originally referenced nodes incompatible.

Regards,

Mattias

There is also a question of whether certain data could be compatible
> with more than one template or archetype. It can certainly be compatible
> with more than one template, since templates re-use archetypes. It can
> also be used with parents of specialised archetypes. We have already
> tested ,more generic archetypes (and no archetypes) being used with data
> archetyped with specific specialised archetypes, and it works fine for
> display.
>
> does this help?
>
> -  thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/7114dfd2/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Archetype questions

[Mattias Forss]

2006/11/13, Thomas Beale :
>
> Mattias Forss wrote:
> >
> >
> >
> >
> > Yes, I knew that. There seems to be some options when archetypes need
> > to reference the same kind of information to be entered in an EHR, e.g
> > . slots, specialisations, etc. Some EHR data should probably be
> > limited to be created in only one archetype if it's concerning the
> > same finding context in a domain. In addition, if data spreads over
> > several areas of findings, single nodes from archetypes should
> > probably not be reused and instead they should exist in several
> > archetypes since finding procedures may change in certain domains and
> > make the originally referenced nodes incompatible.
> this is our experience so far, and we have to learn (as technical
> people) to really trust the experience of clinical people, not think we
> know too much about real archetypes. The vision of archetypes is really
> about empowering domain users, and sometimes it can feel odd to be told
> we engineers don't quite know what we are talking about. I see it as a
> sign of a successful future for information systems development.


I totally agree with this.

Mattias

- thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061113/01487297/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML archetypes

[Mattias Forss]

Hi,

I am doing some experiments on a XML serializer for the Java archetype
editor. I wonder if there are any example XML archetypes that I can look at
to verify that I follow the XML-schema documentation correctly?

Regards,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] XML serializer (retry due to too large message)

[Mattias Forss]

Hi all,

I've just finished implementing an XML serializer. I have followed the XML
schema specifications carefully, but I've deviated from some parts,
particularly the ontology section. In the terms element (defined as 
ARCHETYPE_TERM<http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-47810521.html>
[1..*])
found in language_set of term_definitions and constraint_definitions I found
the definition of ARCHETYPE_TERM (found here:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-47810521.html)
to be a little bit strange. You will see that the items element has a
hashTableStringString, but I think the entire items element should be
replaced with 
dictionaryItem<http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h776235118.html>
[1..*]
or something similar, since there is no need to have a hashTableStringString
when there is only one local definition per at/ac-code.

However, I am not sure if I have followed the specifications correctly in
some cases - for example when printing the hashTableStringString in the
description part. Have a look at my example below and at the specification
and provide me with feedback if something is wrong. If there are many
errors, maybe the XML specifications should be clarified ;-) I hope to
contribute with the XMLSerializer component to the openEHR Java reference
implementation.

I also found some other issues in the XML specification, e.g. spelling
mistakes etc., which I will provide in another mail. When I went through the
specification I started thinking that some things probably could be made a
bit more compact. Why not include rm_type_name, node_id/cardinality as
attributes in the parent element instead of separate elements. This will
make the XML archetypes slightly smaller...


Example of openEHR-EHR-OBSERVATION.height.v1

XML: http://www.imt.liu.se/~matfo/openEHR-EHR-OBSERVATION.height.v1.xml
ADL: http://www.imt.liu.se/~matfo/openEHR-EHR-OBSERVATION.height.v1.adl

Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061116/f0ebd4e6/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML serializer (retry due to too large message)

[Mattias Forss]

Hi Andrew,

I looked at your example and I think it could be a good way to use xsi:type
to indicate sub-types where the number of children elements are specified
to be only one. This will mean that we don't need to add an extra
sub-element, e.g.  (details
here:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h439624612.html).
However, I don't think the XML schema specification of the AOM explicitly
state that xsi:type should be in XML archetypes. I would appreciate if
openEHR published some XML archetypes that exemplified the standard way to
express them. I don't like the idea of having several ways of representing
archetypes in XML so it would be nice if some examples were out to lead the
way.

When there are more than one child inside an element, the idea with
xsi:type requires us to repeat the container element for each child instead
of placing all children inside a single container element, so you have

 
...
...
...


instead of


...

...
...



The first example is of course more compact, but the element name "children"
doesn't make sense, since it doesn't contain all of the attribute's
children. The second example will collect all the children in one single
container element, but again, I don't know what the specification mean with
the occurrences brackets, e.g. what does [0..*] refer to in 
C_OBJECT
[0..*]
? Does it refer to the  element or to the C_OBJECT element? This
should be clarified. I have been dealing a lot with ADL and I can say that
the second example seems more plausible to me and I see the children element
equal to an attribute's "matches {}" in ADL.

Any thoughts about this?

Regards,

Mattias

2006/11/16, Andrew Patterson :
>
> Hi Mattias, I've attached my attempt at a serialized adl instance -
> perhaps
> we can converge on a consensus as to what they should look like!
>
> Mine is incomplete - especially around the ontology section - but I have
> done the attributes and children nodes differently, using xsi:type to
> indicate the sub-type. This is similar to the way Sam did the reference
> model serializations I saw, so I thought similar techniques would be
> applied here.
>
> Anyhow, I'm off on another project for a few weeks, but I thought I'd
> send you this instance as food for thought.
>
> Andrew
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: XML serializer (retry due to too large message)

[Mattias Forss]

Hi Heath,

I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members' in
the AOM (since I know the AOM very much in detail), but it's not in the XML
schema specification. I have not followed the AOM, because I thought I was
only supposed to look at the schema. Here's the XML schema and XML instance
of C_MULTIPLE_ATTRIBUTE with the property 'children' and not 'members' as in
the AOM:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h783584366.html
.
If you could explain a bit more which strategy I should use when generating
XML instances I would be very grateful. It seems you suggest I should follow
the AOM more closely instead of the XML schema of AOM and its instance
representations.

By the way, your second example representation of 'members' is similar to
Andrew's example and not mine. I have one container element
called 'children', but no xsi:type specified. Where do you get the 
element name from? I can't find it neither in the XML schema nor the AOM.

Regards,

Mattias

2006/11/17, Heath Frankel :
>
>  Mattias,
> You don't seem to follow the AOM when generating your XML instances.  For
> example, the C_MULTIPLE_ATTRIBUTE class has a property of 'members' which is
> a list of C_OBJECT.  This property name should be used in the XML instance
> so you would get:
>
>  
> 
> ...
> ...
> 
> 
>
> The alternative is to have the following but I suggest that members is not
> quite right similar to your use of children below.
>
>   
> ...
> ...
> 
>
> I would also suggest that we should follow the AOM more closely and use an
> existence element rather than minOccurs and maxOccurs.  What you are doing
> by using the later is mimicking ADL rather than following the AOM.
> Therefore you would get by following based on the openEHR RM for the
> Interval type.
>
>   
>  
> 1
> 1
> ...
> 
> 
> ...
> ...
> 
> 
>
> Regards
>
> Heath
>
>  --
> *From:* openehr-technical-bounces at openehr.org [mailto:
> openehr-technical-bounces at openehr.org] *On Behalf Of *Mattias Forss
> *Sent:* Friday, 17 November 2006 8:16 AM
> *To:* For openEHR technical discussions
> *Subject:* Re: XML serializer (retry due to too large message)
>
>
>  Hi Andrew,
>
> I looked at your example and I think it could be a good way to use
> xsi:type to indicate sub-types where the number of children elements
> are specified to be only one. This will mean that we don't need to add an
> extra sub-element, e.g. 
> (details here:
> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h439624612.html).
> However, I don't think the XML schema specification of the AOM explicitly
> state that xsi:type should be in XML archetypes. I would appreciate if
> openEHR published some XML archetypes that exemplified the standard way to
> express them. I don't like the idea of having several ways of representing
> archetypes in XML so it would be nice if some examples were out to lead the
> way.
>
> When there are more than one child inside an element, the idea with
> xsi:type requires us to repeat the container element for each child instead
> of placing all children inside a single container element, so you have
>
>   maxOccurs="1">
> ...
> ...
> ...
> 
>
> instead of
>
>  maxOccurs="1">
> ...
> 
> ...
> ...
> 
> 
>
> The first example is of course more compact, but the element name
> "children" doesn't make sense, since it doesn't contain all of the
> attribute's children. The second example will collect all the children in
> one single container element, but again, I don't know what the specification
> mean with the occurrences brackets, e.g. what does [0..*] refer to in
>  
> C_OBJECT<http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-1665829344.html>
>  [0..*]
> ? Does it refer to the  element or to the C_OBJECT element? This
> should be clarified. I have been dealing a lot with ADL and I can say that
> the second example seems more plausible to me and I see the children element
> equal to an attribute's "matches {}" in ADL.
>
> Any thoughts about this?
>
> Regards,
>
> Mattias
>
> 2006/11/16, Andrew Patterson :
> >
> > Hi Mattias, I've attached my attempt at a seri

XML serializer (retry due to too large message)

[Mattias Forss]

2006/11/17, Andrew Patterson :
>
> > I know that the C_MULTIPLE_ATTRIBUTE class has a property of 'members'
> in
> > the AOM (since I know the AOM very much in detail), but it's not in the
> XML
> > schema specification. I have not followed the AOM, because I thought I
> was
> > only supposed to look at the schema.
>
> The AOM is at fault in this instance - the AOM has a field defined in
> C_ATTRIBUTE called 'children', and then proceeds to rename this field
> to 'attributes' and 'members' in the two subclasses C_SINGLE_ATTRIBUTE
> and C_MULTIPLE_ATTRIBUTE. This of course is not really implementable
> in any OO style language or XML.. the XML schema does the correct
> thing and just defines 'children' in the base C_ATTRIBUTE class.


No, it proceeds to rename this field to 'alternatives' (not attributes) and
'members'.

I agree, that it's not OO style, but why isn't it implementable in XML? XML
isn't OO, it's just a way of storing structured information, and the guys
building the XML parsers to create the AOM objects again can probably deal
with that. But since the AOM is OO I guess it wouldn't be a bad idea if the
contents of the XML instances were in OO style.

Mattias

I have followed the XSD exactly in my serialization.. I believe the
> intention is that the archetype XSD reflects the AOM model 1:1
> (as much as possible). I see the archetype XSD as a formal
> definition of the cotnent of the AOM document.
>
> Andrew
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML serializer (retry due to too large message)

[Mattias Forss]

Heath, I must say that I have come to agree with you (and Andrew concerning
the repeating of 'children' for multiple children) - but lets hear what Sam
has to say about the changes you propose.

Mattias

2006/11/17, Heath Frankel :
>
>  Mattias,
> Sorry, I didn't realise this schema was available (I overlooked your
> reference to it in your original email).  OK, so based on this schema the
> instance is similar to my second example (but using children as the element
> name rather than members) and your first example, which neither of us like
> due to the plural nature of the element name for a singular element.  I
> think we need to pass this feedback on to Sam and see if we can ensure that
> the schema fully reflects the Reference Model including element names that
> reflect model attribute names such as members and existence.
>
> The usual way a list is represented is a container with multiple items,
> this is how I came up with this representation of a members element with
> item child elements.  You are right in stating that this is not in the XML
> schema or AOM, I was looking at this from first principles.
>
> Looking deeper into how the openEHR RM XML schemata represent containment,
> I find that it has used the pattern suggested in the Archetype XML
> schema.  For example SECTION has element called items that is repeatable.  I
> guess we need to continue with that pattern unless we change the openEHR RM
> XML schemata as well.  The problem with changing this is that the openEHR
> paths are designed to be compatible with XPath and converting a path such as
> /content[openEHR-EHR-SECTION-findings.v1]/items[
> openEHR-EHR-OBSERVATION-laboratory.v1] into XPath and evaluating it will
> expect to have an XML element called items within an element called content.
>
> Therefore I suggest that based on the current XML schema your instance
> should look like your first example:
>
>   maxOccurs="1">
> ...
> ...
> ...
> 
>
> However, I would advocate that we should submit a change request to change
> the schema to use the element name of members rather than children.  There
> are probably other AOM alignments required.
>
> Additionally I would like to see the use of an existence element of type
> INTEGER_INTERVAL (i.e. INTERVAL) rather than minOccurs &
> maxOccurs.  Thoughts?
>
> Heath
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML serializer (retry due to too large message)

[Mattias Forss]

Well, I'm no expert on XSD since I never cared about learning it... but if I
go back to your example, why didn't you use xsi:type in some places, for
example:


   
...

Is you used it here it would be:



 ...


Regards,

Mattias

2006/11/17, Andrew Patterson :
>
> Mattias,
>
> the usage of xsi:type is solely because object hierarchies are being
> used in the AOM. Using xsi:type allows serializers to know the type
> they are getting before having to parse it in.. however, even without
> xsi:type, your serialization would still not be correct for the xsd
> given (i.e. let us pretend there is only a C_ATTRIBUTE, with no
> subclasses). Any reference to an element of type C_ATTRIBUTE
> in xml should result in an xml entry named by the 'element with
> type C_ATTRIBUTE' i.e. 'children'. You never put type names into
> the actual xml instances, merely element names. And for sequences,
> this means repeating the xml entry name 'children' (augmented in
> this case by an xsi:type to help with the subclasses).
>
> Andrew
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML serializer (retry due to too large message)

[Mattias Forss]

All right then, so now I know how I should proceed. Thank you very much for
your help. It was a lot faster to understand the schema by your input rather
than starting to read some XSD documentation.

Regards,

Mattias

2006/11/17, Andrew Patterson :
>
> > go back to your example, why didn't you use xsi:type in some places, for
> > example:
> >
> > 
> > 
> >  ...
> >
> > Is you used it here it would be:
> >
> > 
> > 
> >  ...
>
> because there are no doubts about the actual type of
> 'description' (i.e. it has no subclasses), when the
> serialiazer gets to the 'description' node. it knows
> what to expect. If we had a RESOURCE_DESCRIPTION_EXTENDED
> complexType that was based on RESOURCE_DESCRIPTION,
> then we would need to use xsi:type.
>
> Andrew
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML serializer (retry due to too large message)

[Mattias Forss]

2006/11/17, Heath Frankel :
>
> > The AOM is at fault in this instance - the AOM has a field
> > defined in C_ATTRIBUTE called 'children', and then proceeds
> > to rename this field to 'attributes' and 'members' in the two
> > subclasses C_SINGLE_ATTRIBUTE and C_MULTIPLE_ATTRIBUTE. This
> > of course is not really implementable in any OO style
> > language or XML.. the XML schema does the correct thing and
> > just defines 'children' in the base C_ATTRIBUTE class.
> >
> > I have followed the XSD exactly in my serialization.. I
> > believe the intention is that the archetype XSD reflects the
> > AOM model 1:1 (as much as possible). I see the archetype XSD
> > as a formal definition of the cotnent of the AOM document.
> >
> Oh, so that's why I got confused why members was implemented as a method
> rather than an attribute, I didn't make the correlation between members
> and
> children (perhaps I should have read the words rather than just the
> picture
> :>).


Oops, I also missed that it was a function :-)

Maybe the specs could distinct attributes, functions, etc with different
coloring.


In that case, the XML schema does not require a change request for this
> issue.  I would still like to explore the use of an existence element
> rather
> than minOccurs and maxOccurs attributes.  I don't see why existence and
> occurrences in C_OBJECT are treated differently.  And then I think the
> interval_of_integer type should use elements lower and upper as per the
> Interval assumed type specified in the openEHR Support package.


Agree

Mattias

Heath
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: XML serializer (retry due to too large message)

[Mattias Forss]

2006/11/17, Bert Verhees :
>
>  Bert Verhees schreef:
>
> Mattias Forss schreef:
>
>  Well, I'm no expert on XSD since I never cared about learning it...
> but if I go back to your example, why didn't you use xsi:type in some
> places, for example:
>
>  I don't know if you ever saw this site, I did, it was helpful
>
>  http://www.w3schools.com/schema/default.asp
>
> (forgot ;-)
>

Yes, the tutorials by W3 schools are nice, but most often not as detailed as
one might wish.

//Mattias

Bert
> ___
> openEHR-technical mailing list
> openEHR-technical at 
> openehr.orghttp://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061117/b24322db/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML serializer (retry due to too large message)

[Mattias Forss]

Andrew,

In your example, you have the other_contributors element even when it has no
children, but the schema specification says that it's optional, i.e.

list_of_string
[0..1].
Shouldn't you discard that element when the list of contributors is empty?

/Mattias

2006/11/16, Andrew Patterson :
>
>   
> 
> AuthorDraft
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

EHR specification

[Mattias Forss]

Hi all,

I found there is an error at page 42 in the class description of
CONTENT_ITEM in the EHR specification. As you can see in the inherit field,
the class inherits itself, but it should inherit the class LOCATABLE from
the common package instead.

Another thing I would like to be clarified is that the archetype_details
field of LOCATABLE is mandatory for all archetype root points. The
COMPOSITION and ENTRY classes have the following invariants respectively:

Is_archetype_root: is_archetype_root
Archetype_root_point: is_archetype_root

However, it should probably be pointed out that if either of the classes are
archetype root points, the archetype_details field inherited from LOCATABLE
is mandatory and must not be void. I assumed that COMPOSITON classes can be
archetype root points as well, but I am not sure of the meaning of the term.

Regards,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

List of errors in XML schema spec of AOM

[Mattias Forss]

Hi again,

As promised, I will provide a list of errors in the XML schema specification
of the AOM.

1. Element name 'rm_type_name' should be renamed to 'rm_attribute_name' for
the C_ATTRIBUTE entity so that the naming follows the AOM specification.

2. The C_ATTRIBUTE has an attribute called 'unbounded' which follows the AOM
specification the existence attribute which is an Interval, but is
it really needed in the XML spec, i.e. will there ever be a case where the
existence is unbounded?

http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-1167105029.html

3. The element name 'precedence_overriden' should be corrected to
'precedence_overridden' here
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h-223793303.html


4. There's an entity called 'C_CODED_TERM' which is a DOMAIN_TYPE, but it
should probably be renamed to 'C_CODED_TEXT'. If this is a correct
assumption, the 'reference' element should then be renamed to 'query' and
another element called 'subset' should also be added. See the specification
of C_DV_CODED_TEXT in the Archetype Profile specification here:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/am/openehr_archetype_profile.pdf.

XML spec of 'C_CODED_TERM' is found here:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h1644545557.html


5. In ADL archetypes the ontology section usually contains
'primary_language', 'languages_available', but neither of these are found in
the ARCHETYPE_ONTOLOGY entity in the XML schema spec. When looking through
the AOM specification of the ARCHETYPE_ONTOLOGY I found that these
attributes didn't exist there either - so how come the ADL archetypes
contain these attributes?. I can only guess they haven't evolved as fast as
the specifications...

Furthermore, there are two attributes in the AOM specification of
ARCHETYPE_ONTOLOGY that I couldn't find in the ADL archetypes - namely
'specialisation_depth' and 'parent_archetype'. These attributes are not
accessible from the ArchetypeOntology class in the 1.0.1-RC1 version of the
Java kernel, and the latter is not found in the XML schema spec.

See the XML schema spec of ARCHETYPE_ONTOLOGY here:
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h1873534858.html

6. All the sub-classes of C_PRIMITIVE has an attribute called
'assumed_value', but in the XML schema specs it has mistakenly been spelled
'assummed_value'.
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h1279968838.html


Regards,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML serializer (retry due to too large message)

[Mattias Forss]

2006/11/21, Sam Heard :
>
> The Ontology is so huge I have wondered about having the Text and
> Description as attributes - it would save a lot of space and I do not think
> it would complicate things at all.
>
> What do others think?
>

Sounds like a good idea as long as the two parts (text, description) of the
description items will remain. If more parts are added though, it is not a
flexible solution.

Mattias

Cheers, Sam
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: List of errors in XML schema spec of AOM

[Mattias Forss]

2006/11/21, Sam Heard :
>
>  Mattias
> Thanks - we were not really prepared for people to run with this right now
> but I include a candidate schema which is in tune with the ADL Parser and
> encorporates your observations
>
Hi Sam,

Thanks, I'll have a look at it.

> 4. There's an entity called 'C_CODED_TERM' which is a DOMAIN_TYPE, but it
> should probably be renamed to 'C_CODED_TEXT'. If this is a correct
> assumption, the 'reference' element should then be renamed to 'query' and
> another element called 'subset' should also be added. See the specification
> of C_DV_CODED_TEXT in the Archetype Profile specification here: 
> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/am/openehr_archetype_profile.pdf
> .
>
> XML spec of 'C_CODED_TERM' is found here: 
> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/its/XML-schema/documentation/Archetype.xsd.html_h1644545557.html
>
>
>  Actually the constraint required is on the CODE_PHRASE and in the new ADL
> Parser it is called C_CODE_PHRASE. This does not affect the ADL so noone
> noticed the change. The schema now has C_CODE_PHRASE instead.
>

But the C_CODE_PHRASE is _not_ a C_DOMAIN_TYPE according to the Archetype
Profile. Where can I find this class specification? If you look at the
schema you see that C_CODED_TERM inherits C_DOMAIN_TYPE...


> Furthermore, there are two attributes in the AOM specification of
> ARCHETYPE_ONTOLOGY that I couldn't find in the ADL archetypes - namely
> 'specialisation_depth' and 'parent_archetype'. These attributes are not
> accessible from the ArchetypeOntology class in the 1.0.1-RC1 version of
> the Java kernel, and the latter is not found in the XML schema spec.
>
> parent_archetype_id is part of archetype in the Schema.
>

Okay, I guess the XML schema isn't completely equal to the AOM in this case
because it would require to output yet another archetype in the
ARCHETYPE_ONTOLOGY.


> Still interested in the changing the term.text and description to
> attributes - any interest? The implementation is not given in the AOM.
>

This is found in the AOM:

items: Hash 
Hash of keys ("text", "description" etc) and corresponding values.

at page 46
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/am/aom.pdf


Cheers,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

EHR specification

[Mattias Forss]

2006/11/22, Thomas Beale :
>
> See the class LOCATABLE - you will see it has the invariant:
>
> Archetyped_valid: is_archetype_root xor archetype_details = Void
>
> this means that if is_archetype_root is True, then archetype_details /=
> Void


Ah, it says 'xor' and not 'or' :-)

Thanks,

Mattias

- thomas
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Constraint references

[Mattias Forss]

Hi all,

I'm wondering what the difference is between a CONSTRAINT_REF and a
C_DV_CODED_TEXT that has the query attribute set? The descriptions of the
two are the following:

CONSTRAINT_REF class description:
Reference to a constraint described in the same archetype, but outside the
main constraint structure. This is used to refer to constraints expressed in
terms of external resources, such as constraints on terminology value sets.

Description of query attribute of C_DV_CODED_TEXT:
Constraint in terms of an abstract query expression to be addressed to a
terminology server.

Is there a syntactic difference between the two in ADL?

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Regular expressions?

[Mattias Forss]

Hi,

I have noticed that instruction archetypes have different ways of adding
constraints on archetype IDs and domain concepts. Here's an example:

INSTRUCTION[at] matches {-- Imaging request
activities cardinality matches {0..*; unordered} matches {
ACTIVITY[at0001] occurrences matches {1..*} matches {--
Imaging activity
action_archetype_id matches {"/imaging\.v1/"}
description matches {
allow_archetype ITEM_TREE occurrences matches {0..1}
matches {
include
domain_concept matches {/imaging.v1/}
exclude
domain_concept matches {/.*/}
}
}
}
}
}

As you can see for the action_archetype_id the leaf constraint is
"/imaging\.v1/" which will correspond to a C_STRING. However, since we have
the
quotation marks the Eiffel parser will probably just add /imaging\.v1/ into
the list of the C_STRING (the Java parser will not even parse this, and
fails when it detects the escape character, i.e. \ ).

What I think we want to achieve here is to set the pattern attribute of
C_STRING. Here's a description of the pattern attribute:

pattern: String Regular expression pattern for proposed instances of String
to match.

Now to do this we must remove the quotation marks which gives us:

/imaging\.v1/ which works in the Java parser and sets the pattern attribute
of the CString class.

Now the leaf constraint of action_archetype_id will be more similar to the
archetype slot includes and excludes. However, you will see one difference.
In the include slot (/imaging.v1/) the dot is not escaped, which in regular
expressions means it will match any character and not just the dot, for
example an archetype with the domain concept imagingav1 would be perfectly
legal.

Another issue is whether action_archetype_id should have a regular
expression that matches a domain concept (for any kind of archetype) or if
the regular expression in this case actually should be extended to
/openEHR-EHR-ACTION\.imaging\.v1/ ? I think it would be good if the regex
always started with openEHR-EHR-ACTION in this case, but maybe the
distinction can be made when the rm objects are built...

Hope to sort this out.

Regards,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Release of Java Archetype Editor v0.4

[Mattias Forss]

Dear all,

The Java Archetype Editor v0.4 has now been released. Both the binary
and the source code is available for download here:
http://www.imt.liu.se/mi/ehr .

Please take your time to read the release notes before installing the program.

The Archetype Editor was developed within the framework of the
EU-funded Network of Excellence entitled Semantic Interoperability and
Data Mining in Medicine. Read more about Semantic Mining at
http://www.semanticmining.org .


Best regards,

Mattias Forss via the Medical Informatics Group,
Department of Biomedical Engineering,
Link?ping University, Sweden

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Archetype blood_pressure: Data <-> State <-> Protocol - correlation

[Mattias Forss]

2006/10/8, Sam Heard :
>
>  Christoph
>  Some things have been around for a long time in our development and one was
> to have state defined at the root level even though it applied to each
> event. The current editor should read both but saves the correct version.
>  The result is attached, Sam

I should point out that the embedded state within each event isn't
supported by the Java Archetype Editor (only separate state with
history), but a new version that supports this will probably be out
soon...

Actually, when the Java editor finds a state defined at the root level
it is transformed to a state with history because that is the closest
thing it resembles.

/Mattias
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Archetype blood_pressure: Data <-> State <-> Protocol - correlation

[Mattias Forss]

2006/10/9, Mattias Forss :
> 2006/10/8, Sam Heard :
> >
> >  Christoph
> >  Some things have been around for a long time in our development and one was
> > to have state defined at the root level even though it applied to each
> > event. The current editor should read both but saves the correct version.
> >  The result is attached, Sam
>
> I should point out that the embedded state within each event isn't
> supported by the Java Archetype Editor (only separate state with
> history), but a new version that supports this will probably be out
> soon...
>
> Actually, when the Java editor finds a state defined at the root level
> it is transformed to a state with history because that is the closest
> thing it resembles.
>

Another question related to this. Is there any need in an archetype
editor to specify different data and state for some events instead of
always creating them in the first event in the history and then let
all the succeding events reference (use_node) the data and state in
the first event? If a user decides to edit ADL manually and sets
different data and state for some events, it is not supported by
neither of the current archetype editors...

/Mattias
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Archetype blood_pressure: Data <-> State <-> Protocol - correlation

[Mattias Forss]

2006/10/11, Thomas Beale :
> Mattias Forss wrote:
> > 2006/10/9, Mattias Forss :
> >
> >> 2006/10/8, Sam Heard :
> >>
> >>>  Christoph
> >>>  Some things have been around for a long time in our development and one 
> >>> was
> >>> to have state defined at the root level even though it applied to each
> >>> event. The current editor should read both but saves the correct version.
> >>>  The result is attached, Sam
> >>>
> >> I should point out that the embedded state within each event isn't
> >> supported by the Java Archetype Editor (only separate state with
> >> history), but a new version that supports this will probably be out
> >> soon...
> >>
> >> Actually, when the Java editor finds a state defined at the root level
> >> it is transformed to a state with history because that is the closest
> >> thing it resembles.
> >>
> >>
> >
> > Another question related to this. Is there any need in an archetype
> > editor to specify different data and state for some events instead of
> > always creating them in the first event in the history and then let
> > all the succeding events reference (use_node) the data and state in
> > the first event? If a user decides to edit ADL manually and sets
> > different data and state for some events, it is not supported by
> > neither of the current archetype editors...
> >
> In general this should not happen, since the phenomenon being recorded
> in each event is supposed to be the same one, just at different time-points.

Just what I suspected. Thanks

Mattias
>
> - thomas beale
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

a zero existence constraint

[Mattias Forss]

How about specialised archetypes? Wouldn't there be occasions when a
parent archetype has some attribute, which a child (specialisation) of
that archetype don't want to deal with?

Mattias

2006/10/25, Sam Heard :
>
>  This is not sensible to have in an archetype - otherwise it would not be
> there! It is a requirement for templates in use.
>  Sam
>
>
>  Thomas Beale wrote:
>  Andrew Patterson wrote:
>
>
>  For the case where an attribute is constrained to '0'
> existence i.e.
>
> state existence matches {0} .
>
> what should follow as the rest of the attribute
> constraint? Technically, the rest of the definition
> is superfluous as we have already stated that the
> attribute must not exist, but the
> 'matches' clause needs to exist in the grammar. Should
> it be matched to *, or should it be empty?
>
> state existence matches {0} matches {*}
>
> or
>
> state existence matches {0} matches {}
> (I'm not sure the grammar allows this)
>
>
>  we certainly have not allowed for it yet; indeed, no-one has ever wanted
> to do it in an archetype, it has only come up as a need in templates
> (which simply quote path names and then add an existence constraint).
>
> Possible responses that come to mind:
> - in openEHR we try never to include a feature that is not justified by
> at least one known use case. So we should try to find a real use case
> before doing anything.
> - there is in fact already a way to do this: by adding an invariant to
> an archetype of the form
>  not exists (/path/to/some/attribute/that/we/dont/want)
> - if we had to add more syntax to the cADL part of ADL, I would probably
> opt for the second proposal above.
>
> Buta credible use case needs to be found first.
>
> - thomas beale
>
>
>  Andrew
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
>
>
>
>
>
> --
>
> Dr. Sam Heard
>  MBBS, FRACGP, MRCGP, DRCOG, FACHI
>
> CEO and Clinical Director
>  Ocean Informatics Pty. Ltd.
>  Adjunct Professor, Health Informatics, Central Queensland University
>  Senior Visiting Research Fellow, CHIME, University College London
>  Chair, Standards Australia, EHR Working Group (IT14-9-2)
>  Ph: +61 (0)4 1783 8808
>  Fx: +61 (0)8 8948 0215
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

ISM_TRANSITION

[Mattias Forss]

Hi,

I started wondering about different representations of ISM_TRANSITIONs of
the ism_transition attribute in the ACTION archetypes. I found that the
below example:

ISM_TRANSITION matches {
current_state matches {
CODED_TEXT matches {
code matches {[openehr::524]}
}
}
careflow_step matches {
CODED_TEXT matches {
code matches {[local::at0001]}-- Planned
}
}
}
ISM_TRANSITION matches {
current_state matches {
CODED_TEXT matches {
code matches {[openehr::524]}
}
}
careflow_step matches {
CODED_TEXT matches {
code matches {[local::at0004]}-- Requested
}
}
}

could be compressed into this:

ISM_TRANSITION matches {
current_state matches {
CODED_TEXT matches {
code matches {[openehr::524]}
}
}
careflow_step matches {
CODED_TEXT matches {
code matches {[local::at0001, -- Planned
   at0004]} -- Requested
}
}
}

The examples have the same semantic meaning. However, at data entry the
second example would mean that a choice must be made concerning the
careflow_step, i.e. either at0001 or at0004. Should the archetype editors
support both examples? The first example is the only one I've seen in
archetypes...

Regards,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

ISM_TRANSITION

[Mattias Forss]

Hi again,

I should probably also mention that we need some document that provides
recommendations about how archetypes should be created when there are more
than one way to do it like the example below. Otherwise there is a risk that
there are too many archetypes with different representations that
essentially mean the same thing.

The rules that Thomas talked about in this thread
http://www.openehr.org/advice/implementers-priv/msg00311.html , i.e.

- if there is a plug-in C_DOMAIN_TYPE type available, always use it to
represent constraints for the corresponding RM type
- if there is a syntax equivalent for this type, then use it
- otherwise use generic ADL


Should also be documented somewhere.

Regards,

Mattias

2006/10/31, Mattias Forss :
>
> Hi,
>
> I started wondering about different representations of ISM_TRANSITIONs of
> the ism_transition attribute in the ACTION archetypes. I found that the
> below example:
>
> ISM_TRANSITION matches {
> current_state matches {
> CODED_TEXT matches {
> code matches {[openehr::524]}
> }
> }
> careflow_step matches {
> CODED_TEXT matches {
> code matches {[local::at0001]}-- Planned
> }
> }
> }
> ISM_TRANSITION matches {
> current_state matches {
> CODED_TEXT matches {
> code matches {[openehr::524]}
> }
> }
> careflow_step matches {
> CODED_TEXT matches {
> code matches {[local::at0004]}-- Requested
> }
> }
> }
>
> could be compressed into this:
>
> ISM_TRANSITION matches {
> current_state matches {
> CODED_TEXT matches {
> code matches {[openehr::524]}
> }
> }
> careflow_step matches {
> CODED_TEXT matches {
> code matches {[local::at0001, -- Planned
>at0004]} --
> Requested
> }
> }
> }
>
> The examples have the same semantic meaning. However, at data entry the
> second example would mean that a choice must be made concerning the
> careflow_step, i.e. either at0001 or at0004. Should the archetype editors
> support both examples? The first example is the only one I've seen in
> archetypes...
>
> Regards,
>
> Mattias
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061031/acd0c4b4/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Archchetype editor on Linux --help

[Mattias Forss]

2006/9/2, Bert Verhees :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Mattias Forss schreef:

> > We used (and modified) parts of the code from the existing editor
> > which was used as a facade against the openEHR archetype object model
> > since that model is immutable. On the other hand, I don't think that
> > this code is easy to understand even if you understand the API for the
> > Java kernel. When we open source the code for the editor I suppose
> > there might be questions if the facade code is worth using anymore or
> > if it should be replaced with a better API that could be used as a
> > facade for the archetype object model.
>
> I don't know what you mean in this, I think the best way to write a
> archetype editor is to directly use the java-kernel-code.
> I see some people want to rewrite the adl-parser, but, in fact the
> adl-parser is in its source quite clear and good.

We cannot use the kernel code directly unless we make changes to it to
be mutable (changeable). The reason for this is because whenever you
want to alter things, the Archetype object has to be rebuilt all over
again because it is not allowed to be changed. Using the kernel code
directly and rebuilding every time some small thing has changed would
be very slow (especially very slow response in the GUI). However, I've
heard of a new technique that could be used in Java to be able to do
this a lot faster, but I'm not sure if it will solve all the problems
in this case.

>
> For me it is necessary to work also outside the reference model, but in
> ADL. It is a bit complicated to explain, Maybe read my previous mails.
>
> So I need a archetype-editor which loads ADL-files, and does not enforce
> or check the referene model. I translate HL7 XSD-files directly to ADL,
> that is to say, I am working on that, and the improvements give hope.
>
> The thing I miss is to viualize my ADL-files, so I have to check/debug
> them manually, which is hard. I could use the code of the archetype
> editor to change it for my needs, maybe it is not hard to do, but maybe
> it is, as I read about ugly code now.

This would require a feature in the editor to chose an "unknown"
reference model (which you can give a name) and maybe also specify
that reference model's semantics. It could be really messy working
with unknown reference models, and hard to come up good ways to
display things in a GUI. Since any rm type name can really constrain
any data type (text, boolean, date) even things there aren't any
corresponding controls for.

I have almost finished implementing an ADL-editor, (in the formats
view of the archetype editor) which could be used to edit whatever the
parser accepts, but whenever the ADL is reloaded in the GUI, all
things not corresponding to the openEHR RM (and things that aren't
recognized as editable in the GUI) will disappear. I believe you could
use this ADL-editor as a start, since it marks the line number that
the parser fails on, but the downside is of course that you would have
to do things manually. On the other hand, I don't think it's easy to
create efficient GUIs for unknown reference models, since class and
attribute names always have to be specified, unless of course one
creates a really smart GUI that follows defined RM semantics which
configures the widgets' functionality.

Regards,

Mattias

>
> Except from my needs, which is at this moment, get a certain HL7 DMIM
> into ADL, I would think it is a good thing when a ADL-editor has a
> possibility for not to enforce the OpenEHR reference model. With all
> respect to the design of that model (clever people work hard on it. I
> sure want to follow that in the near future), I think it can be good if
> it is possible if people have good reasons to do something else with
> ADL, to facilitate that.
>
> So in this context, I think publishing the code will be very good. I
> hope it will be done in short time.
>
> regards
> Bert Verhees
>
>
> >
> >> 2006/8/28, Bert Verhees :
> >>>
> >>> > There is already a Java-based archetype editor available here:
> >>> >
> >>> > http://svn.openehr.org/knowledge/archetypes/dev/index.html
> >>>
> >>> Too bad, the sourcecode still is not published (last time I
> >>> downloaded
> >>> it), I would like to see some improvements in (f.e.) error-handling.
> >>> It
> >>> does never say why I ADL-file cannot be loaded, it just says it
> >>> cannot
> >>> load it. There are many ADL-files, which it does not load, and I
> >>> think
> >>> for
> >>> good reasons, but it should say why. If it had sourcecode with it, I
> >>

Normal and other ranges

[Mattias Forss]

2006/9/20, Gerard Freriks :
>
> Hi,
> I'm not a pathologist.
> But was a GP.
>
> As GP I'm not interested in an arbitrary classification.
> What is minimally necessary are: the value, the units of measurement and
> the normal range as used in that lab for that measurement at that time.
> What is handy (optional) and only for signalling a human reader, and NOT
> for computer semantic processing, are: a Flag that a value is out of range,
> and a comment/advice/interpretation provided by the lab.
>


What about decision support software?

/Mattias

"Value" is not always a series of digits. It can be an ordinal. It can be
> text.
>
> Gerard
>
> --   --
>
> Gerard Freriks, arts
>
> Huigsloterdijk 378
>
> 2158 LR Buitenkaag
>
> The Netherlands
>
>
> T: +31 252 544896
>
> M: +31 653 108732
>
>
>
>
> On 20-sep-2006, at 0:27, Heath Frankel wrote:
>
> So, it appears that we have no pathologists on the list to comment on the
>
> standardisation of these codes.  I guess all I can suggest is that these
> are
>
> standard codes as per the HL7 V2.x standard but the interpretation of
> using
>
> them is unlikely to be but it is just that we are looking the capture and
>
> not loose in the translation from HL7 message to openEHR.  Having said
> that,
>
> in Australia it is common practice by labs to use three levels of
>
> abnormality (i.e. HHH & LLL(.
>
>
> Would an alternate approach be to include an additional element in the
>
> Archetype to store this abnormality flag rather than including it in the
>
> DV_ORDERED?
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

the periodic definition in data structures IM

[Mattias Forss]

2006/9/26, Thomas Beale :
>
> I have improved the documentation in the class definitions, and added
> the following invariant to History:
>
> period_consistency: is_periodic implies events.for_all (e: EVENT |
> e.offset.to_seconds.mod(period.to_seconds) =
> e.offset.to_seconds/period.to_seconds)


Hi Thomas,

With the risk of making a fool of my self, shouldn't a consistent period
mean that all events should have an offset to the original time of starting
the observations which is periodic? In that case, doesn't it mean that the
offset modulo the period should be zero and not offset/period? If the offset
is evenly dividable with the period, then it should mean that the event is
periodic and if all events are periodic then the period for the history is
consistent.

Correct me if I'm wrong.

/Mattias

and added the query to_seconds: Double to the ISO8601_DURATION class in
> the Support IM package.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Preprint re: SNOMED codes

[Mattias Forss]

2007/1/3, Andrew Patterson :
>
> > The system at present is performing mappings on pre-modeled archetypes
> > depriving it the luxury of having access to the author.
>
> This is what I meant by the 'split' case - a split between the
> people/group
> constructing the archetype, and the people doing the binding (in this
> Sam writing the archetype and you guys doing the terminology stuff). It
> doesn't lessen your points about the difficulties of doing the terminology
> mapping - I just wanted to clarify that the plan in the 'best case' is
> that there wouldn't be so much of a split (i.e. you'd be in communication
> with the people writing the archetype, or it would all be done within one
> tool by the same author)
>
> >  I agree that this URL feature sounds a bit complex. Not having complete
> > knowledge of the Ocean methodology and objective makes it rather
> difficult
> > to comment though. However, 'is_a' trees are only part of the solution
> to
> > the binding/mapping process. There are a few archetypes that have 'is_a'
> > terms and can be dealt with in a less complex way i.e. without the use
> of
> > URL's.
>
> Other than actually enumerating the term codes in the ADL file, what other
> mechanism is there other than URLs?
>
> > Though am not sure whether the Ocean team had something else in mind
> > when using URLs.
>
> The URL system is not inherently bad - it solves the problem in a
> relatively clean way that allows lots of room for future developments
> in terminologies without constraining the solutions. I just worry that
> with complex terminologies like snomed being used more often
> it may be useful to have an inbetween solution i.e.
>
> simplest)
>   list of codes typed in '123123', '3242342', '123123'
> * moderate *)
>   simple langauge like "limit depth 5 (is_a('102323','arm fracture'))"
> complex)
>http://www.termserver.com/saved_query?realm=uk&concept_root=1231231



Hi,

Within our team in Link?ping we've discussed the potential of using OWL as a
query-language for constraint bindings. It might be something worth looking
into.

Regards,

Mattias
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Problem in some sample archetypes and questions

[Mattias Forss]

2007/1/8, Koray Atalag :
>
> Currently both the Editor and the
> Workbench allow these type of errors.


Hi Koray,

The latest code of the Java Archetype Editor now validates cardinalities. It
also has support for all but the demographics archetypes now. Lots of new
improvements and features have been added and version 0.5 of the editor
(including the source code) will be released before the end of this month.

Regards,

Mattias Forss
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/fd5b8126/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Problem in some sample archetypes and questions

[Mattias Forss]

2007/1/8, Thomas Beale :
>
>
> >
> > Koray Atalag wrote:
> >> QUESTION-1: What is the correct approach for above problem?
> >>
> as Sam has said your understanding is correct and the archetype is in
> error.
> >> QUESTION-2: Assume in some other place in the archetype you reference
> >> the ELEMENT node with occurences {0..8} by use_node. And in this
> >> particular place you do not want to have up to 8 instances and but also
> >> you want it to be mandatory (i.e. 1..) or even want {3..5}. What is the
> >> solution? (other than writing the whole thing once again)
> >>
> the current semantics are that the occurrences of the referenced node
> are what takes effect. However, I agree that a preferable approach would
> be if the occurrences could be overridden at the origin point of the
> use_node reference. This would not be incompatible with the current
> semantics, and would probably be a useful change. What do others think?
> [Particularly the Archetype tool authors]?


Hi Thomas,

I think it would be a good idea to let the users of the archetype editors
override occurrences of referenced nodes.

Regards,

Mattias

Note that in the AOM, an
> ARCHETYPE_INTERNAL_REF inherits occurrences from C_OBJECT, so in theory
> our archetype parsers should handle them, but I have just looked at
> mine, and it doesn't...Rong, how about the Java parser? (So much for
> having complete test archetype coverage;-)
> >> QUESTION-3: Related with second question, I also need to disallow usage
> >> of some values when referencing by use_node entries. This I believe is
> >> not an uncommon requirement in clinical medicine.For me I have an
> >> element with a long list of  values of sites of an organ (Esophagus,
> >> stomach, colon and so on) and in many places of an observation these
> >> sites repeat without change so I can reference original. But in some
> >> cases selection of certain site(s) is not logical and should better be
> >> restricted or selection of only one site makes sense. What is the
> solution?
> >>
> I actually think there are various solutions here...
> * the most obvious would be that at the point of reference, you create a
> CLUSTER node, and then individually reference the subset of paths of
> items from the target CLUSTER that you want, but not others.
> * another one would be to make a number of ITEM_TREE or ITEM_LIST
> archetype of the relevant piece of content as separate archetypes, and
> use slots to include particular subsets.
> * a third possibility is to use invariants to prevent certain paths from
> existing that would otherwise be allowed by the main part of the
> definition of the archetype.
>
> - thomas beale
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: Problem in some sample archetypes and questions

[Mattias Forss]

Hi Jose,

I don't think the meaning of the node will not change, but it depends on how
you define it. If we think of the reference node (use_node) as a shortcut to
an entry form. Also think of it as if that shortcut decided how many times
the same entry form would show up. If we override the occurrences we don't
change the meaning of the entry form.

However, if the original meaning of having for example 2 occurrences of a
node we're referencing is to enter observations about two different sites
(say internal and external) and if we are allowed to override those
occurrences, then the original purpose of the node is not fulfilled because
it allows entry to be made less or more times.

This was probably not a full answer to your question.

Regards,

Mattias


2007/1/8, Jose Alberto Maldonado :
>
> Hi all,
>
> we have a doubt regarding the possibility of overriding occurrences of
> referenced node. The main concern has to do with the fact that a occurrence
> constraint is "part" of the semantics of the node being constrained. If it
> is true, when overriding the occurrences of referenced nodes, do we change
> the meaning of the original node and therefore the description (and even
> terminology binding) might become erroneous?.
>
> best regards
>
>
>
>
> Mattias Forss escribi?:
>
>
>
> 2007/1/8, Thomas Beale :
> >
> >
> > >
> > > Koray Atalag wrote:
> > >> QUESTION-1: What is the correct approach for above problem?
> > >>
> > as Sam has said your understanding is correct and the archetype is in
> > error.
> > >> QUESTION-2: Assume in some other place in the archetype you reference
> >
> > >> the ELEMENT node with occurences {0..8} by use_node. And in this
> > >> particular place you do not want to have up to 8 instances and but
> > also
> > >> you want it to be mandatory (i.e. 1..) or even want {3..5}. What is
> > the
> > >> solution? (other than writing the whole thing once again)
> > >>
> > the current semantics are that the occurrences of the referenced node
> > are what takes effect. However, I agree that a preferable approach would
> >
> > be if the occurrences could be overridden at the origin point of the
> > use_node reference. This would not be incompatible with the current
> > semantics, and would probably be a useful change. What do others think?
> > [Particularly the Archetype tool authors]?
>
>
> Hi Thomas,
>
> I think it would be a good idea to let the users of the archetype editors
> override occurrences of referenced nodes.
>
> Regards,
>
> Mattias
>
>
> Note that in the AOM, an
> > ARCHETYPE_INTERNAL_REF inherits occurrences from C_OBJECT, so in theory
> > our archetype parsers should handle them, but I have just looked at
> > mine, and it doesn't...Rong, how about the Java parser? (So much for
> > having complete test archetype coverage;-)
> > >> QUESTION-3: Related with second question, I also need to disallow
> > usage
> > >> of some values when referencing by use_node entries. This I believe
> > is
> > >> not an uncommon requirement in clinical medicine.For me I have an
> > >> element with a long list of  values of sites of an organ (Esophagus,
> > >> stomach, colon and so on) and in many places of an observation these
> > >> sites repeat without change so I can reference original. But in some
> > >> cases selection of certain site(s) is not logical and should better
> > be
> > >> restricted or selection of only one site makes sense. What is the
> > solution?
> > >>
> > I actually think there are various solutions here...
> > * the most obvious would be that at the point of reference, you create a
> >
> > CLUSTER node, and then individually reference the subset of paths of
> > items from the target CLUSTER that you want, but not others.
> > * another one would be to make a number of ITEM_TREE or ITEM_LIST
> > archetype of the relevant piece of content as separate archetypes, and
> > use slots to include particular subsets.
> > * a third possibility is to use invariants to prevent certain paths from
> > existing that would otherwise be allowed by the main part of the
> > definition of the archetype.
> >
> > - thomas beale
> >
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
>
> --
>
> __

Problem in some sample archetypes and questions

[Mattias Forss]

2007/1/8, Koray Atalag :
>
> Mattias Forss wrote:
> > The latest code of the Java Archetype Editor now validates
> > cardinalities. It also has support for all but the demographics
> > archetypes now. Lots of new improvements and features have been added
> > and version 0.5 of the editor (including the source code) will be
> > released before the end of this month.
> Hi Mattias and others,
>
> I am sorry I did forget to specify which tools I was mentioning about,
> it is not the Java one. In fact I haven't studied the Java work yet but
> will do soon. To tell you the truth, while writing down 4 monstrous
> archetypes (each having 1500-2000 lines!), I did not use an editor -
> just the good old vi(m).


Oh, that must have taken a lot of time, but maybe you're an expert on all
the keyboard shortcuts in vi ;-)

BTW I was wondering if the Java editor supports Unicode as I desperately
> need it.


Java supports Unicode and hence the editor does. There are some issues in
the ADLSerializer and ADLParser for different encodings and ADLs which don't
have UTF-8 encoding may become scrambled on view because the ADLParser uses
Unicode and also on serialization because the ADLSerializer currently only
serializes to UTF-8. I also think there may be problems with quoted Unicode.
I think Rong Chen knows better what issues there are. The editor mainly
relies on the status of the Java reference implementation when it comes to
Unicode support.

Regards,

Mattias

Best regards,
>
> -koray
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/85a7ab90/attachment.html>
-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

[Norton AntiSpam] Re: Problem in some sample archetypes and questions

[Mattias Forss]

*Corrected first sentence*

/Mattias


2007/1/8, Mattias Forss :
>
> Hi Jose,
>
> I don't think the meaning of the node will change, but it depends on how
> you define it. If we think of the reference node (use_node) as a shortcut to
> an entry form. Also think of it as if that shortcut decided how many times
> the same entry form would show up. If we override the occurrences we don't
> change the meaning of the entry form.
>
> However, if the original meaning of having for example 2 occurrences of a
> node we're referencing is to enter observations about two different sites
> (say internal and external) and if we are allowed to override those
> occurrences, then the original purpose of the node is not fulfilled because
> it allows entry to be made less or more times.
>
> This was probably not a full answer to your question.
>
> Regards,
>
> Mattias
>
>
> 2007/1/8, Jose Alberto Maldonado :
> >
> > Hi all,
> >
> > we have a doubt regarding the possibility of overriding occurrences of
> > referenced node. The main concern has to do with the fact that a occurrence
> > constraint is "part" of the semantics of the node being constrained. If it
> > is true, when overriding the occurrences of referenced nodes, do we change
> > the meaning of the original node and therefore the description (and even
> > terminology binding) might become erroneous?.
> >
> > best regards
> >
> >
> >
> >
> > Mattias Forss escribi?:
> >
> >
> >
> > 2007/1/8, Thomas Beale :
> > >
> > >
> > > >
> > > > Koray Atalag wrote:
> > > >> QUESTION-1: What is the correct approach for above problem?
> > > >>
> > > as Sam has said your understanding is correct and the archetype is in
> > > error.
> > > >> QUESTION-2: Assume in some other place in the archetype you
> > > reference
> > > >> the ELEMENT node with occurences {0..8} by use_node. And in this
> > > >> particular place you do not want to have up to 8 instances and but
> > > also
> > > >> you want it to be mandatory (i.e. 1..) or even want {3..5}. What is
> > > the
> > > >> solution? (other than writing the whole thing once again)
> > > >>
> > > the current semantics are that the occurrences of the referenced node
> > > are what takes effect. However, I agree that a preferable approach
> > > would
> > > be if the occurrences could be overridden at the origin point of the
> > > use_node reference. This would not be incompatible with the current
> > > semantics, and would probably be a useful change. What do others
> > > think?
> > > [Particularly the Archetype tool authors]?
> >
> >
> > Hi Thomas,
> >
> > I think it would be a good idea to let the users of the archetype
> > editors override occurrences of referenced nodes.
> >
> > Regards,
> >
> > Mattias
> >
> >
> > Note that in the AOM, an
> > > ARCHETYPE_INTERNAL_REF inherits occurrences from C_OBJECT, so in
> > > theory
> > > our archetype parsers should handle them, but I have just looked at
> > > mine, and it doesn't...Rong, how about the Java parser? (So much for
> > > having complete test archetype coverage;-)
> > > >> QUESTION-3: Related with second question, I also need to disallow
> > > usage
> > > >> of some values when referencing by use_node entries. This I believe
> > > is
> > > >> not an uncommon requirement in clinical medicine.For me I have an
> > > >> element with a long list of  values of sites of an organ
> > > (Esophagus,
> > > >> stomach, colon and so on) and in many places of an observation
> > > these
> > > >> sites repeat without change so I can reference original. But in
> > > some
> > > >> cases selection of certain site(s) is not logical and should better
> > > be
> > > >> restricted or selection of only one site makes sense. What is the
> > > solution?
> > > >>
> > > I actually think there are various solutions here...
> > > * the most obvious would be that at the point of reference, you create
> > > a
> > > CLUSTER node, and then individually reference the subset of paths of
> > > items from the target CLUSTER that you want, but not others.
> > > * another one would be to make a number of ITEM_TREE or ITEM_LIST
> > > archetype of t

Error in terminology.xml?

[Mattias Forss]

Hi Bert,

Yes, I believe it should be changed. I actually made a heading change for
the subject setting in the GUI of the archetype editor when I saw that the
subject attribute of the ENTRY classes should be a PARTY_RELATED (which
represents the relation to the subject of data) and not a PARTY_SELF (which
represents the subject of data).

For some reason I never realized that the terminology.xml was wrong.

Regards,

Mattias


2007/3/16, Bert Verhees :
>
> This line is in it:
> 
>
> when you go to grouper:
> 
>
> and then to groupedconcept:
> 
> 
> 
> 
>
> etc
>
> which points to:
> 
> 
> 
> 
> etc...
> 
> I wonder if the above (first) line should be
> 
>
> because this is also in the PDF-documents: terminology.pdf page 22
> and in support_im.pdf, page: 59
>
> Thanks,
> bert
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Instruction & action archetypes?

[Mattias Forss]

Hello Erik,

I will provide you a quick answer, but I'll reply to the list so other may
comment as well.

Instructions and Actions are both entry subtypes but the difference is that
Instructions tell what the planned activities were and Actions tell which
actual actions were taken. They are meant to be recorded separately and
since the instruction state machine (ISM) used in openEHR is coded by the
support terminology the available states are static and every recorded
action will cause a care flow step to be taken (which has an optional
description) that defines a transition state in the ISM.

Also note that if the action was caused by an instruction the action will
hold instruction details that reference the instruction and activity that
was planned for the action.

Best wishes,

Mattias

2007/5/25, Erik Sundvall :
>
> Hi!
>
> Some (possibly stupid) questions:
>
> - Are there any examples of instruction archetypes with more than one
> activity anywhere?
> - If different activities (of the same instruction) point to different
> action archetypes how should then the resulting usage of the ISM be
> interpreted? Can they be considered part of the same process with some
> states in each action archetype?
>
> A swift reply to one or more of the questions would be very welcome.
>
> Best regards,
> Erik Sundvall
> http://www.imt.liu.se/~erisu/
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: