Carriage returns in DV_TEXT not allowed

[Thomas Beale]

On 10/01/2012 23:24, Colin Sutton wrote:
>
> Couldn't the text stored in the eHR include HTML paragraph separators, 
> replacing Windows or Unix specific line separators?
>
> And HTML escape sequences
>
> DV_HTMLTEXT?
>

Hi Colin,

you can already do that with DV_PARSABLE, which has two fields: the 
'value' (text string) and the 'formalism', i.e. says whether it is HTML 
1.4, PDF or whatever.

- thomas


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

Carriage returns in DV_TEXT not allowed

[Thomas Beale]

On 10/01/2012 23:24, Peter Gummer wrote:
> Thomas Beale wrote:
>
>>> You could model multiple paragraphs as a LIST of DV_PARAGRAPH.
>> but there is no 'LIST' data type to contain the DV_PARAGRAPHs.
> Sorry, not a LIST, I meant a multiple-occurrence element like this:
>
>   ELEMENT[at0009] occurrences matches {0..*} matches {-- My document
>   value matches {
>   DV_PARAGRAPH matches {*}
>   }
>   }
>
> In data this would become a sequences of paragraphs.

yes, but this needlessly creates multiple ELEMENTs, when intuitively you 
would expect one ELEMENT with the whole report in it. You are right - 
this is the solution available today. But I think its wrong..

- thomas

Carriage returns in DV_TEXT not allowed

[Thomas Beale]

On 10/01/2012 22:14, Peter Gummer wrote:
> Thomas Beale wrote:
>
>> This does not actually solve properly the problem of how CR/LFs are added. 
>> If we assume one DV_PARAGRAPH = 1 CR/LF (as in word processing) then a 
>> report needs to consist of multiple DV_PARAGRAPHs, and we don't currently 
>> have a data type for that. To fix the current model we could add a new type 
>> DV_DOCUMENT,   which contains multiple DV_PARAGRAPHs.
> You could model multiple paragraphs as a LIST of DV_PARAGRAPH.
>

but there is no 'LIST' data type to contain the DV_PARAGRAPHs.

- thomas

Constraints on class methods

[Thomas Beale]

On 10/01/2012 14:32, David Moner wrote:
> Doesn't this create problems while using archetypes/templates as basis 
> for the generation of data instances?
>
> I mean, a computed attribute (for example, the EVENT offset) gets its 
> value from already existing values or attributes of the instance class 
> (in this example, from the time and the parent.origin). We should not 
> create the instance if data is not valid regarding the 
> archetype/template, but we cannot check the validity of the 
> constrained offset while we don't have the instance complete. It seems 
> somehow a vicious circle. An assertion here is clearly preferable, 
> since by definition it is only applied to existing instances.
>
> David

David,

the usual situation in operational systems is that there are RM objects 
being created by some process. These will not by default obey the 
template and its archetypes, only the RM; to make the instances obey the 
template, you have to do something specific, e.g. engineer (or generate) 
the UI so it only allows exactly what the template says, or... if you 
have a custom UI (still the case in most real systems today) you will 
make calls to some programming object to either set or check the data. 
If you use the 'Template Data Object' approach - an API generated from 
the template, various types of checking are done. Usually, the checks 
are done after a 'commit' call is made, and any wrongly set fields have 
to be fixed by making a new call with appropriate data. This is a 
similar to the process of the typical web-page on a booking site, where 
you can't get to the next page until there are no more 'red' fields to 
correct.

There are a lot of different ways to technically do this data setting, 
too many to explain here, but in essence, a RM-valid but 
template-invalid RM instance is always possible in the instance building 
phase; what can't happen in a proper system is for non 
template-compliant data to be committed to the EHR repository.

- thomas

termbinding constraints in the archetype editor

[Peter Gummer]

Jostein Ven wrote:

> I am trying to bind an attribute in an archetype to a value set from a 
> terminology server. The data in the termserver is availiable through web 
> services. In practice, it should thus be possible to specify a URI in an 
> archetype constraint for the elementattribute. Can't figure out how this is 
> meant to be done in AE. Anyone with experience of how to do this in practice? 

Hi Jostein,

This depends whether you got AE from the openEHR web site or from Ocean 
Informatics.
* The openEHR build lacks a way of of connecting to a terminology server.
* The Ocean informatics build, on the other hand, uses a proprietary component 
to connect to the Ocean Terminology Server (OTS).

Why have two builds? Because AE is open source, and the inclusion of a 
proprietary component would prevent people from being able to build AE 
themselves. But people want this functionality, so the only solution was to do 
a separate Ocean build of AE, with the appropriate hooks to connect to OTS. In 
theory, any one who has the time and expertise could use those same hooks to 
connect to some other terminology service.

So, once you've installed the Ocean build of AE, here's how to do it. First you 
have to configure AE to point to the web service that you want to use:

1. Under the Tools menu, select Options.

2. In the Options dialog, select the File Locations tab.

3. Tick "Enable Terminology Lookup". (This is not available in the openEHR 
build.)

4. Enter the web service URL into the "URL for Terminology Service" box. (This 
isn't in the openEHR build either.)

5. Click OK.

Then you can set term bindings and constraint bindings. This can be done on the 
Definition tab.

To set a term binding, select the element that you want to bind to a term. 
Then, over on the right, select the little Details tab. Towards the bottom is a 
box, "Node meaning in terminologies", containing an empty grid. Click the 
button in the top row of the grid. This will show a dialog where you can select 
your binding.

To set a constraint binding on a DV_CODED_TEXT, select the text element that 
you want to bind. Over on the right, select the "Terminology" radio button. 
This will display an empty grid down below. Click the [+] button. This will 
show a dialog where you can add your binding.


> Does anyone know what the AE does when you enter the interface screen. Is the 
> constraint executed, if not, when is the constraint executed (or is it 
> executed at all?).

Term binding constraints aren't executed on the Interface tab. The Interface 
tab doesn't do anything really. Its only purpose is to give you a bit of an 
idea of how a hypothetical form based this archetype might look. I never use it 
myself, but I've noticed that it seems to help some people visualise their 
archetypes.


> References to AE user manual is also welcome. Can't find this.

Under the Help menu, select "Help Topics". This opens up 
http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html
 and from there you can follow a link to more detailed help.

AE's online help hasn't been revised for more than five years, however. It's 
out of date in places. For example, it doesn't describe what I've written 
above, because it was only implemented a year or two ago, but it does describe 
an alternative way using the "Terminology" tab.

- Peter

Carriage returns in DV_TEXT not allowed

[pablo pazos]

Hi Thomas,
In our RM implementation (Open EHRGen Framework), we use DV_TEXT to keep all 
kinds of non coded text: words, sentences, paragraphs, documents, etc. We don't 
use DV_PARAGRAPH.
-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Tue, 10 Jan 2012 14:19:01 +
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: Carriage returns in DV_TEXT not allowed



It would be interesting to know how many other implementers agree
with this restriction. It was put in (from memory) in the very early
days of modelling, based on GEHR, and possibly somewhat on 13606 -
nearly 10 years ago!

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

Did anybody implement AQL with a LL parser framework?

[Boštjan Lah]

periences of others too. 
> 
> 
> Kind regards
> Seref
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> 
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> 
> 
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
>     http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> 
> 
> ___
> 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: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/e28cc7f8/attachment.html>

Constraints on class methods

[Thomas Beale]

On 10/01/2012 09:52, Sebastian Garde wrote:
> Thomas, Rong and I had a similar discussion many moons ago, and in the 
> end I think we agreed to disagree ;-)
>
> A few other functional properties come to mind such as "type" in 
> PARTY_RELATIONSHIP and "is_integral" in DV_QUANTITY.
> These are more or less frequently constrained in archetypes as well.
>
> At the very least my thinking is that it is counter-intuitive to 
> constrain them directly.
> Also, for the Java validator that is also used in CKM, we had to 
> introduce a special hard-coded check for "commonly constrained 
> functional properties" such as the three mentioned here.

I am a bit surprised by that, because they can be represented easily in 
a standard way. Have a look at this schema 
<http://www.openehr.org/svn/knowledge2/TRUNK/rm_schemas/openehr_demographic_102.bmm>and
 
search for 'is_computed'.

>
> Re "offset":
> I wonder if offset could be expressed as an attribute with an 
> invariant for its validity.

well then it would be redundant with the 'time' attribute of EVENT.

>
> In fact, looking at the specs, there already is an invariant 
> "Offset_validity":
> inv: offset <> Void and offset = time - parent.origin
>
> Now I wonder what the point of this invariant is when offset is a 
> function that is already defined to be "time - parent.origin"?

this is what defines it. Arguably it should have been a post-condition 
of the function rather than a class invariant. But the effect is 
essentially the same.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/971dcf7c/attachment.html>

Constraints on class methods

[David Moner]

Doesn't this create problems while using archetypes/templates as basis for
the generation of data instances?

I mean, a computed attribute (for example, the EVENT offset) gets its value
from already existing values or attributes of the instance class (in this
example, from the time and the parent.origin). We should not create the
instance if data is not valid regarding the archetype/template, but we
cannot check the validity of the constrained offset while we don't have the
instance complete. It seems somehow a vicious circle. An assertion here is
clearly preferable, since by definition it is only applied to existing
instances.

David


2012/1/10 Thomas Beale 

> On 10/01/2012 08:40, Diego Bosc? wrote:
> > Oh, this is the first time I have heard that functions can be
> > constrained. However, AOM specifications say otherwise:
> > "C_attribute:  a  node  representing  a  constraint  on  an  attribute
> >   (i.e.  UML  ?relationship?  or
> > ?primitive attribute?) in an object type;" (AOM specifications, page 12)
> > This excludes clearly the 'stored properties'.
> >
> >
>
> That wording in the current release does exclude non-attributes. But I
> think it should be possible to state constraints on computed attributes
> (public functions with no parameters). It has already been implemented
> and is not difficult.
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/096b847f/attachment.html>

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Rene Spronk (Ringholm)]

All,

I'd support such a meeting. I may not be part of the active openEHR 
community, but I certainly believe in the power of face to face 
meetings, next to being a virtual community. To only be virtual has some 
serious disadvantages..

This is also the main reason why the HL7 RIM implementers community 
mainly meets face to face, instead of relying on teleconferences. It's 
all about the networking [plug: the next meeting will be in Sweden, 
joint with openEHR implementers: 
http://wiki.hl7.org/index.php?title=RIMBAA_201203_Agenda]

Back to the openEHR event: if it doesn't conflict with some other stuff 
I'll be attending .. so I did fill in the doodle poll.

TTYL,

-Rene


On 2012-01-10 13:14, Thomas Beale wrote:
>
> Dear all,
>
> for some years now, people have expressed interest in a live openEHR
> event. There is no doubt it is overdue! One nice place for such an event
> happens to be available for 2012: *Lake Bled, Slovenia*, sometime in the
> period *mid September - mid October* - if we act fast. *Nothing has been
> booked*: the purpose of this post is for you to decide if you like the
> idea, and vote on the doodle poll below, so we can determine interest
> and dates. PLEASE RESPOND AS SOON AS YOU RECEIVE THIS, TIME IS SHORT FOR
> BOOKING.
>
> Possibilities for a conference are as below (it's a compendium of ideas
> from people with a slight allergy to wall-to-wall presentations inside a
> hotel!) I have run these ideas past the interim openEHR board, and a few
> other experienced openEHR-ites, and the initial response was positive.
> There is a poll below to register your interest.
>
>   * LOCATION: Lake Bled, Slovenia, one of the jewels of central Europe,
> easy to get to, not too expensive; touristic info
> 
>   * CONFERENCE ACTIVITIES:
>   o max 3 days of 'conference' activity, with keynotes & organised
> presentations, many self-organised workshops and hang-outs
>   o keynotes: 2 or 3 international speakers
>   o hang-outs could be in the hotels, but also cafes, by the lake
> shore, or in picnic fields
>   o topics would include all levels of openEHR-related work, including
>   + clinical modelling,
>   + governance,
>   + programming & solutions in every language,
>   + decision support,
>   + model merging for 13606 revision,
>   + possible Clinical Information Modelling Initiative (CIMI)
> meetings/presentations
>   + using archetypes to make coffee
>   + etc
>   o academic side: it seems like a good opportunity to get some nice
> papers together. They would be published in a special issue of
> one of the existing journals, possibly ejHI
> .
>   o there would be significant opportunity for the community to
> self-organise events & activities leading up to the conference.
>   * SOCIAL:
>   o participants encouraged to bring partners, kids and to enjoy the
> beautiful surroundings
>   o one conference dinner
>   o interspersed with the conference activities, there would be some
> organised outdoor activities, and free time for self-organised
> things like canoing, sight-seeing, tourist visits to Ljubljana,
> the caves, etc
>   o we would organise some good cultural stuff, including live music
> and maybe a dance night etc
>   o the first day of the conference would be 80% organised social
> activities and meeting people, no presentations at all (Joaquim
> Dudeck did this years ago at a CDA conference in Berlin, and it
> worked fantastically well - all the attendees more or less knew
> each other by the time any actual conferencing got underway).
>   * COSTS:
>   o we have done some pricing, and we think the attendance price
> would be around ?500 / head
>   o air-travel to Ljubljana (capital of Slovenia) and then to lake
> Bled is generally in the ?100 per head range if booked ahead
> from European destinations.
>   o hotel costs are in a wide range, from ?70 / night single, 80-90
> twin, to ?150+/night for lake view doubles and suites.
>   * The organisers would provide guidance for people who want to make a
> proper holiday out of it and stay one or both weekends (in fact, we
> might make one weekend part of the conf)
>   * There is a large contingent of local openEHR interest in Slovenia,
> and many friendly people there who will make visitors welcome and
> help with organisation (of course there will be a professional
> company running the event, an organising committee, and so on).
>
> Those of you who get involved in conferences will know that there is not
> much time left for 2012 - about 8 months lead time is needed. We would
> look for sponsorship to help cover costs.
>
> WHAT WE NEED TO DO NOW (AND QUICKLY):
>
>

Carriage returns in DV_TEXT not allowed

[Thomas Beale]

On 10/01/2012 10:05, Leonardo Moretti wrote:
> If DV_TEXT doesn't allow to use carriage returns, line feeds, or other 
> non-printing characters, as stated in 
> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf, 
> pag 29, there is a way to represent short text with minimal formatting 
> characters (carriage returns)? Which data type should be used?
>

It would be interesting to know how many other implementers agree with 
this restriction. It was put in (from memory) in the very early days of 
modelling, based on GEHR, and possibly somewhat on 13606 - nearly 10 
years ago!

The idea was that DV_TEXT models a 'text fragment', essentially the idea 
of a word, string of words, sentence or possibly a group of sentences. 
No CR/LF were allowed because this is taken as a paragraph delimiter, 
and the type DV_PARAGRAPH was defined to represent multiple DV_TEXTs 
making up a long tract of text like a report. In proper word processing 
& publishing, this is correct; a 'paragraph' has no CR/LF in it, which 
is what allows resizing to work properly in different screen / form widths.

Additionally, any 'atomic' text item, e.g. a single disease name, single 
sentence etc - which make up the majority of text data within structured 
data - should not have a CR/LF.

This way of thinking may be dated, and it is a good question as to when 
a piece of text can't be a single DV_TEXT. If we stick with the current 
model 
<http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109597816149_873308_762Report.html>
 
(and remember, a DV_CODED_TEXT is-a DV_TEXT in openEHR), the openEHR RM 
is imposing a simple word processing model of 'paragraphs' made up of 
'text fragments'. An alternative would be to allow anything in a 
DV_TEXT. The decision about when you have to have a new DV_TEXT is made 
on the basis of attributes other than the actual string value, i.e.:

  * hyperlink: if there is a hyperink, it applies to the entire DV_TEXT;
therefore, if you only want a link to correspond to 2 words, then
those 2 words = 1 DV_TEXT
  * formattting: simple formatting like bolding, emphasis (about the
same level as typical wiki markup) applies to the whole DV_TEXT;
  * mappings: coded mappings, e.g. ICD code applies to whole DV_TEXT;
need to use multiple DV_TEXTs if only some words are to have an
associated code mapping
  * formal coding: if a DV_CODED_TEXT is to be used - i.e. when the
string value is the term for the code from its terminology (not just
some mapping), then the DV_CODED_TEXT.value can only consist of the
exact word string to which the code corresponds; more DV_TEXTs have
to be added using a DV_PARAGRAPH to construct a whole paragraph

The best approach with the current model is:

  * for atomic text items, e.g. single word/sentence answers to
questions, single coded terms like names of diseases, procedures
etc, use a single DV_CODED_TEXT or DV_TEXT.
  * for a tract of text containing some words that are hyperlinked /
coded / formatted, use a DV_PARAGRAPH containing multiple DV_TEXTs.
  * Or else you use a DV_PARSABLE, containing XML, HTML, RTF or whatever
you like - but ... no guarantee the receiver can read it!

This does not actually solve properly the problem of how CR/LFs are 
added. If we assume one DV_PARAGRAPH = 1 CR/LF (as in word processing) 
then a report needs to consist of multiple DV_PARAGRAPHs, and we don't 
currently have a data type for that. To fix the current model we could 
add a new type DV_DOCUMENT, which contains multiple DV_PARAGRAPHs. Or we 
could remove the restriction on CR/LF on DV_TEXT, but that then would 
allow CR/LFs to occur in single DV_CODED_TEXT strings, which is almost 
certainly an error. But maybe we just assume that software never makes 
this error?

The real question is: do we want to have any explicit word-processor 
like model of text? 10 years ago, the answer seemed obvious: yes, 
because there is no reliable standard of marked up text (many variants 
of HTML, XML, wiki markup, etc). I am not sure the answer is any 
different today. From a clinical perspective, guaranteeing readability 
of text in a standard way is paramount.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/4922e19d/attachment.html>

Constraints on class methods

[Thomas Beale]

On 10/01/2012 08:40, Diego Bosc? wrote:
> Oh, this is the first time I have heard that functions can be
> constrained. However, AOM specifications say otherwise:
> "C_attribute:  a  node  representing  a  constraint  on  an  attribute
>   (i.e.  UML  ?relationship?  or
> ?primitive attribute?) in an object type;" (AOM specifications, page 12)
> This excludes clearly the 'stored properties'.
>
>

That wording in the current release does exclude non-attributes. But I 
think it should be possible to state constraints on computed attributes 
(public functions with no parameters). It has already been implemented 
and is not difficult.

- thomas

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Thomas Beale]

nical list
in response to this post.

THE INTENDED OUTCOME OF THE POLL IS TO DETERMINE:

  * *how many people *(roughly) are interested, and would come sometime
in the period available
  * *which week *should be booked for the conference, since this has to
be locked in very soon

One variable that could also be changed is duration. Some people might 
want more of a short working meeting - as far as I can see, there is no 
way to include this idea on the doodle poll; please indicate on the lists.

If you like the conference idea, but can't participate in the above 
proposal, or would like some other proposal, please post you ideas 
instead on the lists.

thanks for your input.

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

termbinding constraints in the archetype editor

[Daniel Karlsson]

Jostein,

as a possible work-around, we have used internal at-codes and mapped
those at-codes to the external terminology. This, of course, only works
if the number of allowed codes is limited, which have been the case in
our projects so far. This also has the benefit that the archetype does
not depend on external (terminology server) resources.

If the terminology used is SNOMED CT, IHTSDO will (eventually) provide a
standard for constraining expressions which will be applicable. This
would though have to be implemented in your terminology server.

Out of curiosity, what terminology server are you using?

Regards,
Daniel
-- 
Daniel Karlsson, PhD
Department of Biomedical Engineering/Medical Informatics
Link?pings universitet
SE-58185 Link?ping
Sweden
Phone: +46 13 286762, Cellular: +46 70 8350109, Skype: imt_danka



Tue 2012-01-10 klockan 10:55 +0100 skrev Jostein Ven:
> Everybody,
> 
> I am trying to bind an attribute in an archetype to a value set from a
> terminology server. The data in the termserver is availiable through
> web services. In practice, it should thus be possible to specify a URI
> in an archetype constraint for the elementattribute. Can't figure out
> how this is meant to be done in AE. Anyone with experience of how to
> do this in practice? 
> 
> Does anyone know what the AE does when you enter the interface screen.
> Is the constraint executed, if not, when is the constraint executed
> (or is it executed at all?).
> 
> References to AE user manual is also welcome. Can't find this.
> 
> 
> All the best 
> Jostein Ven
> Senior adviser
> Norwegian Directorate of Health
> 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/696dc33d/attachment.html>

Carriage returns in DV_TEXT not allowed

[Leonardo Moretti]

If DV_TEXT doesn't allow to use carriage returns, line feeds, or other
non-printing characters, as stated in
http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf,
pag 29, there is a way to represent short text with minimal formatting
characters (carriage returns)? Which data type should be used?

Thank you.
Regards

leo
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/c20eba63/attachment.html>

termbinding constraints in the archetype editor

[Jostein Ven]

Everybody,

I am trying to bind an attribute in an archetype to a value set from a 
terminology server. The data in the termserver is availiable through web 
services. In practice, it should thus be possible to specify a URI in an 
archetype constraint for the elementattribute. Can't figure out how this is 
meant to be done in AE. Anyone with experience of how to do this in practice? 

Does anyone know what the AE does when you enter the interface screen. Is the 
constraint executed, if not, when is the constraint executed (or is it executed 
at all?).

References to AE user manual is also welcome. Can't find this.


All the best 
Jostein Ven
Senior adviser
Norwegian Directorate of Health
  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/711503fc/attachment.html>

Constraints on class methods

[Sebastian Garde]

Thomas, Rong and I had a similar discussion many moons ago, and in the 
end I think we agreed to disagree ;-)

A few other functional properties come to mind such as "type" in 
PARTY_RELATIONSHIP and "is_integral" in DV_QUANTITY.
These are more or less frequently constrained in archetypes as well.

At the very least my thinking is that it is counter-intuitive to 
constrain them directly.
Also, for the Java validator that is also used in CKM, we had to 
introduce a special hard-coded check for "commonly constrained 
functional properties" such as the three mentioned here.

Re "offset":
I wonder if offset could be expressed as an attribute with an invariant 
for its validity.

In fact, looking at the specs, there already is an invariant 
"Offset_validity":
inv: offset <> Void and offset = time - parent.origin

Now I wonder what the point of this invariant is when offset is a 
function that is already defined to be "time - parent.origin"?

Re "type": This is the same as the property "name" (because of the 
type_validity invariant)

Sebastian

On 10.01.2012 09:40, Diego Bosc? wrote:
> Oh, this is the first time I have heard that functions can be
> constrained. However, AOM specifications say otherwise:
> "C_attribute:  a  node  representing  a  constraint  on  an  attribute
>   (i.e.  UML  ?relationship?  or
> ?primitive attribute?) in an object type;" (AOM specifications, page 12)
> This excludes clearly the 'stored properties'.
>
>
>
> 2012/1/9 Thomas Beale:
>> In ADL/AOM, constraints can be made on computed properties as well as
>> stored ones.  If you look at the spec, EVENT.offset is computed as
>> time.diff(parent.origin). Making a constraint on EVENT.time, which is
>> the absolute time (which is what you want in the data) is annoying
>> because you want to constraint on relative time, not absolute time. It
>> would mean creating constraints in the rules section with an equivalent
>> expression, i.e.
>>
>> .../some/path/to/event[5 min]/time - .../some/path/to/event[5
>> min]/parent/origin<= PT5m
>>
>> - thomas
>>
>> On 09/01/2012 11:41, Diego Bosc? wrote:
>>> When I was trying to validate an archetype with the reference model
>>> (openEHR-EHR-OBSERVATION.apgar), I found something strange on all
>>> 'event' archetypes.
>>> The EVENT class has a function (method) that calculates the offset.
>>> However, in that archetype the offset was restricted as if it was an
>>> attribute.
>>> What is the sense for this? Shouldn't this restriction be expressed as
>>> an assertion over the different attributes? (that is, a restriction
>>> that must be checked at runtime as it is a result from a method).
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

-- 
Ocean Informatics   
Dr Sebastian Garde
Senior Developer
Ocean Informatics

/Dr. sc. hum., Dipl.-Inform. Med, FACHI/

Skype: gardeseb

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/2fd63c03/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: oceanlogo.png
Type: image/png
Size: 5677 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/2fd63c03/attachment.png>

termbinding constraints in the archetype editor

[Seref Arikan]

Hi Jostein,
Regarding your question about what AE does when you enter the interface
screen: it is open source. In case you have someone who can speak vb.net,
you can simply debug that part of the code and see what it does.

Probably not the most practical way of knowing the answer, but the most
certain one..

Cheers
Seref


On Tue, Jan 10, 2012 at 9:55 AM, Jostein Ven  wrote:

>  Everybody,
>
> I am trying to bind an attribute in an archetype to a value set from a
> terminology server. The data in the termserver is availiable through web
> services. In practice, it should thus be possible to specify a URI in an
> archetype constraint for the elementattribute. Can't figure out how this is
> meant to be done in AE. Anyone with experience of how to do this in
> practice?
>
> Does anyone know what the AE does when you enter the interface screen. Is
> the constraint executed, if not, when is the constraint executed (or is it
> executed at all?).
>
> References to AE user manual is also welcome. Can't find this.
>
>
> All the best
> Jostein Ven
> Senior adviser
> Norwegian Directorate of Health
>
> ___
> 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: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/90fc149c/attachment.html>

Constraints on class methods

[Diego Boscá]

Oh, this is the first time I have heard that functions can be
constrained. However, AOM specifications say otherwise:
"C_attribute:  a  node  representing  a  constraint  on  an  attribute
 (i.e.  UML  ?relationship?  or
?primitive attribute?) in an object type;" (AOM specifications, page 12)
This excludes clearly the 'stored properties'.



2012/1/9 Thomas Beale :
>
> In ADL/AOM, constraints can be made on computed properties as well as
> stored ones. ?If you look at the spec, EVENT.offset is computed as
> time.diff(parent.origin). Making a constraint on EVENT.time, which is
> the absolute time (which is what you want in the data) is annoying
> because you want to constraint on relative time, not absolute time. It
> would mean creating constraints in the rules section with an equivalent
> expression, i.e.
>
> .../some/path/to/event[5 min]/time - .../some/path/to/event[5
> min]/parent/origin <= PT5m
>
> - thomas
>
> On 09/01/2012 11:41, Diego Bosc? wrote:
>> When I was trying to validate an archetype with the reference model
>> (openEHR-EHR-OBSERVATION.apgar), I found something strange on all
>> 'event' archetypes.
>> The EVENT class has a function (method) that calculates the offset.
>> However, in that archetype the offset was restricted as if it was an
>> attribute.
>> What is the sense for this? Shouldn't this restriction be expressed as
>> an assertion over the different attributes? (that is, a restriction
>> that must be checked at runtime as it is a result from a method).
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical