Re: Archie version 0.6.0 released

[Seref Arikan]

Thank you. Please see inline

On Tue, Feb 12, 2019 at 7:02 PM Pieter Bos  wrote:

> I mean OPT2, which is according to the ooenehr specifications a flattened
> archetype with extra operations performed on it, such as including and
> flattening all archetype roots in the same tree, including their
> terminologies,and replacing all use_node with a copy of the tree to be
> used. Very useful. Can be expressed in ADL.
>
I did not realise that opt2 was fully defined. I thought it was ongoing
work. I'll have to go and check it now :)

>
> Archie does not support the 1.4 xml OPT format.
>
Thanks for the clarification.

>
> Note that xml bindings are in place for the AOM, but I wouldn't use them
> for interoperability because they were written before an official xsd has
> been published - I'm actually not sure if an official AOM 2 xsd currently
> exists.
>
Could you please clarify which official XSD you're referring to? AOM2?

>
> Note that there is also the concept of a template, which is also an
> archetype, but is different from an operational template - templates are
> authored, opts are generated, often generated from a template.
>
Hmm. I guess this means opts lose some information regarding their lineage.

>
> Regards,
>

thanks a lot for the detailed response.

All the best
Seref


> Pieter Bos
>
> Op 12 feb. 2019 19:12 schreef Seref Arikan <
> serefari...@kurumsalteknoloji.com>:
>
> Hi Pieter,
>
> Excellent work, many thanks for all the effort your team put into this
> library. Could you clarify something? When you say an operational template,
> do you mean a flattened archetype as per ADL 2.0? (that's the impression I
> got looking at the code)
>
> I'm a bit behind re adl 2.0; does your implementation imply that an opt
> according to 2.0 specs is no different than an archetype? I can see that
> you declared some xml bindings in your OperationalTemplate class which seam
> to refer to type names from opt 1.4 .
>
> In summary I'm a bit confused :) Could you briefly explain how Archie team
> sees the relationship between opt 1.4 and 2.0 ?
>
> All the best
> Seref
>
>
> On Tue, Feb 12, 2019 at 1:04 PM Pieter Bos  wrote:
>
> Today I’m pleased to announce another major release of the Archie library.
> This release brings a number of new features and improvements:
>
>
>
>- A tool that constructs valid json example instances of RM Objects,
>based on an operational template. Can be parsed to RM Objects.
>- Native ODIN serialization of arbitrary java objects using the
>Jackson library, now used in Archetype and P_BMM serialization
>- The library is now supported on Android, Android 8.0/API level 26
>and higher, including faster initialization time
>- The RM implementation has been verified against the 1.0.4 BMM
>models, and fixed where needed
>- A complete rewrite of the P_BMM implementation, with improved
>validation. The new implementation is much easier to understand and 
> maintain
>
>
>
> Because of the last two features, this version may require some changes to
> your existing code. For more information, see
> https://github.com/openEHR/archie/releases/tag/0.6.0 and the readme.
>
>
>
> Regards,
>
>
>
> Pieter Bos
>
> Nedap Healthcare
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Archie version 0.6.0 released

[Seref Arikan]

Hi Pieter,

Excellent work, many thanks for all the effort your team put into this
library. Could you clarify something? When you say an operational template,
do you mean a flattened archetype as per ADL 2.0? (that's the impression I
got looking at the code)

I'm a bit behind re adl 2.0; does your implementation imply that an opt
according to 2.0 specs is no different than an archetype? I can see that
you declared some xml bindings in your OperationalTemplate class which seam
to refer to type names from opt 1.4 .

In summary I'm a bit confused :) Could you briefly explain how Archie team
sees the relationship between opt 1.4 and 2.0 ?

All the best
Seref


On Tue, Feb 12, 2019 at 1:04 PM Pieter Bos  wrote:

> Today I’m pleased to announce another major release of the Archie library.
> This release brings a number of new features and improvements:
>
>
>
>- A tool that constructs valid json example instances of RM Objects,
>based on an operational template. Can be parsed to RM Objects.
>- Native ODIN serialization of arbitrary java objects using the
>Jackson library, now used in Archetype and P_BMM serialization
>- The library is now supported on Android, Android 8.0/API level 26
>and higher, including faster initialization time
>- The RM implementation has been verified against the 1.0.4 BMM
>models, and fixed where needed
>- A complete rewrite of the P_BMM implementation, with improved
>validation. The new implementation is much easier to understand and 
> maintain
>
>
>
> Because of the last two features, this version may require some changes to
> your existing code. For more information, see
> https://github.com/openEHR/archie/releases/tag/0.6.0 and the readme.
>
>
>
> Regards,
>
>
>
> Pieter Bos
>
> Nedap Healthcare
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Seref Arikan]

You are way more technical than just a consumer of AQL, so you may consider
adopting semantics from XQuery/XPath/Sparql. It would not really leave you
a million miles from the current AQL semantics. I'll leave it at that since
this is not a technical list as far as I my understanding goes. Feel free
to re-initiate discussion under technical list if you have comments (goes
for everyone) :)

All the best
Seref


On Wed, Oct 10, 2018 at 8:24 PM Pablo Pazos 
wrote:

>
>
> On Wed, Oct 10, 2018, 07:10 David Moner  wrote:
>
>>
>>
>> El mié., 10 oct. 2018 a las 11:52, Seref Arikan (<
>> serefari...@kurumsalteknoloji.com>) escribió:
>>
>>>
>>> Obligatory moaning for the millionth time: All of this confusion stems
>>> from lack of a formal model defining AQL semantics. I used tree pattern
>>> queries in my research so I can use those to explain aql, but as it stands
>>> the standard we have does not have this so users will keep getting
>>> confused.
>>>
>>>>
>>>>
>> This. A query language is more than just a syntax. And probably we don't
>> need to invent different behaviors than technologies that already work
>> (XPath/XQuery, for example)
>>
>
> That is exactly why I didn't implement AQL yet, the spec should include
> syntax, behavior, semantics and result sets defined. And lots of examples
> of those things combined. Because impregnada should include parser+engine
> and the parser is the simple part. Until we have that all implementations
> will have differences when querying the same database.
>
>
>> --
>> David Moner Cano
>>
>> Web: http://www.linkedin.com/in/davidmoner
>> Twitter: @davidmoner
>> Skype: davidmoner
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Seref Arikan]

You'll be hearing from me kind sir :)

On Wed, Oct 10, 2018 at 3:38 PM Thomas Beale 
wrote:

>
>
> On 10/10/2018 06:52, Seref Arikan wrote:
>
>
> Obligatory moaning for the millionth time: All of this confusion stems
> from lack of a formal model defining AQL semantics. I used tree pattern
> queries in my research so I can use those to explain aql, but as it stands
> the standard we have does not have this so users will keep getting
> confused.
>
>
> we are open to upgrading the AQL spec at any time ;)
>
> - thomas
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Seref Arikan]

Comments inline

On Tue, Oct 9, 2018 at 11:05 PM Pablo Pazos 
wrote:

> Hi Seref, see below :)
>
> On Tue, Oct 9, 2018 at 5:19 AM Seref Arikan <
> serefari...@kurumsalteknoloji.com> wrote:
>
>> Hi Pablo, see inline please
>>
>> On Mon, Oct 8, 2018 at 8:29 PM Pablo Pazos 
>> wrote:
>>
>>> Recently we discussed other problematic cases, like having criteria over
>>> a structured datatype like:
>>>
>>> WHERE /data[at0001]/items[at0004]/value/magnitude >= 140 AND 
>>> /data[at0001]/items[at0004]/value/units
>>> = "mmHg"
>>>
>>> Internally that should be interpreted as "magnitude" and "units" should
>>> be attributes of the same DV_QUANTITY instance, but do all AQL
>>> implementations actually do that?
>>>
>>
>> Who knows? :) the syntax is correct though, so what they do internally
>> does not matter, the WHERE clause is clearly introducing two constraints on
>> the same DV_QUANTITY instance.
>>
>
> That should be defined by the spec to avoid inconsistent implementations.
>
Sorry, I misunderstood what you wrote earlier. My response 'who knows?' is
not valid. The semantics is clear, mag and units are attributes of the same
instance. it is the aql semantics.

>
> On the other hand, paths might not reference the same data instance,
> consider multiple occurrences of the ELEMENT in 
> /data[at0001]/items[at0004],
> the only way to be sure that references the same data instance is by doing
> something like /data[at0001]/items[at0004][0]/value/... or 
> /data[at0001]/items[at0004][1]/value/...
> without the index, paths references a list of objects.
>

Very short answer: No. similar to attributes being attributes of same
DV_QUANTITY instance, paths are relative paths from a single 'match', i.e.
an actual object that fits the criteria defined by the FROM clause . There
may be multiple matches but the where clause would not apply criteria 1 to
match one and criteria 2 to match two. You can see the same semantics used
by XQuery and Sparql as well.

Obligatory moaning for the millionth time: All of this confusion stems from
lack of a formal model defining AQL semantics. I used tree pattern queries
in my research so I can use those to explain aql, but as it stands the
standard we have does not have this so users will keep getting confused.

>
>
>
>>
>>
>>>
>>>
>>> But maybe that kind of query should be written as:
>>>
>>> WHERE dv/magnitude >= 140 AND dv/units = "mmHg"
>>>
>>> In that case, dv should be defined in the FROM, and all
>>> variables/aliases should point to the same data instance.
>>>
>>
>> this is also valid AQL but you may have two problems here:
>>
>> 1) AQL implementations may not support the full AQL semantics. That is,
>> even though EHR e[..] CONTAINS DV_QUANTITY dv is legal AQL a particular
>> back end may not support it.
>>
>
> I was thinking about EHR CONTAINS OBSERVATION CONTAINS  CONTAINS
> DV_QUANTITY dv, not directly referencing a DV from the EHR, but as you
> said, it is valid.
>
> The CONTAINS also has to handle the multiple occurrences of contained
> items on attributes that are collections.
>
>
>> In your example snippet, the FROM statement (which we don't see) should
>> have an . Now to use the dv alias as you've suggested, that FROM
>> claused would have to become: /data[at0001]/items[at0004]/value as dv
>> and this is the case a back end may not support, or all back ends may not
>> support because a common thinking among vendors is users would select more
>> meaningful/high-level nodes (mostly entries or clusters under them) and
>> access data via SELECT or apply criteria in WHERE clauses using relative
>> paths.
>>
>> 2) if you'd like to apply two criteria to , then you have to declare
>>  in FROM clause and do WHERE xxx/path1/value  AND
>> xxx/path2/value  So you have to define  here, if you do what
>> I described above, you only have DV_QUANTITY leaf node and you cannot
>> introduce constraints to other nodes relative to . So you have pros and
>> cons or 'high level nodes giveth and taketh away'...
>>
>> Another option, which should actually be legal given the current AQL
>> grammar may be to move all constraints on xxx to the immediate predicate of
>>  but this should be used only when there is no ambiguity. As in:
>>
>> FROM . CONTAINS [data/items/value/magnitude >= 140 AND
>> data/items/value/units = 'mmHg']
>&

Re: query writing question 2

[Seref Arikan]

Hi Tom,

I remember reading this somewhere. Can you remember if the current antlr
grammar supports that embedded adl syntax?

Cheers
Seref


On Tue, Oct 9, 2018 at 3:22 PM Thomas Beale 
wrote:

> The correct way to do this IMO, and my earliest idea for AQL in about 2006
> was using archetype fragments, which are a kind of Frame-logic approach,
> formally. Today, people think in terms of GraphQL, but you need constraints.
>
> E.g.
>
> WHERE
> dv matches {
> magnitude matches {|>=140.0|}
>units matches {"mm[Hg]"}
> }
>
> Or, more readably:
>
> WHERE
> dv ∈ {
> magnitude ∈ {|>=140.0|}
>units ∈ {"mm[Hg]"}
> }
>
> - thomas
>
> On 08/10/2018 16:27, Pablo Pazos wrote:
>
>
>
> But maybe that kind of query should be written as:
>
> WHERE dv/magnitude >= 140 AND dv/units = "mmHg"
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Project, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
>  | The Objective Stance
> 
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2 (Seref Arikan)

[Seref Arikan]

Simply put, the semantics of AQL. that 'a' means the same node in SELECT
and WHERE clauses. Now, there may be > 1 node at a relative path
(a/.../node) but even then, the semantics of AQL requires that the SELECT
and WHERE clauses apply to the exact same data node. Where there is > 1,
you'll see the result set contain a row for each, but SELECT and WHERE will
always apply to the same node. it is the implementer's responsibility to
ensure that this semantics holds.

On Tue, Oct 9, 2018 at 9:45 AM Georg Fette 
wrote:

> Oh, sorry. I have indeed used the wrong alias in the example. I intended
> to write
>
> SELECT a/data[at0001]/items[at0004]/value
> FROM EHR e CONTAINS COMPOSITION a[openEHR-EHR-COMPOSITION.encounter.v1]
> WHERE a/data[at0001]/items[at0004]/value/value >= 140
>
> What ensures that the identified path in the SELECT section references
> the same data instances that are contrained with the same identified
> path in the WHERE section ?
>
> 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-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Seref Arikan]

Hi Pablo, see inline please

On Mon, Oct 8, 2018 at 8:29 PM Pablo Pazos  wrote:

> Recently we discussed other problematic cases, like having criteria over a
> structured datatype like:
>
> WHERE /data[at0001]/items[at0004]/value/magnitude >= 140 AND
> /data[at0001]/items[at0004]/value/units = "mmHg"
>
> Internally that should be interpreted as "magnitude" and "units" should be
> attributes of the same DV_QUANTITY instance, but do all AQL implementations
> actually do that?
>

Who knows? :) the syntax is correct though, so what they do internally does
not matter, the WHERE clause is clearly introducing two constraints on the
same DV_QUANTITY instance.


>
>
> But maybe that kind of query should be written as:
>
> WHERE dv/magnitude >= 140 AND dv/units = "mmHg"
>
> In that case, dv should be defined in the FROM, and all variables/aliases
> should point to the same data instance.
>

this is also valid AQL but you may have two problems here:

1) AQL implementations may not support the full AQL semantics. That is,
even though EHR e[..] CONTAINS DV_QUANTITY dv is legal AQL a particular
back end may not support it. In your example snippet, the FROM statement
(which we don't see) should have an . Now to use the dv alias as you've
suggested, that FROM claused would have to become:
/data[at0001]/items[at0004]/value as dv and this is the case a back end
may not support, or all back ends may not support because a common thinking
among vendors is users would select more meaningful/high-level nodes
(mostly entries or clusters under them) and access data via SELECT or apply
criteria in WHERE clauses using relative paths.

2) if you'd like to apply two criteria to , then you have to declare
 in FROM clause and do WHERE xxx/path1/value  AND
xxx/path2/value  So you have to define  here, if you do what
I described above, you only have DV_QUANTITY leaf node and you cannot
introduce constraints to other nodes relative to . So you have pros and
cons or 'high level nodes giveth and taketh away'...

Another option, which should actually be legal given the current AQL
grammar may be to move all constraints on xxx to the immediate predicate of
 but this should be used only when there is no ambiguity. As in:

FROM . CONTAINS [data/items/value/magnitude >= 140 AND
data/items/value/units = 'mmHg']

This would neatly move the joint criteria up but I would be uncomfortable
with this because you cannot specify archetype node ids for data[]/items[]
anymore and this would likely trigger a cartesian explosion in result sets.
Then you'd have Ian complaining about duplicate results ;)

All the best
Seref


> On Mon, Oct 8, 2018 at 3:06 PM Georg Fette 
> wrote:
>
>> Hello,
>> I have another question concerning the semantics of AQL queries:
>> In the documentation there are queries of the form
>> SELECT a/data[at0001]/items[at0004]/value
>> FROM EHR e CONTAINS COMPOSITION a[openEHR-EHR-COMPOSITION.encounter.v1]
>> WHERE b/data[at0001]/items[at0004]/value/value >= 140
>> What ensures that the identified path in the SELECT section references
>> the same data instances that are contrained with the same identified
>> path in the WHERE section ? It could be argued that there is only one
>> "data[at0001]" in "b" and only one "items[at0004]" in "a/data[at0001]"
>> and so on. But is this already the full explanation for the expression
>> to be unambiguous ? The aliases used in queries (e.g. "a") ensures that
>> a reference to an alias definitely means the same instance. Looking at
>> queries like the one above let assume that aliases are only syntactic
>> sugar and are not functionally needed. Is this correct ?
>> Greetings
>> Georg
>>
>> --
>> -
>> Dipl.-Inf. Georg Fette  Raum: B001
>> Universität WürzburgTel.: +49-(0)931-31-85516
>> Am Hubland  Fax.: +49-(0)931-31-86732
>> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
>> -
>>
>>
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter 
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Seref Arikan]

That query does not look valid to me. There is no 'b' that is defined in
the FROM clause. Once an alias for a node is created in the FROM clause, as
in COMPOSITION a[..] the alias 'a' in the FROM and WHERE clauses refers to
the same matching data node.

I would not assume anything based on the query you've given because that
query is invalid as far as I can see.

On Mon, Oct 8, 2018 at 7:06 PM Georg Fette 
wrote:

> Hello,
> I have another question concerning the semantics of AQL queries:
> In the documentation there are queries of the form
> SELECT a/data[at0001]/items[at0004]/value
> FROM EHR e CONTAINS COMPOSITION a[openEHR-EHR-COMPOSITION.encounter.v1]
> WHERE b/data[at0001]/items[at0004]/value/value >= 140
> What ensures that the identified path in the SELECT section references
> the same data instances that are contrained with the same identified
> path in the WHERE section ? It could be argued that there is only one
> "data[at0001]" in "b" and only one "items[at0004]" in "a/data[at0001]"
> and so on. But is this already the full explanation for the expression
> to be unambiguous ? The aliases used in queries (e.g. "a") ensures that
> a reference to an alias definitely means the same instance. Looking at
> queries like the one above let assume that aliases are only syntactic
> sugar and are not functionally needed. Is this correct ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: AQL query writing question

[Seref Arikan]

Given the AQL syntax and its current specifications, nothing stops you from
using the WHERE clause. However, you should consider the consequences of
using the WHERE clause to express that constraint.

if you'd like to express any other criteria such as a particular
DV_QUANTITY/magnitude value being greater than x (.../magnitude >= x) this
will go WHERE clause as well. Since multiple constraints in the WHERE
clause have to be connected by logical operators, you now have to write:

WHERE e/ehr_id/value = $ehrId AND c//magnitude >= x

so you'll have to express the implicitly stated (when you use
[ehr_id/value=..] AND condition explicitly and think about that logic. I'd
say it is possible that this will lead to bugs especially in complicated
AQL queries.

the second reason, which is pure speculation: is that some back ends are
likely to have mechanisms that process different constraints in an AQL
query in different ways. Pretty similar to query planners in relational
databases. The back end you're using may end up selecting all ehrs(!) and
then applying a filter due to ehr id constraint being in the WHERE clause.
This may or may not be the case, but I would not risk it.

Finally, to make things even more complicated, as per the predicates
section of aql spec (
https://www.openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#_predicates
), there is nothing that stops you from moving a constraint in the WHERE
clause into the FROm clause (in some cases). Why? Because both archetype
and node predicates are syntactic sugar for standard predicate. So if you
have a standard predicate such as the dv_quantity example I gave you above,
you could move it into FROM clause as follows:

... COMPOSITION c[/bla/bla/bla/magnitude >= x] CONTAINS bla bla

But in that case you would not be able to express boolean operations where
the operands are constrains of the nodes in the FROM clause. That's why I
said in some cases above.

My suggestion: stick to conventions as much as you can, there is quite a
bit of flexibility in the AQL syntax and its semantics is not formally
defined (as in no formal backing model of queries and match operation etc)
and you don't want to fall into those cracks. You may get wrong results due
to interpretation differences between vendors and your queries may lose
portability.

All the best
Seref




On Mon, Oct 8, 2018 at 8:46 AM Georg Fette 
wrote:

> Hello,
> In the AQL documentation there is a query
>
> SELECT c/uid/value, instruction
> FROM EHR e[ehr_id/value=$ehrid]
> CONTAINS COMPOSITION c
> CONTAINS INSTRUCTION instruction[openEHR-EHR-INSTRUCTION.referral.v1]
> WHERE EXISTS
>
> instruction/links[target='ehr://32702/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version
> ']
>
> When I reduce this query to
>
> SELECT e FROM EHR e[ehr_id/value=$ehrid]
>
> why is the constraint on the ehr_id done in the FROM section and not in
> the WHERE section like
>
> SELECT e
> FROM EHR e
> WHERE e/ehr_id/value = $ehrid
>
> Greetings
> Geirg
>
> --
> -
> 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-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Getting to know openEHR

[Seref Arikan]

Hi Alex,

This is probably a good starting point:

https://www.openehr.org/resources/white_papers

Not in great shape and showing its age now, but this one could give you a
slightly technically perspective:

https://serefarikan.com/2012/11/08/openehr-for-practical-people-cleaned-up/

I'd suggest that you also checkout Tom's blog: https://wolandscat.net/

These are good paths for a pragmatic introduction but the lists would
probably be the most useful resource; just ask whatever you want to/does
not make sense.

More substantial resources exist, like to specification documents and
papers/thesis on openEHR but I'd suggest you follow a goal driven approach.

Cheers
Seref

ps: I think technical and implementers lists became the common ground in
time, will need to check what is going on with C#, thanks for raising that.


On Fri, Jul 20, 2018 at 1:31 PM, HITCHINS, Alex (EAST SUSSEX HEALTHCARE NHS
TRUST)  wrote:

> Hello All,
>
>
>
> I’m relatively new to this topic so wondered if anyone had any pointers
> for me to get started. Currently working on some integration projects for
> an NHS trust and this looks like it could be the ideal route for us to go
> down in terms of structuring data etc.
>
>
>
> If anyone has any good ‘beginners-guides’ they could point me to, it would
> be very welcomed!
>
>
>
> Also, I notice the C#/.Net mailing list doesn’t seem to work, has this
> been disbanded now?
>
>
>
> Many thanks,
>
>
>
> Alex Hitchins
>
>
> 
> 
>
> This message may contain confidential information. If you are not the
> intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-mail or
> take any action in relation to its contents. To do so is strictly
> prohibited and may be unlawful. Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all NHS
> staff in England and Scotland. NHSmail is approved for exchanging patient
> data and other sensitive information with NHSmail and other accredited
> email services.
>
> For more information and to find out how you can switch,
> https://portal.nhs.net/help/joiningnhsmail
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Announcing Archie version 0.4

[Seref Arikan]

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-techni...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Announcing Archie version 0.4

[Seref Arikan]

Pieter,

Allow me to express my appreciation and gratitude please: Archie is a
fantastic piece of work, which has become my go-to library since I
discovered it. Thanks a lot for all your hard work.

Kind regards
Seref


On Wed, Jan 31, 2018 at 3:18 PM, 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-technical mailing list
> openehr-techni...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Seref Arikan]

Hi Danny,

You can unsubscribe from the same page you've subscribed.
http://www.openehr.org/community/mailinglists


On Mon, Aug 21, 2017 at 1:11 AM, Danny Nguyen  wrote:

> Dear All,
>
> Please remove me from this listserv.
>
> Best,
>
> Danny
>
> On Sat, Aug 19, 2017 at 6:18 AM Bert Verhees  wrote:
>
>> I agree that merging is (normally) only interesting for persistent
>> compositions, that are the only kind of compositions which are candidat for
>> simultaneously editing (branching), and then afterwards merging of the
>> branches is needed.
>>
>> I think, getting rid of the persistent compositions would solve these
>> problems. I don't see objections against medication-lists in normal
>> compositions. Maybe the persistent composition idea was something from the
>> old days to have all medications handy together?
>>
>> If that is so, than we can consider that this way of preordening  is not
>> anymore needed because modern systems can quickly find medication-entries,
>> and the extra advantage is that branching and merging is then also not
>> needed anymore.
>>
>> Best regards
>> Bert Verhees
>>
>> Op vr 18 aug. 2017 15:18 schreef Thomas Beale :
>>
>>>
>>> Naturally I am all for revising the specs (it's what we do ;) and
>>> throwing out dead stuff. But one thing I have realised over the years is
>>> that many of the scenarios (such as multi-system syncing) we thought of in
>>> the 1990s and early 200s are only just coming onto the radar now. Progress
>>> is much slower than many of us thought.
>>>
>>> Consequently, some types of implementation experience gained so far -
>>> particularly anything cross-enterprise or regional - is not going to be an
>>> indicator to the future. Of course, some kinds of experience, say with
>>> using the RM, or ADL 1.4, AQL etc, has been giving us all the feedback that
>>> we needed to make the updates we are currently making to the specifications.
>>>
>>> Probably what we should consider in this case is an update to the Change
>>> control spec that describes a variant or guideline for using the model to
>>> implement linear versioning, while allowing for later addition of branched
>>> versioning when/if needed.
>>>
>>> - thomas
>>>
>>> On 18/08/2017 12:49, Pablo Pazos wrote:
>>>
>>> From Thomas comments, it is clear that we have such last two use cases,
>>> internal versioning and cross-system versioning / sync / consolidation.
>>>
>>> Consider people here is talking about their own experience with the
>>> specs under the use case they implemented. We can argue that internal
>>> versioning is needed in 100% of the implementations while cross-system is a
>>> much less implemented case. This doesn't mean that the current specs are
>>> not usable and useful in abstract, but we should contextualize the
>>> discussion by use case and by the frequency each is implemented.
>>>
>>>  For internal versioning it is clear that distributed versioning spec
>>> generate some friction at implementation time. IMO we need to address both
>>> use cases trying to minimize friction for new developers. That can improve
>>> the quality of the specs without print anything out.
>>>
>>> Also, I would like to hear more about implementations of both use cases
>>> and the challenges implementers had to really validate the idea of
>>> addressing both use cases explicitly in the specs.
>>>
>>> Cheers,
>>> Pablo.
>>>
>>>
>>> On Aug 18, 2017 5:39 AM, "Seref Arikan" >> kurumsalteknoloji.com> wrote:
>>>
>>> I did not realise that this discussion reached the point of suggesting
>>> that distributed versioning is taken out from the specs. I have been
>>> designing and implementing lots of openEHR data syncing functionality which
>>> relies on the distributed versioning specifications. I have heaps of work
>>> pending, which will also use that part of the specs. I can tell you that
>>> the current specs have worked just fine for me so far and they are up to
>>> the same high quality as the rest of the specifications, so they are
>>> absolutely usable and useful.
>>>
>>> The challenges of distributed versioning does not eliminate the need for
>>> them, so I cannot agree with the suggestion to remove them.  Sure, move
>>> them around in the specs all you want, but please keep them.
>>>
>&g

Re: Versioning implementations

[Seref Arikan]

I did not realise that this discussion reached the point of suggesting that
distributed versioning is taken out from the specs. I have been designing
and implementing lots of openEHR data syncing functionality which relies on
the distributed versioning specifications. I have heaps of work pending,
which will also use that part of the specs. I can tell you that the current
specs have worked just fine for me so far and they are up to the same high
quality as the rest of the specifications, so they are absolutely usable
and useful.

The challenges of distributed versioning does not eliminate the need for
them, so I cannot agree with the suggestion to remove them.  Sure, move
them around in the specs all you want, but please keep them.

All the best
Seref


On Fri, Aug 18, 2017 at 9:15 AM, Thomas Beale 
wrote:

> Hi,
>
> distributed versioning with branching was included to allow syncing of
> data gathered about the same patient in different EHR repositories. For
> most data, syncing the repos is trivial, since it's different data.
>
> The classic cases of potential clashes is medication list, problem list,
> basic clinical demographic data, etc. If a sync was started and two
> medication lists are found that are forks of a single earlier one, a manual
> merge will be required.
>
> We are only just starting to see the implementation of systems where
> syncing may be a question, so although there may be adjustments to make to
> the branched versioning model, I would not be in favour of throwing it out
> at this point.
>
> We are however going to move it to the BASE component and make it a
> standalone model.
>
> - thomas
>
> On 21/06/2017 09:19, Pablo Pazos wrote:
>
> Hi Bert, see below
>
> On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees 
> wrote:
>
>> Hi Pablo, I did it a few years ago, just dumped not-current versions in a
>> slow XML database, because, in normal cases they are never queried, and
>> when they need to be queried, there can always be found a faster solution.
>>
>> But of course, this was a linear version system. ExistDB supports
>> distributed versioning on XML out of the box. And you can also use a
>> normal, not OpenEHR, version system like Git or VCL.
>>
>> But when looking at how OpenEHR works, is there ever need of merging? Do
>> people edit concurrently same datasets? I think they are they always
>> working on new versions of datasets, there is only one exception, that is
>> the persistent Composition, there could occur merging problems.
>>
>> The openEHR versioning mechanism is like Git. The problem I see with this
> approach is that real users don't want to deal with that level of
> complexity just to track changes in a distributed way. openEHR allows
> branching, so if there is no merging, each user can be working on a
> different branch, seeing just part of the data. Merging is complex, but
> that is needed only if branching is allowed, so the problem is really
> branching.
>
> With branches, when a query is executed, it is getting data form the
> latest version of the CURRENT branch, potentially missing data from other
> branches. This might have patient safety issues also.
>
> That is the main reason I ask this because it is not clear to me that a
> good technical solution like distributed versioning, is the best for EHRs.
> Moreover considering that most documents will have 1 or 2 versions at most
> (talking about event). Of course there will be more versions for persistent
> compos.
>
> *Thinking out loud, wouldn't be interesting to have an alternative spec
> for versioning where only linear versions are allowed? (IMO that would be
> easier to implement even though the current spec includes that case).*
>
>
>> But I think, you don't need distributed versioning to handle this, a
>> locking system (like databases have) is, I think, good enough. That is how
>> classic EHR builders handle concurrency.
>>
>> Bert
>>
>>
>> On 21-06-17 03:04, Pablo Pazos wrote:
>>
>> Hi all,
>>
>> I had this questions in mind for a long time: did someone implemented the
>> distributed versioning of openEHR?
>>
>> The specs define a great distributed versioning mechanism but it is a
>> little trickier to implement. Also there is no clear who will do the work
>> of managing that, and how that structure will be queried. It is very
>> difficult to me to think of an amendment sent to an EHR and that not being
>> available for all the parties looking at the EHR of the patient.
>>
>> In the case of the EHRServer I built, only linear versioning is possible,
>> there is only one latest version for each compo, and queries only get data
>> from latest versions.
>>
>> Just wondering, what do others did for versioning and what policies do
>> you have if you implemented the distributed approach in terms of branching,
>> merging and querying.
>>
>>
>> Thanks!
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> Cel:(00598) 99 043 145 <099%20043%20145>
>> Skype: cabolabs
>> 
>> http://www.cabolabs.com
>> pablo.

Re: Archie version 0.1.0 released

[Seref Arikan]

Hi Pieter,
This is a significant piece of work! Congratulations for reaching this
point and thank you for sharing it with the rest of the world. I for one
look forward to hearing good news about your openEHR implementation.

All the best
Seref


On Tue, May 17, 2016 at 12:53 PM, Pieter Bos  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-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org