Problem in some sample archetypes and questions

[Stap, R.E. (Roel)]

 
Hi Koray,

I am not sure if I understand the detailed questions fully, however, I
think that you should keep in mind that the archetypes should be
"generic" as possible. Archetypes are intended to be reused, and if I
read e.g. your issues for a {3..8} cardinality I get the impression that
this could be valid for a specific application. In this situation I
would suggest to make the archetype generic e.g. {0..N}, and configure
your application in terms of (business) rules (constrains on the
association).

If you need more information please provide a little more information
about your requirements and the application in which you need this...

regards
Roel


Roel Stap

TNO-ICT
Colosseum 27
7521 PV Enschede
+31 53 4835212
+31 6 10968787

http://www.tno.nl/ict

DISCLAIMER 
http://www.tno.nl/disclaimer/email.html


-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Koray Atalag
Sent: maandag 8 januari 2007 12:10
To: For openEHR technical discussions
Subject: Re: Problem in some sample archetypes and questions

Stap, R.E. (Roel) wrote:
> Hello Koray,
>  
> Reading your issues around cardinallity, perhaps you can solve this 
> issue with help of constrains/business rules. E.g. if you consider in 
> the Archetype model the ability to have a cardinality between A and B 
> of (0..N), you can constrain practically this cardinality to a maximum

> of e.g. 4. The risk of modelling you cardinalities so precise in the 
> archetype model is that if in future this is changed, your system 
> (e.g. database schema's or applications) needs to be updated if this 
> cardinality changes. If you are able to define the reason of this 
> cardinality in rules you may create the flexibility in future to adapt

> this without changing systems or applications. I am not sure if this 
> will help you, but consider this mechanism to handle cardinalities
issues.
> I hope this may help you in finding a solution for your issue,
>  
> regards
> Roel
>  
>  
Hi Roel,

Thanks for the information you provided; especially the one about the
effect of archetype design on the resulting software and database
schema. I would still like to take your attention to my specific
questions 2 and 3. These point out to very detailed aspects of archetype
design - ones that most probably will never encounter while designing
their archetypes.

Best regards and Bedankt!

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

This e-mail and its contents are subject to the DISCLAIMER at 
http://www.tno.nl/disclaimer/email.html
-- next part --
A non-text attachment was scrubbed...
Name: Stap, R.E..vcf
Type: text/x-vcard
Size: 248 bytes
Desc: Stap, R.E..vcf
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/25261561/attachment.vcf>
-- 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

[Stap, R.E. (Roel)]

Hello Koray,
 
Reading your issues around cardinallity, perhaps you can solve this
issue with help of constrains/business rules. E.g. if you consider in
the Archetype model the ability to have a cardinality between A and B of
(0..N), you can constrain practically this cardinality to a maximum of
e.g. 4. The risk of modelling you cardinalities so precise in the
archetype model is that if in future this is changed, your system (e.g.
database schema's or applications) needs to be updated if this
cardinality changes. If you are able to define the reason of this
cardinality in rules you may create the flexibility in future to adapt
this without changing systems or applications. I am not sure if this
will help you, but consider this mechanism to handle cardinalities
issues.
I hope this may help you in finding a solution for your issue,
 
regards
Roel
 
 

Roel Stap 

TNO-ICT 
Colosseum 27 
7521 PV Enschede 
+31 53 4835212 
+31 6 10968787 

http://www.tno.nl/ict 

DISCLAIMER
http://www.tno.nl/disclaimer/email.html 

 



From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: zondag 7 januari 2007 17:39
To: For openEHR technical discussions
Subject: Re: Problem in some sample archetypes and questions


Thanks Koray

Your expression of cardinality and occurrences is exactly correct -
there are clearly some errors in the archetypes.

The only reason to limit cardinality in the archetype is to force a
choice when there are more than one child e.g.

container x with cardinality 1..2
has children a (occurrences 1..1)
   b (occurrences 0..1)
   c (occurrences 0..1)

This forces a choice between b and c.

Cheers, Sam

Cheers, Sam

Koray Atalag wrote: 

Hi to all,

While revising my MST archetypes, I came across some confusion
on the 
use of cardinality and occurences. And when I reread ADL 1.4 and
ADL2, 
inspected the sample archetypes and then created new ones with
Archetype 
Editor and also tested with the Workbench my confusion got even
more 
increased. Here is the problem description and some questions:

As stated in ADL 1.4: "Cardinalities indicate limits on the
number of 
members of instances of container types such as lists and sets".
From a 
simpler point of view, what I understand it tells the min and
max 
allowed number of beads (same or different beads) in a box. From
a more 
sensible way in the realm of clinical archetypes written in ADL,
it is 
used to constrain the min and max allowed number of run-time
instances 
of child nodes of attributes which can be a container such as
CLUSTER, 
ITEM_TREE, ITEM_LIST, HISTORY and so on.

So far so good but I have a practical problem to model a
situation like 
the following:
PARENT_NODE (A container type and might not exist or repeat up
to  2 times)
a) CHILD_NODE (Must appear once)
b) CHILD_NODE (May appear 0 to 8 times)

So this roughly can be expressed as:
CLUSTER occurences {0..2}
any container attribute cardinality {1..9}
QUANTITY occurences {1..1}
ELEMENT   occurences {0..8}

PROBLEM-1: As understood from above description that cardinality
simply 
depicts the number of instances of subchilds - REGARDLESS of
their type 
(i.e. QUANTITY or ELEMENT), then above cardinality can be {1..9}
or 
simply {1..*}. When I examine some sample archetypes such as
Line 67 in 
autopsy.v1, Line 33 in respiration.v1 and Line 103 in
microbiology.v1 
the cardinality of container node is {0..1} and they have a
number of 
child nodes with occurences >0 and it is clear clinically that
almost 
ALL of those nodes should appear in runtime data. So there is
either a 
misunderstanding of the use of cardinality here among most of us
or I am 
totally lost here :)

The above model is expressed in those archetypes roughly as
follows:

CLUSTER
any container attribute cardinality {0..2}
QUANTITY occurences {1..1}
ELEMENT   occurences {0..8}

QUESTION-1: What is the correct approach for above problem?

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)

QUESTION-3: Related with second question, I also need to
disallow usage 
of some values when referencing by use_node entries. This 

Antw: Re: Antw: Re: Antw: Re: AW: HL7 templates/archetypes

[Stap, R.E. (Roel)]

William,
 
I think "a working system" is not the only criteria to be met. As far as
I understand, all the (formal) specification we have in HL7v3, CEN and
other organisation have the goal to achieve open, transparent and
(relative) easy maintainable care information systems. As far as I heard
so far there are singe HL7 v3 systems working, but without any
collaboration with other HLv3 systems... I haven't hear about
working openEHR systems in this way either, but from system engineering
point of view this is a matter of time. In other business sectors the
openEHR engineering's method has been proven to work.
 

Roel Stap 




From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of
Williamtfgoossen at cs.com
Sent: dinsdag 17 oktober 2006 8:16
To: openehr-technical at openehr.org
Subject: Antw: Re: Antw: Re: Antw: Re: AW: HL7 templates/archetypes


Yes Bert, 

I agree with many of the problems. 

My point was: today I cannot go to a live implementation of a OpenEHR
system. You support this. 

Today I can point you at least to 3 working systems that have HL7 v3
Care Provision as the founding principle and they run, although still in
test environment. 

I do know one system in New Zealand based on HL7 v3 RIM which is fully
operational. 

Of course we need to be patient. It is a difficult task! 

Good luck and yes I look forward to seeing it work and consider myself
on the list of invitees to see the formal release. 

With respect to the dinosaur systems for GPs, stemming from the 80 ies,
I agree, these have difficulties with HL7 v3, and they would have
similar troubles with OpenEHR archetypes. 

My point is that you need to change to new desigs to make it work. 

Thanks for the feedback 

This e-mail and its contents are subject to the DISCLAIMER at 
http://www.tno.nl/disclaimer/email.html
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: Stap, R.E..vcf
Type: text/x-vcard
Size: 248 bytes
Desc: Stap, R.E..vcf
URL: 

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

Antw: HL7 templates/archetypes

[Stap, R.E. (Roel)]

Dear William,
 
I am currently working on the creation of Diabetes related archetypes
based on common archetypes. These archetypes are used to be specialised
in templates for use in diabetes protocol support systems. 
Please, can you provide me with one example where you have an HL7
compliant "archetype" (I am not sure mean this) which van be easily in
an openEHR template? Because my HL7 knowledge is limited ( I have my
doubts about the engineering concepts of HL7 v3), I was not able to see
this link in an real implementation
 
Thanks in advance,
 

Roel Stap 

TNO-ICT 
Colosseum 27 
7521 PV Enschede 
+31 53 4835212 
+31 6 10968787 

http://www.tno.nl/ict 

DISCLAIMER
http://www.tno.nl/disclaimer/email.html 

 



From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of
Williamtfgoossen at cs.com
Sent: zondag 15 oktober 2006 21:12
To: openehr-technical at openehr.org
Subject: Antw: HL7 templates/archetypes


In een bericht met de datum 15-10-2006 19:15:05 West-Europa (zomertijd),
schrijft e0125766 at student.tuwien.ac.at: 




Hi, 

I'm writing my diploma thesis at the Vienna Medical University
and I have a question concerning the HL7 templates/archetypes. I'm aware
that this sites are related to the openEHR but maybe somebody can answer
the following question: 

Which model (RIM, R-MIM, ...) and which formalism (ADL, OCL,
OWL, ...) should be used for the description and creation of the
entry-level templates? 

Thanks for a brief answer! 

Best regards 
Dana Prochazkova 




Can you define what you mean with 'entry level templates?' 

I am creating HL7 compliant and easily transformable to OpenEHR
templates covering a wealth of clinical details. We have currently over
150 examples. 

dr. William Goossen\ 
the Netherlands 


This e-mail and its contents are subject to the DISCLAIMER at 
http://www.tno.nl/disclaimer/email.html
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: Stap, R.E..vcf
Type: text/x-vcard
Size: 248 bytes
Desc: Stap, R.E..vcf
URL: 

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