Re: data element type from the RM

[Pieter Bos]

In a serialized RM instance there is always a field that lets you know what the 
class is, for example standardized as discussed before in xml, and as the field 
_type in json.

If you have this mapped as actual objects in memory in your system, those 
usually have something in place to determine which class an object is. There's 
no need to replace the standard mechanisms with something custom and 
non-standard.

In other words, yes you need to know the class of a given object, but it is 
mapped to the mechanism best suited for the used concepts and technology.

Regards,

Pieter Bos

Op 10 okt. 2019 12:19 schreef Georg Fette :
But if the class is contained within a template instance only within
some technical background information and it is not part of the
reference model, how can a query mechanism like AQL use this information
during query execution ?
How does an AQL query engine know that an archetype based on Composition
is a Composition when this link is given in the RM-part of the
serialized instance only within the archetype_id of the
archetype_details ? From that it could deduced by using the background
knowledge of the available archetype definitions that it is in fact a
Composition. It would be easier if this would be directly included in
the RM-part of a serialized Composition itself.
Or is the class type something one would assume as part of the RM ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B009
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: JSON for definitions-notation

[Pieter Bos]

Archie offers a json serializer and deserializer. For Odin they are present as 
well, but has not been tested with archetypes, may need a small bit of work. 
Yaml should be a matter of adding a dependency and configuring it.
We're still working on XML - the bindings are there and it works, but the AOM 
schemas have not been finished yet so there will be changes, see the 
specifications-ITS-XML repository on GitHub for details.

One could argue ADL is easier to read and write by humans than json, yaml, Odin 
or XML. The other formats have a lot more tools available. Good thing we have 
both.

Regards,

Pieter Bos



Op 15 feb. 2019 20:41 schreef Thomas Beale :

JSON, YAML and ODIN are all just object-dump serial formats that result from 
traversing an in-memory object graph, so it is a generic operation to generate 
them from tools (XML is more problematic due to being irregular in many ways 
and being schema-dependent).

In the case of archetypes, the dump is just of objects that are instances of 
the 
AOM<https://specifications.openehr.org/releases/AM/latest/AOM2.html#_the_archetype_package>,
 i.e., ARCHETYPE, C_ATTRIBUTE, various kinds of C_OBJECT and so on.

The ADL Workbench has an export mode (for I think around 5 yeras) that 
generates the first 3 for any archetype, and also a whole archetype library. 
The folks doing CIMI use at least the JSON mode. It also generates XML, via 
custom serialiser.

One of the jobs I never completed is a deserialiser for the 3 regular formats, 
but it is nearly trivial. I am not sure if Archie or Marand's ADL-designer 
tools do the same but I think it should be trivial for them to implement as 
well.

I will look into this again...

- thomas

On 15/02/2019 18:51, Bert Verhees wrote:
I always admired OpenEhr for its ability to notate archetype-definitions and 
now also BMM definitions in any type.

I saw experiments in XML, but the official endorsed notation language is ADL.


I wonder, would it also be possible to write archetypes and reference-models in 
JSON?

If so, it would save us tons of code, no grammars needed, no parsers needed. 
Many programming languages support JSON out of the box, with only some 
annotations needed. NoSQL Databases often support JSON, and have their own 
JSON-path based hierarchical query-languages.

Venkat Subramaniam, who is a java-guru, said: "Don't walk away from complexity, 
RUN!!!"

But Einstein said: "Everything Should Be Made as Simple as Possible, But Not 
Simpler"

So the question is: Are there any technical objections to express archetypes 
and reference-models in JSON?

Best regards

Bert Verhees


___
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: 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?

[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 example since those have occurrences {0..1} in the archetype).

Re: Rules in archetypes - what are the requirements?

[Pieter Bos]

But then you need a second language to define a function to calculate a simple 
score. Without it's possible to create tooling to help modelers write at least 
simple expressions. basic math and some simple 'if x is between 3 and 10, fill 
this field with this value' is entirely doable without manually writing 
expressions, even in the proposed syntax. And the more technically inclined 
modellers can do a lot more if the tooling helps them with choosing the right 
paths. Also functions will need to be reimplemented for every environment - 
doesn't sound like interoperability to me.

On the subject of the lists of values problem: Instead of binding outside the 
expression language, you could do something like assigning the value of a path 
to variables with a readable name as statements in the actual expression 
language. in combination with a for loop that can contain multiple statements, 
or at least variable assignments and one statement, it would solve these issues 
completely and still be readable to humans. and you can still write tooling to 
visualize the rules to non-technical people like we can now.

Also I consider the requirement to explicitly state the type of variables 
beforehand to be tricky. Tooling could solve it, but it's not something I can 
easily explain to less technical people.

An alternative could be to switch to something Turing complete, like JavaScript 
or typescript, to define a few included functions to lookup data and to 
interact with the data, and a defined data model to ensure interoperability. 
Much easier to specify and implement, although it will be harder/no longer 
possible to write tooling to visualize the code and harder to write tools that 
allow less-technical people to write code.

Regards,

Pieter Bos

Op 2 feb. 2019 14:16 schreef 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<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 Fri, 1 Feb 2019 at 14:53, Pieter Bos 
mailto:pieter@nedap.com>> 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 obser

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?

[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: ADL specification question

[Pieter Bos]

The cardinality you mention only defines how many values the items attribute 
must have. In this case at least two.

Which values that are depends on the child elements/items and their occurrences 
attribute. If the occurrence of both of these  is 1 exactly, they must both 
appear. If they both are 0..*, it can be two or more of the first, two or more 
of the second, or at least one but possibly more of both. More options are 
possible. If occurrences is not defined, in this case I think it defaults to 
0..*.

Regards,

Pieter Bos

Op 29 nov. 2018 10:31 schreef Georg Fette :
Hello,
I have an archetype with a complex object derived of CLUSTER with
"items cardinality matches {2..*; ordered}"
and those two items are also defined inside the complex object.
I understand the semantics of this definition that both items always
have to appear together inside the cluster but the package of those two
items may appear any number of times.
Is it allowed for instances of this archetype to have an uneven number
of items > 2 inside this cluster, because that would still suffice the
restriction of having 2..* children. Or do the instances always have to
have both elements as a package that are defined as items in this cluster.
As I am not the author of the archetype I do not completely understand
how the definition has to be interpreted.
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: 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

[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

Re: DV_DURATION and magnitude_status?

[Pieter Bos]

Not sure if this is already in the RM version you use and not sure if ADL 1.4 
supports this, but can this be a DV_INTERVAL of DV_DURATION?

Regards,

Pieter Bos

Op 24 sep. 2018 14:42 schreef "Bakke, Silje Ljosland" 
:

Hi,



I’ve got a use case where we need to represent a time duration (of a symptom), 
which can be for example <24H or >3M. Is it possible to represent this using 
the DV_DURATION data type, like you can do with DV_QUANTITY and 
magnitude_status? If not, what should we do?



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: Strange behavior in Template designer 2.8.94 Beta

[Pieter Bos]

Has that been changed? Last time I checked and asked Marand it was ADL 1.4 
only. Or is it AOM 2.x but ADL 1.4?

Regards,

Pieter Bos

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

Date: Monday, 20 August 2018 at 13:04
To: "openehr-technical@lists.openehr.org" 
Subject: Re: Strange behavior in Template designer 2.8.94 Beta


The new tool is AOM 2.x inside, but I have to admit I have not investigated how 
this particular problem is resolved in it.

- thomas

On 20/08/2018 11:42, Peter Gummer wrote:
Hi Hildi,


On 20 Aug 2018, at 19:13, Hildegard McNicoll 
mailto:hi...@freshehr.com>> wrote:

Incidentally, the new web based ADL Designer tool developed by Marand doesn't 
have this problem anymore. As far as I know it is very close to being released 
now.


I’m curious — from a purely academic perspective, now, since unfortunately I’ve 
not been able to participate in the openEHR revolution for the last couple of 
years — how this new tool is able to do that. Does this require migrating to 
ADL 2.0? As I recall (and it could be my memory at fault here) this was a 
limitation of ADL 1.4, rather than of the Ocean Template Designer itself.

Peter


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

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Pieter Bos]

I don't understand. You can implement a single class ISO8601 Duration, 
containing all the different fields, all optional, that directly maps to and 
from the string representation. You can also easily use it to model both P30D 
and P1M, which are indeed different things. Depending on the fields set, it's 
either very exact or a bit less exact notion of duration.

You should not expect to always to the same calculations with all recorded 
values. How you should exactly handle durations, or dates, or date times, or 
intervals of date times, and if and how you need to split classes, depends on 
the context (archetypes are a very nice tool to define and standardize 
context). The standard ISO8601 types are very useful for having a standard way 
to record date, time, date+time, duration and intervals between fixed points in 
time, with varying precision. And I don't think we need anything else and 
certainly not anything less in the RM.


Also days are not always 24 hours. Next weekend in our time zone we have a 23 
hour day... 
That is one reason why some libraries make a different split between the 
concepts than what you call 'calendar' and 'duration'. Also every library and 
standard has its own term for those concepts.

 
Regards,

Pieter Bos

On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" 
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> 
wrote:

No Duration type is a ISO8601 duration, ISO8601 is just a string 
representation of a duration. No programming language can, from its 
standard library safely express an ISO8601 in a class, because the 
ISO8601 is a combination of two types.
Unless you are wiling to have an uncertainty of 10%, you cannot express 
a month in a Duration type. For many software, this uncertainty is not 
acceptable. Maybe it is for medical purposes, but OpenEhr also has an 
Admin_Entry, and there this uncertainty is not always acceptable. How do 
you bill someone who was one month in a clinic? Make it 28 days or 31 days?

And the solution is easy, and it has advantages.

If we split the Dv_Duration in a Calendar part and in a Duration part, 
then both have their own merits. If you want to bill a stay of a month 
in a clinic, you express it by days (which are always 24 hours) P30D 
(represented by the Duration class) and if you want the patient to 
return every month, you can use the first part, P1M (represented by the 
Calendar class).

I don't think this is complex or requires complex algorithms, even 
opposite, it makes it more simple and more certain to process and all 
the troubles and bad feelings when converting a month to 30 days, and 
then find out it was 28 days, are gone. I think Joda was a complex 
solution for a simple problem.

Bert




On 21-03-18 13:47, Pieter Bos wrote:
> There seems to be some confusion regarding the concept of a ISO8601 
Duration. You can definitely define a duration of 2 months in ISO8601 
Durations. It has separate fields for years, months, weeks, days, plus an 
optional time with hours, minutes and seconds. All these fields are optional 
and can all be combined. It cannot be fully modelled using a single nanosecond 
field - you would run into trouble with years, months, and even days, plus you 
cannot express for example a duration of 1 hour with no precision in the 
minutes and seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.
>
> The golang Duration type in the time package is _not_ an ISO8601 
duration, but just a duration in nanoseconds, explicitly omitting the 
definition of days. There are libraries available for golang that do model the 
full iso8601 duration.
>
> Of course, I agree that we should not have a far too big reference model. 
There is a point at which it no longer makes sense to add something to the 
reference model because it is better modelled in an archetype. But I think the 
concept of a duration can be very useful. You could use it to model the 
examples Gerard Freriks mentions for example:
>   
> - 24 minutes, 5 seconds can be modelled as a single Element with a 
DV_Duration value. The ISO8601 text representation of the dv_duration.value 
field would be PT24M5S.
> - For 2 hours past midnight can be modeled with two Elements, for example 
a 'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
> - A duration after a specific clinical event can be modelled as however 
you want to model the reference to the clinical event, plus a single 
DV_DURATION field. In the first example the  value field of the DV_DURATION 
would be P2M, the second PT2H
>
> Say you want to model the duration 

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Pieter Bos]

There seems to be some confusion regarding the concept of a ISO8601 Duration. 
You can definitely define a duration of 2 months in ISO8601 Durations. It has 
separate fields for years, months, weeks, days, plus an optional time with 
hours, minutes and seconds. All these fields are optional and can all be 
combined. It cannot be fully modelled using a single nanosecond field - you 
would run into trouble with years, months, and even days, plus you cannot 
express for example a duration of 1 hour with no precision in the minutes and 
seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.

The golang Duration type in the time package is _not_ an ISO8601 duration, but 
just a duration in nanoseconds, explicitly omitting the definition of days. 
There are libraries available for golang that do model the full iso8601 
duration.

Of course, I agree that we should not have a far too big reference model. There 
is a point at which it no longer makes sense to add something to the reference 
model because it is better modelled in an archetype. But I think the concept of 
a duration can be very useful. You could use it to model the examples Gerard 
Freriks mentions for example:
 
- 24 minutes, 5 seconds can be modelled as a single Element with a DV_Duration 
value. The ISO8601 text representation of the dv_duration.value field would be 
PT24M5S.
- For 2 hours past midnight can be modeled with two Elements, for example a 
'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
- A duration after a specific clinical event can be modelled as however you 
want to model the reference to the clinical event, plus a single DV_DURATION 
field. In the first example the  value field of the DV_DURATION would be P2M, 
the second PT2H

Say you want to model the duration after which to resume a specified daily 
activity after a specified clinical event . You could model it by creating an 
archetype with a reference to the clinical event, a model of a description of 
the activity, and then a single DV_DURATION field, describing the time between 
the event and the start of the daily activity. 
The person entering the data with this archetype now has the freedom of 
choosing any detail level he or she wants - whether that is in terms of years, 
months, weeks, days, hours, minutes, seconds, or any combination of any of 
these terms.

And the nice thing is, you would use a standards based duration concept that is 
readily available in many off the shelf languages, libraries, serialization 
tools, UI components and databases, instead of defining your own. And it's 
already defined in the OpenEHR models, so you can start using it right away.

Regards,

Pieter Bos
Nedap Healthcare


On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" 
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> 
wrote:


On 21-03-18 10:50, GF wrote:
> Does including Duration in the RM fit with the scope for the RM?
>
> Why do we have archetypes?
> Why not include every thing in the RM?
> Do we want the HL7v3 Reference Model as it existed many years ago and 
> that could not be inspected without a magnifying glass on a sheet of 
> paper that was 2 by 1 meters?
>
> Is there one kind of duration?
> 24 minutes, 5 seconds?
> For 2 hours past midnight?
> For 2 hours after (clinical) event x
> For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because month 
is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration and 
a Calendar class.

Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right (I 
prefer this way),
or express months as if it is a stable time-indicator and ignore it is 
not (like it is now)

Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

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: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

[Pieter Bos]

Java 8 has a Duration for hours, minutes and seconds, and Period for years, 
months and days. Both implement a few interfaces with which you can abstract 
them.
No idea why they chose this, it’s quite annoying to work with. You can 
relatively easily implement your own variant of ChronoPeriof that supports all 
of the options.

Regards,

Pieter Bos

Op 20 mrt. 2018 om 21:06 heeft Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> het volgende 
geschreven:

Thanks Thomas, will create the PR!

Also will double check if the same happens with other types, but I think the 
only "odd" one that might not be correct to assume, is the Duration. For 
instance, Java 8 added the Duration as a base type, but it only handles day to 
seconds duration expressions, year, month, week are not supported. Each 
technology has it's own quirks :)

On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:


On 19/03/2018 22:25, Pablo Pazos wrote:
Hi Thomas, the definition of DV_DURATION is clear to me :)

The issue is on the 1.0.2 specs, I guess they used DV_DURATION in C_DURATION 
because the referenced Duration class in C_DURATION was not included on the 
specs. This is the issue I'm pointing to, the missing class.

Right - the ADL/AOM 1.4 specs made the assumption that each primitive 
constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc, constrained 
a same- or similarly named primitive type like Integer, String, Date, Duration 
etc that are assumed to be part of the technology environment. THey are 
normally part of the programming language, DB, or serialisation formalisms.

I think this probably was not as clear as it should have been in that spec.

In the AOM2/ADL2 specs, we have clarified this so that the same types 
(C_INTEGER etc) now refer to types that are defined in the Foundation spec of 
the BASE component.


Clarifying that on an errata addendum would help to avoid such implementation 
mistakes, that are really caused by the missing information on the spec + 
interpretation to fill the gap.

agree, we should do this - can you create a PR for this? Or add to an existing 
PR.



BTW, this is one case that I detected because I'm doing research for a new 
course. There might be issues like this on other areas of 1.0.2, I mean missing 
classes referenced from AOM or AOP. I didn't do a complete review of the specs.

I would love to migrate everything to baseline spec and use AOM2, but I can't 
afford the cost right now. I'm sure others are on my same position.

hopefully that will change soon, because ADL2 is more regular and simpler than 
ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be interested 
to know what the real costs are and to see what we can do to make the 
transition simpler, because staying with ADL1.4 is limiting system 
functionality for the future.


BTW tried to check if the issue is also on 1.0.3 but the link to support is 
broken http://openehr.org/RM/Release-1.0.3/support.html

the page where you got that 
link<https://www.openehr.org/releases/RM/Release-1.0.3/docs/index> is now fixed.

- 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



--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 <http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
https://cloudehrserver.com<https://cloudehrserver.com/>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

___
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: Announcing Archie version 0.4

[Pieter Bos]

From the tutorial you mention:

'Don't go looking for facilities similar to class inheritance, though – 
protocol buffers don't do that.'

On 23/02/2018, 16:57, "openEHR-technical on behalf of Bert Verhees" 
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> 
wrote:

On 23-02-18 16:36, Pieter Bos wrote:
> you would have to find a way to map all the inheritance in the OpenEHR 
model to protocol buffers.
For Java I found this web-page which explains how to do it. It is about 
a class with one nested class

https://developers.google.com/protocol-buffers/docs/javatutorial




___
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: Announcing Archie version 0.4

[Pieter Bos]

Those are all valid points, but for many applications, I would say are not 
actual problems. If we're discussing the context of archetype editing tools, I 
would say REST with JSON is fine. HTTP traffic is usually compressed and 
browsers have heavily optimized their JSON parsing, making it much more 
efficient than it would seem. Very good tools are available in many languages 
to parse and validate JSON encoded data against a given model and given types. 
Many people know how to use it so they can start developing right away, and 
debugging is easy due to the fact that is human readable.

For microservices with enough traffic, or for devices with limited processing 
power or limited bandwidth, a binary encoding makes sense. However, GRPC would 
not be my first choice for OpenEHR - you would have to find a way to map all 
the inheritance in the OpenEHR model to protocol buffers.

Regards,

Pieter Bos
Nedap Healthcare

On 23/02/2018, 15:30, "openEHR-technical on behalf of Bert Verhees" 
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> 
wrote:

On 23-02-18 14:37, Pieter Bos wrote:
> A small amount of JavaScript working with Json from a backend works very 
well for us.
>
> You don’t always need explicit class definitions. it does require a 
different programming style than a more object oriented language.

Thomas has a point,

JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 
bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of 
CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are 
misused for functional error-codes
- the http-protocol with all the headers is not efficient and has 
unnecessary overload
- REST is not error or type safe, you can send anything to a 
restservice, it processes the whole request-headers, and then looks if 
the parameters are sufficient in number and in type

Check this, it is a good explanation (if you have time for that, it 
hardly handles about Go):
https://www.youtube.com/watch?v=J-NTfvYL_OE

The question is only of a license-restricted product as ICE is the 
answer to this problem
For microservices GRPC works very well, it has a performance of 
sometimes 100* the performance of rest, it supports also bi-directional 
streaming, and it is safe, because the interface-code is generated.

There are some promising projects for GRPC in browsers which support 
HTTP/2 (this are all browsers in their latest versions)
I did not test it, but I will, in a few weeks in a project I am working on.
https://github.com/improbable-eng/grpc-web

Bert

>
> Regards,
>
> Pieter Bos
>
> Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> het volgende geschreven:
>
> The problem with Ice is that it is not open source licensed when used in 
a non GPLv2 product.
> Another problem is that they do not publish the price of a commercial 
license.
>
> That are restrictions that cause many programmers not to use it.
>
> https://zeroc.com/licensing
>
>
> On 23-02-18 13:59, Thomas Beale wrote:
>
> Belated thought on this topic: a much better way to connect a JavaScript 
front end with a Java back end, or any similar combination, would be with a 
binary RPC protocol like ICE<https://zeroc.com/products/ice>, that comes with 
tools to make it all work.
>
> - thomas
>
> On 05/02/2018 22:04, Thomas Beale wrote:
>
>
> yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.
>
> - thomas
>
> On 03/02/2018 07:56, Peter Gummer wrote:
> On 1 Feb 2018, at 05:13, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:
>
> ... But the main interest is that we will be able to build new tools such 
as a Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.
>
> Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how 
Archie (written in Java, disappointingly) would enable JavaScript 
implementations. JavaScript has nothing in common with Java (apart from the 
name).
>
> Peter
>
>
 

Re: Announcing Archie version 0.4

[Pieter Bos]

A small amount of JavaScript working with Json from a backend works very well 
for us.

You don’t always need explicit class definitions. it does require a different 
programming style than a more object oriented language.

Regards,

Pieter Bos

Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> het volgende geschreven:

The problem with Ice is that it is not open source licensed when used in a non 
GPLv2 product.
Another problem is that they do not publish the price of a commercial license.

That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:

Belated thought on this topic: a much better way to connect a JavaScript front 
end with a Java back end, or any similar combination, would be with a binary 
RPC protocol like ICE<https://zeroc.com/products/ice>, that comes with tools to 
make it all work.

- thomas

On 05/02/2018 22:04, Thomas Beale wrote:


yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. 
Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.

- thomas

On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter




___
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<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

HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

[Pieter Bos]

Sounds like a good proposal Pablo.

For ADL 2 a single archetype api can be used for both archetypes and templates. 
However, it makes sense to allow the get api of archetypes to specify the form 
you want the result in: differential, flattened, or operational template (opt2).

Our EHR still will integrate the archetype part and query part, as well as the 
option to choose a used archetype for a slot at runtime. Could all be built 
with separate services and apis, but once you have everything integrated it 
makes for a very easy to use API for both EHR and datawarehouse usage. without 
needing sophisticated client libraries. However, you need much more complex 
server side tools in the EHR of course.

Regards,

Pieter

Op 16 feb. 2018 om 15:48 heeft Pablo Pazos <pablo.,@cabolabs.com> het volgende 
geschreven:Ivo

Hi Pieter,s

Besides the API, I think for ADL2 archetypes and templates/OPTs have the same 
model, and archetype IDs / template IDs will follow the same structure.So for 
ADL2 using archetypes or templates would be the same in the API.

Which endpoints do you find problematic in terms of using ADL2?


About querying, analyzing your use case, I think there are two ways of knowing 
the full specialization hierarchy, one is to query an archetype repo/CKM while 
evaluating a query and do not have that info in the data repo. Like "give me 
all archetype IDs that specialize arch ID X", this will be [A, B, C], then use 
that list on the query in your data repo like "archetype_id IN [A, B, C]".

The other option is to have the archetype repo/CKM integrated with the clinical 
data repo (which I don't like architecturally speaking), so the "give me all 
the archetype IDs that specialize arch ID X" is resolved internally.

Considering there is a component that has knowledge about the specialization, 
and that can be used internally (behind the API) I don't see the need of adding 
explicit support in the API for archetypes.

What I think is better is to define an archetype repo/CKM API to manage 
archetypes and to resolve specialization queries among other queries like "this 
path exists for this archetype ID?", etc. If this is possible, we can have 
interoperability between archetype repos and your queries can use my repo to 
get specialization info, and vice-versa.


Best,
Pablo.



On Thu, Feb 15, 2018 at 1:09 PM, Pieter Bos 
<pieter@nedap.com<mailto:pieter@nedap.com>> wrote:
I noticed the recent version of the REST api  only works with templates, and 
not archetypes.

As our EHR is ADL 2 only, this has some interesting consequences.

Of course, you can upload just the operational templates and probably create a 
fully functional EHR, but if you work with ADL 2, you would always need an 
external tool to create the OPT2 from the ADL repository that you want to use, 
instead of an EHR that generates the OPT2s from the source archetypes itself. 
Of course, you could just use the ADL workbench or the Archie adlchecker 
command-line utility to do it for you, but I’m not sure if it’s a nice thing to 
do.

Also if you only use OPT2, you might want to do queries such as ‘retrieve all 
information that is stored in an EHR that has been derived from archetype with 
id X, including archetypes specializing from X’ (not just operational template 
X). An example: retrieve all reports, or all care plans, regardless of the used 
template. To do that, you probably need a specialization section in the OPT2, 
which according to the specs should have been removed, and you also need to 
create operational templates for archetypes that you never use to directly 
create compositions from. Or the tool querying the EHR must be fully aware of 
the full archetype specialization tree and use that to create a query with all 
specializing archetypes included in the query.

So, is it intended that the REST API only works with operational templates, and 
never archetypes?

Regards,

Pieter Bos

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Date: Friday, 26 January 2018 at 14:23
To: Openehr-Technical 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Subject: openEHR REST APIs - Release 0.9.0 / invitation for comments


The REST API Team (Bostjan Lah, Erik Sundvall, Sebastian Iancu, Heath Frankel, 
Pablo Pazos, and others on the 
SEC<https://www.openehr.org/programs/specification/editorialcommittee> and 
elsewhere) have made a 0.9.0 Release of the ITS (Implementation Technology 
Specifications) component, in order to make a pre-1.0.0 release of the REST 
APIs available for wider comment.

The key poin

Re: openEHR REST APIs - Release 0.9.0 / invitation for comments

[Pieter Bos]

I noticed the recent version of the REST api  only works with templates, and 
not archetypes.

As our EHR is ADL 2 only, this has some interesting consequences.

Of course, you can upload just the operational templates and probably create a 
fully functional EHR, but if you work with ADL 2, you would always need an 
external tool to create the OPT2 from the ADL repository that you want to use, 
instead of an EHR that generates the OPT2s from the source archetypes itself. 
Of course, you could just use the ADL workbench or the Archie adlchecker 
command-line utility to do it for you, but I’m not sure if it’s a nice thing to 
do.

Also if you only use OPT2, you might want to do queries such as ‘retrieve all 
information that is stored in an EHR that has been derived from archetype with 
id X, including archetypes specializing from X’ (not just operational template 
X). An example: retrieve all reports, or all care plans, regardless of the used 
template. To do that, you probably need a specialization section in the OPT2, 
which according to the specs should have been removed, and you also need to 
create operational templates for archetypes that you never use to directly 
create compositions from. Or the tool querying the EHR must be fully aware of 
the full archetype specialization tree and use that to create a query with all 
specializing archetypes included in the query.

So, is it intended that the REST API only works with operational templates, and 
never archetypes?

Regards,

Pieter Bos

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Thomas Beale <thomas.be...@openehr.org>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org>
Date: Friday, 26 January 2018 at 14:23
To: Openehr-Technical <openehr-technical@lists.openehr.org>
Subject: openEHR REST APIs - Release 0.9.0 / invitation for comments


The REST API Team (Bostjan Lah, Erik Sundvall, Sebastian Iancu, Heath Frankel, 
Pablo Pazos, and others on the 
SEC<https://www.openehr.org/programs/specification/editorialcommittee> and 
elsewhere) have made a 0.9.0 Release of the ITS (Implementation Technology 
Specifications) component, in order to make a pre-1.0.0 release of the REST 
APIs available for wider comment.

The key point about this current release is that it is meant to be a 'core 
basics' foundation of APIs to build on, and some services like CDS, and more 
sophisticated querying (e.g. that Erik Sundvall has published in the past) will 
be added over time.

NOTE THAT IN THE 0.9.0 RELEASE, BREAKING CHANGES ARE POSSIBLE.

You can see the ITS Release 0.9.0 link 
here<https://www.openehr.org/programs/specification/latestreleases>, while the 
links you see on the specs 'working baseline' 
page<https://www.openehr.org/programs/specification/workingbaseline> are the 
result of 0.9.0 plus any modifications made due to feedback. The .apib files 
are here in 
Github<https://github.com/openEHR/specifications-ITS/tree/master/REST_API> (see 
mainly the includes directory).

We are aiming to release 1.0.0 at the end of February, at which point the 
formal process kicks in.

Since we are in Release 0.9.0, the formal PR/CR process is not needed, and you 
can comment here. However, if you want to raise a PR you can, in which case, 
please set the Component and Affects Version fields appropriately:

[cid:image001.png@01D3A67F.BBCA2180]

- thomas  beale
--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, 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/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Announcing Archie version 0.4

[Pieter Bos]

Or a Java app with rest api and a JavaScript frontend. Let the java application 
take care of parsing, validating, flattening, operational template creation etc 
and send json to your front end. Archie has built-in json serialization and 
deserialization support.

Pieter

Op 3 feb. 2018 om 12:05 heeft Seref Arikan 
> 
het volgende geschreven:

Hi Peter,

Presumably via use of a transpiler or a bytecode to js/webassembly compiler.

On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer 
> wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter


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

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

Re: Announcing Archie version 0.4

[Pieter Bos]

And due to several small bugs, we’re at version 0.4.2. Should be available soon 
at maven central.

For anyone wanting to test Archie without writing code, we’ve also created a 
command-line archetype validator. Works with all included BMM reference models, 
including OpenEHR and CIMI.

To use:

1.   Download adlchecker.zip version 0.4.2 from the releases page of the 
archie github repository, at https://github.com/openEHR/archie/releases.

2.   Unzip

3.   Make sure you have a java 8 JRE installed and that typing ‘java 
-version’ in a command/terminal window shows you installed java version 1.8.x

4.   Run bin/adlchecker (linux, OS X) or bin/adlchecker.bat (windows) from 
a terminal/command prompt and follow the instructions to point it at your 
archetypes

Note that it only supports ADL 2, not 1.4. It can also output the flat ADL.

If you find any issues, they can be reported at the github repository.

Regards,

Pieter Bos
Nedap Healthcare

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Thomas Beale <thomas.be...@openehr.org>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org>
Date: Wednesday, 31 January 2018 at 19:13
To: "openehr-implement...@lists.openehr.org" 
<openehr-implement...@lists.openehr.org>, Openehr-Technical 
<openehr-technical@lists.openehr.org>
Subject: Re: Announcing Archie version 0.4




This is excellent work, and has proven to be a great test for the AM 
specifications<http://www.openehr.org/releases/AM/latest/docs/index>, helping 
me to find various errors. But the main interest is that we will be able to 
build new tools such as a Java/JS replacement for the ADL Workbench, and of 
course things like a high-quality, BMM-driven runtime archetype validating 
kernel for EHR systems, workflow implementations and many other components.
- thomas
On 31/01/2018 15:18, Pieter Bos wrote:

Hi,



We’re pleased to announce Archie version 0.4! For those of you unfamiliar with 
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for 
archetype modelling and EHR implementations with ADL 2.



Version 0.4 is a big change from version 0.3. Many features have been added 
that make Archie suitable as a library for modelling archetypes, and the 
existing functionality has been improved.



It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and 
Kurt Allen. This enables Archie to work with other reference models than the 
included OpenEHR reference model. The BMM files and AOM profiles that are in 
the ADL workbench are included in the library – of course you can supply your 
own as well.



We developed an archetype validator that implements nearly all of the 
validations in the specification, and we improved the flattener and the 
operational template creator to be compliant with the specifications. The 
flattener, archetype validator and operational template creator work with both 
the BMM models or with metadata derived from an actual java reference model 
implementation.

Many tests were added to ensure better conformance with the specification and 
many fixes have been introduced. We’d like to thank Thomas Beale for giving 
advice about many details of the working of OpenEHR implementations and for 
fixing mistakes in the specifications when they were found.



Of course, Archie also contains a lot of other tools, many of which allow it to 
be used as the basis for an EHR implementation as well as a modelling tool: An 
ADL parser and serializer, the OpenEHR reference models, rule evaluation, path 
lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation 
tools.



Archie version 0.4.1 is available at Maven Central. See the instructions and 
documentation in the readme at https://github.com/openehr/archie for how to use 
the library.



Regards,



Pieter Bos

Nedap Healthcare

___

openEHR-implementers mailing list

openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>

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

--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, 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/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Announcing Archie version 0.4

[Pieter Bos]

Hi,

We’re pleased to announce Archie version 0.4! For those of you unfamiliar with 
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for 
archetype modelling and EHR implementations with ADL 2.

Version 0.4 is a big change from version 0.3. Many features have been added 
that make Archie suitable as a library for modelling archetypes, and the 
existing functionality has been improved.

It includes a BMM implementation contributed by Claude Nanjo, Joey Coyle and 
Kurt Allen. This enables Archie to work with other reference models than the 
included OpenEHR reference model. The BMM files and AOM profiles that are in 
the ADL workbench are included in the library – of course you can supply your 
own as well.

We developed an archetype validator that implements nearly all of the 
validations in the specification, and we improved the flattener and the 
operational template creator to be compliant with the specifications. The 
flattener, archetype validator and operational template creator work with both 
the BMM models or with metadata derived from an actual java reference model 
implementation.
Many tests were added to ensure better conformance with the specification and 
many fixes have been introduced. We’d like to thank Thomas Beale for giving 
advice about many details of the working of OpenEHR implementations and for 
fixing mistakes in the specifications when they were found.

Of course, Archie also contains a lot of other tools, many of which allow it to 
be used as the basis for an EHR implementation as well as a modelling tool: An 
ADL parser and serializer, the OpenEHR reference models, rule evaluation, path 
lookup, JSON and XML (de)serialization, ODIN parsing and RM object manipulation 
tools.

Archie version 0.4.1 is available at Maven Central. See the instructions and 
documentation in the readme at https://github.com/openehr/archie for how to use 
the library.

Regards,

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

Re: Quantities of arbitrary units in openEHR

[Pieter Bos]

A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification, there is 
no property attribute or function present in dv_quantity, even though the text 
says it can be conveniently constrained. There is a reference to the spec-95 
jira issue, which says it has been removed. So there’s no way to constrain it - 
unless the specification contains a mistake :)

It is present in the BMM variants of the RM though, as a mandatory field.

Regards,

Pieter Bos

Op 26 jan. 2018 om 08:19 heeft Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 het volgende geschreven:

Hi all, thanks for your replies!

I’m sure the CKM would accept the unit string, but which property would the 
Quantity have? Eg property = <[openehr::124]> for weight or property = 
<[openehr::127]> for temperature? I don’t think we have one of those codes for 
“Arbitrary”?

I’m sure you’re correct about the syntax, btw. ☺

Regards,
Silje

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Sebastian Garde
Sendt: torsdag 25. januar 2018 11:03
Til: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Emne: AW: Quantities of arbitrary units in openEHR

Hi Silje,

I think this may ‘just’ be a modelling tooling issue, openEHR itself supports 
this ok.

Speaking for CKM, if you upload an archetype with this to CKM, it should 
validate the UCUM unit correctly for [arb'U]{whatever}.
However, [arb‘u]{whatever} or similar is (very slightly) incorrect in my 
understanding:


  1.  Use the completely vertical ' not ‘ or similar (at least that is my 
understanding).
  2.  openEHR uses (implicitly I think, but it may be hidden somewhere in the 
spec), the case-sensitive version of UCUM – therefore the U needs to be upper 
case, see e.g. http://unitsofmeasure.org/ucum.html#para-45

Regards
Sebastian

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Betreff: Re: Quantities of arbitrary units in openEHR


Hi Silje,

I don't understand how adding an 'Arbitrary' term to the openEHR terminology 
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units 
just turn up in the String form you quoted for UCUM arbitrary units in that 
field?

(BTW, to ask for a new terminology term, just create a new issue on the PR 
tracker with component=New Term Request - choose this from the dropdown).

Setting property and not units makes sense - and if we had a proper, 
standardised units service, a runtime archetype evaluator would use it to limit 
the actual units for property = pressure (say) to only pressure units. I think 
we need to define such a service properly

- thomas

On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:
Hi all,

I’m working on representing medication strengths in archetypes at the moment. 
Most medications are thankfully measured in SI units such as mg/ml or mg/{dose 
unit}, but others use arbitrary units that are not derived from any other 
physical dimensional units. Examples of these are standardized quality units 
(SQ-U), focus forming units (FFU), European and American pharmacopoeia units, 
anti factor Xa units, or international units (IU). There are seemingly an 
unlimited number of these units, and they apparently make up new ones as they 
go along (ref: SQ-T and SQ-HDM). See 
http://unitsofmeasure.org/ucum.html#para-45 for more.

UCUM has a generic way of representing these, as “[arb’u]{whatever}” (arbitrary 
unit, name of the unit), but openEHR doesn’t seem to have a property in its 
Quantity data type for them. Could it be a possibility to add an “Arbitrary” 
property to the openEHR support terminology for unit properties?

Also, is it ok to model Quantity elements with a property set but the units 
left unconstrained? I’ve just started trying to add these units to an archetype 
(as a concentration, so got around the property issue), and it’s just a never 
ending task.

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 Team, Intermountain 
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR 
Foundation<http://www.openehr

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

[Pieter Bos]

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

Pieter

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

Date: Thursday, 30 November 2017 at 13:06
To: For openEHR technical discussions 
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á 
>:
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


--

[eraTech for Health SL]

[witter]   [inkedIn]  
  [aps]  

[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

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.



--

[eraTech for Health SL]

[witter]   [inkedIn]  
  [aps]  

[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

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

Re: Blockchain

[Pieter Bos]

One problem with blockchain is that people think every blockchain is secure, 
anonymous and decentralized – but that really depends on the specific 
implementation.

You can probably still create a proof of something-that-is-not-work-or-space 
that is reasonably decentralized, given you have enough independent parties who 
can authorize blocks, a mechanism to decide how to trust new authorizing 
parties and a good tamper-proof protocol including for example strict rate 
limiting.

But the very nature of storing healthcare related data in a public blockchain 
seems very tricky to me anyway – almost any implementation would need to be 
able to handle attacks where you link multiple pieces of data to the same 
person or party without having explicit permission to do so.
Regards,

Pieter Bos


From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Grahame Grieve <grah...@healthintersections.com.au>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org>
Date: Tuesday, 14 November 2017 at 17:02
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: Aw: Re: Blockchain

bitcoin doesn't use a reduced proof of work. That's the costly feature of it, 
and why it's genuinely distributed.

Grahame


On Wed, Nov 15, 2017 at 2:55 AM, Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> wrote:
On 14-11-17 16:39, Grahame Grieve wrote:
either you end up falling back to a central authority after all -

Can you explain why?

Bitcoin, f.e. is about billions of dollars without central authority, that is 
one of the reasons the Chinese government prohibited the creation (although 
they do not admit this real reason)

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://www.healthintersections.com.au / 
grah...@healthintersections.com.au<mailto:grah...@healthintersections.com.au> / 
+61 411 867 065
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Aw: Re: Blockchain

[Pieter Bos]

In the healthcare related blockchain ideas or prototype implementations I have 
heard about so far something different than proof of work is used, for example 
proof of authority. That has other drawbacks and challenges, but it does not 
suffer from the same power consumption problems.

Also any public healthcare related blockchain has interesting privacy issues 
that will need to be solved.

Regards,

Pieter Bos

Op 14 nov. 2017 om 16:21 heeft Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> het volgende geschreven:

On 14-11-17 16:02, Philippe Ameline wrote:
It can currently been argued that this competition led to concentrating
miners in China... but what could possibly go wrong?

Bitcoin is since a few weeks prohibited in China but it seems hard to kill.

But still, I don't think the use of blockchain in healthcare can be compared to 
the use of blockchain in currency, because, bitcoins is about getting rich by 
creating as many as possible, while in healthcare they exist to facilitate 
processes, and the number of processes create the demand, not the wish to get 
rich.

Another thing which came to mind, electricity is expensive because it needs to 
be created near the place where it is going to be used, or it needs to be 
transported. But blockchains for any purpose can be created on any place on 
earth, also on places where energy is almost for free. For example, windmills 
on top of the Himalaya, or solar cells in the middle of the Sahara. Just 
transport the bitcoins, no need to pollute the world very much.


___
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: Scenarios for change type "deleted"

[Pieter Bos]

I meant data using the criteria you outlined.

Regards,

Pieter Bos

Op 2 nov. 2017 om 18:25 heeft Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> het volgende 
geschreven:

Hi Pieter,

What structure?

On Thu, Nov 2, 2017 at 2:21 PM, Pieter Bos 
<pieter@nedap.com<mailto:pieter@nedap.com>> wrote:
You would be able to import this structure into our implementation and it would 
work the same way.

Pieter

Op 2 nov. 2017 om 17:24 heeft Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>>
 het volgende geschreven:

Until we have a clear criteria for commits after delete, I'll use this:

1. lineal versioning (no branching)
2. "deleted" compositions can be "undeleted" using "modification" change type, 
since we don't have an "undelete" change type
3. if current latest version is "deleted" the composition won't appear on query 
results



On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>>
 wrote:
Hi I'm trying to define a set of rules for a logical delete commit and have 
some gray areas that I'm not sure of.

1. commit after delete flow

[creation v1] => [modification v2] => [deleted v3] => ?

Can a modification/amendment v4 happen after a delete?

This is one of those cases that forks in the version tree can happen, since v2 
is deleted by v3, but v1 can be forked and a commit of modification or 
amendment can happen on that branch.

I'm considering the delete only affects a VERSION, not the whole 
VERSIONED_OBJECT.

Can a delete logically delete the whole VERSIONED_OBJECT?

On a lineal versioning scheme, I'm not sure if an amendment can happen after 
the delete. because the semantics of lineal versioning is I'm versioning v3 not 
v1 if I do a commit after v3.

I think if a delete happens, that is like killing that branch, so no new 
versions can be added.

Is that correct? What do others think?



2. delete on persistent compos

Looking at the specs, it is not clear to me how a delete would affect a 
persistent composition.

This is an open question.

This is also related with the previous case, since if a version is deleted on a 
persistent composition, there will be more commits for it after the delete, 
because it is persistent.



3. delete a non-trunk version

[creation v1] => [modification v2] => [amendment v3] => ...

Let's say there are many modifications/amendments for a compo, can be 
persistent or event.

What happens if a version in the middle of the version tree/line is deleted?

Can that even happen?

What happens with the created versions after that?

In my head those versions created on the branch of a deleted version should 
also be deleted if deletes are accepted in the middle of the tree. The other 
rule can be only accept deletes on the latest versions.


What do you think?


--
Ing. Pablo Pazos Guti?rrez
e: 
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>
p: +598 99 043 145<tel:%2B598%2099%20043%20145><tel:099%20043%20145>
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 <http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
https://cloudehrserver.com<https://cloudehrserver.com/>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>




--
Ing. Pablo Pazos Guti?rrez
e: 
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>
p: +598 99 043 145<tel:%2B598%2099%20043%20145>
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 <http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
https://cloudehrserver.com<https://cloudehrserver.com/>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

___
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

___
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



--
Ing. Pablo Pazos Guti?rrez
e: pablo.pa...@cabolabs.com<mailto:pablo.

Re: Scenarios for change type "deleted"

[Pieter Bos]

You would be able to import this structure into our implementation and it would 
work the same way.

Pieter

Op 2 nov. 2017 om 17:24 heeft Pablo Pazos 
> het volgende 
geschreven:

Until we have a clear criteria for commits after delete, I'll use this:

1. lineal versioning (no branching)
2. "deleted" compositions can be "undeleted" using "modification" change type, 
since we don't have an "undelete" change type
3. if current latest version is "deleted" the composition won't appear on query 
results



On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos 
> wrote:
Hi I'm trying to define a set of rules for a logical delete commit and have 
some gray areas that I'm not sure of.

1. commit after delete flow

[creation v1] => [modification v2] => [deleted v3] => ?

Can a modification/amendment v4 happen after a delete?

This is one of those cases that forks in the version tree can happen, since v2 
is deleted by v3, but v1 can be forked and a commit of modification or 
amendment can happen on that branch.

I'm considering the delete only affects a VERSION, not the whole 
VERSIONED_OBJECT.

Can a delete logically delete the whole VERSIONED_OBJECT?

On a lineal versioning scheme, I'm not sure if an amendment can happen after 
the delete. because the semantics of lineal versioning is I'm versioning v3 not 
v1 if I do a commit after v3.

I think if a delete happens, that is like killing that branch, so no new 
versions can be added.

Is that correct? What do others think?



2. delete on persistent compos

Looking at the specs, it is not clear to me how a delete would affect a 
persistent composition.

This is an open question.

This is also related with the previous case, since if a version is deleted on a 
persistent composition, there will be more commits for it after the delete, 
because it is persistent.



3. delete a non-trunk version

[creation v1] => [modification v2] => [amendment v3] => ...

Let's say there are many modifications/amendments for a compo, can be 
persistent or event.

What happens if a version in the middle of the version tree/line is deleted?

Can that even happen?

What happens with the created versions after that?

In my head those versions created on the branch of a deleted version should 
also be deleted if deletes are accepted in the middle of the tree. The other 
rule can be only accept deletes on the latest versions.


What do you think?


--
Ing. Pablo Pazos Guti?rrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter




--
Ing. Pablo Pazos Guti?rrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter

___
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: Is 'Choice' datatype available in Archetype editor an OpenEHR standard

[Pieter Bos]

It is explained in the ADL 2 spec here: 
http://openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_single_valued_attributes

And the ADL 1.4 spec here: 
http://openehr.org/releases/AM/latest/docs/ADL1.4/ADL1.4.html#_single_valued_attributes

Pieter


From: openEHR-technical  on behalf 
of Dileep V S 
Reply-To: For openEHR technical discussions 

Date: Friday, 22 September 2017 at 13:14
To: For openEHR technical discussions 
Subject: Is 'Choice' datatype available in Archetype editor an OpenEHR standard

Hi,
Archetype editor includes a datatype called "Choice'. This allows more than one 
data type(text & coded text for example) for the same node. Is this OpenEHR 
standard?

regards
[https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]

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: A little community coordination

[Pieter Bos]

Submitted our response - looking forward to the responses from others. There's 
no 'partially open source' option :)

Regards,

Pieter Bos

Op 21 mei 2017 om 12:16 heeft Koray Atalag 
<k.ata...@auckland.ac.nz<mailto:k.ata...@auckland.ac.nz>> het volgende 
geschreven:

Hi Pablo, great initiative!

I’ve filled my response…Looking forward to seeing results

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: Sunday, 21 May 2017 10:46 a.m.
To: For openEHR technical discussions
Subject: [FORGED] Re: A little community coordination

Hi all, this is the form: https://goo.gl/forms/oloBgwQlLU3NGrbr1
Here is my response https://ibb.co/nKqq8F (tried to attach it but exceeded the 
lists max size msg), that can help you as a guide. After we have some responses 
I'll share the responses with the community.

On Sat, May 20, 2017 at 2:57 PM, Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> wrote:
Hi all, this is the form: https://goo.gl/forms/oloBgwQlLU3NGrbr1
Attached find my response, that can help you as a guide. After we have some 
responses I'll share the responses with the community.


On Sat, May 20, 2017 at 10:51 AM, Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> wrote:

Yes, me too, good idea. Working on project, more details soon

Op za 20 mei 2017 10:04 schreef Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>:
Great suggestions, will add a comment on that to the form so people can specify 
that in free text (trying not to make it too structured).

On Sat, May 20, 2017 at 4:14 AM, Pieter Bos 
<pieter@nedap.com<mailto:pieter@nedap.com>> wrote:
Hello Pablo,

This sounds like a good initiative! Maybe it could be a good idea to add some 
way to distinguish ADL 1.4 and ADL/AOM 2 projects. Perhaps also the different 
RM versions?

Regards,

Pieter Bos

Op 19 mei 2017 om 18:30 heeft Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>>
 het volgende geschreven:

Hi all,

We were discussing on other threads about the need to improve the tools, ref 
impls and frameworks we use for openEHR stuff. We are few in the community 
working on those areas, and sometimes doing duplicated work and overlapping 
solutions.

I believe if we know who is working on what, we can make a better use of our 
collective time as a community, and reuse others work, or even help on their 
projects.

Modeling tools are getting behind the specs progress, tool chain is broken and 
needs manual work to get modeling done, open implementation tech stacks are not 
complete, etc...

What if we can publish the areas we are working on, tools that we already have, 
and try to coordinate better to fix those issues and collaborate better as a 
community?


I have created a small google form to gather and share that info, it has these 
questions:

1. On which areas are you / your company working on? (modeling tools, CDRs, 
APIs, ...)
2. Is code open or planned to be open?
3. Current status (idea, planned, developing, developed, released, ...)
4. Main issues and challenges (for the community to help)
5. Available tools / solutions and where to find them


If you see there is another question that can add value to this, please let me 
know. After this is complete, I'll share the form. When we have some answers, 
I'll publish them on the wiki.

Hopefully others can this this as an opportunity to move forward on the 
modeling and dev areas to increase openEHR adoption.


Kind regards,
Pablo.

--
Ing. Pablo Pazos Guti?rrez
Cel:(00598) 99 043 145<tel:%2800598%29%2099%20043%20145>
Skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 <http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com><mailto:pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

___
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

___
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


--
Ing. Pablo Pazos Gutiérrez


Cel:(00598) 99 043 145<tel:099%20043%20145>
Skype: cabolabs



[https://docs.google.com/uc?export=download=0B27lX-s

Re: A little community coordination

[Pieter Bos]

Hello Pablo,

This sounds like a good initiative! Maybe it could be a good idea to add some 
way to distinguish ADL 1.4 and ADL/AOM 2 projects. Perhaps also the different 
RM versions?

Regards,

Pieter Bos

Op 19 mei 2017 om 18:30 heeft Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> het volgende 
geschreven:

Hi all,

We were discussing on other threads about the need to improve the tools, ref 
impls and frameworks we use for openEHR stuff. We are few in the community 
working on those areas, and sometimes doing duplicated work and overlapping 
solutions.

I believe if we know who is working on what, we can make a better use of our 
collective time as a community, and reuse others work, or even help on their 
projects.

Modeling tools are getting behind the specs progress, tool chain is broken and 
needs manual work to get modeling done, open implementation tech stacks are not 
complete, etc...

What if we can publish the areas we are working on, tools that we already have, 
and try to coordinate better to fix those issues and collaborate better as a 
community?


I have created a small google form to gather and share that info, it has these 
questions:

1. On which areas are you / your company working on? (modeling tools, CDRs, 
APIs, ...)
2. Is code open or planned to be open?
3. Current status (idea, planned, developing, developed, released, ...)
4. Main issues and challenges (for the community to help)
5. Available tools / solutions and where to find them


If you see there is another question that can add value to this, please let me 
know. After this is complete, I'll share the form. When we have some answers, 
I'll publish them on the wiki.

Hopefully others can this this as an opportunity to move forward on the 
modeling and dev areas to increase openEHR adoption.


Kind regards,
Pablo.

--
Ing. Pablo Pazos Guti?rrez
Cel:(00598) 99 043 145
Skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 <http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

___
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: SNOMEDCT - correct representation

[Pieter Bos]

If anyone knows an editor that does ADL2 and supports enough options to make 
editing by hand no longer needed, we're interested.

Regards,

Pieter Bos

Op 16 mei 2017 om 18:23 heeft Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> het volgende 
geschreven:

it would be good to ask them why they do that, maybe is for limitations on the 
modeling tools, or maybe they are cyborgs in disguise.

On Tue, May 16, 2017 at 1:14 PM, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:


sure. But there are a lot that do, just not the ones you know ;) We have to 
make things work for everyone.

- thomas

On 16/05/2017 13:08, Bert Verhees wrote:
Most creators or users of archetypes I know, completely depend on tooling. They 
are never capable to read an ADL text, nor do they ever want to read it.

And as I suggested, with smart text-editors http-url encoding can be easily 
translated/showed into readable url's


On 16-05-17 16:06, Pablo Pazos wrote:
Not sure why readability is a requirement here. Shouldn't those expressions be 
generated and consumed by systems?

We should create simple to use GUIs not simple to read code :)

On Wed, May 3, 2017 at 9:31 AM, Diego Bosc? 
<yamp...@gmail.com<mailto:yamp...@gmail.com>> wrote:
Or just use the "Long syntax" as described in point 5.2 from Expression 
Constraint Language, which keeps things readable enough
http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus|

2017-05-03 14:20 GMT+02:00 Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>>:


___
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



--
Ing. Pablo Pazos Guti?rrez
Cel:(00598) 99 043 145
Skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 <http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

___
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

[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: Hand coding templates in ADL 1.4

[Pieter Bos]

The editing tools for adl 2 are still limited. However the template editing by 
hand is easier in adl 2 than the earlier template xml formats because it's the 
same adl with a few extra language constructs for templates.

And you can convert the ckm to adl 2 quite easily.

Pieter Bos


Op 12 feb. 2017 om 12:04 heeft Diego Bosc? 
<yamp...@gmail.com<mailto:yamp...@gmail.com>> het volgende geschreven:

Hello Dileep,

If you stick with ADL 1.4 then you could use LinkEHR Studio 
(http://linkehr.com) to create templates from other RM such as demographic 
model. The same tool can be used to import OET and export OPT for any given RM.

Regards

El 12/2/2017 9:44, "Dileep V S" 
<dil...@healthelife.in<mailto:dil...@healthelife.in>> escribi?:
Hi,

We are exploring OpenEHR as part of a public health management pilot project in 
India and have some questions that I am unable to find proper answers.

After studying the available libraries, tools and opensource server 
implementations, ADL 1.4 seems to be more widely supported than the newer ADL 
2.0. The shared archetype repository (CKM) still contains only 1.4 version 
archetypes. In light of this, I am assuming that for anybody planning to adopt 
OpenEHR, it will be advisable to stick to ADL1.4 for now.

Further I have learned the following wrt. ADL 1.4 standards

File formats for 1.4 version

  *   Archetypes  - ADL 1.4
  *   Templates - OET
  *   Operational template - OPT 1.4

Modelling tools - Archetype editor, template designer

I am stuck with trying to answer the following questions. It would be great if 
somebody can help.

  1.  Can we hand create templates that are not supported by the template 
designer? For example demographics?
  2.  If yes how do we convert the hand coded OETs to OPTs?
  3.  Where do we get more details on OET file syntax?

Thanks

Dileep
HealtheLife Ventures LLP
bamgalore


___
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<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: Could the specs group consider making uid mandatory?

[Pieter Bos]

That sounds reasonable. I wonder how many existing systems already do this…

Regards,

Pieter Bos
Nedap Healthcare

On 13/12/16 14:24, "openEHR-technical on behalf of Ian McNicoll" 
<openehr-technical-boun...@lists.openehr.org on behalf of i...@freshehr.com> 
wrote:

There may be some advantages in routine application of uid at ENTRY level.

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


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

Re: Could the specs group consider making uid mandatory?

[Pieter Bos]

Generally the top-level structures will have a UID, and the other nodes can be 
reached with a path from there. So a UID plus path combination should make all 
features possible. It’s already recommended to set the uid on those top-level 
structures.

Setting an uid on all locatables is quite a lot of overhead.

What are you trying to do that cannot be solved with a top-level UID plus a 
path?

Regards,

Pieter Bos
Nedap Healthcare

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Seref Arikan <serefari...@kurumsalteknoloji.com>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org>
Date: Tuesday 13 December 2016 at 12:18
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Could the specs group consider making uid mandatory?

Greetings,

Apologies if I missed a discussion about this, but as per 
http://www.openehr.org/releases/RM/latest/docs/common/common.html#_unique_node_identification

"LOCATABLE descendants may have a uid, containing a GUID"


The optional/recommended nature of uid makes it impossible to implement some  
features that I have in mind because I can't rely on all implementations to 
follow the same approach.

However I realise that making it mandatory could introduce compatibility issues 
with existing data so it is not simply making a decision and putting it into 
specs.

Has this been discussed anywhere?

All the best
Seref

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

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

[Pieter Bos]

I fully agree that they should be mandatory. Things like this make writing 
software based on OpenEHR more complex than it could be.

I also never understood that the DV_-types do not have an archetype node id in 
the reference model. This adds complexity, because the paths in an archetype do 
not always match the paths in a reference model object. Sometimes you just need 
paths based on an archetype that need to work in reference model objects. For 
example when displaying information, rendering forms, evaluating rules or score 
calculations, or rendering a UI to edit stored reference model objects. Of 
course, you can write something that converts these paths from the AOM to the 
RM, but I don’t see why that should be necessary.

Perhaps someone can explain the reasoning behind these choices?

Regards,

Pieter Bos
Nedap Healthcare


From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of pablo pazos <pazospa...@hotmail.com>
Reply-To: openeh technical <openehr-technical@lists.openehr.org>
Date: Monday 31 October 2016 at 17:08
To: openehr clinical <openehr-clini...@lists.openehr.org>, openeh technical 
<openehr-technical@lists.openehr.org>
Subject: Question about paths to C_SINGLE_ATTRIBUTE alternatives


Hi,



I was chatting with Diego, about the need of nodeIds for ELEMENT.value and I 
detected some archetypes with alternatives but no nodeIds, I guess, created 
with the Archetype Editor.



Examples from openEHR-EHR-CLUSTER.timing_daily.v0



...
ELEMENT[at0004] occurrences matches {0..*} matches {-- Specific 
time
value matches {
DV_TIME matches {*}
DV_INTERVAL matches {
upper matches {
DV_TIME matches {*}
}
lower matches {
DV_TIME matches {*}
}
}
}
}
ELEMENT[at0026] occurrences matches {0..*} matches {-- Named 
time event
value matches {
DV_TEXT matches {*}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0031, -- immediately (stat)
at0032, -- in the morning
at0033, -- at night
at0034]-- in the morning and at night
}
}
}
}

...





How can software create paths to the specific ELEMENT.value constraint if the 
constraints don't have a nodeId?





This remembers me of an old discussion about if the nodeIds should or not be 
mandatory. Opinions?




--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR draft Expression spec

[Pieter Bos]

 node set, because there is no matching attribute called 
archetype_node_id. Instead, you could just write /context, which works.

So, there are several options to address this in the specification, for example:

  1.  Specify that paths to non-locatables should NOT have a [idx] predicate, 
even though the id in the archetype is present
  2.  Specify that paths to non-locatables can have a [idx] predicate, but it 
should be ignored in implementations

Option 2 is a harder to implement, because you can no longer convert from Apath 
to Xpath without knowledge of the model. But as Apath expressions are not new, 
I’m thinking some other people will have an opinion on this :)

Regards,

Pieter Bos








From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>>
Reply-To: 
"openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>"
 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Date: Thursday 19 May 2016 at 14:38
To: 
"openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>"
 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Subject: openEHR draft Expression spec


Pieter,

With respect to the 'rules' bit of ADL, and also GDL, there is a new draft 
'Expressions' spec in the BASE 
component<http://www.openehr.org/releases/BASE/latest/docs/index>. This is a 
working draft, and partly lifted from ADL/AOMs specs (those now just include 
this one), plus some extensions to show how rule extensions are done properly.

This spec proposes an improved syntax, but it's definitely not finished (e.g. I 
am thinking of getting rid of the $var style syntax), and it would be great to 
have some other collaborators on it who have a lot of experience with 
expressions / rules systems. So please have a look and feel free to comment - 
comments here probably make sense since others may be interested.

The draft of this spec will be released soon in a new release of the BASE 
component. All that means is that changes from then need to be documented by 
PRs and CRs in the normal fashion.

- thomas

On 19/05/2016 13:01, Pieter Bos wrote:

It certainly does validate specs. In fact, it already has caused some 
corrections to both the specs and the ANTLR-grammar.

And we already found a few more issues in the specs. I’ll soon file an issue 
report about the rules section, to specify how to handle operators on 
multiple-valued path expressions without a for_all :)

Pieter

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org><mailto:openehr-technical-boun...@lists.openehr.org><mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Sebastian Garde 
<sebastian.ga...@oceaninformatics.com<mailto:sebastian.ga...@oceaninformatics.com><mailto:sebastian.ga...@oceaninformatics.com><mailto:sebastian.ga...@oceaninformatics.com>>
Reply-To: 
"openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org>"
 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org>>
Date: Wednesday 18 May 2016 at 18:31
To: 
"openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org>"
 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr.org>>
Subject: AW: Archie version 0.1.0 released



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

Re: AW: Archie version 0.1.0 released

[Pieter Bos]

It certainly does validate specs. In fact, it already has caused some 
corrections to both the specs and the ANTLR-grammar.

And we already found a few more issues in the specs. I’ll soon file an issue 
report about the rules section, to specify how to handle operators on 
multiple-valued path expressions without a for_all :)

Pieter

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Sebastian Garde 
<sebastian.ga...@oceaninformatics.com<mailto:sebastian.ga...@oceaninformatics.com>>
Reply-To: 
"openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>"
 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Date: Wednesday 18 May 2016 at 18:31
To: 
"openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>"
 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Subject: AW: Archie version 0.1.0 released

My congratulations too, Pieter!

To add to Thomas, a perfectly redundant wheel-reinvention based on the specs 
also validates the specs nicely and highlights potential 
problems/inaccuracies/underspecified things in the underlying specs as we have 
seen previously with the various 1.4 implementations.
(Yes, even with the nearly perfect openEHR specs ;-) )

Sebastian

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Thomas Beale
Gesendet: Mittwoch, 18. Mai 2016 17:24
An: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Betreff: Re: Archie version 0.1.0 released


I'm sure something can be worked out. Not my call personally of course.

But just a thought for everyone who instantly thinks 'oh no, not another wheel 
re-invention'... the work described here probably is slightly re-inventing 
something, but as Pieter has said, there are overlaps and also unique elements 
to each library.
Anyway, my thought is this: even a perfectly redundant wheel-reinvention 
exercise does achieve one very useful thing: it creates a new dev team that 
understands the specification and model intimately, and knows how to code with 
it - in other words we are growing the developer community. This is very 
valuable.

- thomas
On 18/05/2016 10:49, Pieter Bos wrote:

Hello Diego,



That is possibly, but has some complications:



To make a dual licensing approach work in this case it would requires us to 
release Archie under the AGPL, combine it with adl2-core and get a license from 
Marand to use their contributions to the resulting library in our products 
combined with a license from us to them to use our contributions in their 
products. Also all future contributors will have to sign a document allowing to 
use their contribution to be released under a different license by Marand and 
Nedap.



That would leave the resulting combined library still unusable for other 
non-GPL projects by others.



I would prefer another way forward :)



Regards,



Pieter Bos







On 18/05/16 11:10, "openEHR-technical on behalf of Diego Boscá" 
<openehr-technical-boun...@lists.openehr.org on behalf of 
yamp...@gmail.com><mailto:openehr-technical-bounces@lists.openehr.orgonbehalfofyamp...@gmail.com>
 wrote:



Nice wok Piter!



I've seen quite a lot of open source projects with dual licensing.

Maybe this is the way to go so we can please everyone



Regards



2016-05-18 11:06 GMT+02:00 Pieter Bos 
<pieter@nedap.com><mailto:pieter@nedap.com>:

Hi Ian,



Good to hear this work is being appreciated.



It could certainly be possible to merge Archie with the existing adl2-core 
library. I think the adl2-core library looks like it has good quality code and 
decent API. It could be interesting because although there is quite a bit of 
overlap in functionality, Archie has functionality that adl2-core does not 
have, and adl2-core has functionality Archie does not yet have. If the owners 
of that library are willing to relicense their code or at least parts of their 
code under a different license, it could be interesting. We’re open to 
releasing this code under a different license, but only if the resulting work 
can be used in non-GPL software.



Regards,



Pieter Bos

Nedap Healthcare



From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org><mailto:openehr-technical-boun...@lists.openehr.org><mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Ian McNicoll 
<i...@freshehr.com<mailto:i...@freshehr.com><mailto:i...@freshehr.com><mailto:i...@freshehr.com>>

Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org><mailto:openehr-technical@lists.openehr

Re: Archie version 0.1.0 released

[Pieter Bos]

Hello Diego,

That is possibly, but has some complications:

To make a dual licensing approach work in this case it would requires us to 
release Archie under the AGPL, combine it with adl2-core and get a license from 
Marand to use their contributions to the resulting library in our products 
combined with a license from us to them to use our contributions in their 
products. Also all future contributors will have to sign a document allowing to 
use their contribution to be released under a different license by Marand and 
Nedap.

That would leave the resulting combined library still unusable for other 
non-GPL projects by others.

I would prefer another way forward :)

Regards,

Pieter Bos



On 18/05/16 11:10, "openEHR-technical on behalf of Diego Boscá" 
<openehr-technical-boun...@lists.openehr.org on behalf of yamp...@gmail.com> 
wrote:

>Nice wok Piter!
>
>I've seen quite a lot of open source projects with dual licensing.
>Maybe this is the way to go so we can please everyone
>
>Regards
>
>2016-05-18 11:06 GMT+02:00 Pieter Bos <pieter@nedap.com>:
>> Hi Ian,
>>
>> Good to hear this work is being appreciated.
>>
>> It could certainly be possible to merge Archie with the existing adl2-core 
>> library. I think the adl2-core library looks like it has good quality code 
>> and decent API. It could be interesting because although there is quite a 
>> bit of overlap in functionality, Archie has functionality that adl2-core 
>> does not have, and adl2-core has functionality Archie does not yet have. If 
>> the owners of that library are willing to relicense their code or at least 
>> parts of their code under a different license, it could be interesting. 
>> We’re open to releasing this code under a different license, but only if the 
>> resulting work can be used in non-GPL software.
>>
>> Regards,
>>
>> Pieter Bos
>> Nedap Healthcare
>>
>> From: openEHR-technical 
>> <openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
>>  on behalf of Ian McNicoll <i...@freshehr.com<mailto:i...@freshehr.com>>
>> Reply-To: For openEHR technical discussions 
>> <openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
>> Date: Wednesday 18 May 2016 at 10:42
>> To: For openEHR technical discussions 
>> <openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
>> Cc: 
>> "openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>"
>>  
>> <openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>>
>> Subject: Re: Archie version 0.1.0 released
>>
>> Hi Pieter,
>>
>> This looks a really interesting and valuable piece of work. Many thanks for 
>> your efforts - hopefully others will want to contribute. It would be nice if 
>> we could somehow bring this work and the existing AOM2/ADL2 work together 
>> (or at least not duplicate work). I appreciate there is a different 
>> licensing approach but I don't think that is necessarily set in stone.
>>
>> 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?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
>> 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 17 May 2016 at 12:53, Pieter Bos 
>> <pieter@nedap.com<mailto:pieter@nedap.com>> wrote:
>> A few months ago I announced the development of an open source Java openEHR 
>> library called Archie. It has progressed enough that I’m now pleased to 
>> announced the release of version 0.1.0 of Archie. It supports the latest ADL 
>> 2 and reference model versions and is licensed under the Apache license.
>>
>> The documentation and source can be found at 
>> https://github.com/nedap/archie. It’s available at Maven Central at 
>> com.nedap.healthcare:archie:0.1.0 .
>>
>> Why another library?
>>
>> The existing open source openEHR libraries were either ADL 1.4 or published 
>> under the Affero GPL. This means there is no library available for non-GPL 
>> ADL 2 openEHR projects. We are building a non-GPL openEHR implementation, so 
>> we needed a library and wrote it. We 

Re: Archie version 0.1.0 released

[Pieter Bos]

Hi Ian,

Good to hear this work is being appreciated.

It could certainly be possible to merge Archie with the existing adl2-core 
library. I think the adl2-core library looks like it has good quality code and 
decent API. It could be interesting because although there is quite a bit of 
overlap in functionality, Archie has functionality that adl2-core does not 
have, and adl2-core has functionality Archie does not yet have. If the owners 
of that library are willing to relicense their code or at least parts of their 
code under a different license, it could be interesting. We’re open to 
releasing this code under a different license, but only if the resulting work 
can be used in non-GPL software.

Regards,

Pieter Bos
Nedap Healthcare

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Ian McNicoll <i...@freshehr.com<mailto:i...@freshehr.com>>
Reply-To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Date: Wednesday 18 May 2016 at 10:42
To: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Cc: 
"openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>"
 
<openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>>
Subject: Re: Archie version 0.1.0 released

Hi Pieter,

This looks a really interesting and valuable piece of work. Many thanks for 
your efforts - hopefully others will want to contribute. It would be nice if we 
could somehow bring this work and the existing AOM2/ADL2 work together (or at 
least not duplicate work). I appreciate there is a different licensing approach 
but I don't think that is necessarily set in stone.

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?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
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 17 May 2016 at 12:53, Pieter Bos 
<pieter@nedap.com<mailto:pieter@nedap.com>> wrote:
A few months ago I announced the development of an open source Java openEHR 
library called Archie. It has progressed enough that I’m now pleased to 
announced the release of version 0.1.0 of Archie. It supports the latest ADL 2 
and reference model versions and is licensed under the Apache license.

The documentation and source can be found at https://github.com/nedap/archie. 
It’s available at Maven Central at com.nedap.healthcare:archie:0.1.0 .

Why another library?

The existing open source openEHR libraries were either ADL 1.4 or published 
under the Affero GPL. This means there is no library available for non-GPL ADL 
2 openEHR projects. We are building a non-GPL openEHR implementation, so we 
needed a library and wrote it. We believe the openEHR community benefits from 
having up to date open source tools, so we decided to release Archie.

Features:

  *   ADL parser, including a generic ODIN to Java objects mapper
  *   Archetype Object Model
  *   The EHR part of the Reference Model
  *   Basic APath-queries on AOM and RM objects
  *   Flattener
  *   Operational template creation
  *   Easy to use APIs for object creation, terminology lookup, archetype model 
tree walking and constraint checking
  *   RM serializes to XML in accordance with the openEHR-published XSD, or to 
JSON using jackson
  *   AOM serialization to JSON for easy use in JavaScript based 
web-applications.
  *   Tools for reference model object creation and attribute setting based on 
archetype constraints
  *   Pluggable reference model architecture: the reference model can be 
swapped for some other implementation and the tools keep working

Experimental features:

These features are included, but the API and implementation of these features 
will probably change in the coming versions:

  *   Rules evaluation (with some minor syntax changes for now, see the project 
readme)
  *   Full APath and XPath expression evaluation on reference model objects 
using the JAXP–implementation of your choice

Future releases and contributions

We’re continuing the development, so there will be more releases in the near 
future. If you want to contribute: pull requests and issue reports are very 
welcome!

Regards,

Pieter Bos
Nedap Healthcare


___
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

_

Archie version 0.1.0 released

[Pieter Bos]

A few months ago I announced the development of an open source Java openEHR 
library called Archie. It has progressed enough that I’m now pleased to 
announced the release of version 0.1.0 of Archie. It supports the latest ADL 2 
and reference model versions and is licensed under the Apache license.

The documentation and source can be found at https://github.com/nedap/archie. 
It’s available at Maven Central at com.nedap.healthcare:archie:0.1.0 .

Why another library?

The existing open source openEHR libraries were either ADL 1.4 or published 
under the Affero GPL. This means there is no library available for non-GPL ADL 
2 openEHR projects. We are building a non-GPL openEHR implementation, so we 
needed a library and wrote it. We believe the openEHR community benefits from 
having up to date open source tools, so we decided to release Archie.

Features:

  *   ADL parser, including a generic ODIN to Java objects mapper
  *   Archetype Object Model
  *   The EHR part of the Reference Model
  *   Basic APath-queries on AOM and RM objects
  *   Flattener
  *   Operational template creation
  *   Easy to use APIs for object creation, terminology lookup, archetype model 
tree walking and constraint checking
  *   RM serializes to XML in accordance with the openEHR-published XSD, or to 
JSON using jackson
  *   AOM serialization to JSON for easy use in JavaScript based 
web-applications.
  *   Tools for reference model object creation and attribute setting based on 
archetype constraints
  *   Pluggable reference model architecture: the reference model can be 
swapped for some other implementation and the tools keep working

Experimental features:

These features are included, but the API and implementation of these features 
will probably change in the coming versions:

  *   Rules evaluation (with some minor syntax changes for now, see the project 
readme)
  *   Full APath and XPath expression evaluation on reference model objects 
using the JAXP–implementation of your choice

Future releases and contributions

We’re continuing the development, so there will be more releases in the near 
future. If you want to contribute: pull requests and issue reports are very 
welcome!

Regards,

Pieter Bos
Nedap Healthcare


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