Re: definition of custom fields in archetypes

[Ian McNicoll]

Hi Georg,

Yes that is absolutely correct. The archetypes act as a constraint on the
RM so must always be compliant with the RM, and whatever underlying
archetype class is selected. Same applies to templates. Practically
speaking this does still give us a huge amount of flexibility, especially
as we can add cluster archetypes in Slots, which is very useful when trying
to align with legacy system data.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll



Director, freshEHR Clinical Informatics Ltd.
CCIO inidus Ltd. i...@inidus.com
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Hon. Senior Research Associate, CHIME, UCL


On Wed, 9 Oct 2019 at 08:30, Georg Fette 
wrote:

> Hallo,
> I have a question about the degree of freedom in defining archetypes:
> Archetypes are not composed but rather specified by constraining the
> base classes from the reference model. Hence no new/custom field members
> can be definied in the definition of a new archetype but only the field
> members already existing in the base classes have to be used. So there
> will never be a path like
>
> a/myField/myProperty/value
>
> but always just something like
>
> a/data/events/items/value
>
> The same applies for the definition of templates.
> Is this correct ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

definition of custom fields in archetypes

[Georg Fette]

Hallo,
I have a question about the degree of freedom in defining archetypes:
Archetypes are not composed but rather specified by constraining the 
base classes from the reference model. Hence no new/custom field members 
can be definied in the definition of a new archetype but only the field 
members already existing in the base classes have to be used. So there 
will never be a path like


a/myField/myProperty/value

but always just something like

a/data/events/items/value

The same applies for the definition of templates.
Is this correct ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL access of fields of potential subclasses or derived archetypes

[Thomas Beale]

Hi Georg,

The generic way to do this is to do what archetype tools do. An 
archetype itself mentioned class and attribute names from a 'reference 
model', but it doesn't know anything about any particular model. SUch 
tools have to be told to load a representation of the model in order to 
validate an archetype against it (i.e. in addition to validating correct 
ADL structures etc). Today, every tool is doing this by loading the BMM 
schemas of the reference models. Probably the Archie project 
<https://github.com/openEHR/archie>contains the easiest to use code that 
does this. (Note: the latest Marand ADL-designer, and LinkEHR, as well 
as the original ADL Workbench all use BMM files these days; but Archie 
is probably going to have the cleanest, most modern source code to work 
with).


The general picture is the same for AQL queries: figure out from some 
environment var, config setting or the RM names in the archetype ids in 
the queries which BMM to use to do the validation. Once you have that it 
is easy.


If you want to know more on Archie, ask here, the authors will no doubt 
respond.


- thomas

On 03/05/2019 12:09, Georg Fette wrote:

Hello,
I have a question the is a bit related to the discussion about the 
constraining of the ELEMENT type in the laboratory_analytes.
The current specification defines the field "ehr_status" of the class 
EHR with the type OBJECT_REF. In the AQL specification there is an 
example (chapter 3.7.2.3. NOT) that accesses this field with the 
assumption that the field is of type EHR_STATUS.
I have written a type checker for AQL queries, so I am now stumbling 
across queries that access fields of potential subclasses or derived 
archetypes.

Does/should the specification generally allow such a thing ?
Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL access of fields of potential subclasses or derived archetypes

[Seref Arikan]

Bah, meant "..(I think) it should not..."

On Fri, May 3, 2019 at 12:19 PM Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> As things stand, No, the spec does not allow such a thing (since it is
> unspecified at the moment) and also partially No, (I don't think) it should
> not allow such a thing auto-magically or try to be smart about it.
>
> As things stand, AQL has only access to information provided by the RM. I
> for one would be uncomfortable with Aql queries making assumptions about
> actual subtypes of abstract/parent types because validating those at the
> query level is impossible.
> It is semantically 'downcasting' the type and it should only be done in an
> explicit way when the authors of the queries explicitly declare the cast
> and take the risk.
>
> I'll take a look at the example you mentioned, but it does not sound right
> to me. My earlier response to Tom mentioning comparison operators also fall
> under this topic.
>
> All the best
> Seref
>
> On Fri, May 3, 2019 at 12:10 PM Georg Fette 
> wrote:
>
>> Hello,
>> I have a question the is a bit related to the discussion about the
>> constraining of the ELEMENT type in the laboratory_analytes.
>> The current specification defines the field "ehr_status" of the class
>> EHR with the type OBJECT_REF. In the AQL specification there is an
>> example (chapter 3.7.2.3. NOT) that accesses this field with the
>> assumption that the field is of type EHR_STATUS.
>> I have written a type checker for AQL queries, so I am now stumbling
>> across queries that access fields of potential subclasses or derived
>> archetypes.
>> Does/should the specification generally allow such a thing ?
>> Greetings
>> Georg
>>
>> --
>> -
>> Dipl.-Inf. Georg Fette  Raum: B001
>> Universität WürzburgTel.: +49-(0)931-31-85516
>> Am Hubland  Fax.: +49-(0)931-31-86732
>> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
>> -
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL access of fields of potential subclasses or derived archetypes

[Seref Arikan]

As things stand, No, the spec does not allow such a thing (since it is
unspecified at the moment) and also partially No, (I don't think) it should
not allow such a thing auto-magically or try to be smart about it.

As things stand, AQL has only access to information provided by the RM. I
for one would be uncomfortable with Aql queries making assumptions about
actual subtypes of abstract/parent types because validating those at the
query level is impossible.
It is semantically 'downcasting' the type and it should only be done in an
explicit way when the authors of the queries explicitly declare the cast
and take the risk.

I'll take a look at the example you mentioned, but it does not sound right
to me. My earlier response to Tom mentioning comparison operators also fall
under this topic.

All the best
Seref

On Fri, May 3, 2019 at 12:10 PM Georg Fette 
wrote:

> Hello,
> I have a question the is a bit related to the discussion about the
> constraining of the ELEMENT type in the laboratory_analytes.
> The current specification defines the field "ehr_status" of the class
> EHR with the type OBJECT_REF. In the AQL specification there is an
> example (chapter 3.7.2.3. NOT) that accesses this field with the
> assumption that the field is of type EHR_STATUS.
> I have written a type checker for AQL queries, so I am now stumbling
> across queries that access fields of potential subclasses or derived
> archetypes.
> Does/should the specification generally allow such a thing ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

AQL access of fields of potential subclasses or derived archetypes

[Georg Fette]

Hello,
I have a question the is a bit related to the discussion about the 
constraining of the ELEMENT type in the laboratory_analytes.
The current specification defines the field "ehr_status" of the class 
EHR with the type OBJECT_REF. In the AQL specification there is an 
example (chapter 3.7.2.3. NOT) that accesses this field with the 
assumption that the field is of type EHR_STATUS.
I have written a type checker for AQL queries, so I am now stumbling 
across queries that access fields of potential subclasses or derived 
archetypes.

Does/should the specification generally allow such a thing ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Rules in archetypes - what are the requirements?

[Pieter Bos]

From: openEHR-technical  on behalf 
of Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Saturday, 2 February 2019 at 20:10
To: "openehr-technical@lists.openehr.org" 
Subject: Re: Rules in archetypes - what are the requirements?



On 02/02/2019 16:21, Pieter Bos wrote:

From: openEHR-technical 
<mailto:openehr-technical-boun...@lists.openehr.org>
 on behalf of Thomas Beale 
<mailto:thomas.be...@openehr.org>
Reply-To: For openEHR technical discussions 
<mailto:openehr-technical@lists.openehr.org>
Date: Saturday, 2 February 2019 at 15:01
To: 
"openehr-technical@lists.openehr.org"<mailto:openehr-technical@lists.openehr.org>
 
<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Rules in archetypes - what are the requirements?


Assuming you meant to put 'id7' as the first one, I don't understand what this 
achieves beyond just:

/events[id2]/data/items/element[id7]/value/magnitude >
/events[id2]/data/items/element[id4]/value/magnitude +
/events[id2]/data/items/element[id5]/value/magnitude +
/events[id2]/data/items/element[id6]/value/magnitude

which says the same thing, for all events in the runtime data that conform to 
the /events[id2] branch of the structure.

Since the occurrences of events[id2] can be more than one, 
/events[id2]/data/items/element[id7]/value/magnitude in the execution 
environment (actual data) maps to  a List.

well it could be understood that way - that would be to literally interpret it 
as a runtime path. The way I think of it is to mean 'this condition xyz must 
hold true' for each instance to which it applies. This greatly simplifies 
things - otherwise you end up in a complicated place like you have described 
below.

If not runtime but archetype paths, eventually you need to apply them to 
runtime data to evaluate. There are several ways of doing that – one way is 
what I did in Archie. Another one that I considered was automatically detecting 
common parent objects with effective_occurrences potentially > 1 and 
automatically adding for_all, plus some validation  – less code, but more 
complex code. Another one is requiring for_all statements written by the rule 
modeler/developer (this is not possible in the published draft without your 
relative path proposal below). There are more ways to do this. Each one will 
operate differently in different edge cases, if this is not specified.

If however you do your ‘this path is relative to the other one’ context binding 
below, with a for_all that works with these path bindings, I think that should 
solve most of the problems.

the Expression Language 
draft<https://specifications.openehr.org/releases/LANG/latest/expression_language.html#_defined_predicate>
 has the defined() predicate which I think should do the job.

It should, when combined with the new if-statement that is much more powerful 
than the implies-statement in the previous version.

However, it has some interesting implications when combined with the “'this 
condition xyz must hold true for each instance to which it applies”-idea 
specified above if not combined with an explicit for_all. Because also the 
corresponding defined()-check must be done for each instance. That’s the reason 
I integrated null-handling as ‘if an assertion/check has a null value, that 
means it’s missing data required to evaluate it. So the assertions is not 
relevant, meaning that it passes’. Then you can manually specify exists/defined 
conditions if you need them.

It would still be Real. The idea is that the path is relative to an EVENT, 
although that is not clear from the above. Perhaps something like:

$item_aaa -> (EVENT)/data/items/element[id7]/value/magnitude

That would solve it.

That would solve the problem. Why not just inline the assignments, such as:

$events := /events[id2]

this was in a previous draft. But I am pretty convinced we don't want to mix 
paths in with the main 'code'. This is particularly the case if we want to use 
TypeScript or some other mainstream language to write the main statements in - 
the bindings need to be separate.

I'll have more of a think about how the bindings should work.

If typescript/javascript (typescript compiles to javascript before execution), 
that will change quite a lot about the discussion before.

Since a path query is just a string, it’s not so hard to create an (included) 
path lookup function and an ‘assign value to this path’ function.

Regards,

Pieter Bos

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

On 02/02/2019 16:21, Pieter Bos wrote:


*From: *openEHR-technical 
 on behalf of Thomas 
Beale 
*Reply-To: *For openEHR technical discussions 


*Date: *Saturday, 2 February 2019 at 15:01
*To: *"openehr-technical@lists.openehr.org" 


*Subject: *Re: Rules in archetypes - what are the requirements?

Assuming you meant to put 'id7' as the first one, I don't understand 
what this achieves beyond just:


/events[id2]/data/items/element[id7]/value/magnitude >
    /events[id2]/data/items/element[id4]/value/magnitude +
    /events[id2]/data/items/element[id5]/value/magnitude +
    /events[id2]/data/items/element[id6]/value/magnitude

which says the same thing, for all events in the runtime data that 
conform to the /events[id2] branch of the structure.


Since the occurrences of events[id2] can be more than one, 
/events[id2]/data/items/element[id7]/value/magnitude in the execution 
environment (actual data) maps to  a List.


well it could be understood that way - that would be to literally 
interpret it as a runtime path. The way I think of it is to mean 'this 
condition xyz must hold true' for each instance to which it applies. 
This greatly simplifies things - otherwise you end up in a complicated 
place like you have described below.


That means you need to define operators such as +, > and = on a list 
of reals. Or to define somehow that a statement containing only path 
bindings within a single multiply-occurring structure will mean that 
it gets evaluated for each occurrence of such a structure. The second 
case is complicated if you need to include data outside /events[id2] 
in your expression. A real world use case would be data in /protocol, 
which can influence the interpretation of event data, but is outside 
of the event.
So we did the first in Archie, with a bit of tricks to make this work 
for assignments. For example, how the plus operator is interpreted in 
Archie:


+(Real r1, Real r2)
  return the sum both numbers
...
Much of this complexity can be avoided by  not defining the operator 
on lists/sets, and requiring the for_all loop on lists or sets of data 
in the specification. This comes at a price, because the author of the 
expressions needs to understand more of the language and data 
structures. So we chose the second, since the previous draft 
specification did not specify at all how to handle these cases.


Undefined value handling is another subject, I have not checked yet if 
the new proposal solves it. We defined some functions to handle this 
explicitly if the automatic handling doesn’t do it ((input , 
alternative) -> return input  unless input is undefined, then 
alternative), as well as some rounding functions.


the Expression Language draft 
<https://specifications.openehr.org/releases/LANG/latest/expression_language.html#_defined_predicate> 
has the defined() predicate which I think should do the job.



If we were to allow the expression for_all $event in /data/events[id3] 
then we need to be clear on what it means: it actually refers to an 
object of type List, but do the members consist of EVENT 
objects found in data at the moment the expression is evaluated? Or 
just the statically defined members in the archetype - which can also 
be multiple, e.g. see the Apgar archetype, it has 1 min, 2 min, 5 min 
events?


You would need to evaluate on actual data. If you define it on the 
archetype data, you would need some kind of rules to convert it to an 
evaluation on actual data with different multiplicities than the rules 
specify, for example if events[id2] has occurrences > 1. Might be 
possible, I have not tried to define that. Would probably include some 
extra for_all loops plus some kind of validation errors for cases that 
cannot be converted.
So I would say always the data found at the moment which the 
expression is evaluated. You can still refer to separate statically 
defined members using their distinct node ids, and even those could 
have occurrences > 1 (not in the apgar example since those have 
occurrences {0..1} in the archetype).


Normally we want the processing of 'rules' expressions in archetypes 
to apply to the data when the archetype is being used in its normal 
role of creation / semantic validation at data commit time.


Agreed.

So it seems to me that if we want to support expressions like the 
above, we need to be able to do something like (don't worry about the 
concrete syntax too much, could easily be TS or java-flavoured):


*use_model*
    org.openehr.rm

*data_context*

$xxx_events: List
    $item_aaa, $item_bbb, $item_ccc, $item_ddd: Real

*definition*

check for_all event in $xxx_events:
    event/$item_aaa > event/$item_bbb + event/$item_ccc + 
event/$item_ddd


*data_bindings*-- pseudo-code for now

$xxx_events -> /events[id2]
    $item_aaa -> /data/items/element[id7]/value/magnitude
    $item_bbb -> /data/items/element[id4]/value/magnitude
    $item_ccc -> /data/it

Re: Rules in archetypes - what are the requirements?

[Pieter Bos]

From: openEHR-technical  on behalf 
of Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Saturday, 2 February 2019 at 15:01
To: "openehr-technical@lists.openehr.org" 
Subject: Re: Rules in archetypes - what are the requirements?


Assuming you meant to put 'id7' as the first one, I don't understand what this 
achieves beyond just:

/events[id2]/data/items/element[id7]/value/magnitude >
/events[id2]/data/items/element[id4]/value/magnitude +
/events[id2]/data/items/element[id5]/value/magnitude +
/events[id2]/data/items/element[id6]/value/magnitude

which says the same thing, for all events in the runtime data that conform to 
the /events[id2] branch of the structure.

Since the occurrences of events[id2] can be more than one, 
/events[id2]/data/items/element[id7]/value/magnitude in the execution 
environment (actual data) maps to  a List. That means you need to define 
operators such as +, > and = on a list of reals. Or to define somehow that a 
statement containing only path bindings within a single multiply-occurring 
structure will mean that it gets evaluated for each occurrence of such a 
structure. The second case is complicated if you need to include data outside 
/events[id2] in your expression. A real world use case would be data in 
/protocol, which can influence the interpretation of event data, but is outside 
of the event.
So we did the first in Archie, with a bit of tricks to make this work for 
assignments. For example, how the plus operator is interpreted in Archie:

+(Real r1, Real r2)
  return the sum both numbers
+(Real r1, List r2)
   return a list the same size as r2, with every element result[i] = r1 + r2[i]
+(List r1, r2)
   return a list the same size as r1, with every element result[i] = r1[i] + r2
+(Listl r1, List r2)
  if r1 and r2 have different length, throw an exception. Otherwise, return a 
list the same size as r1, with every element result[i] being r1[i] + r2[i]

And the > operator:

>(Real r1, Real r2)
  return true if r1 > r2, false otherwise
>(Real r1, List r2)
  return a list of Booleans, one for every element in r2, true if r1 > that 
element
>(List r1, r2)
  return a list of Booleans, one for every element in r1, true if that element 
> r2
>(Listl r1, List r2)
  if r1 and r2 have different length, throw an exception. Otherwise, return a 
list of Booleans, with every element result[i] being r1[i] > r2[i]

This is a simplification, in reality there is null-handling and integer-> real 
conversion involved, which is also missing in the specification I think.
We defined assertions/checks to only succeed if every Boolean in such a list is 
true or null/undefined (to not fail on data which is optional). Additionally in 
Archie every value returned contains every unique path in the data that was 
used to evaluate it, so you can see exactly for which data an assertion/check 
failed in the result, to notify the user where the problem occurs. Or to apply 
an assignment to the correct output if the output path does not match a single 
field. This last bit is implementation specific of course.

Much of this complexity can be avoided by  not defining the operator on 
lists/sets, and requiring the for_all loop on lists or sets of data in the 
specification. This comes at a price, because the author of the expressions 
needs to understand more of the language and data structures. So we chose the 
second, since the previous draft specification did not specify at all how to 
handle these cases.

Undefined value handling is another subject, I have not checked yet if the new 
proposal solves it. We defined some functions to handle this explicitly if the 
automatic handling doesn’t do it ((input , alternative) -> return input  unless 
input is undefined, then alternative), as well as some rounding functions.

If we were to allow the expression for_all $event in /data/events[id3] then we 
need to be clear on what it means: it actually refers to an object of type 
List, but do the members consist of EVENT objects found in data at the 
moment the expression is evaluated? Or just the statically defined members in 
the archetype - which can also be multiple, e.g. see the Apgar archetype, it 
has 1 min, 2 min, 5 min events?

You would need to evaluate on actual data. If you define it on the archetype 
data, you would need some kind of rules to convert it to an evaluation on 
actual data with different multiplicities than the rules specify, for example 
if events[id2] has occurrences > 1. Might be possible, I have not tried to 
define that. Would probably include some extra for_all loops plus some kind of 
validation errors for cases that cannot be converted.
So I would say always the data found at the moment which the expression is 
evaluated. You can still refer to separate statically defined members using 
their distinct node ids, and even those could have occurrences > 1 (not in the 
apgar examp

Re: Rules in archetypes - what are the requirements?

[Pieter Bos]

vation. So if you really want them to be 
typed on validation time, you need to check every attribute in the path to see 
if it can point to more than one value, then either make it a 
List> or define in which order to add it as a single list.
I implemented it by determining type at runtime, but it’s possible otherwise. 
This means that very often you need a for all statement, in which case data 
binding doesn’t really help. I defined some tricks with the basic operators 
also working on equally sized lists to make things a bit easier to understand 
for modelers. That’s why I asked about the execution rules. The tricks I did 
can be easily rewritten into for_all statements if we need to have them removed.

This leads to more interesting cases when you flatten rules to an OPT 2 
template, to obtain a single artifact that can be used for many things, 
including rule evaluation. That is very doable right now by prepending some 
paths and adding some for_all statements. I’m not sure how to do that with data 
binding.

Regards,


Pieter Bos

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Thomas Beale 
mailto:thomas.be...@openehr.org>>
Reply-To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Date: Friday, 1 February 2019 at 14:16
To: 
"openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>"
 
mailto:openehr-technical@lists.openehr.org>>
Subject: Re: Rules in archetypes - what are the requirements?


Thanks Pieter,

this is very useful.
On 01/02/2019 12:54, Pieter Bos wrote:
For us the main requirement of the rules is to calculate the value of other 
fields based on other fields. Only the checking of assertions has relatively 
little added value for the use cases our customers encounter. I would find it 
very hard to explain to any users or modelers that they can write checks that 
do the actual score calculation, but that they cannot actually use the 
calculated value anywhere. So we ignore this limitation altogether.

the obvious solution to that requirement seems to be to a) use functions and b) 
to allow assignment:

rules
-- assert that manually set total is correct
check $apgar_total_value == apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)



rules
-- assign total value
$apgar_total_value = apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)



Also the value binding seems to have an case that has not been covered:


it is possible that a single path lookup results in a list of values. This 
means a single path-bound variable will contain multiple values (so a list of 
values). In the old case, you could handle this with a for_all statement to 
express that the assertion should be valid within the scope of a single event, 
for all events. How could value binding solve this? The same question applies 
to output variable binding as well as input variable binding.

conceptually, rules statements are typed, so in this case, the type will be 
List or List or whatever. In that case, expressions need to 
treat it in the normal way, i.e. with List or Set operators that obtain single 
values. E.g.

$systolic_bp_samples: List

there_exists v in $systolic_bp_samples : v > Systolic_bp_threshold implies 

These kinds of things (and for_all) are documented in the Expression Language 
draft<https://specifications.openehr.org/releases/LANG/latest/expression_language.html#_collection_operators>.

Related to this, both the current and proposed specification is missing 
execution rules, especially when paths lookup to a list of values instead of a 
single variable and how to handle that. For example what does the following 
mean when /data/events/data/items/element[id3]/value/magnitude resolves to more 
than one value?

I don't see how it can, since that path is defined to be of type Real (not 
List or Set etc) by the RM definition of DvQuantity. But I'm 
probably missing something in the sense of your question...

Anyway, the more I can find out about current requirements, working solutions, 
workaround etc, the better - the intention is to evolve the expression facility 
in archetypes to match those needs and to be as useful as possible.

- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

On 02/02/2019 13:15, Ian McNicoll wrote:

Hi Pieter,

"But why would I need a function to calculate a score that is just a 
sum of a number of values, instead of a few +-operators?"


It is an open question but one advantage of using the function 
approach, with simple values is that it can encapsulate the algorithm 
without too much dependency on understanding openEHR paths or path 
-bindings. That should allow broader engagement with non-openEHR 
specialists.


My preference is to support use of openEHR datatypes within the 
expression (albeit perhaps in reduced format), as otherwise passing 
units etc as scalars starts to get cumbersome.


agree - that is the idea of this construct in the EL

*use_model*
    org.openehr.rm

then you can declare vars to be of RM types like DvQuantity, DvOrdinal etc.

- t


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

On 01/02/2019 14:53, Pieter Bos wrote:


About the calculation:

Ah, I see, the assignment seems like a good solution. But why would I 
need a function to calculate a score that is just a sum of a number of 
values, instead of a few +-operators?


well you might want to re-use that function. More generally, some 
functions are more interesting, e.g. MAP calculation, and it is 
potentially better to a) name them, b) declare them in a more obvious 
place and c) make them re-usable.





Multiplicities/data binding:

The there exists case is clear. However, what if I have four events, 
all having four elements, each with dv_quantity as value. Say I want 
the magnitude of the last of these quantities to be larger than the 
sum of the first three. Before I could write something like:


for_all $event in /data/events[id3]
 $event/data/items/element[id6]/value/magnitude >
$event/data/items/element[id4]/value/magnitude +
$event/data/items/element[id5]/value/magnitude +
$event/data/items/element[id6]/value/magnitude

Assuming you meant to put 'id7' as the first one, I don't understand 
what this achieves beyond just:


/events[id2]/data/items/element[id7]/value/magnitude >
    /events[id2]/data/items/element[id4]/value/magnitude +
    /events[id2]/data/items/element[id5]/value/magnitude +
    /events[id2]/data/items/element[id6]/value/magnitude

which says the same thing, for all events in the runtime data that 
conform to the /events[id2] branch of the structure.


If we were to allow the expression for_all $event in /data/events[id3] 
then we need to be clear on what it means: it actually refers to an 
object of type List, but do the members consist of EVENT objects 
found in data at the moment the expression is evaluated? Or just the 
statically defined members in the archetype - which can also be 
multiple, e.g. see the Apgar archetype, it has 1 min, 2 min, 5 min events?


Normally we want the processing of 'rules' expressions in archetypes to 
apply to the data when the archetype is being used in its normal role of 
creation / semantic validation at data commit time. So it seems to me 
that if we want to support expressions like the above, we need to be 
able to do something like (don't worry about the concrete syntax too 
much, could easily be TS or java-flavoured):


*use_model*
    org.openehr.rm

*data_context*

    $xxx_events: List
    $item_aaa, $item_bbb, $item_ccc, $item_ddd: Real

*definition*

    check for_all event in $xxx_events:
    event/$item_aaa > event/$item_bbb + event/$item_ccc + 
event/$item_ddd


*data_bindings* -- pseudo-code for now

$xxx_events -> /events[id2]
$item_aaa -> /data/items/element[id7]/value/magnitude
$item_bbb -> /data/items/element[id4]/value/magnitude
$item_ccc -> /data/items/element[id5]/value/magnitude
$item_ddd -> /data/items/element[id6]/value/magnitude

I don't know what this archetype is, so assume that $xxx_events, 
$item_aaa etc are more meaningful names.


The next problem you mentioned is:

PB: Note that a path that points to a single typed dvquantity in an 
archetype can still point to many items in the RM if somewhere up the 
tree there is a list or a set, for example more than one observation


So I think this implies an incorrect interpretation of this kind of code 
within an archetype. It can't be understood as simultaneously applying 
to multiple Observations if it is within an Observation archetype, only 
to one OBSERVATION instance at a time - usually one about to be committed.


You can still have Lists of things internal to the archetype, as shown 
above with the Events list, but to process the multiplicity, you would 
need to do as we have done and use for_all, or some other 
container-aware operator or function.


Anyway, does this get closer to the sense of what you would like to do? 
It's more than I had conceived of, so this is a useful challenge...


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Rules in archetypes - what are the requirements?

[Ian McNicoll]

Hi Pieter,

"But why would I need a function to calculate a score that is just a sum of
a number of values, instead of a few +-operators?"

It is an open question but one advantage of using the function approach,
with simple values is that it can encapsulate the algorithm without too
much dependency on understanding openEHR paths or path -bindings. That
should allow broader engagement with non-openEHR specialists.

My preference is to support use of openEHR datatypes within the expression
(albeit perhaps in reduced format), as otherwise passing units etc as
scalars starts to get cumbersome.

e.g

$apgar_heartrate, $apgar_breathing, $apgar_reflex, $apgar_muscle, $
apgar_colour)

where each of these is actually an ordinal, rather than a scalar value.

Not such a good example but think of a BMI calc, where the units used for
height and weight are critical
We can learn a lot from GDL experience in this regard.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Fri, 1 Feb 2019 at 14:53, Pieter Bos  wrote:

> About the calculation:
>
>
>
> Ah, I see, the assignment seems like a good solution. But why would I need
> a function to calculate a score that is just a sum of a number of values,
> instead of a few +-operators?
>
>
> Multiplicities/data binding:
>
> The there exists case is clear. However, what if I have four events, all
> having four elements, each with dv_quantity as value. Say I want the
> magnitude of the last of these quantities to be larger than the sum of the
> first three. Before I could write something like:
>
> for_all $event in /data/events[id3]
>  $event/data/items/element[id6]/value/magnitude >
> $event/data/items/element[id4]/value/magnitude +
> $event/data/items/element[id5]/value/magnitude +
> $event/data/items/element[id6]/value/magnitude
>
>
>
> (I omitted a few node ids here that are not important for the example)
>
> Not the most readable -  but it does the job. With data binding, how do I
> express this? There no longer seems to be a path lookup outside of data
> binding, so I can’t write:
>
> for_all $event in $events
>  $event/data/items/element[id6]/value/magnitude >
> $event/data/items/element[id4]/value/magnitude +
> $event/data/items/element[id5]/value/magnitude +
> $event/data/items/element[id6]/value/magnitude
>
>
>
> And binding all the separate paths to variables doesn’t work either – they
> will be bound as lists, and there is no way to iterate over four lists of
> values at once.
>
>
>
> Note that a path that points to a single typed dvquantity in an archetype
> can still point to many items in the RM if somewhere up the tree there is a
> list or a set, for example more than one observation. So if you really want
> them to be typed on validation time, you need to check every attribute in
> the path to see if it can point to more than one value, then either make it
> a List> or define in which order to add it as a single list.
>
> I implemented it by determining type at runtime, but it’s possible
> otherwise. This means that very often you need a for all statement, in
> which case data binding doesn’t really help. I defined some tricks with the
> basic operators also working on equally sized lists to make things a bit
> easier to understand for modelers. That’s why I asked about the execution
> rules. The tricks I did can be easily rewritten into for_all statements if
> we need to have them removed.
>
>
>
> This leads to more interesting cases when you flatten rules to an OPT 2
> template, to obtain a single artifact that can be used for many things,
> including rule evaluation. That is very doable right now by prepending some
> paths and adding some for_all statements. I’m not sure how to do that with
> data binding.
>
>
>
> Regards,
>
>
> Pieter Bos
>
>
>
> *From: *openEHR-technical 
> on behalf of Thomas Beale 
> *Reply-To: *For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Date: *Friday, 1 February 2019 at 14:16
> *To: *"openehr-technical@lists.openehr.org" <
> openehr-technical@lists.openehr.org>
> *Subject: *Re: Rules in archetypes - what are the requirements?
>
>
>
> Thanks Pieter,
>
> this is very useful.
>
> On 01/02/2019 12:54, Pieter Bos wrote:
>
> For us the main requirement of the rules is to calculate the value of
> other fields based on other fields. Only the checking of assertions has
> 

Re: Rules in archetypes - what are the requirements?

[Pieter Bos]

About the calculation:

Ah, I see, the assignment seems like a good solution. But why would I need a 
function to calculate a score that is just a sum of a number of values, instead 
of a few +-operators?


Multiplicities/data binding:

The there exists case is clear. However, what if I have four events, all having 
four elements, each with dv_quantity as value. Say I want the magnitude of the 
last of these quantities to be larger than the sum of the first three. Before I 
could write something like:

for_all $event in /data/events[id3]
 $event/data/items/element[id6]/value/magnitude >
$event/data/items/element[id4]/value/magnitude +
$event/data/items/element[id5]/value/magnitude +
$event/data/items/element[id6]/value/magnitude

(I omitted a few node ids here that are not important for the example)
Not the most readable -  but it does the job. With data binding, how do I 
express this? There no longer seems to be a path lookup outside of data 
binding, so I can’t write:

for_all $event in $events
 $event/data/items/element[id6]/value/magnitude >
$event/data/items/element[id4]/value/magnitude +
$event/data/items/element[id5]/value/magnitude +
$event/data/items/element[id6]/value/magnitude

And binding all the separate paths to variables doesn’t work either – they will 
be bound as lists, and there is no way to iterate over four lists of values at 
once.

Note that a path that points to a single typed dvquantity in an archetype can 
still point to many items in the RM if somewhere up the tree there is a list or 
a set, for example more than one observation. So if you really want them to be 
typed on validation time, you need to check every attribute in the path to see 
if it can point to more than one value, then either make it a 
List> or define in which order to add it as a single list.
I implemented it by determining type at runtime, but it’s possible otherwise. 
This means that very often you need a for all statement, in which case data 
binding doesn’t really help. I defined some tricks with the basic operators 
also working on equally sized lists to make things a bit easier to understand 
for modelers. That’s why I asked about the execution rules. The tricks I did 
can be easily rewritten into for_all statements if we need to have them removed.

This leads to more interesting cases when you flatten rules to an OPT 2 
template, to obtain a single artifact that can be used for many things, 
including rule evaluation. That is very doable right now by prepending some 
paths and adding some for_all statements. I’m not sure how to do that with data 
binding.

Regards,


Pieter Bos

From: openEHR-technical  on behalf 
of Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Friday, 1 February 2019 at 14:16
To: "openehr-technical@lists.openehr.org" 
Subject: Re: Rules in archetypes - what are the requirements?


Thanks Pieter,

this is very useful.
On 01/02/2019 12:54, Pieter Bos wrote:
For us the main requirement of the rules is to calculate the value of other 
fields based on other fields. Only the checking of assertions has relatively 
little added value for the use cases our customers encounter. I would find it 
very hard to explain to any users or modelers that they can write checks that 
do the actual score calculation, but that they cannot actually use the 
calculated value anywhere. So we ignore this limitation altogether.

the obvious solution to that requirement seems to be to a) use functions and b) 
to allow assignment:

rules
-- assert that manually set total is correct
check $apgar_total_value == apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)



rules
-- assign total value
$apgar_total_value = apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)



Also the value binding seems to have an case that has not been covered:


it is possible that a single path lookup results in a list of values. This 
means a single path-bound variable will contain multiple values (so a list of 
values). In the old case, you could handle this with a for_all statement to 
express that the assertion should be valid within the scope of a single event, 
for all events. How could value binding solve this? The same question applies 
to output variable binding as well as input variable binding.

conceptually, rules statements are typed, so in this case, the type will be 
List or List or whatever. In that case, expressions need to 
treat it in the normal way, i.e. with List or Set operators that obtain single 
values. E.g.

$systolic_bp_samples: List

there_exists v in $systolic_bp_samples : v > Systolic_bp_threshold implies 

These kinds of things (and for_all) are documented in the Expression Language 
draft<https://specifications.openehr.org/releases/LANG/latest

Re: Rules in archetypes - what are the requirements?

[Thomas Beale]

Thanks Pieter,

this is very useful.

On 01/02/2019 12:54, Pieter Bos wrote:


For us the main requirement of the rules is to calculate the value of 
other fields based on other fields. Only the checking of assertions 
has relatively little added value for the use cases our customers 
encounter. I would find it very hard to explain to any users or 
modelers that they can write checks that do the actual score 
calculation, but that they cannot actually use the calculated value 
anywhere. So we ignore this limitation altogether.


the obvious solution to that requirement seems to be to a) use functions 
and b) to allow assignment:


*rules
*    -- assert that manually set total is correct
*check *$apgar_total_value == apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)



*rules
*    -- assign total value
    $apgar_total_value = apgar_total ($apgar_heartrate_value, 
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value, 
$apgar_colour_value)




Also the value binding seems to have an case that has not been covered:

it is possible that a single path lookup results in a list of values. 
This means a single path-bound variable will contain multiple values 
(so a list of values). In the old case, you could handle this with a 
for_all statement to express that the assertion should be valid within 
the scope of a single event, for all events. How could value binding 
solve this? The same question applies to output variable binding as 
well as input variable binding.


conceptually, rules statements are typed, so in this case, the type will 
be List or List or whatever. In that case, expressions 
need to treat it in the normal way, i.e. with List or Set operators that 
obtain single values. E.g.


$systolic_bp_samples: List

there_exists v in $systolic_bp_samples : v > Systolic_bp_threshold 
implies 


These kinds of things (and for_all) are documented in the Expression 
Language draft 
<https://specifications.openehr.org/releases/LANG/latest/expression_language.html#_collection_operators>.


Related to this, both the current and proposed specification is 
missing execution rules, especially when paths lookup to a list of 
values instead of a single variable and how to handle that. For 
example what does the following mean when 
/data/events/data/items/element[id3]/value/magnitude resolves to more 
than one value?


I don't see how it can, since that path is defined to be of type Real 
(not List or Set etc) by the RM definition of DvQuantity. 
But I'm probably missing something in the sense of your question...


Anyway, the more I can find out about current requirements, working 
solutions, workaround etc, the better - the intention is to evolve the 
expression facility in archetypes to match those needs and to be as 
useful as possible.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Rules in archetypes - what are the requirements?

[Pieter Bos]

For us the main requirement of the rules is to calculate the value of other 
fields based on other fields. Only the checking of assertions has relatively 
little added value for the use cases our customers encounter. I would find it 
very hard to explain to any users or modelers that they can write checks that 
do the actual score calculation, but that they cannot actually use the 
calculated value anywhere. So we ignore this limitation altogether.

Also the value binding seems to have an case that has not been covered:

it is possible that a single path lookup results in a list of values. This 
means a single path-bound variable will contain multiple values (so a list of 
values). In the old case, you could handle this with a for_all statement to 
express that the assertion should be valid within the scope of a single event, 
for all events. How could value binding solve this? The same question applies 
to output variable binding as well as input variable binding.

Related to this, both the current and proposed specification is missing 
execution rules, especially when paths lookup to a list of values instead of a 
single variable and how to handle that. For example what does the following 
mean when /data/events/data/items/element[id3]/value/magnitude resolves to more 
than one value?

/data/events/data/items/element[id15]/value/magnitude = 
/data/events/data/items/element[id3]/value/magnitude + 3

And what if 3 is replaced by another path instead? What if the left hand side 
matches one value? And what if it matches more than one? In Archie I 
implemented ways to handle these cases by defining the operations on single 
values, on equally sized lists and in cases where one value is a list and the 
other one is a single value. But unless this is specified, this will be 
different for different implementations.

Regards,

Pieter Bos

From: openEHR-technical  on behalf 
of Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Friday, 1 February 2019 at 13:01
To: Openehr-Technical 
Subject: Rules in archetypes - what are the requirements?


For many years, there has been a little-used capability in ADL which enables 
basic expressions to be stated such as the following in the Apgar Observation 
archetype:

rules

score_sum: 
/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude = 
/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value + 
/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value + 
/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value + 
/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value + 
/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value

where all those paths point to the various Apgar leaf data values, i.e. total, 
heart rate etc.

This kind of statement is intended to assert that the total value = the sum of 
the 5 elements, as per the Apgar formula. However, it was never that clear that 
it is an assertion, not a value-setting formula, which might also be something 
we want.

It's also not very readable, even if the paths were rendered with a tool, they 
are long and painful to read.

Another kind of assertion was to for conditional mandation of some part of the 
data depending on some other data element (or more generally, an expression), 
e.g.

rules

/data[id2]/items[id21]/items[id15]/value[id50]/defining_code matches 
{[at19]} implies exists /data[id2]/items[id21]/items[id20]

Here the logical intention is to mandate that the data at the second path, 
which is about details of transfer (i.e. discharge to other care) if the value 
of the datum at the first path, which is 'type of separation' = at19|transfer|. 
Other examples are mandating data containing details of tobacco use if the 
value of the data item 'tobacco use' /= at44|non-user|.

This also is not that easy to read, or clear in its intentions.

More recently, as part of the development of a simple expression language that 
can be used across openEHR (archetypes, Task Planning, GDL etc), I proposed 
some key improvements to expressions in archetypes, namely:

  *   symbolic names for paths, done by bindings
  *   an explicit 'check' instruction to make the intention of assertion clearer
  *   a defined() predicate to replace the use of 'exists'

Examples of how these changes look are shown here in the working copy of the 
ADL2 
spec<https://specifications.openehr.org/releases/AM/latest/ADL2.html#_rules_section>.
 In this form, the above Apgar example becomes:

rules
check $apgar_total_value = $apgar_heartrate_value + $apgar_breathing_value 
+ $apgar_reflex_value + $apgar_muscle_value + $apgar_colour_value

data_bindings

content_bindings = <
["apgar_breathing_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value">
["apgar_heartrate_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value">
["apgar_muscle_va

Re: Rules in archetypes - what are the requirements?

[Diego Boscá]

I'm fine with this improvements, the only thing I feel that can be
troublesome for users is having data_bindings and computed values in a
completely different format/style


El vie., 1 feb. 2019 a las 13:01, Thomas Beale ()
escribió:

> For many years, there has been a little-used capability in ADL which
> enables basic expressions to be stated such as the following in the Apgar
> Observation archetype:
>
> *rules*
>
> *score_sum*:
> /data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude =
> /data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value +
> /data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value +
> /data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value +
> /data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value +
> /data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value
>
> where all those paths point to the various Apgar leaf data values, i.e.
> total, heart rate etc.
>
> This kind of statement is intended to assert that the total value = the
> sum of the 5 elements, as per the Apgar formula. However, it was never that
> clear that it is an assertion, not a value-setting formula, which might
> also be something we want.
>
> It's also not very readable, even if the paths were rendered with a tool,
> they are long and painful to read.
>
> Another kind of assertion was to for conditional mandation of some part of
> the data depending on some other data element (or more generally, an
> expression), e.g.
>
> *rules*
>
> /data[id2]/items[id21]/items[id15]/value[id50]/defining_code *matches
> *{[at19]} *implies exists */data[id2]/items[id21]/items[id20]
>
> Here the logical intention is to mandate that the data at the second path,
> which is about details of transfer (i.e. discharge to other care) if the
> value of the datum at the first path, which is 'type of separation' =
> at19|transfer|. Other examples are mandating data containing details of
> tobacco use if the value of the data item 'tobacco use' /= at44|non-user|.
>
> This also is not that easy to read, or clear in its intentions.
>
> More recently, as part of the development of a simple expression language
> that can be used across openEHR (archetypes, Task Planning, GDL etc), I
> proposed some key improvements to expressions in archetypes, namely:
>
>- symbolic names for paths, done by bindings
>- an explicit 'check' instruction to make the intention of assertion
>clearer
>- a defined() predicate to replace the use of 'exists'
>
> Examples of how these changes look are shown here in the working copy of
> the ADL2 spec
> <https://specifications.openehr.org/releases/AM/latest/ADL2.html#_rules_section>.
> In this form, the above Apgar example becomes:
>
> *rules*
> *check *$apgar_total_value = $apgar_heartrate_value + $
> apgar_breathing_value + $apgar_reflex_value + $apgar_muscle_value + $
> apgar_colour_value
>
> *data_bindings*
>
> content_bindings = <
> ["apgar_breathing_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value">
> ["apgar_heartrate_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value">
> ["apgar_muscle_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value">
> ["apgar_reflex_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value">
> ["apgar_colour_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value">
> ["apgar_total_value"] =
> <"/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude">
> >
>
> And the smoking example is:
>
> *check *$is_smoker = *True **implies **defined *($smoking_details)
>
> Note that this does not address the possible requirement of being able to
> state a formula that *sets *a field, or defines a purely computed value
> at a path.
>
> We are still working on details of the expression language, variable
> binding idea and so on. I am interested in feedback on the approach shown
> in the spec, preferably provided here in the first instance.
>
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/0

Rules in archetypes - what are the requirements?

[Thomas Beale]

For many years, there has been a little-used capability in ADL which 
enables basic expressions to be stated such as the following in the 
Apgar Observation archetype:


*rules*

/score_sum/: 
/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude = 
/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value + 
/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value + 
/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value + 
/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value + 
/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value


where all those paths point to the various Apgar leaf data values, i.e. 
total, heart rate etc.


This kind of statement is intended to assert that the total value = the 
sum of the 5 elements, as per the Apgar formula. However, it was never 
that clear that it is an assertion, not a value-setting formula, which 
might also be something we want.


It's also not very readable, even if the paths were rendered with a 
tool, they are long and painful to read.


Another kind of assertion was to for conditional mandation of some part 
of the data depending on some other data element (or more generally, an 
expression), e.g.


*rules*

/data[id2]/items[id21]/items[id15]/value[id50]/defining_code *matches 
*{[at19]} *implies exists */data[id2]/items[id21]/items[id20]


Here the logical intention is to mandate that the data at the second 
path, which is about details of transfer (i.e. discharge to other care) 
if the value of the datum at the first path, which is 'type of 
separation' = at19|transfer|. Other examples are mandating data 
containing details of tobacco use if the value of the data item 'tobacco 
use' /= at44|non-user|.


This also is not that easy to read, or clear in its intentions.

More recently, as part of the development of a simple expression 
language that can be used across openEHR (archetypes, Task Planning, GDL 
etc), I proposed some key improvements to expressions in archetypes, namely:


 * symbolic names for paths, done by bindings
 * an explicit 'check' instruction to make the intention of assertion
   clearer
 * a defined() predicate to replace the use of 'exists'

Examples of how these changes look are shown here in the working copy of 
the ADL2 spec 
<https://specifications.openehr.org/releases/AM/latest/ADL2.html#_rules_section>. 
In this form, the above Apgar example becomes:


*rules*
*check *$apgar_total_value = $apgar_heartrate_value + 
$apgar_breathing_value + $apgar_reflex_value + $apgar_muscle_value + 
$apgar_colour_value


*data_bindings*

    content_bindings = <
    ["apgar_breathing_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value">
    ["apgar_heartrate_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value">
    ["apgar_muscle_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value">
    ["apgar_reflex_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value">
    ["apgar_colour_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value">
    ["apgar_total_value"] = 
<"/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude">

    >

And the smoking example is:

*check *$is_smoker = *True **implies **defined *($smoking_details)

Note that this does not address the possible requirement of being able 
to state a formula that /sets /a field, or defines a purely computed 
value at a path.


We are still working on details of the expression language, variable 
binding idea and so on. I am interested in feedback on the approach 
shown in the spec, preferably provided here in the first instance.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Amen.

So, do we have a conclusion that toolmakers can reference? Can we document this 
somewhere in the specs or elsewhere?

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Heather Leslie
Sent: Wednesday, December 19, 2018 7:22 AM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi everyone,

In our modelling, it is safe to assume that the latest version of an archetype 
is the best candidate on offer for anyone using an archetype and filling a SLOT 
for the first time. Options for use of previous versions may be useful for 
implementers who have older versions in their current systems and don’t want 
two different versions or to update all their systems to the latest version.

I totally agree that from a governance point of view SLOT inclusions won’t need 
to specify a version in 99% of cases. However in some situations it 
theoretically may be appropriate to fix a version in place in a specific SLOT. 
In fact I can’t think of a use case YET where we need to specify a certain 
version, but no doubt this will occur at some time in the near future.

In all our modelling it seems that as soon as we limit our options one way or 
another we discover a use case that breaks our most recently made rule! 
Murphy’s law?

So we want to have our cake and eat it too – default to any or all versions of 
an archetype, with the option to specify one (or maybe even multiple) if needs 
be. Same theory applies to exclusions in a SLOT as well.

The governance overheads of currently specifying v0 and/or v1 and/or v2  will 
only increase as time goes on and at present as CKAs we have people upset that 
v0 is specifically included but that archetype has subsequently been published 
as v1. They want to see v1 specifically included. They don’t understand the 
theory behind it, not unreasonably, that as long as no archetypes (and 
versions) are excluded in a specific way, even if the SLOT suggests a v0 as an 
inclusion, it technically doesn’t stop a v1 being inserted in there. So the 
inclusion of all versions also has an important design guidance function as 
well. Newbies may not understand that if an archetype of the appropriate class 
is no actively excluded, then any or all of the archetypes of that class are 
technically valid for adding into a template.

Regards

Heather

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: Wednesday, 19 December 2018 1:15 AM
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image001.jpg@01D4A69F.B91D67F0]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
spe

RE: Syntax for including archetypes in SLOTs, regardless of version

[Heather Leslie]

Hi everyone,

In our modelling, it is safe to assume that the latest version of an archetype 
is the best candidate on offer for anyone using an archetype and filling a SLOT 
for the first time. Options for use of previous versions may be useful for 
implementers who have older versions in their current systems and don’t want 
two different versions or to update all their systems to the latest version.

I totally agree that from a governance point of view SLOT inclusions won’t need 
to specify a version in 99% of cases. However in some situations it 
theoretically may be appropriate to fix a version in place in a specific SLOT. 
In fact I can’t think of a use case YET where we need to specify a certain 
version, but no doubt this will occur at some time in the near future.

In all our modelling it seems that as soon as we limit our options one way or 
another we discover a use case that breaks our most recently made rule! 
Murphy’s law?

So we want to have our cake and eat it too – default to any or all versions of 
an archetype, with the option to specify one (or maybe even multiple) if needs 
be. Same theory applies to exclusions in a SLOT as well.

The governance overheads of currently specifying v0 and/or v1 and/or v2  will 
only increase as time goes on and at present as CKAs we have people upset that 
v0 is specifically included but that archetype has subsequently been published 
as v1. They want to see v1 specifically included. They don’t understand the 
theory behind it, not unreasonably, that as long as no archetypes (and 
versions) are excluded in a specific way, even if the SLOT suggests a v0 as an 
inclusion, it technically doesn’t stop a v1 being inserted in there. So the 
inclusion of all versions also has an important design guidance function as 
well. Newbies may not understand that if an archetype of the appropriate class 
is no actively excluded, then any or all of the archetypes of that class are 
technically valid for adding into a template.

Regards

Heather

From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: Wednesday, 19 December 2018 1:15 AM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image002.jpg@01D497BE.ED038BC0]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
go

AW: AW: Syntax for including archetypes in SLOTs, regardless of version

[Sebastian Garde]

Von: openEHR-technical  Im Auftrag 
von Thomas Beale
Gesendet: Dienstag, 18. Dezember 2018 18:39
An: openehr-technical@lists.openehr.org
Betreff: Re: AW: Syntax for including archetypes in SLOTs, regardless of version


The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] means that 
not only v0, v1, v2 are valid, but also v10, v15, v27 to name a few.

the regex character class [0-2] matches only a single digit having the 
character values in the series 0-2, i.e. 0, 1, or 2.

[SG] Sure – but if it is were the case that only a partial match is required, 
anything could be added to the left or the right (as long as it makes a valid 
archetype id).

Now that you mention it, I do seem to remember we specified a very long time 
ago that those regexes did have to be full validating ones.

[SG] That’s exactly what I mean, yes, thank you. (And that then ensures that 
the above does not match v10 or v15…)

So that means using something more like

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0.2}

as the checker regex in CKM, and patterns like 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v.*, where the 
trailing '.*' matches anything, and the validator regex ensures it is only 
semver dotted version patterns.

- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AW: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

On 18/12/2018 16:48, Sebastian Garde wrote:


Hi Silje, hi Thomas, hi all,

Whether the CKM validation errors from below are correct or bogus 
boils down to my question from before whether it is valid or not to 
just leave the version part out completely.


In my understanding the regex needs to be fully matched which means 
you cannot just leave it out completely – but it is not 100% clear 
from the specs as far as I can see (but see my excerpt from the ADL2 
specs from before).


if you are using the regex to validate ids, then you will need the full 
regex to match any valid id. If the regex is just to filter out ids that 
are validated elsewhere then you can minimise the regex.


If we assume the regex does NOT need to be a full match, then the 
validation errors from CKM below are bogus of course.


But if partial matches are sufficient, this in turn requires some 
reinterpretation of existing regexes as well:


For example, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 would 
then also match openEHR-EHR-OBSERVATION.body_mass_index.v15 (or v10 
v11 etc. for example)


The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] 
means that not only v0, v1, v2 are valid, but also v10, v15, v27 to 
name a few.


the regex character class [0-2] matches only a single digit having the 
character values in the series 0-2, i.e. 0, 1, or 2.


Now that you mention it, I do seem to remember we specified a very long 
time ago that those regexes did have to be full validating ones. So that 
means using something more like


openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*)){0.2}

as the checker regex in CKM, and patterns like 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v.*, where 
the trailing '.*' matches anything, and the validator regex ensures it 
is only semver dotted version patterns.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

AW: Syntax for including archetypes in SLOTs, regardless of version

[Sebastian Garde]

Hi Silje, hi Thomas, hi all,

Whether the CKM validation errors from below are correct or bogus boils down to 
my question from before whether it is valid or not to just leave the version 
part out completely.
In my understanding the regex needs to be fully matched which means you cannot 
just leave it out completely – but it is not 100% clear from the specs as far 
as I can see (but see my excerpt from the ADL2 specs from before).

If we assume the regex does NOT need to be a full match, then the validation 
errors from CKM below are bogus of course.
But if partial matches are sufficient, this in turn requires some 
reinterpretation of existing regexes as well:
For example, openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 
would then also match openEHR-EHR-OBSERVATION.body_mass_index.v15 (or v10 v11 
etc. for example)

The example below 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2] means that 
not only v0, v1, v2 are valid, but also v10, v15, v27 to name a few.

A few archetypes in CKM (demographics mainly I think) have shortened this 
further to omit the openEHR-EHR- prefix. This currently turns up as a 
validation error in CKM as well, but in the partial match interpretation, it 
would be validit can be seen as  brief and elegant or regarded as confusing 
(especially with CLUSTERs from the EHR or DEMOGRAPHIC parts).

Personally, I think it is better to always require a full match here – this is 
more explicit and avoids unintended side-effects like the ones described above.
But most importantly, I think this needs to be clarified so that either that 
regex or one with additional open version regex can be used to describe what 
you want to model: any version is allowed (and a template can then tie this 
down).

Regards,
Sebastian
Von: openEHR-technical  Im Auftrag 
von Bakke, Silje Ljosland
Gesendet: Dienstag, 18. Dezember 2018 15:15
An: For openEHR technical discussions 
Betreff: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image002.jpg@01D496F8.22699E70]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for i

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image001.jpg@01D496E4.7F780930]

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Project, Intermountain 
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR 
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer 
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture 
blog<http://wolandsothercat.net/> | The Objective 
Stance<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

For reference, these are the various regexes I use in the ADL workbench 
.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Syntax for including archetypes in SLOTs, regardless of version

[Karsten Hilbert]

On Tue, Dec 18, 2018 at 01:17:38PM +0100, Karsten Hilbert wrote:

> > In other words, add a pattern to catch “any single (possibly double) digit 
> > version number” (?).
> 
>   \d{1,2}

Ah, sorry, was misled by *number*.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Syntax for including archetypes in SLOTs, regardless of version

[Thomas Beale]

Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.


is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically 
different archetypes - i.e. they contain some breaking change. So 
whether allowing any major version of an archetype in a slot is a good 
default probably needs to be thought about carefully.


- thomas

On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:


Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY 
archetypes, or ENTRY archetypes within COMPOSITIONs or SECTIONs). At 
the moment this has to be noted explicitly (whether because of tooling 
or the specifications, I don’t know), so that in order to include for 
example all historical versions and specialisations of the Body Mass 
Index archetype in a COMPOSITION or SECTION, I have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we 
ever make a v3 BMI archetype, this will then need to be added. This is 
a hassle when modelling archetypes in the first place, and it’s an 
even worse problem for governing them over time.


Based on the discussion I had with Sebastian, and with the kind help 
of some regex geeks on Twitter (you know who you are ), I propose 
one of the following as the default syntax for including any version 
of a given archetype in a SLOT:


 1. An explicit regex for the version number, for example

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
 2. Leaving out entirely the version part of the expression, for
example openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be /possible/ to include a specific version of 
the archetype, but that this should not be the default behaviour of 
the tools.


I don’t particularly care if one of these two suggestions, or an 
entirely different solution, is adopted, but this issue has to be 
decided and implemented soon.


Kind regards,
*Silje Ljosland Bakke*

**

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web: http://arketyper.no <http://arketyper.no/>/ Twitter: 
@arketyper_no <https://twitter.com/arketyper_no>



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Syntax for including archetypes in SLOTs, regardless of version

[Karsten Hilbert]

On Tue, Dec 18, 2018 at 12:09:56PM +, Bakke, Silje Ljosland wrote:

> In other words, add a pattern to catch “any single (possibly double) digit 
> version number” (?).

\d{1,2}

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

v[0-9][0-9] would also include v00-v09, which we don’t want.

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Anastasiou A.
Sent: Tuesday, December 18, 2018 1:04 PM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi Silje

I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about 
what follows “body_mass_index”) ?

In other words, add a pattern to catch “any single (possibly double) digit 
version number” (?).

This looks like a straightforward case of “constrain to 
openEHR-EHR-OBSERVATION\.body_mass_index”.

All the best
Athanasios Anastasiou




From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: Syntax for including archetypes in SLOTs, regardless of version

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Syntax for including archetypes in SLOTs, regardless of version

[Anastasiou A .]

Hi Silje

I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about 
what follows “body_mass_index”) ?

In other words, add a pattern to catch “any single (possibly double) digit 
version number” (?).

This looks like a straightforward case of “constrain to 
openEHR-EHR-OBSERVATION\.body_mass_index”.

All the best
Athanasios Anastasiou




From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
Subject: Syntax for including archetypes in SLOTs, regardless of version

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Bert Verhees]

On 12-12-18 15:44, Diego Boscá wrote:
When I say official I refer to AOM. If AOM/ADL let's you say something 
we try to support it. We always 'eat' what others tools produce, and 
have implemented export mechanisms to be compatible with the things 
other tools can handle. In this particular case you mentioned, an 
exported archetype from LinkEHR can be opened in any other archetype 
editor directly. We also gave support for OPT & OET import/export, and 
even OPTs generated this way are virtually identical to the ones 
coming from the template designer.


So yes, we have tweaked the parser to support more things, but the 
archetype creation is completely RM driven (archetypes created with 
LinkEHR are always compliant with the RM you choose). That created 
archetype can be then saved to different representations depending of 
your needs (ADL for specific tools, XML, etc).


Congratulations, I think now nobody has any doubt.

Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

We plan in using Archie library when we migrate our tools for ADL2 :)

El mié., 12 dic. 2018 15:24, Thomas Beale 
escribió:

> You can always check conformance with the ADL Workbench, it will consume
> ADL1.4 and ADL2. And Archie now produces the same regression results as
> ADL WB, so it could be used as well, and in future, will probably become
> the main reference tool.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

When I say official I refer to AOM. If AOM/ADL let's you say something we
try to support it. We always 'eat' what others tools produce, and have
implemented export mechanisms to be compatible with the things other tools
can handle. In this particular case you mentioned, an exported archetype
from LinkEHR can be opened in any other archetype editor directly. We also
gave support for OPT & OET import/export, and even OPTs generated this way
are virtually identical to the ones coming from the template designer.

So yes, we have tweaked the parser to support more things, but the
archetype creation is completely RM driven (archetypes created with LinkEHR
are always compliant with the RM you choose). That created archetype can be
then saved to different representations depending of your needs (ADL for
specific tools, XML, etc).

Regards

El mié., 12 dic. 2018 15:09, Bert Verhees  escribió:

> On 12-12-18 14:49, Diego Boscá wrote:
> > These are modifications on the parser, which parses more things than
> > your standard parser. In fact, the editor supports legal things in ADL
> > that other parsers don't (e.g. explicit node identifiers or
> > existence). The generated ADL is completely fine ADL. There are tools
> > that don't comply with this general ADL, and we provided an export
> > version of archetypes that produces a modified version of the ADL
> > syntax that other older and not maintained tools can parse.
> > If you want to call this subset "official archetypes" be my guest.
>
> The word "official" was used by you, I used it (in quotes) to indicate
> that we refer to the same.
>
> But it may get confusing, also because in the past there were
> discussions about LinkEhr and the Ocean archetype-editor which had
> different interpretations of the prevailing definitions. They did not
> always eat each others archetypes.
>
> I think at this point it is important to state in a simple way, then
> there will be no reason for doubt about intentions:
>
> Does the LinkEhr editor produce archetypes which are always intended to
> be completely conforming the official ADL/AOM and RM definitions?
>
> Best regards
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>

El mié., 12 dic. 2018 15:09, Bert Verhees  escribió:

> On 12-12-18 14:49, Diego Boscá wrote:
> > These are modifications on the parser, which parses more things than
> > your standard parser. In fact, the editor supports legal things in ADL
> > that other parsers don't (e.g. explicit node identifiers or
> > existence). The generated ADL is completely fine ADL. There are tools
> > that don't comply with this general ADL, and we provided an export
> > version of archetypes that produces a modified version of the ADL
> > syntax that other older and not maintained tools can parse.
> > If you want to call this subset "official archetypes" be my guest.
>
> The word "official" was used by you, I used it (in quotes) to indicate
> that we refer to the same.
>
> But it may get confusing, also because in the past there were
> discussions about LinkEhr and the Ocean archetype-editor which had
> different interpretations of the prevailing definitions. They did not
> always eat each others archetypes.
>
> I think at this point it is important to state in a simple way, then
> there will be no reason for doubt about intentions:
>
> Does the LinkEhr editor produce archetypes which are always intended to
> be completely conforming the official ADL/AOM and RM definitions?
>
> Best regards
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Thomas Beale]

You can always check conformance with the ADL Workbench, it will consume 
ADL1.4 and ADL2. And Archie now produces the same regression results as 
ADL WB, so it could be used as well, and in future, will probably become 
the main reference tool.


- thomas



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Bert Verhees]

On 12-12-18 14:49, Diego Boscá wrote:
These are modifications on the parser, which parses more things than 
your standard parser. In fact, the editor supports legal things in ADL 
that other parsers don't (e.g. explicit node identifiers or 
existence). The generated ADL is completely fine ADL. There are tools 
that don't comply with this general ADL, and we provided an export 
version of archetypes that produces a modified version of the ADL 
syntax that other older and not maintained tools can parse.

If you want to call this subset "official archetypes" be my guest.


The word "official" was used by you, I used it (in quotes) to indicate 
that we refer to the same.


But it may get confusing, also because in the past there were 
discussions about LinkEhr and the Ocean archetype-editor which had 
different interpretations of the prevailing definitions. They did not 
always eat each others archetypes.


I think at this point it is important to state in a simple way, then 
there will be no reason for doubt about intentions:


Does the LinkEhr editor produce archetypes which are always intended to 
be completely conforming the official ADL/AOM and RM definitions?


Best regards

Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

These are modifications on the parser, which parses more things than your
standard parser. In fact, the editor supports legal things in ADL that
other parsers don't (e.g. explicit node identifiers or existence). The
generated ADL is completely fine ADL. There are tools that don't comply
with this general ADL, and we provided an export version of archetypes that
produces a modified version of the ADL syntax that other older and not
maintained tools can parse.
If you want to call this subset "official archetypes" be my guest.


El mié., 12 dic. 2018 a las 14:28, Bert Verhees ()
escribió:

> On 12-12-18 13:48, Diego Boscá wrote:
> > The official one, these are 'hacks' that allow you to handle
> > requirements and edge cases only present in these RM archetypes
>
> Diego, I don't want to be harsh about LinkEhr, which is a very strong
> product. But this situation raises questions. I already had this
> discussion a few times.
>
> Especially because it is not mentioned on the LinkEhr website that it
> does not support the official OpenEhr out of the box.
>
> You should have an option in the application for creating "official"
> archetypes, this to avoid confusion.
>
> I think it is very good that you fix issues you experience, but this
> way, by implementing without explicit notifying does not seem the royal
> way.
>
> It is bad, because in this way, the OpenEhr-software-ecosystem-base may
> become too narrow, and it is easy to fix by you, as you indicate to
> Georg Fette
>
> Best regards
>
> Bert
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Bert Verhees]

On 12-12-18 13:48, Diego Boscá wrote:
The official one, these are 'hacks' that allow you to handle 
requirements and edge cases only present in these RM archetypes


Diego, I don't want to be harsh about LinkEhr, which is a very strong 
product. But this situation raises questions. I already had this 
discussion a few times.


Especially because it is not mentioned on the LinkEhr website that it 
does not support the official OpenEhr out of the box.


You should have an option in the application for creating "official" 
archetypes, this to avoid confusion.


I think it is very good that you fix issues you experience, but this 
way, by implementing without explicit notifying does not seem the royal way.


It is bad, because in this way, the OpenEhr-software-ecosystem-base may 
become too narrow, and it is easy to fix by you, as you indicate to 
Georg Fette


Best regards

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

I don't think they are currently generated, but you can generate them if
you reimport the model and select them

El mié., 12 dic. 2018 a las 13:44, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hello,
> In the LinkEHR files the archetypes for the "EHR Infomation Model" are
> contained (ACTION, CLUSTER, etc.). Are there also somewhere archetypes
> that describe the "Data Types Information Model" (e.g. DV_QUANTITY,
> DV_MEDIA, etc.).
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

The official one, these are 'hacks' that allow you to handle requirements
and edge cases only present in these RM archetypes

El mié., 12 dic. 2018 a las 13:41, Bert Verhees ()
escribió:

> On 12-12-18 12:53, Diego Boscá wrote:
> > We used that one as a basis and generalized mostly to allow the
> > special RM 'at' codes we created. I can send you the modified grammar
> > or the parser if you want.
>
> Wouldn't that disturb interoperability processes? One could wonder:
> Which one is the right grammar, which one is the right parser?
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

Grammar (and parser classes) are derived from the original one available in
the repo, so the same license applies.
These are edge cases we detected the original parser didn't treat well
(recursive internal references) and were also fixed.

El mié., 12 dic. 2018 a las 13:19, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> Yes, if you have a working parser for those archetypes that would be
> useful. The modified grammer would also be useful.
> What are the copyright constraints on your parser and your grammmer file ?
> I managed to get one of the archetypes parsed by lowercasing the
> language codes and removing all elements that include a recursive
> use_node statement.
> Is the inability to parse use_nodes that reference a node upwards in the
> same branch of the element a bug in version 1.0.71 ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Georg Fette]

Hello,
In the LinkEHR files the archetypes for the "EHR Infomation Model" are 
contained (ACTION, CLUSTER, etc.). Are there also somewhere archetypes 
that describe the "Data Types Information Model" (e.g. DV_QUANTITY, 
DV_MEDIA, etc.).

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Bert Verhees]

On 12-12-18 12:53, Diego Boscá wrote:
We used that one as a basis and generalized mostly to allow the 
special RM 'at' codes we created. I can send you the modified grammar 
or the parser if you want.


Wouldn't that disturb interoperability processes? One could wonder: 
Which one is the right grammar, which one is the right parser?


Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Georg Fette]

Hi Diego,
In the Archetypes contained in the LinkEHR files I am missing the 
subclasses that are subclassed by the root archetypes. In ACTION for 
example the subclass INSTRUCTION_DETAILS is used. This is used in the 
ACTION.adl file and it is parseable but I wonder if there is an 
INSTRUCTION_DETAILS.adl file somewhere, which possibly defines something 
that is not yet defined in the ACTION.adl file. Or can be assumed that 
the subclasses wherever they are mentioned are fully desribed at the 
places where they are introduced ?

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Georg Fette]

Hi Diego,
Yes, if you have a working parser for those archetypes that would be 
useful. The modified grammer would also be useful.

What are the copyright constraints on your parser and your grammmer file ?
I managed to get one of the archetypes parsed by lowercasing the 
language codes and removing all elements that include a recursive 
use_node statement.
Is the inability to parse use_nodes that reference a node upwards in the 
same branch of the element a bug in version 1.0.71 ?

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

We used that one as a basis and generalized mostly to allow the special RM
'at' codes we created. I can send you the modified grammar or the parser if
you want.

El mié., 12 dic. 2018 a las 12:46, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> I just tried to parse the .adl files from LinkEHR and got several
> Exceptions. I currently use the adl-parser from
> org.openehr.java-libs_v_1.0.71.
> Which parser can I use to parse those archetypes ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Georg Fette]

Hi Diego,
I just tried to parse the .adl files from LinkEHR and got several 
Exceptions. I currently use the adl-parser from 
org.openehr.java-libs_v_1.0.71.

Which parser can I use to parse those archetypes ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

They are generated from different "root" XML Schemas (demographics and
ehr), but in principle the contents should be the same. Models are
generated in a standalone way, so no assumptions are made regarding if ehr
model shares classes with demographic one (or any other model already
imported). As they are archetypes from these classes on the demographic
archetypes of CKM, the classes were selected as archetypable in the RM
import process, and thus generated. They should virtually equivalent (apart
from changes in the archetype identifier).



El mié., 12 dic. 2018 a las 12:21, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Diego,
> Thank you, that is exactly what I was looking for.
> In the DEMOGRAPHICS and the EHR package there are 6 archetypes which
> have the same name but differ only in their full path name: CLUSTER,
> ELEMENT, ITEM_LIST, ITEM_SINGLE, ITEM_TABLE and ITEM_TREE. Why are they
> two versions of those archetypes with almost identical content ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Georg Fette]

Hi Diego,
Thank you, that is exactly what I was looking for.
In the DEMOGRAPHICS and the EHR package there are 6 archetypes which 
have the same name but differ only in their full path name: CLUSTER, 
ELEMENT, ITEM_LIST, ITEM_SINGLE, ITEM_TABLE and ITEM_TREE. Why are they 
two versions of those archetypes with almost identical content ?

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

But in this case the archetype you create couldn't be use for validation
purposes. I think I'm not fully understanding what you mean with this

El mar., 11 dic. 2018 a las 12:37, Thomas Beale ()
escribió:

> I think this is more or less the same as a kind of archetype with no codes
> at all, only containing RM elements.
>
> I was expecting something more like:
> CLASS [Observation_code] matches {
> attributes matches {
> ATTRIBUTE [Observation_data_code] matches {
> name matches {"data"}
> ...
> }
> ATTRIBUTE [Observation_state_code] matches {
> name matches {"state"}
> ...
> }
> }
> }
>
> or you could do it with C_OBJECT and C_ATTRIBUTE, which is a workable
> meta-model.
>
> - thomas
> On 11/12/2018 10:58, Diego Boscá wrote:
>
> As an example, this is the Observation archetype
>
> https://pastebin.com/WhehexLR
>
> El mar., 11 dic. 2018 a las 11:53, Diego Boscá ()
> escribió:
>
>> It is basically AOM, serialized as ADL files
>>
>> El mar., 11 dic. 2018 a las 11:51, Thomas Beale (<
>> thomas.be...@openehr.org>) escribió:
>>
>>> Diego,
>>>
>>> what do you use as the underlying information model in that case?
>>> Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?
>>>
>>> - thomas
>>>
>>> On 11/12/2018 09:40, Diego Boscá wrote:
>>> > Hi Georg,
>>> >
>>> > That's exactly how we define reference models with LinkEHR. We
>>> > generated them from the XSD schemas (and more recently, from BMM). It
>>> > fits quite nicely with the archetype methodology (every archetype is
>>> > an specialization, which eases validation).
>>> > If you want to try or test them you can download LinkEHR and get them
>>> > from there.
>>> >
>>> > Regards
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] 
>>
>> [image: Twitter]   [image: LinkedIn]
>>  [image: Maps]
>> 
>>
>> Diego Boscá Tomás / Senior developer
>> diebo...@veratech.es
>> yamp...@gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> d...@veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido incorporados en el sistema de tratamiento
> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
> rectificación, limitación de tratamiento, supresión, portabilidad y
> oposición/revocación, en los términos que establece la normativa vigente en
> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
> d...@veratech.es
>
> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
> el agente responsable de entregar el mensaje al destinatario, o 

Re: Reference Model as Archetypes ?

[Thomas Beale]

I think this is more or less the same as a kind of archetype with no 
codes at all, only containing RM elements.


I was expecting something more like:

CLASS [Observation_code] matches {
    attributes matches {
    ATTRIBUTE [Observation_data_code] matches {
    name matches {"data"}
    ...
    }
    ATTRIBUTE [Observation_state_code] matches {
    name matches {"state"}
    ...
    }
    }
}

or you could do it with C_OBJECT and C_ATTRIBUTE, which is a workable 
meta-model.


- thomas

On 11/12/2018 10:58, Diego Boscá wrote:

As an example, this is the Observation archetype

https://pastebin.com/WhehexLR

El mar., 11 dic. 2018 a las 11:53, Diego Boscá (>) escribió:


It is basically AOM, serialized as ADL files

El mar., 11 dic. 2018 a las 11:51, Thomas Beale
(mailto:thomas.be...@openehr.org>>)
escribió:

Diego,

what do you use as the underlying information model in that case?
Presumably the BMM/UML meta-model, i.e. things like Class,
Attribute etc?

- thomas

On 11/12/2018 09:40, Diego Boscá wrote:
> Hi Georg,
>
> That's exactly how we define reference models with LinkEHR. We
> generated them from the XSD schemas (and more recently, from
BMM). It
> fits quite nicely with the archetype methodology (every
archetype is
> an specialization, which eases validation).
> If you want to try or test them you can download LinkEHR and
get them
> from there.
>
> Regards


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



-- 


VeraTech for Health SL 

Twitter LinkedIn
Maps


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com 

VeraTech for Health SL
+34 654604676 
www.veratech.es 

La información contenida en este mensaje y/o archivo(s)
adjunto(s), enviada desde VERATECH FOR HEALTH, SL, es
confidencial/privilegiada y está destinada a ser leída sólo por
la(s) persona(s) a la(s) que va dirigida. Le recordamos que sus
datos han sido incorporados en el sistema de tratamiento de
VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los
requisitos exigidos por la normativa, usted podrá ejercer sus
derechos de acceso, rectificación, limitación de tratamiento,
supresión, portabilidad y oposición/revocación, en los términos
que establece la normativa vigente en materia de protección de
datos, dirigiendo su petición a Avda Puerto 237, 1º, pta 1 - 46011
Valencia o bien a través de correo electrónico d...@veratech.es


Si usted lee este mensaje y no es el destinatario señalado, el
empleado o el agente responsable de entregar el mensaje al
destinatario, o ha recibido esta comunicación por error, le
informamos que está totalmente prohibida, y puede ser ilegal,
cualquier divulgación, distribución o reproducción de esta
comunicación, y le rogamos que nos lo notifique inmediatamente y
nos devuelva el mensaje original a la dirección arriba mencionada.
Gracias



--

VeraTech for Health SL 

Twitter LinkedIn 
Maps 



Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com 

VeraTech for Health SL
+34 654604676 
www.veratech.es 

La información contenida en este mensaje y/o archivo(s) adjunto(s), 
enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y 
está destinada a ser leída sólo por la(s) persona(s) a la(s) que va 
dirigida. Le recordamos que sus datos han sido incorporados en el 
sistema de tratamiento de VERATECH FOR HEALTH, SL y que siempre y 
cuando se cumplan los requisitos exigidos por la normativa, usted 
podrá ejercer sus derechos de acceso, rectificación, limitación de 
tratamiento, supresión, portabilidad y oposición/revocación, en los 
términos que establece la normativa vigente en materia de protección 
de datos, dirigiendo su petición a Avda Puerto 237, 1º, pta 1 - 46011 
Valencia o bien a través de correo electrónico d...@veratech.es 



Si usted lee este mensaje y no es el destinatario señalado, el 
empleado o el agente responsable de entregar el mensaje al 

Re: Reference Model as Archetypes ?

[Diego Boscá]

As an example, this is the Observation archetype

https://pastebin.com/WhehexLR

El mar., 11 dic. 2018 a las 11:53, Diego Boscá ()
escribió:

> It is basically AOM, serialized as ADL files
>
> El mar., 11 dic. 2018 a las 11:51, Thomas Beale ()
> escribió:
>
>> Diego,
>>
>> what do you use as the underlying information model in that case?
>> Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?
>>
>> - thomas
>>
>> On 11/12/2018 09:40, Diego Boscá wrote:
>> > Hi Georg,
>> >
>> > That's exactly how we define reference models with LinkEHR. We
>> > generated them from the XSD schemas (and more recently, from BMM). It
>> > fits quite nicely with the archetype methodology (every archetype is
>> > an specialization, which eases validation).
>> > If you want to try or test them you can download LinkEHR and get them
>> > from there.
>> >
>> > Regards
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 654604676 <+34%20654604676>
> www.veratech.es
>
> La información contenida en este mensaje y/o archivo(s) adjunto(s),
> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
> recordamos que sus datos han sido incorporados en el sistema de tratamiento
> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
> rectificación, limitación de tratamiento, supresión, portabilidad y
> oposición/revocación, en los términos que establece la normativa vigente en
> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
> d...@veratech.es
>
> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
> el agente responsable de entregar el mensaje al destinatario, o ha recibido
> esta comunicación por error, le informamos que está totalmente prohibida, y
> puede ser ilegal, cualquier divulgación, distribución o reproducción de
> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

It is basically AOM, serialized as ADL files

El mar., 11 dic. 2018 a las 11:51, Thomas Beale ()
escribió:

> Diego,
>
> what do you use as the underlying information model in that case?
> Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?
>
> - thomas
>
> On 11/12/2018 09:40, Diego Boscá wrote:
> > Hi Georg,
> >
> > That's exactly how we define reference models with LinkEHR. We
> > generated them from the XSD schemas (and more recently, from BMM). It
> > fits quite nicely with the archetype methodology (every archetype is
> > an specialization, which eases validation).
> > If you want to try or test them you can download LinkEHR and get them
> > from there.
> >
> > Regards
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Thomas Beale]

Diego,

what do you use as the underlying information model in that case? 
Presumably the BMM/UML meta-model, i.e. things like Class, Attribute etc?


- thomas

On 11/12/2018 09:40, Diego Boscá wrote:

Hi Georg,

That's exactly how we define reference models with LinkEHR. We 
generated them from the XSD schemas (and more recently, from BMM). It 
fits quite nicely with the archetype methodology (every archetype is 
an specialization, which eases validation).
If you want to try or test them you can download LinkEHR and get them 
from there.


Regards



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Reference Model as Archetypes ?

[Diego Boscá]

Hi Georg,

That's exactly how we define reference models with LinkEHR. We generated
them from the XSD schemas (and more recently, from BMM). It fits quite
nicely with the archetype methodology (every archetype is an
specialization, which eases validation).
If you want to try or test them you can download LinkEHR and get them from
there.

Regards

El mar., 11 dic. 2018 a las 10:20, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hello,
> Is there somewere a machine readable definition available which
> describes the content of the openEHR Reference Model as Archetypes ?
> The Reference Model classes should be expressable as Archetypes,
> shouldn't they ? At least concerning their logical data model. The
> methods they also possibly provide can hardly be expressed using
> Archetypes.
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reference Model as Archetypes ?

[Georg Fette]

Hello,
Is there somewere a machine readable definition available which 
describes the content of the openEHR Reference Model as Archetypes ?
The Reference Model classes should be expressable as Archetypes, 
shouldn't they ? At least concerning their logical data model. The 
methods they also possibly provide can hardly be expressed using Archetypes.

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Bert Verhees]

On 12-11-18 18:40, Bert Verhees wrote:

>> Another very important restriction for using XML Schema, in my opinion,
>> is that you cannot have two or more elements with the same name but a
>> different data type. This data type must be in detail the same. XML Schema
>> regards an Element with a Dv_Text as a different datatype from an Element
>> with a Dv_CodedText.
>>
>> Both elements will be called "items" in an XML schema representing an
>> OpenEhr data structure, and thus is not allowed having them different
>> details in data types.


This already happens in a Item-List, so the constraint is quite easy to 
trigger.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Bert Verhees]

On 12-11-18 17:59, Thomas Beale wrote:



On 12/11/2018 16:04, Bert Verhees wrote:

On 12-11-18 16:13, Thomas Beale wrote:
you can, it's called a Template Data Schema (TDS), and is generated 
from the Template Designer and I think the new Marand ADL-designer. 
Its intended exactly for checking data sets...


Of course you can write any validation tool you want,  but you cannot 
do this and still conform to the XML Schema standard, that is why 
Schematron became important. With Schematron you can validate 
anything. As I wrote this morning, LinkEhr also generates Schematron 
for validation purpose.


this already works (for nearly 10 years) and it validates against the 
XML schema standard. What it doesn't do is validate everything you 
want to validate, i.e. not all things in the archetypes. But it's good 
enough most of the time.



I am in the proud possession of the book, "Definitive XML Schema 1.1" by 
Priscilla Walmsley. We had this discussion a few times already

I quote from
https://www.mail-archive.com/search?q=walmsley=openehr-technical%40lists.openehr.org
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg07405.html


Another very important restriction for using XML Schema, in my opinion,
is that you cannot have two or more elements with the same name but a
different data type. This data type must be in detail the same. XML Schema
regards an Element with a Dv_Text as a different datatype from an Element
with a Dv_CodedText.

Both elements will be called "items" in an XML schema representing an
OpenEhr data structure, and thus is not allowed having them different
details in data types.


Sorry for the funny font,

To do things properly, I agree, you would probably use Schematron + 
XSD, or personally I have always thought that Schematron + Relax-NG 
would be better.


Also I went through that path, with Relax NG, I struggled quite some 
time with this, and not me alone. Ask Diego why LinkEhr does not export 
RelaxNG or XML Schema but Schematron as validation files (although, it 
was like this a few years ago, it still is so in the version I have).


The XSD standard-constraint mentioned above also becomes visible with 
standard XML libraries. If I would have time I would proof it to you in 
a simple way.




whether this is the real requirement being talked about here may be 
another question.


You are right, it was not what was asked, still I thought it would be 
interesting for others to know that there is a JSON Schematron parser 
(instead of an XML Schematron-parser), which can be used to validate 
JSON OpenEhr-datasets against archetypes/templates.


that might be an interesting thing to have in the openEHR toolkit. We 
are just now revising and re-organising all the openEHR XSDs, and also 
adding in some JSON-schemas. Any related artefacts that anyone wants 
to contribute, or fragments that could be used in something larger 
would be appreciated - it will all get posted in the 
specifications-ITS-XML git repo under the usual CC licence.


OpenEhr uses XSD schemas for class descriptions, there is no problem at 
all. It is even an often used methodology in the Java world to 
describe/generate class-interfaces. The problem is when using XML Schema 
for validation of archetyped XML-data. But again, this was not the 
problem the question was initially about. Sorry for the confusion.


Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Bert Verhees]

On 12-11-18 16:13, Thomas Beale wrote:


On 12/11/2018 09:44, Bert Verhees wrote:


Sorry, I first replied to Pieter Bos only, now to the list. Pieter 
already replied to me that the question was not about XSD to check 
datasets was .


So, read my reply, for those interested in easy validating datasets:

It is possible to have an XSD to describe the AOM, but you cannot 
have an XSD to describe an archetype and check a dataset with it.


you can, it's called a Template Data Schema (TDS), and is generated 
from the Template Designer and I think the new Marand ADL-designer. 
Its intended exactly for checking data sets...


Of course you can write any validation tool you want,  but you cannot do 
this and still conform to the XML Schema standard, that is why 
Schematron became important. With Schematron you can validate anything. 
As I wrote this morning, LinkEhr also generates Schematron for 
validation purpose.




whether this is the real requirement being talked about here may be 
another question.


You are right, it was not what was asked, still I thought it would be 
interesting for others to know that there is a JSON Schematron parser 
(instead of an XML Schematron-parser), which can be used to validate 
JSON OpenEhr-datasets against archetypes/templates.


I wrote an AOM(OpenEhr/CEN13606)-Schematron-validation-generator years 
ago, exactly for this reason, I must have the sourcecode somewhere. Good 
for Marand to have validation too, because checking data-sets before 
storing them is an important responsibility of an OpenEhr-kernel.


Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Thomas Beale]

On 12/11/2018 16:04, Bert Verhees wrote:

On 12-11-18 16:13, Thomas Beale wrote:
you can, it's called a Template Data Schema (TDS), and is generated 
from the Template Designer and I think the new Marand ADL-designer. 
Its intended exactly for checking data sets...


Of course you can write any validation tool you want,  but you cannot 
do this and still conform to the XML Schema standard, that is why 
Schematron became important. With Schematron you can validate 
anything. As I wrote this morning, LinkEhr also generates Schematron 
for validation purpose.


this already works (for nearly 10 years) and it validates against the 
XML schema standard. What it doesn't do is validate everything you want 
to validate, i.e. not all things in the archetypes. But it's good enough 
most of the time.


To do things properly, I agree, you would probably use Schematron + XSD, 
or personally I have always thought that Schematron + Relax-NG would be 
better.




whether this is the real requirement being talked about here may be 
another question.


You are right, it was not what was asked, still I thought it would be 
interesting for others to know that there is a JSON Schematron parser 
(instead of an XML Schematron-parser), which can be used to validate 
JSON OpenEhr-datasets against archetypes/templates.


that might be an interesting thing to have in the openEHR toolkit. We 
are just now revising and re-organising all the openEHR XSDs, and also 
adding in some JSON-schemas. Any related artefacts that anyone wants to 
contribute, or fragments that could be used in something larger would be 
appreciated - it will all get posted in the specifications-ITS-XML git 
repo under the usual CC licence.


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Thomas Beale]

On 12/11/2018 09:44, Bert Verhees wrote:


Sorry, I first replied to Pieter Bos only, now to the list. Pieter 
already replied to me that the question was not about XSD to check 
datasets was .


So, read my reply, for those interested in easy validating datasets:

It is possible to have an XSD to describe the AOM, but you cannot have 
an XSD to describe an archetype and check a dataset with it.


you can, it's called a Template Data Schema (TDS), and is generated from 
the Template Designer and I think the new Marand ADL-designer. Its 
intended exactly for checking data sets...


whether this is the real requirement being talked about here may be 
another question.


- thomas



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Pieter Bos]

Yes, https://github.com/openEHR/java-libs works for ADL 1.4.

If you want the latest and newest, ADL 2 is the way to go. You can convert the 
archetypes to ADL 2 using the ADL workbench and they will parse with Archie. 
The workbench can be found at http://www.openehr.org.

If you want compatibility with existing systems, ADL 1.4 for now – I think most 
EHRs are 1.4 only at the moment.

Regards,

Pieter Bos

From: openEHR-technical  on behalf 
of Diego Boscá 
Reply-To: For openEHR technical discussions 

Date: Monday, 12 November 2018 at 13:44
To: For openEHR technical discussions 
Subject: Re: Parsing of Archetypes/Templates

Hello Georg,

Archie is meant to be used with ADL2 archetypes, if you want to parse 1.4 
archetypes I think java implementation you mentioned before is your current 
best option.

Regards

El lun., 12 nov. 2018 a las 13:40, Georg Fette 
(mailto:georg.fe...@uni-wuerzburg.de>>) escribió:
Hi Peter,
The Archie-Toolkit looks promising.

I tried to parse one of the archetypes from the CKM (BloodPressure) and
tried to parse the exported ADL. However, I got a Exception when trying
this because the exported ADL does not seem to be parseable:
line 1:24 mismatched input '1.4' expecting VERSION_ID
line 2:1 mismatched input 'openEHR-EHR-OBSERVATION.blood_pressure.v1'
expecting ARCHETYPE_HRID

With the exported XML and the try to unmarshal the XML with the JAXBUtil
I also did not succeed. Is there somewhere a testcase were I can see a
working example of a parsed ADL String ?

Greetings
Georg

Hello George,

If you are looking for something to handle ADL 2 archetypes - the most
recent version -, have a look at https://github.com/opener/archie . It
is a java library that can parse archetypes, flatten and validate  them,
create operational templates and more.

Are you using the openehr reference model, or something else like fihr?

Although Archie can parse and serialize archetypes in XML, archetypes
are usually stored as ADL. This is a custom more readable format. Of
course you can then easily convert it to XML or Json to work with them
in other tools where you do not have an ADL parser ready.

Note that for ADL 2 as far as I know there is no official XSD released
yet, so it is possible you run into compatibility problems with XML. For
ADL 1.4 this is not a problem.

Regards,

Pieter Bos

Am 12.11.2018 um 09:18 schrieb Georg Fette:
> Hello,
> For a project we want to create a generic mechanism to transform
> archetypes into FHIR Logical Models, so we can store, retrieve and
> query archetype instance with FHIR tools (CQL, FHIR-REST-API-query).
> At the moment we just want to read/write archetypes and not archetype
> instances. We are looking for existing components to parse and process
> archetypes. I have some questions I encountered related to these issues:
> - I have found several projects that store openEHR-data (archetypes as
> well as archetype instances) into different data substrates (Neo4J,
> ARM (archetype relational mapping), EtherCIS). Although I have not yet
> looked at the code of these projects I assume that they take an
> archetype XML-file, parse it and thus create a runtime object of the
> archetype. That runtime object can then be given as a parameter to a
> persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse
> something from already existing projects I am looking for a parser
> that creates a runtime object from an archetype-XML-String, so we can
> write our own components that transform it into a FHIR runtime object.
> The component we are looking for should preferably be written in Java,
> as this is our language of choice in our project.
> - I am not ye sure if we are looking for a method to transform
> archetypes, templates or operational templates into FHIR related
> structures, as I am not yet that familiar with which data structure is
> preferably used for which kind of task. Therefore, component that,
> instead of archetypes, parse templates or operational templates would
> be appreciated as well.
> Greetings
> Georg
>

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: 
georg.fe...@uni-wuerzburg.de<mailto:georg.fe...@uni-wuerzburg.de>
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--

[VeraTech for Health SL]<https://htmlsig.com/t/01C268PZ>

[Twitter] <https://htmlsig.com/t/01C47QQH>  [LinkedIn]  
<https://htmlsig.com/t/01C4DPJG>  [Maps]  
<https://htmlsig.com/t/00

Re: Parsing of Archetypes/Templates

[Diego Boscá]

Hello Georg,

Archie is meant to be used with ADL2 archetypes, if you want to parse 1.4
archetypes I think java implementation you mentioned before is your current
best option.

Regards

El lun., 12 nov. 2018 a las 13:40, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> Hi Peter,
> The Archie-Toolkit looks promising.
>
> I tried to parse one of the archetypes from the CKM (BloodPressure) and
> tried to parse the exported ADL. However, I got a Exception when trying
> this because the exported ADL does not seem to be parseable:
> line 1:24 mismatched input '1.4' expecting VERSION_ID
> line 2:1 mismatched input 'openEHR-EHR-OBSERVATION.blood_pressure.v1'
> expecting ARCHETYPE_HRID
>
> With the exported XML and the try to unmarshal the XML with the JAXBUtil
> I also did not succeed. Is there somewhere a testcase were I can see a
> working example of a parsed ADL String ?
>
> Greetings
> Georg
>
> Hello George,
>
> If you are looking for something to handle ADL 2 archetypes - the most
> recent version -, have a look at https://github.com/opener/archie . It
> is a java library that can parse archetypes, flatten and validate  them,
> create operational templates and more.
>
> Are you using the openehr reference model, or something else like fihr?
>
> Although Archie can parse and serialize archetypes in XML, archetypes
> are usually stored as ADL. This is a custom more readable format. Of
> course you can then easily convert it to XML or Json to work with them
> in other tools where you do not have an ADL parser ready.
>
> Note that for ADL 2 as far as I know there is no official XSD released
> yet, so it is possible you run into compatibility problems with XML. For
> ADL 1.4 this is not a problem.
>
> Regards,
>
> Pieter Bos
>
> Am 12.11.2018 um 09:18 schrieb Georg Fette:
> > Hello,
> > For a project we want to create a generic mechanism to transform
> > archetypes into FHIR Logical Models, so we can store, retrieve and
> > query archetype instance with FHIR tools (CQL, FHIR-REST-API-query).
> > At the moment we just want to read/write archetypes and not archetype
> > instances. We are looking for existing components to parse and process
> > archetypes. I have some questions I encountered related to these issues:
> > - I have found several projects that store openEHR-data (archetypes as
> > well as archetype instances) into different data substrates (Neo4J,
> > ARM (archetype relational mapping), EtherCIS). Although I have not yet
> > looked at the code of these projects I assume that they take an
> > archetype XML-file, parse it and thus create a runtime object of the
> > archetype. That runtime object can then be given as a parameter to a
> > persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse
> > something from already existing projects I am looking for a parser
> > that creates a runtime object from an archetype-XML-String, so we can
> > write our own components that transform it into a FHIR runtime object.
> > The component we are looking for should preferably be written in Java,
> > as this is our language of choice in our project.
> > - I am not ye sure if we are looking for a method to transform
> > archetypes, templates or operational templates into FHIR related
> > structures, as I am not yet that familiar with which data structure is
> > preferably used for which kind of task. Therefore, component that,
> > instead of archetypes, parse templates or operational templates would
> > be appreciated as well.
> > Greetings
> > Georg
> >
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada

Re: Parsing of Archetypes/Templates

[Georg Fette]

Hi Peter,
The Archie-Toolkit looks promising.

I tried to parse one of the archetypes from the CKM (BloodPressure) and 
tried to parse the exported ADL. However, I got a Exception when trying 
this because the exported ADL does not seem to be parseable:

line 1:24 mismatched input '1.4' expecting VERSION_ID
line 2:1 mismatched input 'openEHR-EHR-OBSERVATION.blood_pressure.v1' 
expecting ARCHETYPE_HRID


With the exported XML and the try to unmarshal the XML with the JAXBUtil 
I also did not succeed. Is there somewhere a testcase were I can see a 
working example of a parsed ADL String ?


Greetings
Georg

Hello George,

If you are looking for something to handle ADL 2 archetypes - the most 
recent version -, have a look at https://github.com/opener/archie . It 
is a java library that can parse archetypes, flatten and validate  them, 
create operational templates and more.


Are you using the openehr reference model, or something else like fihr?

Although Archie can parse and serialize archetypes in XML, archetypes 
are usually stored as ADL. This is a custom more readable format. Of 
course you can then easily convert it to XML or Json to work with them 
in other tools where you do not have an ADL parser ready.


Note that for ADL 2 as far as I know there is no official XSD released 
yet, so it is possible you run into compatibility problems with XML. For 
ADL 1.4 this is not a problem.


Regards,

Pieter Bos

Am 12.11.2018 um 09:18 schrieb Georg Fette:

Hello,
For a project we want to create a generic mechanism to transform 
archetypes into FHIR Logical Models, so we can store, retrieve and 
query archetype instance with FHIR tools (CQL, FHIR-REST-API-query). 
At the moment we just want to read/write archetypes and not archetype 
instances. We are looking for existing components to parse and process 
archetypes. I have some questions I encountered related to these issues:
- I have found several projects that store openEHR-data (archetypes as 
well as archetype instances) into different data substrates (Neo4J, 
ARM (archetype relational mapping), EtherCIS). Although I have not yet 
looked at the code of these projects I assume that they take an 
archetype XML-file, parse it and thus create a runtime object of the 
archetype. That runtime object can then be given as a parameter to a 
persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse 
something from already existing projects I am looking for a parser 
that creates a runtime object from an archetype-XML-String, so we can 
write our own components that transform it into a FHIR runtime object. 
The component we are looking for should preferably be written in Java, 
as this is our language of choice in our project.
- I am not ye sure if we are looking for a method to transform 
archetypes, templates or operational templates into FHIR related 
structures, as I am not yet that familiar with which data structure is 
preferably used for which kind of task. Therefore, component that, 
instead of archetypes, parse templates or operational templates would 
be appreciated as well.

Greetings
Georg



--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Bert Verhees]

Sorry, I first replied to Pieter Bos only, now to the list. Pieter 
already replied to me that the question was not about XSD to check 
datasets was .


So, read my reply, for those interested in easy validating datasets:

It is possible to have an XSD to describe the AOM, but you cannot have 
an XSD to describe an archetype and check a dataset with it.


Archetypes can have logical constructs which are not allowed in XSD. It 
has to do with elements with the same name on the same level, that is 
not allowed in XSD, even not when there are different attributes.


You can use Schematron to check an archetyped XML dataset. I believe the 
LinkEHR editor generates such Schematrons.


I also found Schematron validator for JSON, I think that this is very 
interesting for some kernel software developers, because XML is slowly 
becoming something of an previous era.


https://www.npmjs.com/package/jsontron

Good luck with it.

Bert.

On 12-11-18 09:30, Pieter Bos wrote:

Hello George,

If you are looking for something to handle ADL 2 archetypes - the most 
recent version -, have a look at https://github.com/opener/archie . It 
is a java library that can parse archetypes, flatten and validate  
them, create operational  templates and more.


Are you using the openehr reference model, or something else like fihr?

Although Archie can parse and serialize archetypes in XML, archetypes 
are usually stored as ADL. This is a custom more readable format. Of 
course you can then easily convert it to XML or Json to work with them 
in other tools where you do not have an ADL parser ready.


Note that for ADL 2 as far as I know there is no official XSD released 
yet, so it is possible you run into compatibility problems with XML. 
For ADL 1.4 this is not a problem.


Regards,

Pieter Bos


Op 12 nov. 2018 09:18 schreef Georg Fette :
Hello,
For a project we want to create a generic mechanism to transform
archetypes into FHIR Logical Models, so we can store, retrieve and query
archetype instance with FHIR tools (CQL, FHIR-REST-API-query). At the
moment we just want to read/write archetypes and not archetype
instances. We are looking for existing components to parse and process
archetypes. I have some questions I encountered related to these issues:
- I have found several projects that store openEHR-data (archetypes as
well as archetype instances) into different data substrates (Neo4J, ARM
(archetype relational mapping), EtherCIS). Although I have not yet
looked at the code of these projects I assume that they take an
archetype XML-file, parse it and thus create a runtime object of the
archetype. That runtime object can then be given as a parameter to a
persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse
something from already existing projects I am looking for a parser that
creates a runtime object from an archetype-XML-String, so we can write
our own components that transform it into a FHIR runtime object. The
component we are looking for should preferably be written in Java, as
this is our language of choice in our project.
- I am not ye sure if we are looking for a method to transform
archetypes, templates or operational templates into FHIR related
structures, as I am not yet that familiar with which data structure is
preferably used for which kind of task. Therefore, component that,
instead of archetypes, parse templates or operational templates would be
appreciated as well.
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität Würzburg    Tel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Parsing of Archetypes/Templates

[Pieter Bos]

Hello George,

If you are looking for something to handle ADL 2 archetypes - the most recent 
version -, have a look at https://github.com/opener/archie . It is a java 
library that can parse archetypes, flatten and validate  them, create 
operational  templates and more.

Are you using the openehr reference model, or something else like fihr?

Although Archie can parse and serialize archetypes in XML, archetypes are 
usually stored as ADL. This is a custom more readable format. Of course you can 
then easily convert it to XML or Json to work with them in other tools where 
you do not have an ADL parser ready.

Note that for ADL 2 as far as I know there is no official XSD released yet, so 
it is possible you run into compatibility problems with XML. For ADL 1.4 this 
is not a problem.

Regards,

Pieter Bos


Op 12 nov. 2018 09:18 schreef Georg Fette :
Hello,
For a project we want to create a generic mechanism to transform
archetypes into FHIR Logical Models, so we can store, retrieve and query
archetype instance with FHIR tools (CQL, FHIR-REST-API-query). At the
moment we just want to read/write archetypes and not archetype
instances. We are looking for existing components to parse and process
archetypes. I have some questions I encountered related to these issues:
- I have found several projects that store openEHR-data (archetypes as
well as archetype instances) into different data substrates (Neo4J, ARM
(archetype relational mapping), EtherCIS). Although I have not yet
looked at the code of these projects I assume that they take an
archetype XML-file, parse it and thus create a runtime object of the
archetype. That runtime object can then be given as a parameter to a
persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse
something from already existing projects I am looking for a parser that
creates a runtime object from an archetype-XML-String, so we can write
our own components that transform it into a FHIR runtime object. The
component we are looking for should preferably be written in Java, as
this is our language of choice in our project.
- I am not ye sure if we are looking for a method to transform
archetypes, templates or operational templates into FHIR related
structures, as I am not yet that familiar with which data structure is
preferably used for which kind of task. Therefore, component that,
instead of archetypes, parse templates or operational templates would be
appreciated as well.
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Parsing of Archetypes/Templates

[Georg Fette]

Hello,
For a project we want to create a generic mechanism to transform 
archetypes into FHIR Logical Models, so we can store, retrieve and query 
archetype instance with FHIR tools (CQL, FHIR-REST-API-query). At the 
moment we just want to read/write archetypes and not archetype 
instances. We are looking for existing components to parse and process 
archetypes. I have some questions I encountered related to these issues:
- I have found several projects that store openEHR-data (archetypes as 
well as archetype instances) into different data substrates (Neo4J, ARM 
(archetype relational mapping), EtherCIS). Although I have not yet 
looked at the code of these projects I assume that they take an 
archetype XML-file, parse it and thus create a runtime object of the 
archetype. That runtime object can then be given as a parameter to a 
persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse 
something from already existing projects I am looking for a parser that 
creates a runtime object from an archetype-XML-String, so we can write 
our own components that transform it into a FHIR runtime object. The 
component we are looking for should preferably be written in Java, as 
this is our language of choice in our project.
- I am not ye sure if we are looking for a method to transform 
archetypes, templates or operational templates into FHIR related 
structures, as I am not yet that familiar with which data structure is 
preferably used for which kind of task. Therefore, component that, 
instead of archetypes, parse templates or operational templates would be 
appreciated as well.

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Thomas Beale]

Note that for class and property names, we tend to stick to typical 
programming convantions, which is


 * class - first letter capital
 * property / method name - first letter lower-case

One reason to do this is to be able to distinguish a class name on its 
own, e.g. in an ADL archetype, and not mix it up with a property name. 
The ADL workbench does this, and  I would argue we want to keep these rules.


Nothing is ever completely simple...

- thomas


On 30/11/2017 15:01, Pieter Bos wrote:

I agree about the case insensitivity. Archie still does this case sensitive, so 
I just created https://github.com/openEHR/archie/issues/8 (

Pieter

On 30/11/2017, 15:23, "openEHR-technical on behalf of Thomas Beale" 
 wrote:

 
 I think the string matching should be case-insensitive, and the current

 regexes allow for any case. Various tools implementers would need to
 check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc.
 
 - thomas
 
 
 On 30/11/2017 13:55, Bert Verhees wrote:

 > So, there are also considerations I did not see.
 >
 > I can live a few days more without having a definite policy ;-)
 > But the classes are there and people will want to use them.
 >
 > I think Thomas proposal is in line with the other rmNames, like EHR
 > and DEMOGRAPHIC (which are capitalized), and therefor indeed
 > EHR_EXTRACT seems to me the best solution. Sorry for agreeing with
 > previous suggestions.
 >
 > Bert
 
 
 ___

 openEHR-technical mailing list
 openEHR-technical@lists.openehr.org
 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Pieter Bos]

I agree about the case insensitivity. Archie still does this case sensitive, so 
I just created https://github.com/openEHR/archie/issues/8 (

Pieter

On 30/11/2017, 15:23, "openEHR-technical on behalf of Thomas Beale" 
 wrote:


I think the string matching should be case-insensitive, and the current 
regexes allow for any case. Various tools implementers would need to 
check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc.

- thomas


On 30/11/2017 13:55, Bert Verhees wrote:
> So, there are also considerations I did not see.
>
> I can live a few days more without having a definite policy ;-)
> But the classes are there and people will want to use them.
>
> I think Thomas proposal is in line with the other rmNames, like EHR 
> and DEMOGRAPHIC (which are capitalized), and therefor indeed 
> EHR_EXTRACT seems to me the best solution. Sorry for agreeing with 
> previous suggestions.
>
> Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Bert Verhees]

On 30-11-17 15:23, Thomas Beale wrote:


I think the string matching should be case-insensitive, and the 
current regexes allow for any case. Various tools implementers would 
need to check to see if their tools match 'ehr_extract' to 
'EHR_EXTRACT' etc.


This is like Diego and Pieter also suggested.
Okay, thanks.



- thomas


On 30/11/2017 13:55, Bert Verhees wrote:

So, there are also considerations I did not see.

I can live a few days more without having a definite policy ;-)
But the classes are there and people will want to use them.

I think Thomas proposal is in line with the other rmNames, like EHR 
and DEMOGRAPHIC (which are capitalized), and therefor indeed 
EHR_EXTRACT seems to me the best solution. Sorry for agreeing with 
previous suggestions.


Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Thomas Beale]

I think the string matching should be case-insensitive, and the current 
regexes allow for any case. Various tools implementers would need to 
check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc.


- thomas


On 30/11/2017 13:55, Bert Verhees wrote:

So, there are also considerations I did not see.

I can live a few days more without having a definite policy ;-)
But the classes are there and people will want to use them.

I think Thomas proposal is in line with the other rmNames, like EHR 
and DEMOGRAPHIC (which are capitalized), and therefor indeed 
EHR_EXTRACT seems to me the best solution. Sorry for agreeing with 
previous suggestions.


Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Bert Verhees]

So, there are also considerations I did not see.

I can live a few days more without having a definite policy ;-)
But the classes are there and people will want to use them.

I think Thomas proposal is in line with the other rmNames, like EHR and 
DEMOGRAPHIC (which are capitalized), and therefor indeed EHR_EXTRACT 
seems to me the best solution. Sorry for agreeing with previous suggestions.


Bert


On 30-11-17 14:40, Thomas Beale wrote:


The ADL 1.4 identifier syntax is here 
<http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_syntaxes>, 
and permits underscores. The ADL2 syntax for the type ARCHETYPE_HRID I 
think is not visible anywhere except code, so we'll need to remedy 
that. The relevant code 
<https://github.com/openEHR/adl-tools/blob/1fc0e5c9432b3fca55d301652601838d9f78a32f/libraries/openehr/src/am/archetype/archetype_hrid.e#L50> 
shows that underscores are accepted as well.


I would suggest using the proper specification name as various tools 
are starting to depend on consistent use of names across 
specifications, UML packages and classes, and archetypes. In fact I 
suspect that right now the ADL Workbench would not recognise an 
Extract archetype that didn't have EHR_EXTRACT as the RM class 
qualifier, because the relevant BMM 
<https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.3/BMM> 
is named that way (I haven't checked though).


I would go with the id template 
openEHR-EHR_EXTRACT-EXTRACT.something.v1.0.0. There are examples 
<https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/ehr_extract_template/Working/Archetypes/ehr_extract> 
already of this in the archetype test repo.


- thomas


On 30/11/2017 12:09, Bert Verhees wrote:

On 30-11-17 13:06, Diego Boscá wrote:
Having said that, I'm not sure current regex for archetype ids 
allows the use of spaces or undescores on the rm part. I'll have to 
check that


I was too fast with my compliments ;-)
In that case, we can leave the underscore out, It remains readable.

Bert



2017-11-30 9:04 GMT-03:00 Diego Boscá <yamp...@gmail.com 
<mailto:yamp...@gmail.com>>:


Hi Bert,

I would say that the "rm name" would be "EHR_Extract", as it is
the way the package is called in the documentation
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html

<http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html>
(notice that demographics and EHR are the other package names).

After that you would put the corresponding class name to constraint

Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>>:

Hi,


Since that it is so that some extract-classes derive from
Locatable, they can be used to use them as RM-class for an
archetype-definition.

But how would the ArchetypeId look like, special the rmName.
Would it be something like openEHR-Extract-Extract ?

Thanks in advance for answering

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>




-- 


VeraTech for Health SL <https://htmlsig.com/t/01C268PZ>

Twitter <https://htmlsig.com/t/01C47QQH>LinkedIn
<https://htmlsig.com/t/01C4DPJG>Maps
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com <mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 961071863 <tel:+34%20961%2007%2018%2063> / +34 627015023
<tel:+34%20627%2001%2050%2023>
www.veratech.es <http://www.veratech.es/>

Su dirección de correo electrónico junto a sus datos personales
forman parte de un fichero titularidad de VeraTech for Health SL
(CIF B98309511) cuya finalidad es la de mantener el contacto con
usted. Conforme a La Ley Orgánica 15/1999, usted puede ejercitar
sus derechos de acceso, rectificación, cancelación y, en su caso
oposición, enviando una solicitud por escrito a
verat...@veratech.es <mailto:verat...@veratech.es>.




--

VeraTech for Health SL <https://htmlsig.com/t/01C268PZ>

Twitter <https://htmlsig.com/t/01C47QQH>LinkedIn 
<https://htmlsig.com/t/01C4DPJG>Maps 
<https://htmlsig.com/t/01BZTWS7>


Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com <mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 961071863 <

Re: Extract archetypes

[Thomas Beale]

I spoke too fast - the ARCHETYPE_HRID syntax is specified here in the 
Archetype Identification spec. 
<http://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html#_human_readable_identifier_hrid>



On 30/11/2017 13:40, Thomas Beale wrote:


The ADL 1.4 identifier syntax is here 
<http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_syntaxes>, 
and permits underscores. The ADL2 syntax for the type ARCHETYPE_HRID I 
think is not visible anywhere except code, so we'll need to remedy 
that. The relevant code 
<https://github.com/openEHR/adl-tools/blob/1fc0e5c9432b3fca55d301652601838d9f78a32f/libraries/openehr/src/am/archetype/archetype_hrid.e#L50> 
shows that underscores are accepted as well.


I would suggest using the proper specification name as various tools 
are starting to depend on consistent use of names across 
specifications, UML packages and classes, and archetypes. In fact I 
suspect that right now the ADL Workbench would not recognise an 
Extract archetype that didn't have EHR_EXTRACT as the RM class 
qualifier, because the relevant BMM 
<https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.3/BMM> 
is named that way (I haven't checked though).


I would go with the id template 
openEHR-EHR_EXTRACT-EXTRACT.something.v1.0.0. There are examples 
<https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/ehr_extract_template/Working/Archetypes/ehr_extract> 
already of this in the archetype test repo.


- thomas



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Thomas Beale]

The ADL 1.4 identifier syntax is here 
<http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_syntaxes>, 
and permits underscores. The ADL2 syntax for the type ARCHETYPE_HRID I 
think is not visible anywhere except code, so we'll need to remedy that. 
The relevant code 
<https://github.com/openEHR/adl-tools/blob/1fc0e5c9432b3fca55d301652601838d9f78a32f/libraries/openehr/src/am/archetype/archetype_hrid.e#L50> 
shows that underscores are accepted as well.


I would suggest using the proper specification name as various tools are 
starting to depend on consistent use of names across specifications, UML 
packages and classes, and archetypes. In fact I suspect that right now 
the ADL Workbench would not recognise an Extract archetype that didn't 
have EHR_EXTRACT as the RM class qualifier, because the relevant BMM 
<https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.3/BMM> 
is named that way (I haven't checked though).


I would go with the id template 
openEHR-EHR_EXTRACT-EXTRACT.something.v1.0.0. There are examples 
<https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/ehr_extract_template/Working/Archetypes/ehr_extract> 
already of this in the archetype test repo.


- thomas


On 30/11/2017 12:09, Bert Verhees wrote:

On 30-11-17 13:06, Diego Boscá wrote:
Having said that, I'm not sure current regex for archetype ids allows 
the use of spaces or undescores on the rm part. I'll have to check that


I was too fast with my compliments ;-)
In that case, we can leave the underscore out, It remains readable.

Bert



2017-11-30 9:04 GMT-03:00 Diego Boscá <yamp...@gmail.com 
<mailto:yamp...@gmail.com>>:


Hi Bert,

I would say that the "rm name" would be "EHR_Extract", as it is
the way the package is called in the documentation
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html

<http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html>
(notice that demographics and EHR are the other package names).

After that you would put the corresponding class name to constraint

Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>>:

Hi,


Since that it is so that some extract-classes derive from
Locatable, they can be used to use them as RM-class for an
archetype-definition.

But how would the ArchetypeId look like, special the rmName.
Would it be something like openEHR-Extract-Extract ?

Thanks in advance for answering

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>




-- 


VeraTech for Health SL <https://htmlsig.com/t/01C268PZ>

Twitter <https://htmlsig.com/t/01C47QQH>LinkedIn
<https://htmlsig.com/t/01C4DPJG>Maps
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com <mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 961071863 <tel:+34%20961%2007%2018%2063> / +34 627015023
<tel:+34%20627%2001%2050%2023>
www.veratech.es <http://www.veratech.es/>

Su dirección de correo electrónico junto a sus datos personales
forman parte de un fichero titularidad de VeraTech for Health SL
(CIF B98309511) cuya finalidad es la de mantener el contacto con
usted. Conforme a La Ley Orgánica 15/1999, usted puede ejercitar
sus derechos de acceso, rectificación, cancelación y, en su caso
oposición, enviando una solicitud por escrito a
verat...@veratech.es <mailto:verat...@veratech.es>.




--

VeraTech for Health SL <https://htmlsig.com/t/01C268PZ>

Twitter <https://htmlsig.com/t/01C47QQH>LinkedIn 
<https://htmlsig.com/t/01C4DPJG>Maps 
<https://htmlsig.com/t/01BZTWS7>


Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com <mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 961071863 <tel:+34%20961%2007%2018%2063> / +34 627015023 
<tel:+34%20627%2001%2050%2023>

www.veratech.es <http://www.veratech.es/>

Su dirección de correo electrónico junto a sus datos personales 
forman parte de un fichero titularidad de VeraTech for Health SL (CIF 
B98309511) cuya finalidad es la de mantener el contacto con usted. 
Conforme a La Ley Orgánica 15/1999, usted puede ejercitar sus 
derechos de acceso, rectificación, cancelació

Re: Extract archetypes

[Bert Verhees]

On 30-11-17 13:11, Diego Boscá wrote:

underscore it is then! :D


Quick and firm

No objections

Bert



2017-11-30 9:09 GMT-03:00 Pieter Bos <pieter@nedap.com 
<mailto:pieter@nedap.com>>:


The test package is called “test_pkg” at least in adl2 – so
underscores are supported.

Pieter

From: openEHR-technical
<openehr-technical-boun...@lists.openehr.org
<mailto:openehr-technical-boun...@lists.openehr.org>> on behalf of
Diego Boscá <yamp...@gmail.com <mailto:yamp...@gmail.com>>
Reply-To: For openEHR technical discussions
<openehr-technical@lists.openehr.org
<mailto:openehr-technical@lists.openehr.org>>
Date: Thursday, 30 November 2017 at 13:06
To: For openEHR technical discussions
<openehr-technical@lists.openehr.org
<mailto:openehr-technical@lists.openehr.org>>
Subject: Re: Extract archetypes

Having said that, I'm not sure current regex for archetype ids
allows the use of spaces or undescores on the rm part. I'll have
to check that

2017-11-30 9:04 GMT-03:00 Diego Boscá <yamp...@gmail.com
<mailto:yamp...@gmail.com><mailto:yamp...@gmail.com
<mailto:yamp...@gmail.com>>>:
Hi Bert,
I would say that the "rm name" would be "EHR_Extract", as it is
the way the package is called in the documentation
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html

<http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html>
(notice that demographics and EHR are the other package names).
After that you would put the corresponding class name to constraint
Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl><mailto:bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>>>:
Hi,


Since that it is so that some extract-classes derive from
Locatable, they can be used to use them as RM-class for an
archetype-definition.

But how would the ArchetypeId look like, special the rmName. Would
it be something like openEHR-Extract-Extract ?

Thanks in advance for answering

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

<mailto:openEHR-technical@lists.openehr.org><mailto:openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>


--

[eraTech for Health SL]<https://htmlsig.com/t/01C268PZ
<https://htmlsig.com/t/01C268PZ>>

[witter] <https://htmlsig.com/t/01C47QQH
<https://htmlsig.com/t/01C47QQH>> [inkedIn] 
<https://htmlsig.com/t/01C4DPJG
<https://htmlsig.com/t/01C4DPJG>> [aps] 
<https://htmlsig.com/t/01BZTWS7

<https://htmlsig.com/t/01BZTWS7>>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif
<https://s3.amazonaws.com/htmlsig-assets/spacer.gif>]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
<mailto:diebo...@veratech.es><mailto:diebo...@veratech.es
<mailto:diebo...@veratech.es>>
yamp...@gmail.com
<mailto:yamp...@gmail.com><mailto:yamp...@gmail.com
<mailto:yamp...@gmail.com>>

VeraTech for Health SL
+34 961071863
<tel:%2B34%20961071863><tel:+34%20961%2007%2018%2063> / +34
627015023 <tel:%2B34%20627015023><tel:+34%20627%2001%2050%2023>
www.veratech.es <http://www.veratech.es><http://www.veratech.es/
<http://www.veratech.es/>>

Su dirección de correo electrónico junto a sus datos personales
forman parte de un fichero titularidad de VeraTech for Health SL
(CIF B98309511) cuya finalidad es la de mantener el contacto con
usted. Conforme a La Ley Orgánica 15/1999, usted puede ejercitar
sus derechos de acceso, rectificación, cancelación y, en su caso
oposición, enviando una solicitud por escrito a
verat...@veratech.es
<mailto:verat...@veratech.es><mailto:verat...@veratech.es
<mailto:verat...@veratech.es>>.



--

[eraTech for Health SL]<https://htmlsig.com/t/01C268PZ
<https://htmlsig.com/t/01C268PZ>>

[witter] <https://htmlsig.com/t/01C47QQH
<https://htmlsig.com/t/01C47QQH>> [inkedIn] 
<https://htmlsig.com/t/01C4DPJG
<https://htmlsig.com/t/01C4DPJG>> [aps] 
<https://htmlsig.com/t/01BZTWS7

<https://htmlsig.com/t/01BZTWS7>>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif
<https://s3.amazonaws.com/htm

Re: Extract archetypes

[Diego Boscá]

underscore it is then! :D

2017-11-30 9:09 GMT-03:00 Pieter Bos <pieter@nedap.com>:

> The test package is called “test_pkg” at least in adl2 – so underscores
> are supported.
>
> Pieter
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Diego Boscá <yamp...@gmail.com>
> Reply-To: For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> Date: Thursday, 30 November 2017 at 13:06
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: Extract archetypes
>
> Having said that, I'm not sure current regex for archetype ids allows the
> use of spaces or undescores on the rm part. I'll have to check that
>
> 2017-11-30 9:04 GMT-03:00 Diego Boscá <yamp...@gmail.com<mailto:yamp
> e...@gmail.com>>:
> Hi Bert,
> I would say that the "rm name" would be "EHR_Extract", as it is the way
> the package is called in the documentation http://www.openehr.org/
> releases/RM/latest/docs/ehr_extract/ehr_extract.html (notice that
> demographics and EHR are the other package names).
> After that you would put the corresponding class name to constraint
> Regards
>
> 2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl ert.verh...@rosa.nl>>:
> Hi,
>
>
> Since that it is so that some extract-classes derive from Locatable, they
> can be used to use them as RM-class for an archetype-definition.
>
> But how would the ArchetypeId look like, special the rmName. Would it be
> something like openEHR-Extract-Extract ?
>
> Thanks in advance for answering
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org<mailto:openEHR-
> techni...@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> --
>
> [eraTech for Health SL]<https://htmlsig.com/t/01C268PZ>
>
> [witter] <https://htmlsig.com/t/01C47QQH>  [inkedIn]  <
> https://htmlsig.com/t/01C4DPJG>  [aps]  <https://htmlsig.com/t/
> 01BZTWS7>
> [https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es<mailto:diebo...@veratech.es>
> yamp...@gmail.com<mailto:yamp...@gmail.com>
>
> VeraTech for Health SL
> +34 961071863<tel:+34%20961%2007%2018%2063> / +34 627015023
> <tel:+34%20627%2001%2050%2023>
> www.veratech.es<http://www.veratech.es/>
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es<mailto:verat...@veratech.es>.
>
>
>
> --
>
> [eraTech for Health SL]<https://htmlsig.com/t/01C268PZ>
>
> [witter] <https://htmlsig.com/t/01C47QQH>  [inkedIn]  <
> https://htmlsig.com/t/01C4DPJG>  [aps]  <https://htmlsig.com/t/
> 01BZTWS7>
> [https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es<mailto:diebo...@veratech.es>
> yamp...@gmail.com<mailto:yamp...@gmail.com>
>
> VeraTech for Health SL
> +34 961071863<tel:+34%20961%2007%2018%2063> / +34 627015023
> <tel:+34%20627%2001%2050%2023>
> www.veratech.es<http://www.veratech.es/>
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es<mailto:verat...@veratech.es>.
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/01C268PZ>

[image: Twitter]  <https://htmlsig.com/t/01C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/01C4DPJG> [image: Maps]
<https://htmlsig.com/t/01BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2

Re: Extract archetypes

[Bert Verhees]

On 30-11-17 13:06, Diego Boscá wrote:
Having said that, I'm not sure current regex for archetype ids allows 
the use of spaces or undescores on the rm part. I'll have to check that


I was too fast with my compliments ;-)
In that case, we can leave the underscore out, It remains readable.

Bert



2017-11-30 9:04 GMT-03:00 Diego Boscá >:


Hi Bert,

I would say that the "rm name" would be "EHR_Extract", as it is
the way the package is called in the documentation
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html


(notice that demographics and EHR are the other package names).

After that you would put the corresponding class name to constraint

Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees >:

Hi,


Since that it is so that some extract-classes derive from
Locatable, they can be used to use them as RM-class for an
archetype-definition.

But how would the ArchetypeId look like, special the rmName.
Would it be something like openEHR-Extract-Extract ?

Thanks in advance for answering

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org






-- 


VeraTech for Health SL 

Twitter LinkedIn
Maps


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com 

VeraTech for Health SL
+34 961071863  / +34 627015023

www.veratech.es 

Su dirección de correo electrónico junto a sus datos personales
forman parte de un fichero titularidad de VeraTech for Health SL
(CIF B98309511) cuya finalidad es la de mantener el contacto con
usted. Conforme a La Ley Orgánica 15/1999, usted puede ejercitar
sus derechos de acceso, rectificación, cancelación y, en su caso
oposición, enviando una solicitud por escrito a
verat...@veratech.es .




--

VeraTech for Health SL 

Twitter LinkedIn 
Maps 



Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com 

VeraTech for Health SL
+34 961071863  / +34 627015023 


www.veratech.es 

Su dirección de correo electrónico junto a sus datos personales forman 
parte de un fichero titularidad de VeraTech for Health SL (CIF 
B98309511) cuya finalidad es la de mantener el contacto con usted. 
Conforme a La Ley Orgánica 15/1999, usted puede ejercitar sus derechos 
de acceso, rectificación, cancelación y, en su caso oposición, 
enviando una solicitud por escrito a verat...@veratech.es 
.




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Pieter Bos]

The test package is called “test_pkg” at least in adl2 – so underscores are 
supported.

Pieter

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Diego Boscá <yamp...@gmail.com>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org>
Date: Thursday, 30 November 2017 at 13:06
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: Extract archetypes

Having said that, I'm not sure current regex for archetype ids allows the use 
of spaces or undescores on the rm part. I'll have to check that

2017-11-30 9:04 GMT-03:00 Diego Boscá 
<yamp...@gmail.com<mailto:yamp...@gmail.com>>:
Hi Bert,
I would say that the "rm name" would be "EHR_Extract", as it is the way the 
package is called in the documentation 
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html 
(notice that demographics and EHR are the other package names).
After that you would put the corresponding class name to constraint
Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>>:
Hi,


Since that it is so that some extract-classes derive from Locatable, they can 
be used to use them as RM-class for an archetype-definition.

But how would the ArchetypeId look like, special the rmName. Would it be 
something like openEHR-Extract-Extract ?

Thanks in advance for answering

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--

[eraTech for Health SL]<https://htmlsig.com/t/01C268PZ>

[witter] <https://htmlsig.com/t/01C47QQH>  [inkedIn]  
<https://htmlsig.com/t/01C4DPJG>  [aps]  
<https://htmlsig.com/t/01BZTWS7>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com<mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 961071863<tel:+34%20961%2007%2018%2063> / +34 
627015023<tel:+34%20627%2001%2050%2023>
www.veratech.es<http://www.veratech.es/>

Su dirección de correo electrónico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificación, cancelación y, en 
su caso oposición, enviando una solicitud por escrito a 
verat...@veratech.es<mailto:verat...@veratech.es>.



--

[eraTech for Health SL]<https://htmlsig.com/t/01C268PZ>

[witter] <https://htmlsig.com/t/01C47QQH>  [inkedIn]  
<https://htmlsig.com/t/01C4DPJG>  [aps]  
<https://htmlsig.com/t/01BZTWS7>
[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es<mailto:diebo...@veratech.es>
yamp...@gmail.com<mailto:yamp...@gmail.com>

VeraTech for Health SL
+34 961071863<tel:+34%20961%2007%2018%2063> / +34 
627015023<tel:+34%20627%2001%2050%2023>
www.veratech.es<http://www.veratech.es/>

Su dirección de correo electrónico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificación, cancelación y, en 
su caso oposición, enviando una solicitud por escrito a 
verat...@veratech.es<mailto:verat...@veratech.es>.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Bert Verhees]

Thanks Diego, that seems a good suggestion based on good reasoning.

Bert


On 30-11-17 13:04, Diego Boscá wrote:

Hi Bert,

I would say that the "rm name" would be "EHR_Extract", as it is the 
way the package is called in the documentation 
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html 
(notice that demographics and EHR are the other package names).


After that you would put the corresponding class name to constraint

Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees >:


Hi,


Since that it is so that some extract-classes derive from
Locatable, they can be used to use them as RM-class for an
archetype-definition.

But how would the ArchetypeId look like, special the rmName. Would
it be something like openEHR-Extract-Extract ?

Thanks in advance for answering

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org






--

VeraTech for Health SL 

Twitter LinkedIn 
Maps 



Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com 

VeraTech for Health SL
+34 961071863  / +34 627015023 


www.veratech.es 

Su dirección de correo electrónico junto a sus datos personales forman 
parte de un fichero titularidad de VeraTech for Health SL (CIF 
B98309511) cuya finalidad es la de mantener el contacto con usted. 
Conforme a La Ley Orgánica 15/1999, usted puede ejercitar sus derechos 
de acceso, rectificación, cancelación y, en su caso oposición, 
enviando una solicitud por escrito a verat...@veratech.es 
.




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Diego Boscá]

Having said that, I'm not sure current regex for archetype ids allows the
use of spaces or undescores on the rm part. I'll have to check that

2017-11-30 9:04 GMT-03:00 Diego Boscá :

> Hi Bert,
>
> I would say that the "rm name" would be "EHR_Extract", as it is the way
> the package is called in the documentation http://www.openehr.org/
> releases/RM/latest/docs/ehr_extract/ehr_extract.html (notice that
> demographics and EHR are the other package names).
>
> After that you would put the corresponding class name to constraint
>
> Regards
>
> 2017-11-30 8:55 GMT-03:00 Bert Verhees :
>
>> Hi,
>>
>>
>> Since that it is so that some extract-classes derive from Locatable, they
>> can be used to use them as RM-class for an archetype-definition.
>>
>> But how would the ArchetypeId look like, special the rmName. Would it be
>> something like openEHR-Extract-Extract ?
>>
>> Thanks in advance for answering
>>
>> Bert
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Extract archetypes

[Diego Boscá]

Hi Bert,

I would say that the "rm name" would be "EHR_Extract", as it is the way the
package is called in the documentation
http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html
(notice that demographics and EHR are the other package names).

After that you would put the corresponding class name to constraint

Regards

2017-11-30 8:55 GMT-03:00 Bert Verhees :

> Hi,
>
>
> Since that it is so that some extract-classes derive from Locatable, they
> can be used to use them as RM-class for an archetype-definition.
>
> But how would the ArchetypeId look like, special the rmName. Would it be
> something like openEHR-Extract-Extract ?
>
> Thanks in advance for answering
>
> Bert
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Extract archetypes

[Bert Verhees]

Hi,


Since that it is so that some extract-classes derive from Locatable, 
they can be used to use them as RM-class for an archetype-definition.


But how would the ArchetypeId look like, special the rmName. Would it be 
something like openEHR-Extract-Extract ?


Thanks in advance for answering

Bert


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Including reference range in archetypes

[Dileep V S]

Thanks Ian,

I will explore your pointers in details and come back if I need any help.

regards

Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in

On Thu, Apr 13, 2017 at 1:52 PM, Ian McNicoll <i...@freshehr.com> wrote:

> Hi Dileep,
>
> This is a common scenario, that right now is mostly handled in application
> code.
>
> My understanding of normal_range/reference_ranges (part of the quantity
> model) is that these are intended to carry the normal ranges that apply to
> a biological observation such as lab_test or perhaps imaging_ exam, rather
> than (as in your case) a sort of rule that is applied to caclulate or
> categorise risk.
>
> The most high profile comparable example I know of , is the NEWS score.
>
> Archetype at NEWS (UK RCP), Published archetype [Internet]. openEHR
> Foundation, openEHR Clinical Knowledge Manager [cited: 2017-04-13].
> Available from: http://openehr.org/ckm/#showArchetype_1013.1.2423
>
> Rules at https://www.mdcalc.com/national-early-warning-score-news
>
> I would expect a UI to colour-code each component in a similar fashion, to
> indicate potential risk.
>
> You might want to explore GDL, which is an extension to openEHR that acts
> as a glue layer between archetypes and those sort of rules.
>
> http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html
>
> There is also some interest in folding aspects of GDL inside archetypes as
> part of the 'rules' aspect of ADL. One of the barriers to getting this
> working at scale, is deciding what 'vendor-neutral' rules definition
> language to use. Not everyone is a fan of javascript but I do see some
> potential in this space given its ubiquity in the market.
>
> I'm not sure I have answered your question!!
>
> Regards,
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 12 April 2017 at 11:36, Dileep V S <dil...@healthelife.in> wrote:
>
>> Hi,
>>
>> I am trying to create an archetype that screens for health risks. All the
>> questions have ordinal data. Based on the values selected for the
>> questions, the consolidate risk value is calculated.
>>
>> I want the UIi to display appropriate warnings (coloring the risk value
>> etc) based on a reference range for the value. How can I include the
>> reference range in the archetype so that the UI can read that and display
>> the warnings?
>>
>> thanks for the help
>> regards
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113 <+91%2096328%2088113>
>> a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w: healthelife.in  e: dil...@healthelife.in
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Including reference range in archetypes

[Ian McNicoll]

Hi Dileep,

This is a common scenario, that right now is mostly handled in application
code.

My understanding of normal_range/reference_ranges (part of the quantity
model) is that these are intended to carry the normal ranges that apply to
a biological observation such as lab_test or perhaps imaging_ exam, rather
than (as in your case) a sort of rule that is applied to caclulate or
categorise risk.

The most high profile comparable example I know of , is the NEWS score.

Archetype at NEWS (UK RCP), Published archetype [Internet]. openEHR
Foundation, openEHR Clinical Knowledge Manager [cited: 2017-04-13].
Available from: http://openehr.org/ckm/#showArchetype_1013.1.2423

Rules at https://www.mdcalc.com/national-early-warning-score-news

I would expect a UI to colour-code each component in a similar fashion, to
indicate potential risk.

You might want to explore GDL, which is an extension to openEHR that acts
as a glue layer between archetypes and those sort of rules.

http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html

There is also some interest in folding aspects of GDL inside archetypes as
part of the 'rules' aspect of ADL. One of the barriers to getting this
working at scale, is deciding what 'vendor-neutral' rules definition
language to use. Not everyone is a fan of javascript but I do see some
potential in this space given its ubiquity in the market.

I'm not sure I have answered your question!!

Regards,

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 12 April 2017 at 11:36, Dileep V S <dil...@healthelife.in> wrote:

> Hi,
>
> I am trying to create an archetype that screens for health risks. All the
> questions have ordinal data. Based on the values selected for the
> questions, the consolidate risk value is calculated.
>
> I want the UIi to display appropriate warnings (coloring the risk value
> etc) based on a reference range for the value. How can I include the
> reference range in the archetype so that the UI can read that and display
> the warnings?
>
> thanks for the help
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113 <+91%2096328%2088113>
> a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Including reference range in archetypes

[Dileep V S]

Hi,

I am trying to create an archetype that screens for health risks. All the
questions have ordinal data. Based on the values selected for the
questions, the consolidate risk value is calculated.

I want the UIi to display appropriate warnings (coloring the risk value
etc) based on a reference range for the value. How can I include the
reference range in the archetype so that the UI can read that and display
the warnings?

thanks for the help
regards
Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Bert Verhees]

> c'était une blague...

I see that, sorry for that.

Please understand my situation. I was in the urge to solve a problem in the
ADL1. 4 environment and I was not waiting for someone to tell me that that
problem is already solved because ADL2 will come real soon.

Maybe it is maybe it is not, but that discussion did not help me.

But in the end my problem is solved so everything is oké  now.

Best regards
Bert

Op wo 1 mrt. 2017 15:55 schreef Bert Verhees <bert.verh...@rosa.nl>:

> Lots of good things happening. We will see when major shifts will occur. I
> keep my finger in the wind and expect another year to wait.
>
> I hope sooner. There will be a migration period in which both versions
> will be used.
>
> Bert
>
> Op wo 1 mrt. 2017 15:41 schreef Ian McNicoll <i...@freshehr.com>:
>
> Hi Pieter,
>
> Thanks for the update. This kind of innovation is why I am so keen to make
> the jump to this brave new world.
>
> I'd love to hear more about your main project but will contact you
> separately.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 March 2017 at 13:04, Pieter Bos <pieter@nedap.com> wrote:
>
> We’re looking forward to the new ADL-designer. We’re currently building an
> ADL-2 based openEHR implementation and currently doing parts of the
> archetype design by hand until we have better tools.
>
> If you want to use ADL-2 and you’re looking for a java library for your
> EHR or authoring tools, Archie implements ADL-2 and the reference model,
> plus a lot of tools for working with them.
> Important for specialization: It include a flattener and operational
> template creator that converts specialized archetypes and templates to an
> operational template. Those make working with specialized archetypes much
> easier. They combine the archetypes, templates, templates overlays and
> specialized archetypes into one flat archetype that you can use in your
> tools and user interfaces.
>
> See http://github.com/nedap/archie . It now also has experimental but
> usable support for rule evaluation.
>
> Licensed under the Apache license, so it should be usable in any kind of
> project you like – open source or proprietary.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Ian McNicoll <i...@freshehr.com>
> Reply-To: For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> Date: Wednesday, 1 March 2017 at 13:20
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: inheritance of archetypes
>
> Hi Bert,
>
> Marand are about to release a major interim update to their ADL-2
> Archetype tooling. I am told sometime in March).
>
> One of the major design criteria is to be able to create ADL1.4 artefacts
> and, critically, ADL 1.4 .opts so we can use the new tools with existing
> systems, but take advantage of better handling of specialisations etc.
> @Birger - This will also help with transition in tooling like CKM, where we
> should be able to create ADL 1.4 flat forms for review purposes.
>
> We expect this first release to need a bit of work and user-feedback. We
> (freshEHR) have committed to give it a good workout on real-world project
> so that we can rapidly iterate and get it ready for proper release.
>
> This is the year we make the jump, at least in the design space!! I expect
> back-end CDRs and other tooling to be working with ADL1.4 artefacts for
> some time. The impact on CDRs is not actually very significant if we mange
> the transition carefully.
>
> I would be delighted to hear from any developers or companies who might be
> prepared to make a contribution to this project (open-source of course). We
> have had a couple of interesting offers of support already. Good tooling is
> essential to openEHR, and if we get a good set of baseline tools, there are
> all sorts of interesting extensions that could be developed.
>
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com<mailto:i...@freshehr.com>
> twitter: @ianmcnicoll
>
> [
> https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ
> ]
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org ian.mcn

Re: inheritance of archetypes

[Bert Verhees]

Lots of good things happening. We will see when major shifts will occur. I
keep my finger in the wind and expect another year to wait.

I hope sooner. There will be a migration period in which both versions will
be used.

Bert

Op wo 1 mrt. 2017 15:41 schreef Ian McNicoll <i...@freshehr.com>:

> Hi Pieter,
>
> Thanks for the update. This kind of innovation is why I am so keen to make
> the jump to this brave new world.
>
> I'd love to hear more about your main project but will contact you
> separately.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 March 2017 at 13:04, Pieter Bos <pieter@nedap.com> wrote:
>
> We’re looking forward to the new ADL-designer. We’re currently building an
> ADL-2 based openEHR implementation and currently doing parts of the
> archetype design by hand until we have better tools.
>
> If you want to use ADL-2 and you’re looking for a java library for your
> EHR or authoring tools, Archie implements ADL-2 and the reference model,
> plus a lot of tools for working with them.
> Important for specialization: It include a flattener and operational
> template creator that converts specialized archetypes and templates to an
> operational template. Those make working with specialized archetypes much
> easier. They combine the archetypes, templates, templates overlays and
> specialized archetypes into one flat archetype that you can use in your
> tools and user interfaces.
>
> See http://github.com/nedap/archie . It now also has experimental but
> usable support for rule evaluation.
>
> Licensed under the Apache license, so it should be usable in any kind of
> project you like – open source or proprietary.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Ian McNicoll <i...@freshehr.com>
> Reply-To: For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> Date: Wednesday, 1 March 2017 at 13:20
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: inheritance of archetypes
>
> Hi Bert,
>
> Marand are about to release a major interim update to their ADL-2
> Archetype tooling. I am told sometime in March).
>
> One of the major design criteria is to be able to create ADL1.4 artefacts
> and, critically, ADL 1.4 .opts so we can use the new tools with existing
> systems, but take advantage of better handling of specialisations etc.
> @Birger - This will also help with transition in tooling like CKM, where we
> should be able to create ADL 1.4 flat forms for review purposes.
>
> We expect this first release to need a bit of work and user-feedback. We
> (freshEHR) have committed to give it a good workout on real-world project
> so that we can rapidly iterate and get it ready for proper release.
>
> This is the year we make the jump, at least in the design space!! I expect
> back-end CDRs and other tooling to be working with ADL1.4 artefacts for
> some time. The impact on CDRs is not actually very significant if we mange
> the transition carefully.
>
> I would be delighted to hear from any developers or companies who might be
> prepared to make a contribution to this project (open-source of course). We
> have had a couple of interesting offers of support already. Good tooling is
> essential to openEHR, and if we get a good set of baseline tools, there are
> all sorts of interesting extensions that could be developed.
>
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com<mailto:i...@freshehr.com>
> twitter: @ianmcnicoll
>
> [
> https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ
> ]
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org ian.mcnic...@openehr.org>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 March 2017 at 10:00, Bert Verhees <bert.verh...@rosa.nl bert.verh...@rosa.nl>> wrote:
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
> Good news Thomas, but don't bring it with disdain.
>
> I don't know what the words means ;)
>
> I got it from google translate, in French it is dedain.
> that appears to be a PR about GDL?
>
> I meant a

Re: inheritance of archetypes

[Ian McNicoll]

Hi Pieter,

Thanks for the update. This kind of innovation is why I am so keen to make
the jump to this brave new world.

I'd love to hear more about your main project but will contact you
separately.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 1 March 2017 at 13:04, Pieter Bos <pieter@nedap.com> wrote:

> We’re looking forward to the new ADL-designer. We’re currently building an
> ADL-2 based openEHR implementation and currently doing parts of the
> archetype design by hand until we have better tools.
>
> If you want to use ADL-2 and you’re looking for a java library for your
> EHR or authoring tools, Archie implements ADL-2 and the reference model,
> plus a lot of tools for working with them.
> Important for specialization: It include a flattener and operational
> template creator that converts specialized archetypes and templates to an
> operational template. Those make working with specialized archetypes much
> easier. They combine the archetypes, templates, templates overlays and
> specialized archetypes into one flat archetype that you can use in your
> tools and user interfaces.
>
> See http://github.com/nedap/archie . It now also has experimental but
> usable support for rule evaluation.
>
> Licensed under the Apache license, so it should be usable in any kind of
> project you like – open source or proprietary.
>
> Regards,
>
> Pieter Bos
> Nedap Healthcare
>
> From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on
> behalf of Ian McNicoll <i...@freshehr.com>
> Reply-To: For openEHR technical discussions <openehr-technical@lists.
> openehr.org>
> Date: Wednesday, 1 March 2017 at 13:20
> To: For openEHR technical discussions <openehr-technical@lists.openehr.org
> >
> Subject: Re: inheritance of archetypes
>
> Hi Bert,
>
> Marand are about to release a major interim update to their ADL-2
> Archetype tooling. I am told sometime in March).
>
> One of the major design criteria is to be able to create ADL1.4 artefacts
> and, critically, ADL 1.4 .opts so we can use the new tools with existing
> systems, but take advantage of better handling of specialisations etc.
> @Birger - This will also help with transition in tooling like CKM, where we
> should be able to create ADL 1.4 flat forms for review purposes.
>
> We expect this first release to need a bit of work and user-feedback. We
> (freshEHR) have committed to give it a good workout on real-world project
> so that we can rapidly iterate and get it ready for proper release.
>
> This is the year we make the jump, at least in the design space!! I expect
> back-end CDRs and other tooling to be working with ADL1.4 artefacts for
> some time. The impact on CDRs is not actually very significant if we mange
> the transition carefully.
>
> I would be delighted to hear from any developers or companies who might be
> prepared to make a contribution to this project (open-source of course). We
> have had a couple of interesting offers of support already. Good tooling is
> essential to openEHR, and if we get a good set of baseline tools, there are
> all sorts of interesting extensions that could be developed.
>
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com<mailto:i...@freshehr.com>
> twitter: @ianmcnicoll
>
> [https://docs.google.com/uc?export=download=
> 0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtM
> DJ0bkdUcUQxM2dqSVdrPQ]
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org ian.mcnic...@openehr.org>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 March 2017 at 10:00, Bert Verhees <bert.verh...@rosa.nl ert.verh...@rosa.nl>> wrote:
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
> Good news Thomas, but don't bring it with disdain.
>
> I don't know what the words means ;)
>
> I got it from google translate, in French it is dedain.
> that appears to be a PR about GDL?
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
> So it's not perfect, but it's far from non-existent. I'd say your best bet
> is to use the new version of ADL-designer.
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as 

Re: inheritance of archetypes

[Thomas Beale]

well the problem with continuing to use ADL 1.4 is the in a) weaknesses 
modelling semantics (much weaker in 1.4) b) errors caused by lack of 
differential representation of specialised archetypes (a major problem) 
and c) different representation of templates (in ADL2 they are built-in).


Implementations can standardise on OPT 1.4 without difficulty for some 
time, but this doesn't require continued use of ADL 1.4 for modelling.


- thomas

On 01/03/2017 12:54, Ian McNicoll wrote:

Hi Thomas / Bert,

I think you will find a significant pain point in the modelling 
community. Agree that for now 1.4 .opt is going to be best for 
implementers but as I understand things a 2.0 .opt and related RM 
changes would not be radically different, in any case.


The big difference, and gain (once we get over the line) is much 
easier handling of design-time artefacts, and potential extensibility.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Pieter Bos]

We’re looking forward to the new ADL-designer. We’re currently building an 
ADL-2 based openEHR implementation and currently doing parts of the archetype 
design by hand until we have better tools.

If you want to use ADL-2 and you’re looking for a java library for your EHR or 
authoring tools, Archie implements ADL-2 and the reference model, plus a lot of 
tools for working with them.
Important for specialization: It include a flattener and operational template 
creator that converts specialized archetypes and templates to an operational 
template. Those make working with specialized archetypes much easier. They 
combine the archetypes, templates, templates overlays and specialized 
archetypes into one flat archetype that you can use in your tools and user 
interfaces.

See http://github.com/nedap/archie . It now also has experimental but usable 
support for rule evaluation.

Licensed under the Apache license, so it should be usable in any kind of 
project you like – open source or proprietary.

Regards,

Pieter Bos
Nedap Healthcare

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Ian McNicoll <i...@freshehr.com>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org>
Date: Wednesday, 1 March 2017 at 13:20
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: inheritance of archetypes

Hi Bert,

Marand are about to release a major interim update to their ADL-2 Archetype 
tooling. I am told sometime in March).

One of the major design criteria is to be able to create ADL1.4 artefacts and, 
critically, ADL 1.4 .opts so we can use the new tools with existing systems, 
but take advantage of better handling of specialisations etc. @Birger - This 
will also help with transition in tooling like CKM, where we should be able to 
create ADL 1.4 flat forms for review purposes.

We expect this first release to need a bit of work and user-feedback. We 
(freshEHR) have committed to give it a good workout on real-world project so 
that we can rapidly iterate and get it ready for proper release.

This is the year we make the jump, at least in the design space!! I expect 
back-end CDRs and other tooling to be working with ADL1.4 artefacts for some 
time. The impact on CDRs is not actually very significant if we mange the 
transition carefully.

I would be delighted to hear from any developers or companies who might be 
prepared to make a contribution to this project (open-source of course). We 
have had a couple of interesting offers of support already. Good tooling is 
essential to openEHR, and if we get a good set of baseline tools, there are all 
sorts of interesting extensions that could be developed.


Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 1 March 2017 at 10:00, Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> wrote:
Op 1-3-2017 om 10:44 schreef Thomas Beale:
Good news Thomas, but don't bring it with disdain.

I don't know what the words means ;)

I got it from google translate, in French it is dedain.
that appears to be a PR about GDL?

I meant a current list of Open Issues, I don't know why the 168 is on top, it 
seems to have the highest priority, I don't understand why.
That is not my discussion point.
So it's not perfect, but it's far from non-existent. I'd say your best bet is 
to use the new version of ADL-designer.
As said, institutions will want a stable release. I will never advise an 
organization to move to ADL2 as long as it is not stable.
Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4. There 
must be many archetype, and many data-storages based on ADL 1.4

And there is another point, companies don't tend to change when they do not 
feel the pain.
I had my first IP6 course in 1998, I worked for DEC (Digital) at that time, and 
still the computer I work on is configured using IP4, so is my Internet-router.

But the discussion on this technical list can be closed as the point I wanted 
to make is planned to be solved (and maybe soon).

Best regard

Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Ian McNicoll]

Hi Thomas / Bert,

I think you will find a significant pain point in the modelling community.
Agree that for now 1.4 .opt is going to be best for implementers but as I
understand things a 2.0 .opt and related RM changes would not be radically
different, in any case.

The big difference, and gain (once we get over the line) is much easier
handling of design-time artefacts, and potential extensibility.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 1 March 2017 at 12:26, Thomas Beale  wrote:

>
>
> On 01/03/2017 10:00, Bert Verhees wrote:
>
> Op 1-3-2017 om 10:44 schreef Thomas Beale:
>
> Good news Thomas, but don't bring it with disdain.
>
>
> I don't know what the words means ;)
>
>
> I got it from google translate, in French it is dedain.
>
>
> c'était une blague...
>
>
> that appears to be a PR about GDL?
>
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
>
>
> ah - probably you wanted to show these issues
> .
> There are issues (always), but not with the specialisation representation.
>
>
> So it's not perfect, but it's far from non-existent. I'd say your best bet
> is to use the new version of ADL-designer.
>
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as long as it is not stable.
>
>
> well, it has a stable release here
> . As noted
> above, there are issues, but there are issues outstanding on everything -
> they get worked on and the results get added to later releases. I'm not
> sure of what the alternative to that is.
>
> Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4.
> There must be many archetype, and many data-storages based on ADL 1.4
>
>
> well CKM is a problem in one sense, but people could work with ADL2 tools
> and save the results as ADL 1.4, which  you can do in the ADL-designer, for
> upload to CKM. That's not ideal, I agree - it would be better if CKM
> upgraded to ADL2.
>
> Data storage is generally based on OPT 1.4, and I think that is also a
> save format of the ADL-designer.
>
>
> And there is another point, companies don't tend to change when they do
> not feel the pain.
> I had my first IP6 course in 1998, I worked for DEC (Digital) at that
> time, and still the computer I work on is configured using IP4, so is my
> Internet-router.
>
>
> well you are pointing out some pain, and I am pointing out the solution.
> If you are not in enough pain, you may not want the solution ;)
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Thomas Beale]

On 01/03/2017 10:00, Bert Verhees wrote:

Op 1-3-2017 om 10:44 schreef Thomas Beale:

Good news Thomas, but don't bring it with disdain.


I don't know what the words means ;)


I got it from google translate, in French it is dedain.


c'était une blague...




that appears to be a PR about GDL?


I meant a current list of Open Issues, I don't know why the 168 is on 
top, it seems to have the highest priority, I don't understand why.

That is not my discussion point.


ah - probably you wanted to show these issues 
. 
There are issues (always), but not with the specialisation representation.




So it's not perfect, but it's far from non-existent. I'd say your 
best bet is to use the new version of ADL-designer.
As said, institutions will want a stable release. I will never advise 
an organization to move to ADL2 as long as it is not stable.


well, it has a stable release here 
. As noted 
above, there are issues, but there are issues outstanding on everything 
- they get worked on and the results get added to later releases. I'm 
not sure of what the alternative to that is.


Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4. 
There must be many archetype, and many data-storages based on ADL 1.4


well CKM is a problem in one sense, but people could work with ADL2 
tools and save the results as ADL 1.4, which  you can do in the 
ADL-designer, for upload to CKM. That's not ideal, I agree - it would be 
better if CKM upgraded to ADL2.


Data storage is generally based on OPT 1.4, and I think that is also a 
save format of the ADL-designer.




And there is another point, companies don't tend to change when they 
do not feel the pain.
I had my first IP6 course in 1998, I worked for DEC (Digital) at that 
time, and still the computer I work on is configured using IP4, so is 
my Internet-router.


well you are pointing out some pain, and I am pointing out the solution. 
If you are not in enough pain, you may not want the solution ;)


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Ian McNicoll]

Hi Bert,

Marand are about to release a major interim update to their ADL-2 Archetype
tooling. I am told sometime in March).

One of the major design criteria is to be able to create ADL1.4 artefacts
and, critically, ADL 1.4 .opts so we can use the new tools with existing
systems, but take advantage of better handling of specialisations etc.
@Birger - This will also help with transition in tooling like CKM, where we
should be able to create ADL 1.4 flat forms for review purposes.

We expect this first release to need a bit of work and user-feedback. We
(freshEHR) have committed to give it a good workout on real-world project
so that we can rapidly iterate and get it ready for proper release.

This is the year we make the jump, at least in the design space!! I expect
back-end CDRs and other tooling to be working with ADL1.4 artefacts for
some time. The impact on CDRs is not actually very significant if we mange
the transition carefully.

I would be delighted to hear from any developers or companies who might be
prepared to make a contribution to this project (open-source of course). We
have had a couple of interesting offers of support already. Good tooling is
essential to openEHR, and if we get a good set of baseline tools, there are
all sorts of interesting extensions that could be developed.


Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 1 March 2017 at 10:00, Bert Verhees  wrote:

> Op 1-3-2017 om 10:44 schreef Thomas Beale:
>
>> Good news Thomas, but don't bring it with disdain.
>>>
>>
>> I don't know what the words means ;)
>>
>
> I got it from google translate, in French it is dedain.
>
> that appears to be a PR about GDL?
>>
>
> I meant a current list of Open Issues, I don't know why the 168 is on top,
> it seems to have the highest priority, I don't understand why.
> That is not my discussion point.
>
> So it's not perfect, but it's far from non-existent. I'd say your best bet
>> is to use the new version of ADL-designer.
>>
> As said, institutions will want a stable release. I will never advise an
> organization to move to ADL2 as long as it is not stable.
> Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4.
> There must be many archetype, and many data-storages based on ADL 1.4
>
> And there is another point, companies don't tend to change when they do
> not feel the pain.
> I had my first IP6 course in 1998, I worked for DEC (Digital) at that
> time, and still the computer I work on is configured using IP4, so is my
> Internet-router.
>
> But the discussion on this technical list can be closed as the point I
> wanted to make is planned to be solved (and maybe soon).
>
> Best regard
>
> Bert
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Bert Verhees]

Op 1-3-2017 om 10:44 schreef Thomas Beale:

Good news Thomas, but don't bring it with disdain.


I don't know what the words means ;)


I got it from google translate, in French it is dedain.


that appears to be a PR about GDL?


I meant a current list of Open Issues, I don't know why the 168 is on 
top, it seems to have the highest priority, I don't understand why.

That is not my discussion point.

So it's not perfect, but it's far from non-existent. I'd say your best 
bet is to use the new version of ADL-designer.
As said, institutions will want a stable release. I will never advise an 
organization to move to ADL2 as long as it is not stable.
Also one of the selling points of OpenEHR is CKM, it is fully ADL 1.4. 
There must be many archetype, and many data-storages based on ADL 1.4


And there is another point, companies don't tend to change when they do 
not feel the pain.
I had my first IP6 course in 1998, I worked for DEC (Digital) at that 
time, and still the computer I work on is configured using IP4, so is my 
Internet-router.


But the discussion on this technical list can be closed as the point I 
wanted to make is planned to be solved (and maybe soon).


Best regard
Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Thomas Beale]

we may be able to re-use ideas from the Intermountain Healthcare 
Activity-Based Design (ABD) project I am working on in the US, which 
includes presentation specification in its archetypes (they are not ADL 
archetypes, but something similar).



On 01/03/2017 09:26, Anastasiou A. wrote:


Imagine combining all of this with GDL 
(http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html) and a 
specialised

version of a similar DSL to describe archetype / template aware GUIs.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Thomas Beale]

On 01/03/2017 09:35, Bert Verhees wrote:

Good news Thomas, but don't bring it with disdain.


I don't know what the words means ;)



Op 1-3-2017 om 10:15 schreef Thomas Beale:
which when they are read into ADL Workbench, are re-engineered into 
differential form


I think the ADL Workbench is a cryptic piece of software which could 
use some GUI-specialists to redesign it, so it will become 
understandable for non-software-specialists.


well, the point is that the ADL Workbench fully implements the 
differential specialisation semantics you are talking about. Whether it 
has a cryptic UI is apparently a subjective matter ;)





Using this technology is just a case of moving to ADL/AOM2.


I wouldn't call it "just a case", ADL2 is not yet fully defined.
See the open cases in the specifications (128):
https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-168?filter=allopenissues 



that appears to be a PR about GDL?



The tooling is not yet ready, and even when there will be a frozen 
standard, it will take years for institutions to migrate. They want a 
stable version, before shifting their core-information to a new 
information-structure.
It is good news, but don't bring it as it is like a breathe, then you 
disregard the hard work of people working on the technical information 
side of institutions.


Well the tooling that is there now is:

 * ADL Workbench, which will transform any set of ADL 1.4 archetypes to
   ADL2 differential form, and generate error messages for
   specialisations that can't be computed
 * ADL-designer, a modern web-based Archetype Editor and Template
   Designer based on ADL2, for which a new release is imminent (I think
   next month), which also reads ADL 1.4 archetypes.
 * various Java implementations of the ADL 2 spec

So it's not perfect, but it's far from non-existent. I'd say your best 
bet is to use the new version of ADL-designer.


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Bert Verhees]

Good news Thomas, but don't bring it with disdain.

Op 1-3-2017 om 10:15 schreef Thomas Beale:
which when they are read into ADL Workbench, are re-engineered into 
differential form


I think the ADL Workbench is a cryptic piece of software which could use 
some GUI-specialists to redesign it, so it will become understandable 
for non-software-specialists.



Using this technology is just a case of moving to ADL/AOM2.


I wouldn't call it "just a case", ADL2 is not yet fully defined.
See the open cases in the specifications (128):
https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-168?filter=allopenissues

The tooling is not yet ready, and even when there will be a frozen 
standard, it will take years for institutions to migrate. They want a 
stable version, before shifting their core-information to a new 
information-structure.
It is good news, but don't bring it as it is like a breathe, then you 
disregard the hard work of people working on the technical information 
side of institutions.


Sorry to be harsh on this, but so was your reply,

Best regards
Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: inheritance of archetypes

[Anastasiou A .]

Imagine combining all of this with GDL 
(http://www.openehr.org/releases/CDS/latest/docs/GDL/GDL.html) and a specialised
version of a similar DSL to describe archetype / template aware GUIs.



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: 01 March 2017 09:15
To: openehr-technical@lists.openehr.org
Subject: Re: inheritance of archetypes




On 01/03/2017 09:03, Bert Verhees wrote:
Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be discussed 
separately.
I do that because in the other message, I describe a real problem which needs a 
solution, and this message is about thinking about a solution in the 
archetype-framework, which will takes for years to come (if it will come, maybe 
I am wrong in my proposal).
-
When talking about specializing. Specializing an archetype is nothing more then 
copying an archetype and add/change some constraints in them.

Only in older ADL 1.4 tools. In ADL2, specialisation is fully 
defined<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_specialisation>
 and implemented in the ADL Workbench, and more recently in the ADL-designer 
project<https://github.com/openEHR/adl-designer>. it works just like an OO 
programming language. There are dozens of examples in the test 
archteypes<https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/features>,
 and also in the CKM archetypes, which when they are read into ADL Workbench, 
are re-engineered into differential form.

This has been the case for over 5 years, with the implementation in ADL 
Workbench being available for around 4. (You can see the revision 
history<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_amendment_record>
 of the AOM2 spec).

Using this technology is just a case of moving to ADL/AOM2.

- thomas



How different is that in programming languages, where the parent-classes are 
read to understand the child class. There is no need to process all the 
sourcecode of the child-classes to adapt the changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. Easier to 
maintain code (and one definitely need a test framework).

Imagine that dreaded generic labtest archetype in the other message, I wrote 
today.
How convenient would maintainability become if specializations where really and 
life-inherited from parent archetypes?

Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and add the 
appropriate terminology binding?

Maybe we could, in case of lab-test, just created the child archetypes only in 
memory and on the fly, needing only a few keywords to describe the changes. We 
could take a look at hibernate for Java (or many other ORM-frameworks).
They do not deliver the classes needed for handling specific databases, they 
offer a framework to create/generate those classes.

One could argue that specializations are not always inherited like classes in 
programming languages. That is true. What I suggest here maybe limited to the 
cases where it is real inheritance.

Best regards
Bert Verhees

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Birger Haarbrandt]

Hi all,

when will this be available in the openEHR CKM?

Cheers,

Birger


Am 01.03.2017 um 10:15 schrieb Thomas Beale:




On 01/03/2017 09:03, Bert Verhees wrote:

Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be 
discussed separately.
I do that because in the other message, I describe a real problem 
which needs a solution, and this message is about thinking about a 
solution in the archetype-framework, which will takes for years to 
come (if it will come, maybe I am wrong in my proposal).

-
When talking about specializing. Specializing an archetype is nothing 
more then copying an archetype and add/change some constraints in them.


Only in older ADL 1.4 tools. In ADL2, specialisation is fully defined 
<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_specialisation> 
and implemented in the ADL Workbench, and more recently in the 
ADL-designer project <https://github.com/openEHR/adl-designer>. it 
works just like an OO programming language. There are dozens of 
examples in the test archteypes 
<https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/features>, 
and also in the CKM archetypes, which when they are read into ADL 
Workbench, are re-engineered into differential form.


This has been the case for over 5 years, with the implementation in 
ADL Workbench being available for around 4. (You can see the revision 
history 
<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_amendment_record> 
of the AOM2 spec).


Using this technology is just a case of moving to ADL/AOM2.

- thomas



How different is that in programming languages, where the 
parent-classes are read to understand the child class. There is no 
need to process all the sourcecode of the child-classes to adapt the 
changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. 
Easier to maintain code (and one definitely need a test framework).


Imagine that dreaded generic labtest archetype in the other message, 
I wrote today.
How convenient would maintainability become if specializations where 
really and life-inherited from parent archetypes?


Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and 
add the appropriate terminology binding?


Maybe we could, in case of lab-test, just created the child 
archetypes only in memory and on the fly, needing only a few keywords 
to describe the changes. We could take a look at hibernate for Java 
(or many other ORM-frameworks).
They do not deliver the classes needed for handling specific 
databases, they offer a framework to create/generate those classes.


One could argue that specializations are not always inherited like 
classes in programming languages. That is true. What I suggest here 
maybe limited to the cases where it is real inheritance.


Best regards
Bert Verhees




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
*Birger Haarbrandt, M.Sc.*

Peter L. Reichertz Institut für Medizinische Informatik
Technische Universität Braunschweig und
Medizinische Hochschule Hannover
Carl-Neuberg-Str. 1
30625 Hannover

T +49 (0)531 391-2129
F +49 (0)531 391-9502
birger.haarbra...@plri.de
http://www.plri.de

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: inheritance of archetypes

[Thomas Beale]

On 01/03/2017 09:03, Bert Verhees wrote:

Dear all of the technical mailing list,

I made a new message tothis list (specialized ;-), so it will be 
discussed separately.
I do that because in the other message, I describe a real problem 
which needs a solution, and this message is about thinking about a 
solution in the archetype-framework, which will takes for years to 
come (if it will come, maybe I am wrong in my proposal).

-
When talking about specializing. Specializing an archetype is nothing 
more then copying an archetype and add/change some constraints in them.


Only in older ADL 1.4 tools. In ADL2, specialisation is fully defined 
<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_specialisation> 
and implemented in the ADL Workbench, and more recently in the 
ADL-designer project <https://github.com/openEHR/adl-designer>. it works 
just like an OO programming language. There are dozens of examples in 
the test archteypes 
<https://github.com/openEHR/adl-archetypes/tree/master/ADL2-reference/features>, 
and also in the CKM archetypes, which when they are read into ADL 
Workbench, are re-engineered into differential form.


This has been the case for over 5 years, with the implementation in ADL 
Workbench being available for around 4. (You can see the revision 
history 
<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_amendment_record> 
of the AOM2 spec).


Using this technology is just a case of moving to ADL/AOM2.

- thomas



How different is that in programming languages, where the 
parent-classes are read to understand the child class. There is no 
need to process all the sourcecode of the child-classes to adapt the 
changes in a parent class.
This is regarded as a big advantage for Object Oriented Programming. 
Easier to maintain code (and one definitely need a test framework).


Imagine that dreaded generic labtest archetype in the other message, I 
wrote today.
How convenient would maintainability become if specializations where 
really and life-inherited from parent archetypes?


Would we need a big part of the LOINC-database of specialized labtest 
archetypes then, or would we just need to change the identifier and 
add the appropriate terminology binding?


Maybe we could, in case of lab-test, just created the child archetypes 
only in memory and on the fly, needing only a few keywords to describe 
the changes. We could take a look at hibernate for Java (or many other 
ORM-frameworks).
They do not deliver the classes needed for handling specific 
databases, they offer a framework to create/generate those classes.


One could argue that specializations are not always inherited like 
classes in programming languages. That is true. What I suggest here 
maybe limited to the cases where it is real inheritance.


Best regards
Bert Verhees


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org