Re: access on items in a cluster

[Seref Arikan]

Hi Georg,
See inline

On Wed, Oct 30, 2019 at 12:26 PM Georg Fette 
wrote:

> Hello,
> I would like to typecheck AQL queries and have some problems doing that:
> The items in a CLUSTER are of type ITEM. If I access
> myCluster/items[at0001]/value, is there any possibility to type-check
> the validity of this path without having the concrete archetype
> definition at hand? Just using the reference model isn't enough for this
> task, because ITEMs do not have a value-field.
> How can (from an object oriented point of view) the values of the ITEMs
> be accessed without knowing if it is an ELEMENT ?
>

They cannot be accessed. This is one corner case of two level modelling
when it is applied on an RM class that uses a field of abstract type, such
as an ITEM.
The archetypes end up setting the concrete type so from a type
checking/validation perspective, the fact that a field of type ITEM should
have  instances of type CLUSTER or ELEMENT are declared by the archetype.
So you cannot check it without using the archetype, or validate it for that
matter. You'd actually hit this way up in the RM tree before you make it to
types used at the leaves: COMPOSITION has its content field defined as
CONTENT_ITEM
There are no perfect design decisions in computer science/engineering, you
win some, you lose some. Tom did the right thing by using abstract types
when following a OO design for RM. The constraint mechanism (ADL) has to
deal with this correct decision, modelling tools then in turn have to deal
with this, then AQL validators and programmers who write code against
serialised data.


Why is there a distiguishment between ELEMENT, ITEM and CLUSTER at all ?
> If the fields "items" and "value" were already attached to the class
> ITEM it would be easier.
>
CLUSTER is a container of actual data, which allows you to represent
hierarchical structures. ELEMENT is actual data.
All the use cases and justifications for the composite design pattern apply
here, because this is a textbook use of that pattern.

All the best
S

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: data element type from the RM

[Seref Arikan]

Hi Georg,
Do not confuse the RM model aspects with a particular serialisation
format's aspects.

RM is technology agnostic, it contains a definition of types which can be
implemented via most mainstream (OO) programming languages.

Json or XML form of data is a 'serialisation' of an object, which is an
implementation of an RM type in a language you don't even have to know
about. The type field is a requirement of the serialisation format, so that
deserialising code can create the correct instance of the RM types for the
correct attributes.

The RM has no need of a type field, it is based on type definitions
already.  RM uses inheritance (and generics in combination with that) at
various locations in the types it defines and this is the reason the type
field in the serialised formalism is needed.

It is the same with any mainstream serialisation library that serialises
objects which come from a type system that supports inheritance. Nothing
specific to openEHR.

Keep this in mind:

RM Definitions -> Rm implementation(s) -> Data
serialisation/deserialisation -> (XML/JSON/bla)
The @type field is required at the last two levels.

Cheers
Seref


On Wed, Oct 9, 2019 at 10:27 AM Georg Fette 
wrote:

> Hello,
> Which is the field that stores the RM-model-type of data elements ? When
> I use the ocean instance generator the json contains a field called
> "@xsi:type", which contains this information. Where in the RM-model
> itself is this type-field defined ?
> 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: automatic demotion of lists in AQL ?

[Seref Arikan]

Hi Georg,
I’d say yes but do it reluctantly :) you can think in terms of iteration
but in my experience it leads to incorrect assumptions and can confuse you,
especially regarding how result sets are created
I’d suggest thinking in terms of pattern matching rather than traversal but
both are valid ways of interpreting Aql semantics

Cheers
S.

On Monday, May 6, 2019, Georg Fette  wrote:

> Hi Seref,
> Ok, thank you for the answer.
> From that I and the other answers I would summarize that
> "implicit iteration over lists in order to further process the elements"
> is a paradigm that does actually exist in AQL.
> 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: automatic demotion of lists in AQL ?

[Seref Arikan]

Have you seen a previous answer I gave to you re contains clause and nodes
without arch nd ids? The one explaining why it is unlikely to work

a/items[at0001]/value/value should do the trick

On Sunday, May 5, 2019, Georg Fette  wrote:

> Hello,
> In order to better understand the semantics of AQL I try to rephrase the
> problem I have:
> Imagine an archetype "openEHR-EHR-CLUSTER.example.v1" that allows the
> multiple existence of a specific contained field:
>
> definition
> CLUSTER[at] matches {
> items cardinality matches {0..*; unordered} matches {
> ELEMENT[at0001] occurrences matches {0..*} matches { value
> matches { DV_TEXT matches {*} } }
> }
> }
>
> Is it allowed to constrain this archetype in the WHERE part by accessing
> the field within a path? :
>
> SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
> WHERE a/items[at0001]/value = 'test'
>
> The problem I have with this query is that the path "a/items[at0001]" is a
> list, so it perhaps cannot be extended with "value", because a list does
> not have a field "value" but only the members of this list have this field.
> An alternative to the query above would be to resolve the list in the FROM
> part by writing something like this:
>
> SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
> CONTAINS DV_TEXT b
> WHERE b/value = 'test'
>
> This would work in the above example, but would create further problems if
> there are further elements in parallel to ELEMENT[at0001] that as well
> contain DV_TEXTs and which would be matched as well by the alternative
> query.
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Seref Arikan]

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

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

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

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

[Seref Arikan]

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

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

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

All the best
Seref

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

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

Re: AQL query for blood pressure from the AQL documentation

[Seref Arikan]

Hi Tom,
See comments inline please.

On Thu, May 2, 2019 at 12:52 PM Thomas Beale 
wrote:

> Ian,
>
> If you were referring to the discussion about paths and data types, i.e.
> how do you know if you can refer to some path inside a DvQuantity if the
> archetype only knows about DataValue and LOINC codes, it's true that you
> can use such a path, if the real data (Element.value) happen to be a
> DvQuantity, but you have to be able to reliably figure this out at runtime,
> presumably by inferring it from the LOINC or other code - every time? In
> this situation the AQL processor cannot help you, because it doesn't have
> any information about what lies beyond the Element.value point in the
> structure.
>
As I mentioned in my response earlier, the serialisation of Element.value
would have either xsi:type (xml) or "_type" (json) letting the consumer of
the query process this information during runtime. You're right about the
aql processor not having much capability here, though this particular case
is not necessarily problematic since you'll have the archetype node id and
all data instances with that arch. nd. id will be of the same type. A
situation in which you'd need the aql processor to be smarter, but it
cannot be is if you used this Element.value with an operator that is valid
for particular types, such as '<'. So if you were to attempt to filter the
data with aql and used Element.value to filter say based on dates such as:

"...WHERE c/bla/../item[at0022]/value/value < '2008-02-03'"

this would require the AQL processor to do what you said, i.e. check actual
data type at runtime to make sure that Element.value is of type to which
comparison operator can be applied. Heath and I just discussed this issue
based on a feedback/question we received. I am currently in favour of
allowing a cast at the aql level via use of a CAST function, as various SQL
variants do. After all, based on the model the author of the query knows
that the path will contain a date. Read on for why I would not do what
you're suggesting

> It seems to me that it would be preferable to convert data with DataValue
> specific archetypes, since the general case is that data are written once,
> read many times. In that case, you will have data that always has a typed
> analyte Cluster archetype (e.g. to DvQuantity, DvOrdinal etc), and and the
> AQL service will be able to do proper type / path checking. AQL authoring
> tools will also be able to work in a more obvious way (e.g. with
> auto-complete on paths etc).
>
> So far I am not seeing a downside to this. I realise others have thought
> about it longer than I however ...
>
The downside is us, techies pushing our concern into modelling space. Very
much in the spirit of python seeing huge adoption over say Scala or Haskell
or even Java amongst scientists, I'd try to give clinical modellers some
space here. They would have to have a grasp of the type system arguments
above to see the justification for the (modelling) specialisation approach,
which I think is a weak argument here. My preferred compromise is to let
Aql engines know what to expect in advance using CAST (as a function, not
as a keyword) and let clinical modellers go on as things are a.t.m.

All the best
Seref

- thomas
> On 02/05/2019 12:02, Ian McNicoll wrote:
>
> The replies that seref and I gave address the issue. The vast majority of
> lab imports will use the generic analyte cluster.
>
> On Thu, 2 May 2019, 12:01 Ian McNicoll,  wrote:
>
>> Thomas this is not a problem. The aql works as designed
>>
>
> ___
> 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: constraining of laboratory_test_analyte Analyte result

[Seref Arikan]

Hi Georg,

Please note that you can always define your FROM clause with a high level
node such as an OBSERVATION o[archetype_id] and access the particular path
you're interested in using a path starting from o as in o/data[..]/...

Regarding your assumptions re FROM clause, technically there is nothing
stopping you from writing a query such as SELECT x FROM EHR e CONTAINS
DV_CODED_TEXT x. As useless as it may be, this is valid AQL and it asks for
all the DV_CODED_TEXT instances in all compositions under all EHRs
However, it is likely that most AQL implementations won't let you run this
query simply because implementers don't want to pay the multi-dimensional
price for supporting a theoretically possible but useless-in-real-life
use-case. I'm telling this only because your comments sounds like you're
assuming archetype node ids are mandatory in the FROM clause. They're not,
from a syntax standpoint and maybe we should close that gap in the specs.

So use the SELECT clause to define a path from the Observation and the aql
implementation should give you the element you're interested in based on
its archetype node id. Whatever serialisation format the back end uses
(json/xml), you should always get an attribute or a json field telling you
the actual instance type of DATA_VALUE, which you can use to process data.
It is really no different than any subtype based polymorphism
implementation where you're given a base (sometimes abstract) type and you
need to figure out the actual type during runtime.

All the best.
S.



On Mon, Apr 29, 2019 at 11:46 PM Georg Fette 
wrote:

> Hello,
> How do I constrain the Analyte result of a laboratory_test_analyte.v1 ?
> The Analyte result are defined as an ELEMENT that is only constrained by
> a node predicate (i.e. ELEMENT[at0001]). Therefore the results cannot be
> bound with a specialized type and an alias within the FROM part, as in
> the FROM part only archetypeID-predicates are allowed and no node
> predicates. As the result is defined with the abstract ELEMENT type,
> which has an abstract DATA_VALUE as its content, no paths can be defined
> that constrain specific aspects of subclasses of DATA_VALUE that are
> actually stored in the ELEMENT[at0001] field of the test_analyte.
> How can this problem be resolved ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL support for an array of ehr_id

[Seref Arikan]

The matches statement is part of Aql specification

On Friday, August 31, 2018, Dileep V S  wrote:

> Dear Ian,
>
> Thanks. Is this part of the AQL spec or a feature that THinkEhr has
> implemented?
>
> Given the emerging importance of patient consent, given the GDPR and
> similar rules coming our across the world (DISHA in India), this may become
> a basic requirement in any EHR systems of the future. A static mapping of
> an EHR to the creator organization, as is normal in provider centric
> systems, may not be good enough.
>
> regards
>
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Thu, Aug 30, 2018 at 11:11 PM, Ian McNicoll  wrote:
>
>> Hi Dileep - this is supported by THinkEhr...
>>
>> SELECT
>>e/ehr_id/value, a/data[at0001]/events[at0006]/time,
>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value,
>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value --
>> diastolic
>>  FROM EHR e CONTAINS OBSERVATION a[openEHR-EHR-OBSERVATION.bloo
>> d_pressure.v1]
>> WHERE e/ehr_id/value MATCHES { 'e241715b-3ca7-435e-a474-718579aadaa2',
>> '0e7ac1d6-2dc6-40ec-8259-ac9f9a9727d1', 'ed74f788-4bd6-4e47-ab98-21164
>> 3cc4b0c'}
>>
>> Ian
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Thu, 30 Aug 2018 at 18:23, Dileep V S  wrote:
>>
>>> Hi,
>>>
>>> I am not sure if this has been asked before. I am asking again since I
>>> could not find an answer
>>>
>>> Does AQL support an array of EHRs? In AQL specs i can see examples to
>>> query any a single EHR and across all EHRs in the system. If I want to
>>> limit my query to a set of EHRs is it possible using AQL?
>>>
>>> Use case - As part of a dynamic consent management framework, we keep a
>>> dynamic mapping of EHRs to organizations. This is kept updated based on
>>> patient consent. So at any time a query is run by an organization, it
>>> should be limited to the EHRs that it has consent at that point of time.
>>>
>>> regards
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: healthelife.in  e: dil...@healthelife.in
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Seref Arikan]

Ah I see. Well, in that case we agree :)

On Tue, Aug 21, 2018 at 5:30 PM, Birger Haarbrandt <
birger.haarbra...@plri.de> wrote:

> Hi Seref,
>
> I'm sorry, I interpreted the following quote
>
> "anybody using this function could figure out that it was introduced by a
> particular vendor"
>
> as a statement that the folder issue should be solved by particular
> vendors by introducing their own functions. I'm just saying that dealing
> with folders in AQL "somehow" should be part of the specification. However,
> I did not express any preferences regarding the solution.
>
> As you seem to agree on this point: sorry for the misunderstanding!
>
> Best,
>
> Birger
>
>
>
> Am 21.08.2018 um 17:10 schrieb Seref Arikan:
>
> You're missing my point. To express it in your terms: this is not about
> excluding Folders from AQL spec, I said nothing of that sort or implied it
> anyway. AQL does not include or exclude individual RM types, it addresses
> all of RM and it is either consistent or not consistent across all of RM,
> period.
>
> Contains statement works over folders but folders do not contain
> compositions, they contain references to compositions (and to other things
> if necessary) by design. Contains not returning compositions 'referenced'
> under folders is not excluding folders from aql: on the contrary, it is AQL
> working as intended on an RM type.
>
>
> What is suggested here would make it inconsistent due to special cases.
> I'm suggesting a way to preserve consistency and providing the
> functionality that is requested. That is a win-win. There may be better
> ways of doing it, but overloading the contains operator is not one of them
> due to reasons I explained.
>
> All the best
> Seref
>
>
>
>
> On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt <
> birger.haarbra...@plri.de> wrote:
>
>> Hi Seref,
>>
>> while I understand your argument regarding overloading of definitions
>> (and I agree with your reasoning), I see a clear need to not treat folders
>> as second class citizens in openEHR. Not including Folders in the official
>> AQL spec and leaving this to vendor-dependent functions will not be helpful
>> to allow portability. Especially, as the use of folders (especially when it
>> can contain data in an ITEM_STRUCTURE) is becoming a common pattern to
>> represent episodes of care.
>>
>> Cheers,
>>
>> --
>>
>>
>>
>> *Birger Haarbrandt, M. Sc. Peter L. Reichertz Institut for Medical
>> Informatics (PLRI) Technical University Braunschweig and Hannover Medical
>> School Software Architect HiGHmed Project *
>> Tel: +49 176 640 94 640, Fax: +49 531/391-9502
>> birger.haarbra...@plri.de
>> www.plri.de
>>
>>
>>
>>
>> Am 21.08.2018 um 14:37 schrieb Seref Arikan:
>>
>> @Bjorn and @Ian both: I don't think this is a good idea. This example
>> overloads the semantics of CONTAINS operator of AQL for a very specific
>> scenario: when the object reference is a reference to a composition and the
>> reference sits under folder F, which btw should not be a folder contained
>> in another folder. Based on the second Example from Bjorn, It looks like
>> CONTAINS also (silently?) resolves the reference of its parent's parent (f)
>> which is another overload of its very core definition.
>>
>> This is not standard AQL, even though AQL is probably the most variable
>> spec in openEHR in terms of its implementation across vendors. I know
>> different vendors come across different requirements at different times and
>> our individual solutions to those slowly make it into the standard so there
>> is always a window during which a feature is available from a vendor but
>> still not in the spec but this can be problematic at times.
>>
>> As I said in the past in numerous occasions: I think the robust way to
>> deal with these type of edge cases is to leave the core semantics of AQL
>> alone as much as possible and use extensions such as functions. Something
>> like
>>
>> SELECT resolve_folder_comps(f/items) as compositions_under_folder FROM
>> EHR e[$ehrId] CONTAINS FOLDER f[..]
>>
>> would encapsulate the specific case into resolve_folder_comp function's
>> definition and semantics. Anybody using this function could figure out that
>> it was introduced by a particular vendor, see its documentation, read its
>> limitations such as the root folder requirement for f etc etc.
>>
>> Pretty soon, we'll have a REST spec which the vendors will have
>> implemented, with API calls to run AQL queries. If those que

Re: AQL on specific list of compositions

[Seref Arikan]

Hi Sebastian,

Sure, that is another way of dealing with the requirement of resolving
object references. Every time we discuss new features like these for AQL,
we're basically looking at a choice between small language with libraries
vs large language with richer native semantics. (e.g.: Java is former and
C# is latter)

My inclination is usually towards small language option or at least keeping
functionality in libraries and later promoting them to language syntax if
they become features used frequently. The REFERS option presents no
semantic ambiguity so it is not subject to my previous criticism.

On Tue, Aug 21, 2018 at 4:25 PM, Sebastian Iancu 
wrote:

> Hi Seref, Thomas,
>
>
> On the last SEC meeting, another proposed idea (besides the one from
> Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it we did
> not explored further on. Could this still be considered in these
> discussions?
>
>
> Sebastian I.
>
> On 8/21/2018 5:10 PM, Seref Arikan wrote:
>
> You're missing my point. To express it in your terms: this is not about
> excluding Folders from AQL spec, I said nothing of that sort or implied it
> anyway. AQL does not include or exclude individual RM types, it addresses
> all of RM and it is either consistent or not consistent across all of RM,
> period.
>
> Contains statement works over folders but folders do not contain
> compositions, they contain references to compositions (and to other things
> if necessary) by design. Contains not returning compositions 'referenced'
> under folders is not excluding folders from aql: on the contrary, it is AQL
> working as intended on an RM type.
>
>
> What is suggested here would make it inconsistent due to special cases.
> I'm suggesting a way to preserve consistency and providing the
> functionality that is requested. That is a win-win. There may be better
> ways of doing it, but overloading the contains operator is not one of them
> due to reasons I explained.
>
> All the best
> Seref
>
>
>
>
> On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt <
> birger.haarbra...@plri.de> wrote:
>
>> Hi Seref,
>>
>> while I understand your argument regarding overloading of definitions
>> (and I agree with your reasoning), I see a clear need to not treat folders
>> as second class citizens in openEHR. Not including Folders in the official
>> AQL spec and leaving this to vendor-dependent functions will not be helpful
>> to allow portability. Especially, as the use of folders (especially when it
>> can contain data in an ITEM_STRUCTURE) is becoming a common pattern to
>> represent episodes of care.
>>
>> Cheers,
>>
>> --
>>
>>
>>
>> *Birger Haarbrandt, M. Sc. Peter L. Reichertz Institut for Medical
>> Informatics (PLRI) Technical University Braunschweig and Hannover Medical
>> School Software Architect HiGHmed Project *
>> Tel: +49 176 640 94 640, Fax: +49 531/391-9502
>> birger.haarbra...@plri.de
>> www.plri.de
>>
>>
>>
>>
>> Am 21.08.2018 um 14:37 schrieb Seref Arikan:
>>
>> @Bjorn and @Ian both: I don't think this is a good idea. This example
>> overloads the semantics of CONTAINS operator of AQL for a very specific
>> scenario: when the object reference is a reference to a composition and the
>> reference sits under folder F, which btw should not be a folder contained
>> in another folder. Based on the second Example from Bjorn, It looks like
>> CONTAINS also (silently?) resolves the reference of its parent's parent (f)
>> which is another overload of its very core definition.
>>
>> This is not standard AQL, even though AQL is probably the most variable
>> spec in openEHR in terms of its implementation across vendors. I know
>> different vendors come across different requirements at different times and
>> our individual solutions to those slowly make it into the standard so there
>> is always a window during which a feature is available from a vendor but
>> still not in the spec but this can be problematic at times.
>>
>> As I said in the past in numerous occasions: I think the robust way to
>> deal with these type of edge cases is to leave the core semantics of AQL
>> alone as much as possible and use extensions such as functions. Something
>> like
>>
>> SELECT resolve_folder_comps(f/items) as compositions_under_folder FROM
>> EHR e[$ehrId] CONTAINS FOLDER f[..]
>>
>> would encapsulate the specific case into resolve_folder_comp function's
>> definition and semantics. Anybody using this function could figure out that
>> it was introduced by a particular vendor, see its documentation, read its
>&

Re: AQL on specific list of compositions

[Seref Arikan]

You're missing my point. To express it in your terms: this is not about
excluding Folders from AQL spec, I said nothing of that sort or implied it
anyway. AQL does not include or exclude individual RM types, it addresses
all of RM and it is either consistent or not consistent across all of RM,
period.

Contains statement works over folders but folders do not contain
compositions, they contain references to compositions (and to other things
if necessary) by design. Contains not returning compositions 'referenced'
under folders is not excluding folders from aql: on the contrary, it is AQL
working as intended on an RM type.


What is suggested here would make it inconsistent due to special cases. I'm
suggesting a way to preserve consistency and providing the functionality
that is requested. That is a win-win. There may be better ways of doing it,
but overloading the contains operator is not one of them due to reasons I
explained.

All the best
Seref




On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt <
birger.haarbra...@plri.de> wrote:

> Hi Seref,
>
> while I understand your argument regarding overloading of definitions (and
> I agree with your reasoning), I see a clear need to not treat folders as
> second class citizens in openEHR. Not including Folders in the official AQL
> spec and leaving this to vendor-dependent functions will not be helpful to
> allow portability. Especially, as the use of folders (especially when it
> can contain data in an ITEM_STRUCTURE) is becoming a common pattern to
> represent episodes of care.
>
> Cheers,
>
> --
>
>
>
> *Birger Haarbrandt, M. Sc. Peter L. Reichertz Institut for Medical
> Informatics (PLRI) Technical University Braunschweig and Hannover Medical
> School Software Architect HiGHmed Project *
> Tel: +49 176 640 94 640, Fax: +49 531/391-9502
> birger.haarbra...@plri.de
> www.plri.de
>
>
>
>
> Am 21.08.2018 um 14:37 schrieb Seref Arikan:
>
> @Bjorn and @Ian both: I don't think this is a good idea. This example
> overloads the semantics of CONTAINS operator of AQL for a very specific
> scenario: when the object reference is a reference to a composition and the
> reference sits under folder F, which btw should not be a folder contained
> in another folder. Based on the second Example from Bjorn, It looks like
> CONTAINS also (silently?) resolves the reference of its parent's parent (f)
> which is another overload of its very core definition.
>
> This is not standard AQL, even though AQL is probably the most variable
> spec in openEHR in terms of its implementation across vendors. I know
> different vendors come across different requirements at different times and
> our individual solutions to those slowly make it into the standard so there
> is always a window during which a feature is available from a vendor but
> still not in the spec but this can be problematic at times.
>
> As I said in the past in numerous occasions: I think the robust way to
> deal with these type of edge cases is to leave the core semantics of AQL
> alone as much as possible and use extensions such as functions. Something
> like
>
> SELECT resolve_folder_comps(f/items) as compositions_under_folder FROM EHR
> e[$ehrId] CONTAINS FOLDER f[..]
>
> would encapsulate the specific case into resolve_folder_comp function's
> definition and semantics. Anybody using this function could figure out that
> it was introduced by a particular vendor, see its documentation, read its
> limitations such as the root folder requirement for f etc etc.
>
> Pretty soon, we'll have a REST spec which the vendors will have
> implemented, with API calls to run AQL queries. If those queries do not
> work across REST deployments of Ocean, DIPS, Marand, Code24 etc how on
> earth we can claim we have a unified way of retrieving data that works
> consistently across systems?
>
> My suggestion above my be faulty and I'd be delighted to hear objections
> and suggestions for alternatives but let's please try to not to lose the
> big picture when working on AQL: it is going to be a huge value added of
> openEHR in near future and its portability matters a lot. I tried to make
> this point in a more subtle way in my previous messages but I seem to have
> failed, hence: this rather blunt response I'm sending with good intentions
> only.
>
> All the best
> Seref
>
>
>
>
> On Tue, Aug 21, 2018 at 12:44 PM, Ian McNicoll  wrote:
>
>> Thanks Bjorn
>>
>> That feels logical and the restriction to one layer of folders make
>> sense. I appreciate that under the hood 'CONTAINS' is implemented
>> differently but it feels natural to think in terms of logical containment.
>>
>> Ian
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1

Re: AQL on specific list of compositions

[Seref Arikan]

@Bjorn and @Ian both: I don't think this is a good idea. This example
overloads the semantics of CONTAINS operator of AQL for a very specific
scenario: when the object reference is a reference to a composition and the
reference sits under folder F, which btw should not be a folder contained
in another folder. Based on the second Example from Bjorn, It looks like
CONTAINS also (silently?) resolves the reference of its parent's parent (f)
which is another overload of its very core definition.

This is not standard AQL, even though AQL is probably the most variable
spec in openEHR in terms of its implementation across vendors. I know
different vendors come across different requirements at different times and
our individual solutions to those slowly make it into the standard so there
is always a window during which a feature is available from a vendor but
still not in the spec but this can be problematic at times.

As I said in the past in numerous occasions: I think the robust way to deal
with these type of edge cases is to leave the core semantics of AQL alone
as much as possible and use extensions such as functions. Something like

SELECT resolve_folder_comps(f/items) as compositions_under_folder FROM EHR
e[$ehrId] CONTAINS FOLDER f[..]

would encapsulate the specific case into resolve_folder_comp function's
definition and semantics. Anybody using this function could figure out that
it was introduced by a particular vendor, see its documentation, read its
limitations such as the root folder requirement for f etc etc.

Pretty soon, we'll have a REST spec which the vendors will have
implemented, with API calls to run AQL queries. If those queries do not
work across REST deployments of Ocean, DIPS, Marand, Code24 etc how on
earth we can claim we have a unified way of retrieving data that works
consistently across systems?

My suggestion above my be faulty and I'd be delighted to hear objections
and suggestions for alternatives but let's please try to not to lose the
big picture when working on AQL: it is going to be a huge value added of
openEHR in near future and its portability matters a lot. I tried to make
this point in a more subtle way in my previous messages but I seem to have
failed, hence: this rather blunt response I'm sending with good intentions
only.

All the best
Seref




On Tue, Aug 21, 2018 at 12:44 PM, Ian McNicoll  wrote:

> Thanks Bjorn
>
> That feels logical and the restriction to one layer of folders make sense.
> I appreciate that under the hood 'CONTAINS' is implemented differently but
> it feels natural to think in terms of logical containment.
>
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Tue, 21 Aug 2018 at 08:54, Bjørn Næss  wrote:
>
>> @ian – we have implemented the query you wrote:
>>
>>
>>
>> “select c from EHR e contains FOLDER f contains COMPOSITION c where c…..”
>>
>>
>>
>> You might even write:
>>
>>
>>
>> “select c from EHR e contains FOLDER f contains FOLDER child_folder
>> contains COMPOSITION c where c…..”
>>
>>
>>
>>
>>
>> We made a restriction such that the COMPOSITION c MUST be referenced in
>> FOLDER f and not any sub-folder. This was needed to avoid circular
>> references and explosion in the result set.
>>
>>
>>
>>
>>
>> Vennlig hilsen
>> Bjørn Næss
>> Product owner
>> DIPS ASA
>>
>> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>>
>>
>>
>> *From:* openEHR-technical  *On
>> Behalf Of *Ian McNicoll
>> *Sent:* mandag 20. august 2018 11:22
>> *To:* For openEHR technical discussions > openehr.org>
>> *Subject:* Re: AQL on specific list of compositions
>>
>>
>>
>> Yup but AQL is so cool for this kind of thing :)
>>
>> I still want to do
>>
>> Select c FROM EHR Contains folder x contains composition c
>>
>>
>>
>> since logically folder x contains compositions.
>>
>> Ian
>>
>>
>>
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>>
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>>
>>
>>
>> On Mon, 20 Aug 2018 at 10:14, Thomas Beale 
>> wrote:
>>
>> Well if you have access to a Folder, you don't need to do an AQL query,
>> you can just retrieve the Folder structure and recurse through it,
>> picking up direct refs to VERSIONED_COMPOSITIONs.
>>
>> Creating Folders from the data on the other hand requires writing some
>> queries that look for admissions and discharges, matching them up, and
>> generating a Folder for each pair, named after the institution and/or
>> dates of the stay.  A bit messy, but not hard to do, if one wants to

Re: AQL on specific list of compositions

[Seref Arikan]

You're (unintentionally) circling back to discussions re AQL in the last
SEC meeting in Slovenia (I was sitting in remotely)

What you're asking for can be accomplished in a number of ways at the AQL
level, all of which would require changes to AQL specs and implementations.
I'm always happy to discuss these but I suspect it deserves its own thread
:) Hint for subject: How to resolve object references with AQL?

All the best
Seref


On Mon, Aug 20, 2018 at 10:21 AM, Ian McNicoll  wrote:

> Yup but AQL is so cool for this kind of thing :)
>
> I still want to do
>
> Select c FROM EHR Contains folder x contains composition c
>
> since logically folder x contains compositions.
>
> Ian
>
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Mon, 20 Aug 2018 at 10:14, Thomas Beale 
> wrote:
>
>> Well if you have access to a Folder, you don't need to do an AQL query,
>> you can just retrieve the Folder structure and recurse through it,
>> picking up direct refs to VERSIONED_COMPOSITIONs.
>>
>> Creating Folders from the data on the other hand requires writing some
>> queries that look for admissions and discharges, matching them up, and
>> generating a Folder for each pair, named after the institution and/or
>> dates of the stay.  A bit messy, but not hard to do, if one wants to
>> post hoc add Folders to 'old' EHRs that never had them.
>>
>> - thomas
>>
>>
>> On 20/08/2018 10:07, Ian McNicoll wrote:
>> > Thanks Thomas,
>> >
>> > What are your thoughts on the AQL example I foolishly guessed at :(
>> > and that Seref quite correctly rejected!!
>> >
>> > How would/should we do...
>> >
>> > Select all compositions referenced by Folder x.
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Seref Arikan]

But folder does not contain COMPOSITIONS,  it contains object refs
https://www.openehr.org/releases/RM/latest/docs/common/common.html#_folder_class

You need some aql semantics to resolve those refs to whatever they're
pointing at, which does not exist as far as I know (q: what if object refs
are pointing at different types ? :) )

Contains is only applicable to parent/child/../descendant relationship of
object.property paths



On Friday, August 17, 2018, Ian McNicoll  wrote:

> Hi Seref,
>
> My understanding is that AQL can support FOLDER (assuming it is
> implemented) with something like
>
> Select c
> FROM EHR e CONTAINS FOLDER f CONTAINS COMPOSITION c
> Where folder f.name = "My lovely encounters"
>
> but I may be wrong (both in principle and practice)
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Fri, 17 Aug 2018 at 16:20, Seref Arikan  kurumsalteknoloji.com> wrote:
>
>> Hi Ian,
>>
>> When the fact that the Composition is associated to an encounter or
>> episode of care is recorded by including a reference to that composition in
>> a folder, some clinical context/information related to that composition is
>> now stored outside the composition, by means of a refence in a folder
>>
>> Unless I'm missing an Aql feature that can help, you can no longer select
>> those compositions via Aql (since Aql does not support/specify how to
>> resolve refs)
>>
>> If you follow the encounter id approach you mentioned, then you could use
>> Aql.
>>
>> In fact, if Ethercis had support for Folder, Dileep would still not be
>> able to get those compositions with a singl query: he'd need to fetchs uids
>> from a folder with one query, then perform a second query to get
>> compositions in the way I suggested.
>>
>> I'm probably being unnecessarily picky here, just pointing at the
>> difference between approaches and trying to put my finger on any downstream
>> issues. I'm not doing a great job of it though :)
>>
>> On Friday, August 17, 2018, Ian McNicoll  wrote:
>>
>>> Hi Seref,
>>>
>>> I'm not sure I understand your concerns here. I think the use case is
>>> where there is a need to group compositions by some other higher level
>>> construct which usually reflect something like an admission, episode of
>>> outpatient care or perhaps a community plan of care.
>>>
>>> As Dileep has indicated he probably would use folders if Ethercis
>>> supported them. Another alternative is to create an Encounter ID for each
>>> new encounter (which in Dileep's example, I think I would call an episode
>>> of care, and simply tag each composition with that Encounter ID e.g create
>>> a cluster archetype to hold this in every Composition/ other_context. I
>>> have done that on other projects. So it is a case of looking of all
>>> composition with EncounterId = x
>>> Now I would probably go down the Folder route, if I could.
>>> Ian
>>> Dr Ian McNicoll
>>> mobile +44 (0)775 209 7859
>>> office +44 (0)1536 414994
>>> skype: ianmcnicoll
>>> email: i...@freshehr.com
>>> twitter: @ianmcnicoll
>>>
>>>
>>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>>> Director, freshEHR Clinical Informatics Ltd.
>>> Director, HANDIHealth CIC
>>> Hon. Senior Research Associate, CHIME, UCL
>>>
>>>
>>> On Fri, 17 Aug 2018 at 13:59, Seref Arikan >> kurumsalteknoloji.com> wrote:
>>>
>>>> I'm used to thinking compositions as semantcally self contained units
>>>> of information, at the very least using references to other means of
>>>> expressing semantics (as in terminologies)
>>>>
>>>> What you're describing seems to take some clincal semantics out of the
>>>> composion and if we have multiple ways of doing that, it may hurt
>>>> reusability of queries and data.
>>>>
>>>> Do you think we can find a way of expressing this semantcs without
>>>> losing its trace within the cmposition?
>>>>
>>>> (Sorry for the typos, on the phone..)
>>>>
>>>> On Friday, August 17, 2018, Thomas Beale 
>>>> wrote:
>>>>
>>>>> There is a bigger

Re: AQL on specific list of compositions

[Seref Arikan]

Hi Ian,

When the fact that the Composition is associated to an encounter or episode
of care is recorded by including a reference to that composition in a
folder, some clinical context/information related to that composition is
now stored outside the composition, by means of a refence in a folder

Unless I'm missing an Aql feature that can help, you can no longer select
those compositions via Aql (since Aql does not support/specify how to
resolve refs)

If you follow the encounter id approach you mentioned, then you could use
Aql.

In fact, if Ethercis had support for Folder, Dileep would still not be able
to get those compositions with a singl query: he'd need to fetchs uids from
a folder with one query, then perform a second query to get compositions in
the way I suggested.

I'm probably being unnecessarily picky here, just pointing at the
difference between approaches and trying to put my finger on any downstream
issues. I'm not doing a great job of it though :)

On Friday, August 17, 2018, Ian McNicoll  wrote:

> Hi Seref,
>
> I'm not sure I understand your concerns here. I think the use case is
> where there is a need to group compositions by some other higher level
> construct which usually reflect something like an admission, episode of
> outpatient care or perhaps a community plan of care.
>
> As Dileep has indicated he probably would use folders if Ethercis
> supported them. Another alternative is to create an Encounter ID for each
> new encounter (which in Dileep's example, I think I would call an episode
> of care, and simply tag each composition with that Encounter ID e.g create
> a cluster archetype to hold this in every Composition/ other_context. I
> have done that on other projects. So it is a case of looking of all
> composition with EncounterId = x
> Now I would probably go down the Folder route, if I could.
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Fri, 17 Aug 2018 at 13:59, Seref Arikan  kurumsalteknoloji.com> wrote:
>
>> I'm used to thinking compositions as semantcally self contained units of
>> information, at the very least using references to other means of
>> expressing semantics (as in terminologies)
>>
>> What you're describing seems to take some clincal semantics out of the
>> composion and if we have multiple ways of doing that, it may hurt
>> reusability of queries and data.
>>
>> Do you think we can find a way of expressing this semantcs without losing
>> its trace within the cmposition?
>>
>> (Sorry for the typos, on the phone..)
>>
>> On Friday, August 17, 2018, Thomas Beale 
>> wrote:
>>
>>> There is a bigger question of how best to model 'encounter' and
>>> 'admission', which some implementers are doing with Folders, particularly
>>> DIPS in Norway. I suspect that some version of using Folders (or else some
>>> kind of tagging, which is semantically equivalent) will be the long term
>>> approach to doing this.
>>>
>>> - thomas
>>>
>>> On 17/08/2018 10:54, Dileep V S wrote:
>>>
>>> Hi,
>>>
>>> Can you write an AQL to query only on a list of specific compositions?
>>> Is there any sample for reference?
>>>
>>> I am trying to create the concept of clinical encounters and maintain a
>>> collection of compositions per encounter. I am using AQL to retrieve data
>>> per encounter and need to pass the corresponding set of compositions.
>>>
>>> Thanks in advance
>>>
>>> regards
>>>
>>>
>>> --
>>> 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
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Seref Arikan]

I'm used to thinking compositions as semantcally self contained units of
information, at the very least using references to other means of
expressing semantics (as in terminologies)

What you're describing seems to take some clincal semantics out of the
composion and if we have multiple ways of doing that, it may hurt
reusability of queries and data.

Do you think we can find a way of expressing this semantcs without losing
its trace within the cmposition?

(Sorry for the typos, on the phone..)

On Friday, August 17, 2018, Thomas Beale  wrote:

> There is a bigger question of how best to model 'encounter' and
> 'admission', which some implementers are doing with Folders, particularly
> DIPS in Norway. I suspect that some version of using Folders (or else some
> kind of tagging, which is semantically equivalent) will be the long term
> approach to doing this.
>
> - thomas
>
> On 17/08/2018 10:54, Dileep V S wrote:
>
> Hi,
>
> Can you write an AQL to query only on a list of specific compositions? Is
> there any sample for reference?
>
> I am trying to create the concept of clinical encounters and maintain a
> collection of compositions per encounter. I am using AQL to retrieve data
> per encounter and need to pass the corresponding set of compositions.
>
> Thanks in advance
>
> regards
>
>
> --
> 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-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Seref Arikan]

Modifying Ian's example for a/uid/value and using uid values instead of
names should do the trick

On Friday, August 17, 2018, Dileep V S  wrote:

> Thanks Ian,
>
> However my requirement is different. I seem to have confused you with the
> way my question was framed.
>
> What I meant by composition ID was in fact Composition UID. I want to
> query the same template (/name/value), but limited to specific commits
> (compositionUIDs).
>
> I hope that helps
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Fri, Aug 17, 2018 at 3:54 PM, Ian McNicoll  wrote:
>
>> Hi Dileep,
>>
>> I do this by querying on the name attribute of the root composition
>> archetype - see the examples in
>>
>> https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs
>> /bindings/Current%20Ripple%20Headings/Clinical%20notes/clinical_notes.md
>>
>> You can of course query on multiple names.
>>
>> where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}
>>
>> Going forward I would expect the list of allowable composition names to
>> come from a controlled vocabulary or even a local terminology.
>>
>> Ian
>>
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:
>>
>>> Hi,
>>>
>>> Can you write an AQL to query only on a list of specific compositions?
>>> Is there any sample for reference?
>>>
>>> I am trying to create the concept of clinical encounters and maintain a
>>> collection of compositions per encounter. I am using AQL to retrieve data
>>> per encounter and need to pass the corresponding set of compositions.
>>>
>>> Thanks in advance
>>>
>>> regards
>>>
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: healthelife.in  e: dil...@healthelife.in
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SMART on FHIR integration

[Seref Arikan]

It just occurred to me that I unintentionally made a suggestion for
implementing this at the app level using openEHR: match the actor to an ehr
within an "app defined context", wrap current APIs with overloaded versions
that require an app defined context and call the standard apis if the
context is unique etc etc.

On Tue, Apr 24, 2018 at 9:50 AM, Seref Arikan <serefari...@gmail.com> wrote:

> Thanks Tom,
>
> Based on your description, this sounds like something that is completely
> an app level concern for an openEHR based application. I mean, all
> operations on clinical data need an EHR context, the APIs don't let data
> written to the wrong EHR unless well, you provide the wrong EHR identifier
> :) Can't see how this needs safeguarding at the spec/platform level other
> than having the correct semantics in place, which as far as I can see,
> openEHR does.
>
> I guess (from a specification point of view) a naive implementation could
> match an Actor to an EHR within a context (which is the bit we don't have
> in RM to cover this use case I guess) and require the context identifier
> for operations on data to enforce what you're describing but that'd be
> creating a lot of complexity for a potential problem that could be solved
> much easier at the app level.
>
>
>
> On Tue, Apr 24, 2018 at 9:38 AM, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>> He is talking about user context, known as CCOW in HL7, which is to do
>> with solving the problem of ensuring a user with possibly multiple patients
>> open in applications doesn't mix them up. Especially important if the
>> application is meant to stay open while focussing on different patients
>> (i.e. not continuously opening and closing). Some solutions to this do
>> tricks on the screen such as locking / greying out applications not
>> connected to the 'current patient'.
>>
>> The data of this kind of context is all in openEHR (probably the one
>> standard that actually has it), but you still have to design applications
>> to use it in a smart way, or else you'll have a screen with 10 windows open
>> and they'll be connected to 3 different patients.
>>
>> Another way to think about this kind of idea is that you don't just log
>> into a system, but also to a patient (context).
>>
>> - thomas
>>
>> On 24/04/2018 09:05, Seref Arikan wrote:
>>
>> Thanks, would you say then, this definition of context sounds similar to
>> the electronic health record concept openEHR is built on?
>>
>> As in, providing a core EHR concept
>> <http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_ehr_package>
>> exposed by APIs?
>>
>> If you have an application without this concept or based on an organic
>> implementation of this concept, then SMART would make sense.
>>
>> I cannot see the use for it when using openEHR, based on your definition
>> of its real value, since there is no diverging or non-existent context
>> here.
>> I think SMART would help in scenarios where you must mimic a platform on
>> top of a number of black boxes, which is not the case with openEHR. This
>> also sound like the answer to Brian's question, thanks to your kind
>> response.
>>
>> I'll leave it to others (who know SMART and openEHR) to compare the depth
>> and robustness of context provided by SMART with openEHR's EHR model.
>>
>> All the best
>> Seref
>>
>>
>> On Tue, Apr 24, 2018 at 8:48 AM, <michael.law...@csiro.au> wrote:
>>
>>> Broadly, the context is the current patient being looked at in the EMR,
>>> or other platform being used to launch the SMART App.
>>>
>>> This allows the app to request authorisation for data specific to the
>>> 'current patient' and then launch directly into the task.
>>>
>>> Michael
>>>
>>> Sent from my iPhone
>>>
>>> On 24 Apr 2018, at 5:23 pm, Seref Arikan <serefarikan@kurumsalteknoloji
>>> .com> wrote:
>>>
>>> Could you explain what you mean by context please?
>>>
>>> On Tue, Apr 24, 2018 at 1:23 AM, <michael.law...@csiro.au> wrote:
>>>
>>>>
>>>> The real value of SMART (whether its "on FHIR" or not) is that it sets
>>>> a mechanism for EMRs to pass context to external apps.  This means apps are
>>>> re-usable across different back ends.
>>>>
>>>>
>>>> Note that this is not really about authentication (SSO) but rather it
>>>> is about authorisation.
>>>>
>>>>
>>>> 

Re: SMART on FHIR integration

[Seref Arikan]

Thanks Tom,

Based on your description, this sounds like something that is completely an
app level concern for an openEHR based application. I mean, all operations
on clinical data need an EHR context, the APIs don't let data written to
the wrong EHR unless well, you provide the wrong EHR identifier :) Can't
see how this needs safeguarding at the spec/platform level other than
having the correct semantics in place, which as far as I can see, openEHR
does.

I guess (from a specification point of view) a naive implementation could
match an Actor to an EHR within a context (which is the bit we don't have
in RM to cover this use case I guess) and require the context identifier
for operations on data to enforce what you're describing but that'd be
creating a lot of complexity for a potential problem that could be solved
much easier at the app level.

On Tue, Apr 24, 2018 at 9:38 AM, Thomas Beale <thomas.be...@openehr.org>
wrote:

> He is talking about user context, known as CCOW in HL7, which is to do
> with solving the problem of ensuring a user with possibly multiple patients
> open in applications doesn't mix them up. Especially important if the
> application is meant to stay open while focussing on different patients
> (i.e. not continuously opening and closing). Some solutions to this do
> tricks on the screen such as locking / greying out applications not
> connected to the 'current patient'.
>
> The data of this kind of context is all in openEHR (probably the one
> standard that actually has it), but you still have to design applications
> to use it in a smart way, or else you'll have a screen with 10 windows open
> and they'll be connected to 3 different patients.
>
> Another way to think about this kind of idea is that you don't just log
> into a system, but also to a patient (context).
>
> - thomas
>
> On 24/04/2018 09:05, Seref Arikan wrote:
>
> Thanks, would you say then, this definition of context sounds similar to
> the electronic health record concept openEHR is built on?
>
> As in, providing a core EHR concept
> <http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_ehr_package>
> exposed by APIs?
>
> If you have an application without this concept or based on an organic
> implementation of this concept, then SMART would make sense.
>
> I cannot see the use for it when using openEHR, based on your definition
> of its real value, since there is no diverging or non-existent context
> here.
> I think SMART would help in scenarios where you must mimic a platform on
> top of a number of black boxes, which is not the case with openEHR. This
> also sound like the answer to Brian's question, thanks to your kind
> response.
>
> I'll leave it to others (who know SMART and openEHR) to compare the depth
> and robustness of context provided by SMART with openEHR's EHR model.
>
> All the best
> Seref
>
>
> On Tue, Apr 24, 2018 at 8:48 AM, <michael.law...@csiro.au> wrote:
>
>> Broadly, the context is the current patient being looked at in the EMR,
>> or other platform being used to launch the SMART App.
>>
>> This allows the app to request authorisation for data specific to the
>> 'current patient' and then launch directly into the task.
>>
>> Michael
>>
>> Sent from my iPhone
>>
>> On 24 Apr 2018, at 5:23 pm, Seref Arikan <serefarikan@kurumsalteknoloji
>> .com> wrote:
>>
>> Could you explain what you mean by context please?
>>
>> On Tue, Apr 24, 2018 at 1:23 AM, <michael.law...@csiro.au> wrote:
>>
>>>
>>> The real value of SMART (whether its "on FHIR" or not) is that it sets a
>>> mechanism for EMRs to pass context to external apps.  This means apps are
>>> re-usable across different back ends.
>>>
>>>
>>> Note that this is not really about authentication (SSO) but rather it is
>>> about authorisation.
>>>
>>>
>>> michael
>>>
>>>
>>> --
>>> Dr Michael Lawley
>>> Research Group Leader, Health Informatics
>>> The Australia e-Health Research Centre http://aehrc.com/
>>> work: +61 7 3253 3609; mob: +61 427 456 260
>>> --
>>> *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org>
>>> on behalf of Pablo Pazos <pablo.pa...@cabolabs.com>
>>> *Sent:* Tuesday, 24 April 2018 9:29 AM
>>> *To:* For openEHR technical discussions
>>> *Subject:* Re: SMART on FHIR integration
>>>
>>> SSO is a front end feature, that is not on the current scope of the
>>> openEHR specs.
>>>
>>> I think any openEHR implementer can do SSO at the fr

Re: SMART on FHIR integration

[Seref Arikan]

Thanks, would you say then, this definition of context sounds similar to
the electronic health record concept openEHR is built on?

As in, providing a core EHR concept
<http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_ehr_package>
exposed by APIs?

If you have an application without this concept or based on an organic
implementation of this concept, then SMART would make sense.

I cannot see the use for it when using openEHR, based on your definition of
its real value, since there is no diverging or non-existent context here.
I think SMART would help in scenarios where you must mimic a platform on
top of a number of black boxes, which is not the case with openEHR. This
also sound like the answer to Brian's question, thanks to your kind
response.

I'll leave it to others (who know SMART and openEHR) to compare the depth
and robustness of context provided by SMART with openEHR's EHR model.

All the best
Seref


On Tue, Apr 24, 2018 at 8:48 AM, <michael.law...@csiro.au> wrote:

> Broadly, the context is the current patient being looked at in the EMR, or
> other platform being used to launch the SMART App.
>
> This allows the app to request authorisation for data specific to the
> 'current patient' and then launch directly into the task.
>
> Michael
>
> Sent from my iPhone
>
> On 24 Apr 2018, at 5:23 pm, Seref Arikan <serefarikan@
> kurumsalteknoloji.com> wrote:
>
> Could you explain what you mean by context please?
>
> On Tue, Apr 24, 2018 at 1:23 AM, <michael.law...@csiro.au> wrote:
>
>>
>> The real value of SMART (whether its "on FHIR" or not) is that it sets a
>> mechanism for EMRs to pass context to external apps.  This means apps are
>> re-usable across different back ends.
>>
>>
>> Note that this is not really about authentication (SSO) but rather it is
>> about authorisation.
>>
>>
>> michael
>>
>>
>> --
>> Dr Michael Lawley
>> Research Group Leader, Health Informatics
>> The Australia e-Health Research Centre http://aehrc.com/
>> work: +61 7 3253 3609; mob: +61 427 456 260
>> --
>> *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org>
>> on behalf of Pablo Pazos <pablo.pa...@cabolabs.com>
>> *Sent:* Tuesday, 24 April 2018 9:29 AM
>> *To:* For openEHR technical discussions
>> *Subject:* Re: SMART on FHIR integration
>>
>> SSO is a front end feature, that is not on the current scope of the
>> openEHR specs.
>>
>> I think any openEHR implementer can do SSO at the front-end app level to
>> access SMART apps.
>>
>> On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz <br...@nantz.org> wrote:
>>
>>> I see you have had discussions on FHIR and SMART on FHIR.  Is it on the
>>> roadmap for openEHR to support SMART on FHIR launch sequence (
>>> http://docs.smarthealthit.org/authorization/) for single sign on?  I
>>> know many customers who would like this seemless integration.
>>>
>>> ___
>>> openEHR-technical mailing list
>>> 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
>> +598 99 043 145
>> skype: cabolabs
>> <http://cabolabs.com/>
>> http://www.cabolabs.com
>> https://cloudehrserver.com
>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SMART on FHIR integration

[Seref Arikan]

Could you explain what you mean by context please?

On Tue, Apr 24, 2018 at 1:23 AM,  wrote:

>
> The real value of SMART (whether its "on FHIR" or not) is that it sets a
> mechanism for EMRs to pass context to external apps.  This means apps are
> re-usable across different back ends.
>
>
> Note that this is not really about authentication (SSO) but rather it is
> about authorisation.
>
>
> michael
>
>
> --
> Dr Michael Lawley
> Research Group Leader, Health Informatics
> The Australia e-Health Research Centre http://aehrc.com/
> work: +61 7 3253 3609; mob: +61 427 456 260
> --
> *From:* openEHR-technical 
> on behalf of Pablo Pazos 
> *Sent:* Tuesday, 24 April 2018 9:29 AM
> *To:* For openEHR technical discussions
> *Subject:* Re: SMART on FHIR integration
>
> SSO is a front end feature, that is not on the current scope of the
> openEHR specs.
>
> I think any openEHR implementer can do SSO at the front-end app level to
> access SMART apps.
>
> On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz  wrote:
>
>> I see you have had discussions on FHIR and SMART on FHIR.  Is it on the
>> roadmap for openEHR to support SMART on FHIR launch sequence (
>> http://docs.smarthealthit.org/authorization/) for single sign on?  I
>> know many customers who would like this seemless integration.
>>
>> ___
>> openEHR-technical mailing list
>> 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
> +598 99 043 145
> skype: cabolabs
> 
> 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: SV: [Troll] Terminology bindings ... again

[Seref Arikan]

Hi Philippe,
See inline please

On Friday, March 30, 2018, Philippe Ameline 
wrote:

> Le 28/03/2018 à 23:42, GF a écrit :
>
> I see the analogies:
> - Ontology = Encyclopedia
> - Terminology = Dictionary
> - Archetype = Phrase
>
>
> Hi Gerard,
>
> I would rather see Archetypes as "discourse models" that form a mold for
> sentences or groups of sentences. The Phrase, in you enumeration, would
> rather be the instantiated information (stored in database).
>
> If you are curious about the way a tree of concept can be homogeneous to a
> sentence, Google "dependency grammar".
>
> This has been my main topic for 30 years in the report generation domain,
> and I can say that "simply ordering information on a form" and "trying to
> tell something using a structured vocabulary" are much different tasks.
> Typically, the first approach concentrates on the leaves while the other
> makes certain that branches give the proper meaning to the leaves.
>
You nailed it here. My approach to openEhr based data warehouse design has
been taking the leaf nodes of compositions as facts and paths to them as
dimensions.
The design of RM fits this view really well.

It is a bit of an irony that strongest focus on openEhr adoption is on the
data creation step, i.e. clinical care and its potential for secondary use
rarely gets attention

>
>
> Best,
>
> Philippe
>
> Y
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[Seref Arikan]

Hi Tom,

On Thu, Mar 1, 2018 at 2:33 PM, Thomas Beale <thomas.be...@openehr.org>
wrote:

>
> On 01/03/2018 11:05, Seref Arikan wrote:
>
>> Hi Diego,
>>
>> I'd like to hear how you'd address the requirement via a call to an
>> external service.
>>
>>
> I don't think it should be that complicated - after all, a call out to a
> terminology service is already a call out to a service; terminology is just
> one kind of reference knowledge that a query language / engine needs to get
> at; we can assume that a units service (as Bert and others were discussing
> earlier), lab results reference ranges, drug DB and so on may all be needed
> by the query service.
>

In case I gave the wrong impression: my question above was not meant to
sound like I thought this would be a difficult thing. Reading it again, I
can see that it may be interpreted as 'I'd like to see you try', which was
not the intention. I genuinely wanted to  know how Diego would like to use
AQL to address this specific requirement.

>
> So I think it mainly comes down to the syntax and programming model of
> talking out to such interfaces. We might potentially assume that they are
> all based on a common ontology meta-model of some kind (e.g. based on BFO,
> RO, IAO etc) in which case a common underlying style could be established.


The way I see it, your suggestion may pave the way to the can of worms I
mentioned earlier, so I'll give up on my efforts to not to hijack this
thread :)

Re extending AQL for calls to external services: I'd be inclined to keep
the syntax in the scope of the AQL specification and leave the programming
model out of scope.

I think AQL needs to support procedural extensions as an umbrella concept,
which, then, can be used for a number of things, some of which may be calls
to external knowledge services.

There is a lot more than calling out to external terminology services that
can be accomplished with procedural extensions: they could turn AQL into
the ultimate clinical data query language, which is the upside.

But there is a downside as well: things may get complicated from a
standardisation point of view.  Once calls to external services become part
of syntax, AQL's vendor/implementation independent nature will be harder to
preserve, as vendors start doing useful and no doubt clever things with
calls to external services. Aql's behaviour is already slightly different
across vendors, so if vendor X implements a smart feature using an external
service and that service is available only in my vendor X's implementation,
behaviour interoperability provided by AQL would be damaged.

I think the upsides are worth adding this support but downsides will need
careful management, probably based on profiles/levels etc.

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

Re: Setting thresholds

[Seref Arikan]

Hi Diego,

I'd like to hear how you'd address the requirement via a call to an
external service.

I've been holding back on the recent external service calls discussions :)
there is certainly a need for that but it also has the potential to open a
can of worms and I'd better no hijack this thread ;)

On Thu, Mar 1, 2018 at 11:01 AM, Diego Boscá <yamp...@gmail.com> wrote:

> I believe that we need a way in standard AQL to call to arbitrary external
> services, this seems like another use case for that
>
> El 1 mar. 2018 11:46 a. m., "Seref Arikan" <serefarikan@
> kurumsalteknoloji.com> escribió:
>
>> Hi Colin,
>> See responses inline please
>>
>> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <
>> colin.sut...@ctc.usyd.edu.au> wrote:
>>
>>>
>>>
>>> On 1 Mar 2018, at 1:59 am, Seref Arikan <serefarikan@kurumsalteknoloji
>>> .com> wrote:
>>>
>>> […]
>>>
>>>>
>>>>
>>>> First: if the threshold is changing with respect to all instances of a
>>>> particular composition (template_id = 'x') , when the change happens, would
>>>> not you have to update reference ranges of the DV_QUANTITY node in all
>>>> composition instances across all EHRs to express the new threshold? That
>>>> is, if you define high systolic blood pressure using a reference value,
>>>> would not you have to update all blood pressure observations when the
>>>> accepted 'high' value (threshold) changes?
>>>>
>>>> Second: Setting the reference value to express a threshold would make
>>>> it impossible to query above/below threshold sets of composition via AQL
>>>> because it'd require a query that uses the WHERE clause as follows:
>>>> " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
>>>> (excuse the mock paths) which, as far as I know is not supported by AQL at
>>>> the moment, not even grammar-wise (I may be out of date on this one)
>>>>
>>>> If you keep the reference value at the application level, all you have
>>>> to do is update it without having to touch the existing instances and use
>>>> AQL to select above/below threshold since you can plug the threshold value
>>>> directly into WHER
>>>>
>>>> […]
>>>>
>>>  In a clinical trial, the protocol may set thresholds for measurements
>>> in one version of the protocol, then change the thresholds in a subsequent
>>> version of the protocol. Since a decision may be based on a threshold
>>> level, the threshold value needs to be retained along with the measurement
>>> for each instance under each protocol. So I think you need a new template
>>> for each protocol.
>>>
>> Yep, a new template for each protocol would be what I'd consider, as I
>> mentioned in another reply. Based on the information I heard so far
>> regarding the requirements and the specific example you provided here, I'd
>> consider associating thresholds with the identifier+version of the template
>> for the protocol: can you see any problems with this in the context of your
>> specific example?
>>
>>>
>>> An AQL query on the threshold level will therefore need to have a unique
>>> name for each threshold ( not a value of the threshold) in order to
>>> retrieve the value used across protocols in the decision, for a simple case
>>> where the decision algorithm does not change.
>>>
>> Such an AQL query would give you the value used for the protocols indeed
>> (though I don't think you'd need a name, why not use the same path across
>> different versions of protocol templates?) . You could then use those
>> values to issue queries to select above/below threshold instances of data.
>> This would be a workaround for the AQL problem I mentioned in my second
>> point above.
>>
>>> —
>>> Colin
>>> --
>>>
>>> Scanned by *Trustwave SEG* - Trustwave's comprehensive email content
>>> security solution.
>>>
>>> --
>>> IMPORTANT NOTICE: This e-mail and any attachment to it are intended
>>> only to be read or used by the named addressee. It is confidential and may
>>> contain legally privileged information. No confidentiality or privilege is
>>> waived or lost by any mistaken transmission to you. The CTC is not
>>> responsible for any unauthorised alterations to this e-mail or attachment
>>

Re: Setting thresholds

[Seref Arikan]

Hi Colin,
See responses inline please

On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <colin.sut...@ctc.usyd.edu.au>
wrote:

>
>
> On 1 Mar 2018, at 1:59 am, Seref Arikan <serefari...@kurumsalteknoloji.com>
> wrote:
>
> […]
>
>>
>>
>> First: if the threshold is changing with respect to all instances of a
>> particular composition (template_id = 'x') , when the change happens, would
>> not you have to update reference ranges of the DV_QUANTITY node in all
>> composition instances across all EHRs to express the new threshold? That
>> is, if you define high systolic blood pressure using a reference value,
>> would not you have to update all blood pressure observations when the
>> accepted 'high' value (threshold) changes?
>>
>> Second: Setting the reference value to express a threshold would make it
>> impossible to query above/below threshold sets of composition via AQL
>> because it'd require a query that uses the WHERE clause as follows:
>> " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
>> (excuse the mock paths) which, as far as I know is not supported by AQL at
>> the moment, not even grammar-wise (I may be out of date on this one)
>>
>> If you keep the reference value at the application level, all you have to
>> do is update it without having to touch the existing instances and use AQL
>> to select above/below threshold since you can plug the threshold value
>> directly into WHER
>>
>> […]
>>
>  In a clinical trial, the protocol may set thresholds for measurements in
> one version of the protocol, then change the thresholds in a subsequent
> version of the protocol. Since a decision may be based on a threshold
> level, the threshold value needs to be retained along with the measurement
> for each instance under each protocol. So I think you need a new template
> for each protocol.
>
Yep, a new template for each protocol would be what I'd consider, as I
mentioned in another reply. Based on the information I heard so far
regarding the requirements and the specific example you provided here, I'd
consider associating thresholds with the identifier+version of the template
for the protocol: can you see any problems with this in the context of your
specific example?

>
> An AQL query on the threshold level will therefore need to have a unique
> name for each threshold ( not a value of the threshold) in order to
> retrieve the value used across protocols in the decision, for a simple case
> where the decision algorithm does not change.
>
Such an AQL query would give you the value used for the protocols indeed
(though I don't think you'd need a name, why not use the same path across
different versions of protocol templates?) . You could then use those
values to issue queries to select above/below threshold instances of data.
This would be a workaround for the AQL problem I mentioned in my second
point above.

> —
> Colin
> --
>
> Scanned by *Trustwave SEG* - Trustwave's comprehensive email content
> security solution.
>
> --
> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
> to be read or used by the named addressee. It is confidential and may
> contain legally privileged information. No confidentiality or privilege is
> waived or lost by any mistaken transmission to you. The CTC is not
> responsible for any unauthorised alterations to this e-mail or attachment
> to it. Views expressed in this message are those of the individual sender,
> and are not necessarily the views of the CTC. If you receive this e-mail in
> error, please immediately delete it and notify the sender. You must not
> disclose, copy or use any part of this e-mail if you are not the intended
> recipient.
> --
>
> ___
> 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: Setting thresholds

[Seref Arikan]

On Wed, Feb 28, 2018 at 2:35 PM, GF <gf...@luna.nl> wrote:

>
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 28 Feb 2018, at 14:42, Seref Arikan <serefari...@kurumsalteknoloji.com>
> wrote:
>
> Hi Tom,
>
> The original question is talking about 'threshold's changing in time.
> Would not using reference ranges may make things complicated during
> implementation with the changing threshold requirement?
>
>
> Not when the complete context/epistemology- and thus the actual range-  is
> stored next to the data value.
> What is the complexity?
>
>
 I just explained the complexity in the next two items. Neither your
generic and context independent "not when.."  statement nor your question
makes sense to me, in response to a specific points I made. Care to expand
on your claim in the context of the points I made below?

>
>
>
> First: if the threshold is changing with respect to all instances of a
> particular composition (template_id = 'x') , when the change happens, would
> not you have to update reference ranges of the DV_QUANTITY node in all
> composition instances across all EHRs to express the new threshold? That
> is, if you define high systolic blood pressure using a reference value,
> would not you have to update all blood pressure observations when the
> accepted 'high' value (threshold) changes?
>
> Second: Setting the reference value to express a threshold would make it
> impossible to query above/below threshold sets of composition via AQL
> because it'd require a query that uses the WHERE clause as follows:
> " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
> (excuse the mock paths) which, as far as I know is not supported by AQL at
> the moment, not even grammar-wise (I may be out of date on this one)
>
> If you keep the reference value at the application level, all you have to
> do is update it without having to touch the existing instances and use AQL
> to select above/below threshold since you can plug the threshold value
> directly into WHER
>
>
> Leaving epistemological information in the application is. creating
> problems because ranges change overtime and are true in one geo- and
> temporal context only.
>

So? Does this mean what I've written above is incorrect? In what way is it
a response to the points I made? You can keep track of changing reference
ranges by simply associating the range with the template identifier would
give you the exact same information with keeping reference ranges in actual
data instances. If the same reference range does not apply to all instances
of template V1 then it means you can't have a single threshold in the first
place. If you have the same threshold for all instances of template V1 then
why repeat it instead of associating it with the template identifier +
version? Except the case when you'd like to share the data with another
system and you'd like to make sure the reference range is carried over to
that system.
Please expand on your claims based on specific cases, at least in response
to the point I made in the few lines above this one


>
>
> You'd have to
>
>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[Seref Arikan]

Sorry, sent the last email accidentally before it was finished. Here is the
end bit:

...  use AQL to select above/below threshold since you can plug the
threshold value directly into WHERE clause

So I'm not sure if reference ranges would help here. Happy to be educated
if I missing something here :)

All the best
Seref



On Wed, Feb 28, 2018 at 1:42 PM, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Hi Tom,
>
> The original question is talking about 'threshold's changing in time.
> Would not using reference ranges may make things complicated during
> implementation with the changing threshold requirement?
>
> First: if the threshold is changing with respect to all instances of a
> particular composition (template_id = 'x') , when the change happens, would
> not you have to update reference ranges of the DV_QUANTITY node in all
> composition instances across all EHRs to express the new threshold? That
> is, if you define high systolic blood pressure using a reference value,
> would not you have to update all blood pressure observations when the
> accepted 'high' value (threshold) changes?
>
> Second: Setting the reference value to express a threshold would make it
> impossible to query above/below threshold sets of composition via AQL
> because it'd require a query that uses the WHERE clause as follows:
> " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
> (excuse the mock paths) which, as far as I know is not supported by AQL at
> the moment, not even grammar-wise (I may be out of date on this one)
>
> If you keep the reference value at the application level, all you have to
> do is update it without having to touch the existing instances and use AQL
> to select above/below threshold since you can plug the threshold value
> directly into WHER
>
> You'd have to
>
> On Wed, Feb 28, 2018 at 1:17 PM, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>> Although Jussara is right in terms of reference ranges generally, i.e.
>> what you see in a pathology handbook as ref ranges for male / female /
>> child for say Total Cholesterol or some other analyte, the openEHR
>> Reference Model does allow reference ranges to be carried in DV_QUANTITY (see
>> here on the UML site
>> <https://www.openehr.org/releases/trunk/UML/#Diagrams___18_1_83e026d_1433773263789_448306_5573>-
>> DV_ORDERED.normal_range and other_reference_ranges). We do this for the
>> same reasons Karsten explicates below.
>>
>> The idea is that the normal range (and other ranges) *specific to the
>> patient type for the current test order* (sex, age, sometimes 'race',
>> e.g. African American cholesterol normal range is +10%) can be written into
>> the data. So, say the patient is a 64 yo female caucasian, and the analyte
>> is 'total cholesterol'. The ref range will be (something like):
>>
>>- normal range: 159-276 mg/dL or in SI, 4.12-7.15 mmol/L
>>
>> that is just one row from a table of normal ranges keyed by sex, age and
>> with the modifier for African Americans (I have a US path manual, probably
>> it is just 'African' elsewhere).
>>
>> The reference range data is often influenced by other factors depending
>> on what it is, e.g. location, diet, and so on.
>>
>> The point is, that the path lab can help the doc by including the
>> relevant normal range with the measured value, and therefore also generate
>> an 'abnormal' indicator in the result. This is a significant time-saver for
>> doctors, and it also has the effect of writing into the EHR the reference
>> range that was actually used to decide that the patient was abnormal for
>> that analyte and to intervene - i.e. it's the reference knowledge for the
>> assessment.
>>
>> - thomas
>>
>> On 28/02/2018 12:43, Karsten Hilbert wrote:
>>
>> On Wed, Feb 28, 2018 at 12:18:24PM +, Jussara Macedo Rötzsch wrote:
>>
>>
>> Ranges  aren’t actually part   of the Information model, they are rules for
>> decision support, and therefore belong to the Application level, like a gdl
>> based CDS
>>
>> In practice there are still needs to store ranges (with the data):
>>
>> 1) path labs will attach ranges to recommended interpretations
>>
>>  those are best stored "with" the result(-interpretation)
>>
>>  and, no, it is not sufficient to attach them to the test
>>  *type* of a measurement
>>
>> 2) ranges applied by a clinician upon which a conclusion
>>has been made
>>
>>  those will often end up as textual part of a SOAP note
>>
>> Think of a patient with warfarin 

Re: Setting thresholds

[Seref Arikan]

Hi Tom,

The original question is talking about 'threshold's changing in time. Would
not using reference ranges may make things complicated during
implementation with the changing threshold requirement?

First: if the threshold is changing with respect to all instances of a
particular composition (template_id = 'x') , when the change happens, would
not you have to update reference ranges of the DV_QUANTITY node in all
composition instances across all EHRs to express the new threshold? That
is, if you define high systolic blood pressure using a reference value,
would not you have to update all blood pressure observations when the
accepted 'high' value (threshold) changes?

Second: Setting the reference value to express a threshold would make it
impossible to query above/below threshold sets of composition via AQL
because it'd require a query that uses the WHERE clause as follows:
" WHERE some/path/node1.value > /some/path/node1.reference_range.value"
(excuse the mock paths) which, as far as I know is not supported by AQL at
the moment, not even grammar-wise (I may be out of date on this one)

If you keep the reference value at the application level, all you have to
do is update it without having to touch the existing instances and use AQL
to select above/below threshold since you can plug the threshold value
directly into WHER

You'd have to

On Wed, Feb 28, 2018 at 1:17 PM, Thomas Beale 
wrote:

> Although Jussara is right in terms of reference ranges generally, i.e.
> what you see in a pathology handbook as ref ranges for male / female /
> child for say Total Cholesterol or some other analyte, the openEHR
> Reference Model does allow reference ranges to be carried in DV_QUANTITY (see
> here on the UML site
> -
> DV_ORDERED.normal_range and other_reference_ranges). We do this for the
> same reasons Karsten explicates below.
>
> The idea is that the normal range (and other ranges) *specific to the
> patient type for the current test order* (sex, age, sometimes 'race',
> e.g. African American cholesterol normal range is +10%) can be written into
> the data. So, say the patient is a 64 yo female caucasian, and the analyte
> is 'total cholesterol'. The ref range will be (something like):
>
>- normal range: 159-276 mg/dL or in SI, 4.12-7.15 mmol/L
>
> that is just one row from a table of normal ranges keyed by sex, age and
> with the modifier for African Americans (I have a US path manual, probably
> it is just 'African' elsewhere).
>
> The reference range data is often influenced by other factors depending on
> what it is, e.g. location, diet, and so on.
>
> The point is, that the path lab can help the doc by including the relevant
> normal range with the measured value, and therefore also generate an
> 'abnormal' indicator in the result. This is a significant time-saver for
> doctors, and it also has the effect of writing into the EHR the reference
> range that was actually used to decide that the patient was abnormal for
> that analyte and to intervene - i.e. it's the reference knowledge for the
> assessment.
>
> - thomas
>
> On 28/02/2018 12:43, Karsten Hilbert wrote:
>
> On Wed, Feb 28, 2018 at 12:18:24PM +, Jussara Macedo Rötzsch wrote:
>
>
> Ranges  aren’t actually part   of the Information model, they are rules for
> decision support, and therefore belong to the Application level, like a gdl
> based CDS
>
> In practice there are still needs to store ranges (with the data):
>
> 1) path labs will attach ranges to recommended interpretations
>
>   those are best stored "with" the result(-interpretation)
>
>   and, no, it is not sufficient to attach them to the test
>   *type* of a measurement
>
> 2) ranges applied by a clinician upon which a conclusion
>has been made
>
>   those will often end up as textual part of a SOAP note
>
> Think of a patient with warfarin monitoring: The lab will cry
> foul (if not properly informed) but the clinician is happy
> when the INR is in the therapeutic range.
>
> GNUmed "solves" that by allowing to attach both a "nominal"
> and a "desired" range to each test result.
>
> For what that's worth.
>
> Karsten
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>
___
openEHR-technical 

Re: Setting thresholds

[Seref Arikan]

This sounds like something you should handle at the application level
rather than modeling level to me.

On Wed, Feb 28, 2018 at 11:48 AM, Jan-Marc Verlinden 
wrote:

> We are developing a completely openEHR based Personal Health Environment
> (PHR). For this we would like to show measured data in a graph containing
> "good" or "bad". Mostly one would see some traffic light system, our
> approach is different but comes to the same principle.
>
> So for this we need to set thresholds that also could be changed
> afterwards. In the most common BP archetype (and Template) no thresholds
> are defined, so at what level would we do that?
> --
>
> Regards, Jan-Marc
> Mobile: +31 6 53785650 <+31%206%2053785650>
> www.medrecord.io
>
> ___
> 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: Creating a terminology

[Seref Arikan]

Hi Matthew,

Great to hear from you. https://wiki.nci.nih.gov/display/lexevs/lexevs
worked for me back in 2009 or so, it is apparently still alive. maybe worth
taking a look at.

All the best
Seref


On Fri, Feb 23, 2018 at 11:18 AM, Darlison, Matthew 
wrote:

> Dear Charlie,
>
>
>
> That’s interesting, and not something I’d come across – many thanks!
>
>
>
> Is anyone aware of an open, freely available terminology service suite
> that could be used to experiment with what should be in a terminology in
> order to make it useful for various purposes..?
>
>
>
> Yours,
>
>
>
> Matthew
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Charles McCay
> *Sent:* 22 February 2018 15:42
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* Re: Creating a terminology
>
>
>
> HI Matthew
>
> You may be interested in HL7 InfoButton - which is a standard for linking
> clinical systems to knowledge bases -- it is a fairly simple and open REST
> interface -- allowing you to define the sorts of search parameters that you
> are expecting - and retuning the knowledge in a few possible formats.
>
> Whether this will work for you depends upon how you anticipate your
> knowledge being accessed - and whether the process will be triggered from
> within the EHR or from some other user interaction.
>
>
>
> I have not used it but it does not seem too tied to other HL7 standards,
> and so may also be of use and relevance in an OpenEHR context.  At the very
> least it will be an interesting example of folk trying to do something
> similar to you :)
>
> The following page looks like a good place to start ---
> http://www.openinfobutton.org/hl7-infobutton-standard
>
> all the best
>
> Charlie
>
>
> Charlie McCay, char...@ramseysystems.co.uk
> Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES
> tel +44 7808 570172 <+44%207808%20570172>  skype: charliemccay
> linkedin:charliemccay
>
>
>
> On 22 February 2018 at 13:57, Darlison, Matthew 
> wrote:
>
> Dear Diego,
>
>
>
> I don’t know precisely yet, but the problem space arises when, for
> example, a procedure is standardised (by a protocol or SOP), and thus has a
> set of agreed “allowed” outputs which one might need to record in the kind
> of way that would fit with mapping to a DV_CODED_TEXT from an archetype.
> When this goes finer-grained than any existing terminology (for example,
> when the basis is something like a locus-specific mutation database) there
> needs to be a way to create pick-lists etc. without embedding the logic
> inside an archetype.
>
>
>
> My current thinking is that the protocol/SOP maps to 1…* archetypes, but
> the knowledge needs not to be embedded there because it has broader uses.
>
>
>
> Does that make sense?
>
>
>
> Yours,
>
>
>
> Matthew
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Diego Boscá
> *Sent:* 22 February 2018 13:05
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* RE: Creating a terminology
>
>
>
> Matthew, what is the scope of your terminology? Are the terms intended to
> appear in data instances? If terms are intrinsic to a set of archetypes
> then you could probably define the terms as constraint bindings in each
> archetype.
>
>
>
> El 22 feb. 2018 1:44 p. m., "Darlison, Matthew" 
> escribió:
>
> Dear Gerard,
>
>
>
> Many thanks – that’s interesting as an expression of the terminology, but
> I’m guessing that was either generated from a machine-readable expression
> of the terminology, or would need such a machine-readable version to exist
> before it could be instantiated within a terminology server/service? I’m
> also interested to try that out, so that other software might be able to
> interrogate the resource…
>
>
>
> Yours,
>
>
>
> Matthew
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *GF
> *Sent:* 22 February 2018 12:23
> *To:* Thomas Beale 
> *Subject:* Re: Creating a terminology
>
>
>
> Dear Matthew,
>
>
>
> In the attachment a candidate terminology as PDF
>
>
>
> It is known as SIAMM
>
> Semantic Interpretabily Artefact Modelling method
>
>
> Gerard   Freriks
>
> +31 620347088 <+31%206%2020347088>
>   gf...@luna.nl
>
>
>
> Kattensingel  20
>
> 2801 CA Gouda
>
> the Netherlands
>
>
>
> On 22 Feb 2018, at 13:03, Darlison, Matthew  wrote:
>
>
>
> Dear All,
>
> I've been looking for some time for ways of injecting knowledge into the
> ecosystem so that it is available to an EHR, but also to other systems that
> might want to use it.
>
> I currently think I need to create a terminology (or maybe more than one),
> but I've found vanishingly few open tools and little guidance on what I
> could use to do this, and experiment to see if it does 

Re: openEHR REST APIs: any plans for Contribution semantics?

[Seref Arikan]

Apologies: I somehow managed to miss the Contribution resource at the
bottom of EHR API documentation.

On Fri, Feb 23, 2018 at 9:15 AM, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Greetings,
>
> I cannot see any resources that represent Contributions in the current
> REST API specs. Is this on the roadmap for REST API specifications?
>
> All the best
> Seref
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR REST APIs: any plans for Contribution semantics?

[Seref Arikan]

Greetings,

I cannot see any resources that represent Contributions in the current REST
API specs. Is this on the roadmap for REST API specifications?

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: openEHR REST APIs - Release 0.9.0 / invitation for comments

[Seref Arikan]

Hi Georg,
Please see comments inline

On Fri, Feb 16, 2018 at 5:21 PM, Georg Fette 
wrote:

> Hi Seref,
> Quite some discussion you already had on this topic last year. The
> examples are a bit hard to grasp because of their complexity in size.
> Although they are not really that extremely complex but perhaps the
> problems should be discussed with the least complex examples as possible.
>
I'd strongly suggest that you take an Xquery example from the repository I
created and simplify the query I've written. Focus on a small section of
the example data. Then extend the scope. I admit there is a learning curve
but both XQuery and Sparql examples would help you get the logic of AQL
query execution to a sufficient extend since they are mostly aligned with
AQL, at least in the context of examples in that repo

>
> I would think it more understandable if it were explicitely described in
> the API documentation that all result data is generally encoded in JSON
> (with a link/reference to the corresponding reference model page). But that
> wouldn't be sufficient. The description of the encoding concerns not only
> how a single element is encoded but even more how collections are encoded.
> Those collections are not ITEM_LISTs or any other part of the reference
> model of openEHR because they are formed at the moment the query is
> executed. When in the example from the API the "uid"-member of "c" is
> assumed to be of the type ITEM_LIST (or any other collection type) and the
> member "value" of "uid" were a primitive, the requested column
> "c/uid/value" represents a collections although the "value"s themselves are
> primitves. This can't be handled with a generic object-serialization
> mechanism. The only object containing all desired "value"s is the parent
> "c" object. This could be generically serialized, but it isn't requested in
> the query. So there has to be an iteration over all "value"s,which can
> themselves be serialized, but all their resulting JSON-Strings would have
> to be concatenated (externally from the serializing mechanisms) and written
> to the same result cell. Or, when no concatenation is desired, some
> solution with something like a Cartesian product would be needed.
>

Please correct me if I'm wrong but it sounds like you're speculating above
as to how AQL execution works. I'd say you mostly have it right but allow
me to clarify it a bit: there are not collections that are created during
query execution; you should not think about a single variable unless the
aql SELECT clause includes only one variable. The SELECT clause identifies
a number of elements from an object structure (assume that this is a
COMPOSITION instance).

If any of the identified elements of SELECT a,b,c match more than one data
item in the composition instance then the result set has to include all
combinations of matches. Assume that the composition has a1,b1,c1 AND c2.
In this case, the SELECT clause is describing a pattern like this
,, and we have a1,b1 and c1 and c2 which we can use define matches
for this pattern. So our result set would be:

a1,b1,c1
a1,b1,c2

Which is the latter case you're describing. It would not be a1,b1,[c1,c2]
where c1 and c2 are concatenated because *each row of the result set has to
express a match for the SELECT clause contents*. If you concatenate c1 and
c2 and return one row as the result set your result set would no longer
correctly represent a match for the structural and value constraints
expressed by the AQL query. Let me give you an example.

Imagine you want to get a list of allergies for patients using AQL *For
each patient there is only one instance of a COMPOSITION based on an
archetype and all allergies are added to this single instance*. So if you
want to select the composition uid and the allergy name data items you'd
use a SELECT statement like SELECT c/uid/value, alg/value . In this select
clause, alg is some ELEMENT with DV_TEXT value. Your result set would then
be something like:

uid| allergy_value|
1   | nut allergy|
1   | penicillin   |
2   | shellfish|

In the result set above, the composition with uid 1 belongs to patient A
and she/he has nut allergy and penicillin allergy. Patient B is allergic to
shellfish and her/his composition instance gives us this information.

Can you concatenate the allergy_value column values above? No! because then
you'd lose the relationshp between uid and allergy-value, or in more
pragmatic terms, you'd have no clue who has which allergy.

This is annoying, but necessary because it preserves query semantics and
data integrity for result sets. So it is the application developer's task
to take that result set and process it so that the fact that nut allergy
and penicillin are under the same composition is somehow used.

*Most users of AQL are actually (implicitly) asking for a feature that
allows them to retrieve the above result set as follows:*


uid| allergy_value|
1   | nut allergy, penicillin|
2   

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

[Seref Arikan]

Hi Georg,
Please see comments inline

On Thu, Feb 15, 2018 at 9:43 AM, Georg Fette 
wrote:

> Hello,
> I have some questions on the explicit definition on how the result rows
> are returned in the query API:
> 1. In the example at https://www.openehr.org/releas
> es/ITS/Release-0.9.0/docs/query.html#header-resultset-example there is
> one result row with one fact for each of the columns that were requested.
> Three of the columns contain primitves (i.e. Strings) but one column
> contains a JSON representation of an object. It is difficult to grasp from
> the example why some facts are returned as primitves and some as serialized
> JSON objects. It would be beneficial to see the corresponding archetype
> definitions in order to understand how different columns containing
> different parts of the archetypes are encoded.
>
the columns contain data instances that are found at the given path. If the
data (item) instance has type String, then its serialisation is just a
simple string. If you provide a path to an Object (such as the name with
type DV_TEXT) then its serialisation has to represent the object and this
is why you'd get a json payload for that column. Are you suggesting that
this explanation is included in the documentation?

2. When one of the columns contains a list of items in each cell (because
> the denoted data type is an ITEM_LIST), will the content of that cell be
> JSON serialized ? When a user requests all laboratory values (e.g. calcium
> measurements) for a specific patient, then a table would be returned. But
> instead of receiving the individual measurements in seperate columns so the
> result could be immediately processed in tools like Excel or SPSS, the data
> would have to be again crunched by another tool that makes a real table out
> of the table-JSON-compound.
>
This is a sensible expectation and something that gets everyone when they
are first introduced to AQL. AQL is doing what it should do here, *if you
assume that it has a particular semantics to express query patterns.
*Unfortunately,
that particular semantics is not officially described in the specifications
but is inferred via common sense. I drop by and make this point every
couple of months when questions similar to yours arise :) I'll stop here
for reasons to be revealed a few lines below. Read on please ...

> 2b. What happens when multiple columns can contain multiple values as
> their values. When every column containing multiple values (ITEM_LISTs)
> will be encoded with JSON and written to the same cell this will not be an
> issue. But when the multiple values are instead distributed over multiple
> cells (or rows) some mechanism has to be defined how to cope with the
> combination of two columns containing multiple values for one record. In
> SQL-JOINs this is handled with the Cartesian product of the sets of facts.
> But this bears the risk of combinatorial explosions when defining queries
> with too many columns containing too many values for each record.
>
Yep, you got it. I don't think you'd get json serialisations of ITEM_LISTs,
because implementations usually omit LIST types as standalone instances and
expand their children as a group of items sitting under the LIST's parent.
I'm happy to be corrected if my memory is failing me here. It is not only
LISTs that give you this behaviour, if you have a CLUSTER with multiple
ELEMENTs under it, and if you use a SELECT path in AQL that points at the
cluster, then you *may* end up with the cartesian product, which is the *right
result.*
About 10 months ago, this question came from Bjorn in a slightly different
worded way and I tried to clarify it. Unfortunately, my responses, which
included images (or even the ones that did not) are not visible in the mail
archives. So I copied the contents of the thread here:
https://serefarikan.com/2018/02/15/a-rough-and-inaccurate-guide-to-archetype-query-language-semantics/

I created a git repo with examples and I think Bjorn has one that he
created when he asked his question. If you look at my responses, you can
see why AQL implementations are behaving in the way they're doing. The
formalism I'm using to explain things is my view of AQL but as the git repo
I created shows, both SPARQL and XQUERY queries that express the same
semantics deliver the same results.  I'd suggest you read that discussion
(sorry for the bad formatting of some contents, wordpress is a nightmare
when formatting code)

*Can we have a more convenient result set structure then what we have now?* =>
This is an entirely different discussion and quite a deep one too. But I
think clearly explaining and clarifying the result set we have now is a key
task at the moment.

> 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 

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

[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-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: Aw: Re: Blockchain

[Seref Arikan]

You may want to check internet access packages in the Himalayas or Sahara
before you setup shop there Bert ;)

On Tue, Nov 14, 2017 at 3:20 PM, Bert Verhees  wrote:

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

[Seref Arikan]

Dear all,

Many thanks for your kind words. What David, Sam and Tom have created has
so much potential and I hope we'll all get to see it move forward. Exciting
times :)

Kind regards
Seref


On Tue, Oct 31, 2017 at 2:22 AM, Shinji KOBAYASHI <sk...@moss.gr.jp> wrote:

> Congratulations!
> Opereffa, Seref once released, actually motivated to implement EHR.
> I appreciate his achievements and do think worth to get PhD.
>
> Regards,
> Shinji Kobayashi
>
> 2017-10-27 20:27 GMT+09:00 Ingram, David <d.ing...@ucl.ac.uk>:
> > An implementation focused evaluation of openEHR and its integration with
> > Bayesian Belief Networks for clinical decision support
> >
> > One of my most persistent PhD students, Seref Arikan, has published his
> > ground-breaking PhD thesis on the UCL online repository.
> >
> > A fuller announcement and link has been posted in the News Section of the
> > openEHR web site at:
> >
> > http://openehr.org/news_events/community_news
> >
> > We hope it will make a useful contribution to the ongoing international
> > advances in openEHR methodology.
> >
> > David Ingram
> >
> > Emeritus Professor of Health Informatics at UCL
> >
> > President and Chairman of the Board of Governors of the openEHR
> Foundation
> >
> > Trustee of the OpenEyes Foundation Charity
> >
> > Academic Board Member, the Planetearth Institute
> >
> >
> >
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical@lists.openehr.org
> > http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: RE:

[Seref Arikan]

Hi Hildi,

Should not be. Most probably it was a temp glitch :)

On Mon, Oct 30, 2017 at 9:01 AM, Hildegard Franke <hi...@freshehr.com>
wrote:

> Is there a firewall issue on the UCL website if you are accessing from
> abroad?
>
> Kind regards
>
> Hildi
>
> Kind regards
>
> Hildi
>
> Hildegard Franke
> Chief Operations Officer
>
>
>
> mobile:  +44 (0)7932 502655 <+44%207932%20502655>
> landline:  +44 (0)1536 414994 <+44%201536%20414994>
> skype: hild5559
> twitter: @hildegardfranke
> LinkedIn <http://www.linkedin.com/in/hildegardfranke>
>
> On 30 October 2017 at 08:58, Seref Arikan <serefarikan@
> kurumsalteknoloji.com> wrote:
>
>> Hi Wouter,
>>
>> I just checked, and it is working as far as I can see. It should be
>> http://discovery.ucl.ac.uk/1500996/ Does this not work for you?
>>
>> On Mon, Oct 30, 2017 at 8:54 AM, Wouter Zanen <w.za...@eurotransplant.org
>> > wrote:
>>
>>> Hi,
>>>
>>> The link to the full thesis on the openEHR website doesn't seem to work.
>>>
>>> Best regards,
>>>
>>> Wouter Zanen
>>>
>>>
>>>
>>> De inhoud van dit bericht is uitsluitend bestemd voor de geadresseerde
>>> en kan vertrouwelijke en/of persoonlijke informatie bevatten. Als dit
>>> bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de
>>> afzender te melden en het bericht (inclusief bijlagen) uit uw systeem te
>>> verwijderen. Eurotransplant staat door de elektronische verzending van dit
>>> bericht niet in voor de juiste en volledige overbrenging van de inhoud,
>>> noch voor tijdige ontvangst daarvan. Voor informatie over Eurotransplant
>>> raadpleegt u: www.eurotransplant.org.
>>>
>>>
>>>
>>> This message is intended for the addressee's eyes only and it may
>>> contain confidential and/or personal information. If you are not the
>>> intended recipient, you are hereby kindly requested to notify the sender
>>> and delete this message (including attachments) from your system
>>> immediately. In view of the electronic nature of this communication,
>>> Eurotransplant is neither liable for the proper and complete transmission
>>> of the information contained therein nor for any delay in its receipt. For
>>> information on Eurotransplant please visit: www.eurotransplant.org
>>>
>>> >>> Rong Chen <rong.c...@cambio.se> 27/10/2017 14:37 >>>
>>> Congratulations to both Seref and David. I look forward to reading the
>>> full thesis.
>>>
>>> Regards,
>>> Rong
>>>
>>> Rong Chen, MD PhD
>>> Chief Medical Informatics Officer
>>> +46 704 388 001
>>>
>>> *Cambio*+ Healthcare Systems AB
>>> Stockholm:
>>> Drottninggatan 89 SE-113 60 Stockholm
>>> Vx: +46 8 691 49 00 <+46%208%20691%2049%2000> | Fax: +46 8 691 49 99
>>> <+46%208%20691%2049%2099>
>>> Linköping:
>>> Universitetsvägen 14 SE-583 30 Linköping
>>> Vx: +46 13 20 03 00 <+46%2013%2020%2003%2000> | Fax: +46 13 20 03 99
>>> <+46%2013%2020%2003%2099>
>>> Epost: i...@cambio.se  | Hemsida: www.cambio.se
>>>
>>> *From:* openEHR-clinical [mailto:openehr-clinical-bounc
>>> e...@lists.openehr.org] *On Behalf Of *Ingram, David
>>> *Sent:* den 27 oktober 2017 13:28
>>> *To:* For openEHR clinical discussions (openehr-clinical@lists.openeh
>>> r.org) <openehr-clini...@lists.openehr.org>; For openEHR technical
>>> discussions <openehr-technical@lists.openehr.org>
>>> *Subject:*
>>>
>>> *An implementation focused evaluation of openEHR and its integration
>>> with Bayesian Belief Networks for clinical decision support*
>>> One of my most persistent PhD students, Seref Arikan, has published his
>>> ground-breaking PhD thesis on the UCL online repository.
>>> A fuller announcement and link has been posted in the News Section of
>>> the openEHR web site at:
>>> http://openehr.org/news_events/community_news
>>> We hope it will make a useful contribution to the ongoing international
>>> advances in openEHR methodology.
>>> David Ingram
>>> Emeritus Professor of Health Informatics at UCL
>>> President and Chairman of the Board of Governors of the openEHR
>>> Foundation
>>> Trustee of the OpenEyes Foundation Charity
>>> Academic Board Member, the Planetearth Institute
>>>
>>>
>>> ___
>>> openEHR-clinical mailing list
>>> openehr-clini...@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_l
>>> ists.openehr.org
>>>
>>
>>
>> ___
>> openEHR-clinical mailing list
>> openehr-clini...@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> lists.openehr.org
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: RE:

[Seref Arikan]

Hi Wouter,

I just checked, and it is working as far as I can see. It should be
http://discovery.ucl.ac.uk/1500996/ Does this not work for you?

On Mon, Oct 30, 2017 at 8:54 AM, Wouter Zanen <w.za...@eurotransplant.org>
wrote:

> Hi,
>
> The link to the full thesis on the openEHR website doesn't seem to work.
>
> Best regards,
>
> Wouter Zanen
>
>
>
> De inhoud van dit bericht is uitsluitend bestemd voor de geadresseerde en
> kan vertrouwelijke en/of persoonlijke informatie bevatten. Als dit bericht
> niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te
> melden en het bericht (inclusief bijlagen) uit uw systeem te verwijderen.
> Eurotransplant staat door de elektronische verzending van dit bericht niet
> in voor de juiste en volledige overbrenging van de inhoud, noch voor
> tijdige ontvangst daarvan. Voor informatie over Eurotransplant raadpleegt
> u: www.eurotransplant.org.
>
>
>
> This message is intended for the addressee's eyes only and it may contain
> confidential and/or personal information. If you are not the intended
> recipient, you are hereby kindly requested to notify the sender and delete
> this message (including attachments) from your system immediately. In view
> of the electronic nature of this communication, Eurotransplant is neither
> liable for the proper and complete transmission of the information
> contained therein nor for any delay in its receipt. For information on
> Eurotransplant please visit: www.eurotransplant.org
>
> >>> Rong Chen <rong.c...@cambio.se> 27/10/2017 14:37 >>>
> Congratulations to both Seref and David. I look forward to reading the
> full thesis.
>
> Regards,
> Rong
>
> Rong Chen, MD PhD
> Chief Medical Informatics Officer
> +46 704 388 001
>
> *Cambio*+ Healthcare Systems AB
> Stockholm:
> Drottninggatan 89 SE-113 60 Stockholm
> Vx: +46 8 691 49 00 <+46%208%20691%2049%2000> | Fax: +46 8 691 49 99
> <+46%208%20691%2049%2099>
> Linköping:
> Universitetsvägen 14 SE-583 30 Linköping
> Vx: +46 13 20 03 00 <+46%2013%2020%2003%2000> | Fax: +46 13 20 03 99
> <+46%2013%2020%2003%2099>
> Epost: i...@cambio.se  | Hemsida: www.cambio.se
>
> *From:* openEHR-clinical [mailto:openehr-clinical-
> boun...@lists.openehr.org] *On Behalf Of *Ingram, David
> *Sent:* den 27 oktober 2017 13:28
> *To:* For openEHR clinical discussions (openehr-clini...@lists.openehr.org)
> <openehr-clini...@lists.openehr.org>; For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:*
>
> *An implementation focused evaluation of openEHR and its integration with
> Bayesian Belief Networks for clinical decision support*
> One of my most persistent PhD students, Seref Arikan, has published his
> ground-breaking PhD thesis on the UCL online repository.
> A fuller announcement and link has been posted in the News Section of the
> openEHR web site at:
> http://openehr.org/news_events/community_news
> We hope it will make a useful contribution to the ongoing international
> advances in openEHR methodology.
> David Ingram
> Emeritus Professor of Health Informatics at UCL
> President and Chairman of the Board of Governors of the openEHR Foundation
> Trustee of the OpenEyes Foundation Charity
> Academic Board Member, the Planetearth Institute
>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: COMPOSITION (TEMPLATE FILLED) TO XML

[Seref Arikan]

Hi Flavio,

Did you see Pablo's response to this question you've sent earlier?

On Fri, Oct 6, 2017 at 3:01 PM, Flavio Barbosa  wrote:

> Good Morning!
>
> Is there any library in JAVA or any tutorial about serialize a composition
> (template filled with data) in XML?
>
>
> Bom dia!
>
> Existe alguma biblioteca em JAVA ou algum tutorial para serializar uma
> composition (template preenchido com dados) em XML ?
>
> --
> []´s Dr. Flavio Barbosa
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL FROM & CONTAINS with many entries

[Seref Arikan]

Also see this, just in case it may help clarify relevant  Qs:
https://github.com/serefarikan/aql-discussion

On Sunday, October 1, 2017, Pablo Pazos  wrote:

> Hi all, another question about AQL and CONTAINS.
>
> Most of the AQL samples use just one branch in the FROM clause, like:
>
> EHR CONTAINS COMPOSITION CONTAINS OBSERVATION.
>
> I'm wondering what would be the correct FROM notation when more than one
> ENTRY is needed. Some examples below.
>
> SELECT o1/data[...]/.../value, o2/..., 
> FROM
>COMPOSITION c [archid] CONTAINS OBSERVATION o1 [archid2],
>COMPOSITION c [archid] CONTAINS OBSERVATION o2 [archid3],
>COMPOSITION c [archid] CONTAINS OBSERVATION o3 [archid4]
> WHERE ...
>
>
> SELECT o1/data[...]/.../value, o2/..., 
> FROM
>COMPOSITION c [archid]
>   CONTAINS OBSERVATION o1 [archid2] AND
>   CONTAINS OBSERVATION o2 [archid3] AND
>   CONTAINS OBSERVATION o3 [archid4]
> WHERE ...
>
>
> Thanks!
>
> --
> Ing. Pablo Pazos Gutiérrez
> e: pablo.pa...@cabolabs.com
> 
> p: +598 99 043 145
> skype: cabolabs
> 
> 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

Re: AQL FROM & CONTAINS with many entries

[Seref Arikan]

X contains (y and z and t)

The paranthesis are optional above but would help avoid ambiguity when we
have

X contains y and z contains t and o
Is it:
X contains y and (z contains t) and o
Or
X contains y and (z contains t and o)

??

As you can see the paranthesis help define the containment structure




On Sunday, October 1, 2017, Pablo Pazos  wrote:

> Hi all, another question about AQL and CONTAINS.
>
> Most of the AQL samples use just one branch in the FROM clause, like:
>
> EHR CONTAINS COMPOSITION CONTAINS OBSERVATION.
>
> I'm wondering what would be the correct FROM notation when more than one
> ENTRY is needed. Some examples below.
>
> SELECT o1/data[...]/.../value, o2/..., 
> FROM
>COMPOSITION c [archid] CONTAINS OBSERVATION o1 [archid2],
>COMPOSITION c [archid] CONTAINS OBSERVATION o2 [archid3],
>COMPOSITION c [archid] CONTAINS OBSERVATION o3 [archid4]
> WHERE ...
>
>
> SELECT o1/data[...]/.../value, o2/..., 
> FROM
>COMPOSITION c [archid]
>   CONTAINS OBSERVATION o1 [archid2] AND
>   CONTAINS OBSERVATION o2 [archid3] AND
>   CONTAINS OBSERVATION o3 [archid4]
> WHERE ...
>
>
> Thanks!
>
> --
> Ing. Pablo Pazos Gutiérrez
> e: pablo.pa...@cabolabs.com
> 
> p: +598 99 043 145
> skype: cabolabs
> 
> 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

Re: Could the specs group consider making uid mandatory?

[Seref Arikan]

This looks like it. Thanks.

On Tue, Dec 13, 2016 at 12:51 PM, Thomas Beale 
wrote:

> https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-
> 91?filter=allopenissues
>
>
> On 13/12/2016 23:01, Boštjan Lah wrote:
>
>> On 13 Dec 2016, at 12:36, Thomas Beale  wrote:
>>>
>>>
>>>
>>> On 13/12/2016 22:27, Pieter Bos wrote:
>>>
 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.

>>> that's pretty much the view we have on this to date...
>>>
>>> - thomas
>>>
>> There was a discussion about introducing an additional identifier for
>> nodes besides UID, something lighter.
>> Current generation of paths to uniquely identify an element within a
>> composition is difficult and it became even more difficult when name
>> uniqueness was dropped.
>> Think of identifying a specific POINT_EVENT in a HISTORY.
>> There was a suggestion to use other attributes, for example for
>> POINT_EVENT it would be 'time' but this makes things even worse as one
>> would need to use different attribute depending on the node type.
>> I would welcome the idea of having some kind of lightweight identifier on
>> every node in order to make unique path generation easier.
>>
>>
>
>
>
> ___
> 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: Could the specs group consider making uid mandatory?

[Seref Arikan]

My preferred scenario would be to have an identifier on every node indeed.
Not having that, I could live with identifiers for at least some types,
such as entry subtypes and a few more. If it cannot be UID, so be it.

What is the meaning of overhead here? Processing time? Memory/disk space?
According to which criteria the overhead is quantified as "quite a lot"?

You can see I'm not really convinced here :)

On Tue, Dec 13, 2016 at 12:01 PM, Boštjan Lah  wrote:

>
> > On 13 Dec 2016, at 12:36, Thomas Beale  wrote:
> >
> >
> >
> > On 13/12/2016 22:27, Pieter Bos wrote:
> >> 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.
> >
> > that's pretty much the view we have on this to date...
> >
> > - thomas
>
> There was a discussion about introducing an additional identifier for
> nodes besides UID, something lighter.
> Current generation of paths to uniquely identify an element within a
> composition is difficult and it became even more difficult when name
> uniqueness was dropped.
> Think of identifying a specific POINT_EVENT in a HISTORY.
> There was a suggestion to use other attributes, for example for
> POINT_EVENT it would be 'time' but this makes things even worse as one
> would need to use different attribute depending on the node type.
> I would welcome the idea of having some kind of lightweight identifier on
> every node in order to make unique path generation easier.
>
> Bostjan
>
> >
> >>
> >> What are you trying to do that cannot be solved with a top-level UID
> plus a path?
> >>
> >
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical@lists.openehr.org
> > http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Could the specs group consider making uid mandatory?

[Seref Arikan]

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: RM in OWL

[Seref Arikan]

Hi Matheus,

I'd be interested to hear about your problems. I'd also be curious to learn
how you handled generics/parameterized types. Unless one defines a meta
layer in owl with semantics for generics, I guess the only option is to
materialize every possible type parameter T to its own type.

All the best
Seref


On Tue, Jul 12, 2016 at 7:26 PM, Matheus Wichman <matheus.wich...@gmail.com>
wrote:

> Hi Seref,
>
> The ontologies available on the link you posted were developed using an
> old specification of RM.
>
> I converted the current RM to OWL, like Isabel did. However I had some
> problems to represent list structures.
>
> 2016-07-12 13:02 GMT-03:00 Seref Arikan <serefari...@kurumsalteknoloji.com
> >:
>
>> Greetings,
>>
>> I was wondering if there is any projects out there that provide an OWL
>> version of the RM.
>>
>> I found this page: http://trajano.us.es/~isabel/EHR/ where an OWL
>> version is kindly provided, though I'll need to get in touch with the
>> author to clarify the terms and conditions of use.
>>
>> There are papers out there that use an OWL representation of archetypes
>> etc but I could not find any RM representation other than the link above.
>> Any pointers would be appreciated.
>>
>> Cheers
>> Seref
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
>
> --
> Atenciosamente,
>
> Matheus Wichman
>
> ___
> 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

RM in OWL

[Seref Arikan]

Greetings,

I was wondering if there is any projects out there that provide an OWL
version of the RM.

I found this page: http://trajano.us.es/~isabel/EHR/ where an OWL version
is kindly provided, though I'll need to get in touch with the author to
clarify the terms and conditions of use.

There are papers out there that use an OWL representation of archetypes etc
but I could not find any RM representation other than the link above. Any
pointers would be appreciated.

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

Re: Activity based workflow - request for literature & resources

[Seref Arikan]

Hi Tom,

Very interesting. Good to see Intermountain tackling wflow. Especially the
idea of adaptive wflows is intriguing. Cooperative category sounds like a
true challenge.

Inevitable questions follow:

Any specs out there? Any code? A shared space for comments/Qs/Chat?

Comments:

I have long thought that workflows were underutilized in hcare due to
attempts to model them either at a too formal level (petri nets,colored
petri nets or such) or at a too simple level that could not handle the
complexity of healthcare. Something thought specifically for the domain may
do really well. I remember studying process mining and delta analysis with
the aim of analyzing existing workflows to see how much they deviate from
clinical guidelines, but that dream died at one point :) A healthcare
specific computable workflow could allow a lot of interesting things. Hope
this one takes off.

All the best
Seref


On Wed, Apr 13, 2016 at 2:12 PM, Thomas Beale 
wrote:

>
> I added a bit more background information on the ABD workflow project:
>
> Activity-Based Design is based on the idea that an 'Activity' is the unit
> of clinical work, and thus also the unit of formal definition of a
> workflow. An Activity as currently conceived includes:
>
>- semantic model (elements) - something like an archetype or template
>- potentially pre- and post-conditions for execution
>- definition of workflow execution state
>- potentially a definition of user interaction, e.g. how to react to
>user choosing terms etc
>- activity-based costing data, e.g. ICD codes, charge ids
>- qualification - who can perform this Activity?
>- scheduling information
>
> Workflows are assumed to be made of sub-workflows and ultimately
> Activities. It is assumed so far that there are 3 kinds of workflows:
>
>- imperative - essentially fixed, deterministic; probably good for
>mainly admin tasks
>- adaptive - workflows that can be modified or executed differently
>than the definition, without forcing abandonment
>- cooperative - workflows that are adaptive and involve multiple
>execution agents.
>
> The ABD work is current research at Intermountain Healthcare, and has at
> least 12 months to run. Accordingly, all current thinking is, in the usual
> way, somewhat speculative. Implementations are being built to test the
> current state of the ideas as they are at any point in time.
>
>
> The wiki page for posting resources is here
> 
> .
>
> ___
> 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: Archetype relational mapping - a practical openEHR persistence solution

[Seref Arikan]

You're right, it does not read in the way I wanted it to. Let me try to
clarify:

Clinical care is strongly single patient centric, and in most cases this
puts a limit on the amount of data that does not push the limits of
computational power too much. Developers can afford to fetch multiple
documents and go across them if needed without requiring the DB to perform
the same operation, hence having to process XML (or json) So you can get
away with treating the relational database as a document store and
performance problems do not easily reveal themselves.

There will be cases which this won't work (for a single patient's care),
but it is only when the requirement to produce time series, aggregates etc
becomes too expensive to do outside of the DB. Even then, most
implementations would pre-define these and populate them during data entry
in advance, and still get away with not having to dissect XML at the db
level.

So my argument is more about being able to not to process XML using the
relational database than the necessity of clinical data that spans multiple
documents, which can be summarized as "developers are lazy"

Does it make sense now?

On Tue, Feb 16, 2016 at 11:33 AM, Ian McNicoll <i...@freshehr.com> wrote:

> Hi Seref,
>
> "so there is rarely a requirement to read across documents, because
> clinicians would not be able to consume all that information at once
> (except averages or other aggregate values they're interested in)"
>
> I don't think that is true in any other than the most trivial
> implementations. The ability to query and pull granular data across
> documents, for single and multiple patients is a critical requirement for
> anty EPR/EHR.
>
> or perhaps I misunderstood?
>
> Ian
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 16 February 2016 at 11:26, Seref Arikan <
> serefari...@kurumsalteknoloji.com> wrote:
>
>> The document oriented view of the domain has no problem with storing XML
>> text in the DB, because the implementations are built against that view.
>> The clinical care focused use cases require developers to focus on reading
>> & writing documents, so there is rarely a requirement to read across
>> documents, because clinicians would not be able to consume all that
>> information at once (except averages or other aggregate values they're
>> interested in)
>>
>> So developers mostly deal with put document/get document type of
>> requirements and simply having an XML field (or json for that matter) makes
>> things easy for them. Hence, it makes sense to them. Database vendors have
>> their own reasons for supporting direct storage of XML and they deal with
>> obvious disadvantages behind the scenes (google: postgres xml toast). The
>> price of storage keeps falling faster than all the other components,which
>> also helps justify this approach.
>>
>> I suggest a coding exercise for representing XML documents in a
>> relational database with writes and reads to see what a joy it is to
>> rebuild an XML document in comparison to just reading it directly from a
>> column :)
>>
>> Some DBs store XML using tables behind the scenes to save the developers
>> from this pain, but they usually rely on schemas to do that (cough **rcl*)
>> and it becomes another joyful activity to use that feature.
>>
>> So all I'm saying is: there is a price for everything, and in some cases
>> having xml sitting in the db is not as bad as it sounds
>>
>> On Tue, Feb 16, 2016 at 10:47 AM, Thomas Beale <thomas.be...@openehr.org>
>> wrote:
>>
>>>
>>>
>>> On 14/02/2016 23:25, Bert Verhees wrote:
>>>
>>> One doesn't know what software really does. One must distinguish what
>>> software seems to do and what it really does.
>>>
>>> Storing XML really as XML means, storing a lot of redundant information.
>>> I don't know, but I cannot believe postgress really stores the full tag
>>> names,  even when they occur thousand times. I would be really disappointed
>>> if they do.
>>>
>>> Bert
>>>
>>>
>>> storing a text serialisation of an object structure in a database never
>>> makes sense when you think about it. Storing a *binary* serialisation
>>> is a normal 'blob' approach, and if you are not doing blobs or partial
>>> blobs, then you are d

Re: Archetype relational mapping - a practical openEHR persistence solution

[Seref Arikan]

The document oriented view of the domain has no problem with storing XML
text in the DB, because the implementations are built against that view.
The clinical care focused use cases require developers to focus on reading
& writing documents, so there is rarely a requirement to read across
documents, because clinicians would not be able to consume all that
information at once (except averages or other aggregate values they're
interested in)

So developers mostly deal with put document/get document type of
requirements and simply having an XML field (or json for that matter) makes
things easy for them. Hence, it makes sense to them. Database vendors have
their own reasons for supporting direct storage of XML and they deal with
obvious disadvantages behind the scenes (google: postgres xml toast). The
price of storage keeps falling faster than all the other components,which
also helps justify this approach.

I suggest a coding exercise for representing XML documents in a relational
database with writes and reads to see what a joy it is to rebuild an XML
document in comparison to just reading it directly from a column :)

Some DBs store XML using tables behind the scenes to save the developers
from this pain, but they usually rely on schemas to do that (cough **rcl*)
and it becomes another joyful activity to use that feature.

So all I'm saying is: there is a price for everything, and in some cases
having xml sitting in the db is not as bad as it sounds

On Tue, Feb 16, 2016 at 10:47 AM, Thomas Beale 
wrote:

>
>
> On 14/02/2016 23:25, Bert Verhees wrote:
>
> One doesn't know what software really does. One must distinguish what
> software seems to do and what it really does.
>
> Storing XML really as XML means, storing a lot of redundant information. I
> don't know, but I cannot believe postgress really stores the full tag
> names,  even when they occur thousand times. I would be really disappointed
> if they do.
>
> Bert
>
>
> storing a text serialisation of an object structure in a database never
> makes sense when you think about it. Storing a *binary* serialisation is
> a normal 'blob' approach, and if you are not doing blobs or partial blobs,
> then you are doing transparent representation, in which case things like
> XML or JSON don't come into it - they only make sense as one kind of
> generated view on data.
>
> You might implement blobs using a zipped text format, but in a serious
> scalable implementation that would surely have to be the least efficient of
> viable approaches.
>
> I can't think of any circumstance where a DB would actually store its
> information as XML instance text (other than where some column value
> happened to be an XMLstring, i.e. the XML is just data).
>
> - thomas
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype relational mapping - a practical openEHR persistence solution

[Seref Arikan]

Thanks,
My feelings for postgresql are well known, it is a great piece of code.
Final question, do you support AQL with your current design?

On Tue, Jan 26, 2016 at 10:40 AM, Jan-Marc Verlinden <
jan-m...@medvision360.com> wrote:

> Hi Seref,
>
> We tested with lots of queries, not with large datasets (tens of
> thousands) within the system itself. But given the nature of the "normal"
> relational DB schema and queries, this should be no problem at all. It's
> good old postgres..:-).
>
> Jan-Marc
>
> Op di 26 jan. 2016 om 10:53 schreef Seref Arikan <
> serefari...@kurumsalteknoloji.com>:
>
>> Hi Jan-Marc,
>>
>> To clarify: when you say huge: do you mean that the result set is huge,
>> or the the amount of existing data is huge? Are you able to comment on how
>> query performance changes/stays the same when the result set size begins to
>> grow?
>>
>> On Tue, Jan 26, 2016 at 9:38 AM, Jan-Marc Verlinden <
>> jan-m...@medvision360.com> wrote:
>>
>>> I believe your paper is about performance of an openEHR based system
>>> with a relational database. It does not argues if this is the right
>>> approach. And specifically on the performance we could not agree more...:-).
>>>
>>> In the past year we worked on three different versions, all completely
>>> openEHR compliant. We compared them, so I believe we are entitled to
>>> discuss. Let's see:
>>>
>>>1. Our first version was Java based with a postgres DB, everything
>>>stored as path/values.
>>>Every query would take about a second. We did not even try complex
>>>queries..:-). Also the GUI side did not know what to do with the 
>>> pathvalues.
>>>2. Second version was completely XML based, lots of Java with an
>>>Exist DB. This version can be found in GitHub.
>>>Results: a single query over 900 records took 100ms. But the scary
>>>part was that performance exploded linear, so 9 would take about 10
>>>seconds, even for the most simple (already indexed and optimized) query.
>>>3. Our current stack converts archetypes to an Object model and
>>>persists this model to postgres. Indeed this needs some fancy tricks
>>>(@Thomas), but it's doable...:-).
>>>Performance is comparable with the findings in the paper, even with
>>>huge queries. Performance is steady at about 1 to 3ms per query. No
>>>optimization done yet, is not yet needed but could/will make it even 
>>> faster.
>>>
>>> Cheers, Jan-Marc
>>>
>>> Op di 26 jan. 2016 om 09:55 schreef 吕旭东 <lxdlxd7...@gmail.com>:
>>>
>>>> Dear all,
>>>>
>>>> I just found there are lots of comments on our recent paper. Thanks for
>>>> all these comments, I will read them and reply later.
>>>>
>>>> @Shinji, Of course the slides could be shared.
>>>>
>>>> Regards
>>>> Xudong
>>>>
>>>> 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI <sk...@moss.gr.jp>:
>>>>
>>>>> Hi Ian and all,
>>>>>
>>>>> We, openEHR Japan had an unconference with Dr Lu and he gave us a
>>>>> presentation for us about this research.
>>>>> I will ask him if the slides would be shareble.
>>>>>
>>>>> Shinji KOBAYASHI
>>>>>
>>>>> 2016-01-25 22:04 GMT+09:00 Ian McNicoll <i...@freshehr.com>:
>>>>>
>>>>>> Interesting paper from China
>>>>>>
>>>>>>
>>>>>> http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0
>>>>>>
>>>>>> 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://l

Re: Archetype relational mapping - a practical openEHR persistence solution

[Seref Arikan]

Thanks for the answers Jan-Marc.



On Tue, Jan 26, 2016 at 11:55 AM, Jan-Marc Verlinden <
jan-m...@medvision360.com> wrote:

> Dear Seref,
>
> At moment we do not support AQL, mainly because none of our current
> partners/developers are asking for it. We have discussed using AQL
> internally several (lots of-) times, but also with for instance Ian.
>
> If this changes, so if there is a need for AQL, we could easily support
> it. Its just a matter of development. In that case our architecture is to
> convert AQL to SQL, and go from there.
>
> Regards, Jan-Marc
>
> Op di 26 jan. 2016 om 12:26 schreef Seref Arikan <
> serefari...@kurumsalteknoloji.com>:
>
>> Thanks,
>> My feelings for postgresql are well known, it is a great piece of code.
>> Final question, do you support AQL with your current design?
>>
>> On Tue, Jan 26, 2016 at 10:40 AM, Jan-Marc Verlinden <
>> jan-m...@medvision360.com> wrote:
>>
>>> Hi Seref,
>>>
>>> We tested with lots of queries, not with large datasets (tens of
>>> thousands) within the system itself. But given the nature of the "normal"
>>> relational DB schema and queries, this should be no problem at all. It's
>>> good old postgres..:-).
>>>
>>> Jan-Marc
>>>
>>> Op di 26 jan. 2016 om 10:53 schreef Seref Arikan <
>>> serefari...@kurumsalteknoloji.com>:
>>>
>>>> Hi Jan-Marc,
>>>>
>>>> To clarify: when you say huge: do you mean that the result set is huge,
>>>> or the the amount of existing data is huge? Are you able to comment on how
>>>> query performance changes/stays the same when the result set size begins to
>>>> grow?
>>>>
>>>> On Tue, Jan 26, 2016 at 9:38 AM, Jan-Marc Verlinden <
>>>> jan-m...@medvision360.com> wrote:
>>>>
>>>>> I believe your paper is about performance of an openEHR based system
>>>>> with a relational database. It does not argues if this is the right
>>>>> approach. And specifically on the performance we could not agree 
>>>>> more...:-).
>>>>>
>>>>> In the past year we worked on three different versions, all completely
>>>>> openEHR compliant. We compared them, so I believe we are entitled to
>>>>> discuss. Let's see:
>>>>>
>>>>>1. Our first version was Java based with a postgres DB, everything
>>>>>stored as path/values.
>>>>>Every query would take about a second. We did not even try complex
>>>>>queries..:-). Also the GUI side did not know what to do with the 
>>>>> pathvalues.
>>>>>2. Second version was completely XML based, lots of Java with an
>>>>>Exist DB. This version can be found in GitHub.
>>>>>Results: a single query over 900 records took 100ms. But the scary
>>>>>part was that performance exploded linear, so 9 would take about 10
>>>>>seconds, even for the most simple (already indexed and optimized) 
>>>>> query.
>>>>>3. Our current stack converts archetypes to an Object model and
>>>>>persists this model to postgres. Indeed this needs some fancy tricks
>>>>>(@Thomas), but it's doable...:-).
>>>>>Performance is comparable with the findings in the paper, even
>>>>>with huge queries. Performance is steady at about 1 to 3ms per query. 
>>>>> No
>>>>>optimization done yet, is not yet needed but could/will make it even 
>>>>> faster.
>>>>>
>>>>> Cheers, Jan-Marc
>>>>>
>>>>> Op di 26 jan. 2016 om 09:55 schreef 吕旭东 <lxdlxd7...@gmail.com>:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I just found there are lots of comments on our recent paper. Thanks
>>>>>> for all these comments, I will read them and reply later.
>>>>>>
>>>>>> @Shinji, Of course the slides could be shared.
>>>>>>
>>>>>> Regards
>>>>>> Xudong
>>>>>>
>>>>>> 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI <sk...@moss.gr.jp>:
>>>>>>
>>>>>>> Hi Ian and all,
>>>>>>>
>>>>>>> We, openEHR Japan had an unconference with Dr Lu and he gave us a
>>>>>>> presentation for us about this research.
&

Re: Archetype relational mapping - a practical openEHR persistence solution

[Seref Arikan]

Hi Jan-Marc,

To clarify: when you say huge: do you mean that the result set is huge, or
the the amount of existing data is huge? Are you able to comment on how
query performance changes/stays the same when the result set size begins to
grow?

On Tue, Jan 26, 2016 at 9:38 AM, Jan-Marc Verlinden <
jan-m...@medvision360.com> wrote:

> I believe your paper is about performance of an openEHR based system with
> a relational database. It does not argues if this is the right approach.
> And specifically on the performance we could not agree more...:-).
>
> In the past year we worked on three different versions, all completely
> openEHR compliant. We compared them, so I believe we are entitled to
> discuss. Let's see:
>
>1. Our first version was Java based with a postgres DB, everything
>stored as path/values.
>Every query would take about a second. We did not even try complex
>queries..:-). Also the GUI side did not know what to do with the 
> pathvalues.
>2. Second version was completely XML based, lots of Java with an Exist
>DB. This version can be found in GitHub.
>Results: a single query over 900 records took 100ms. But the scary
>part was that performance exploded linear, so 9 would take about 10
>seconds, even for the most simple (already indexed and optimized) query.
>3. Our current stack converts archetypes to an Object model and
>persists this model to postgres. Indeed this needs some fancy tricks
>(@Thomas), but it's doable...:-).
>Performance is comparable with the findings in the paper, even with
>huge queries. Performance is steady at about 1 to 3ms per query. No
>optimization done yet, is not yet needed but could/will make it even 
> faster.
>
> Cheers, Jan-Marc
>
> Op di 26 jan. 2016 om 09:55 schreef 吕旭东 :
>
>> Dear all,
>>
>> I just found there are lots of comments on our recent paper. Thanks for
>> all these comments, I will read them and reply later.
>>
>> @Shinji, Of course the slides could be shared.
>>
>> Regards
>> Xudong
>>
>> 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI :
>>
>>> Hi Ian and all,
>>>
>>> We, openEHR Japan had an unconference with Dr Lu and he gave us a
>>> presentation for us about this research.
>>> I will ask him if the slides would be shareble.
>>>
>>> Shinji KOBAYASHI
>>>
>>> 2016-01-25 22:04 GMT+09:00 Ian McNicoll :
>>>
 Interesting paper from China


 http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0

 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

>>>
>>>
>>> ___
>>> 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
>
> --
>
> Jan-Marc Verlinden
> MedVision (mobile)
>
> *MedVision BV*
> Aagje Dekenkade 71
> 2251 ZV, Voorschoten
> www.medvision360.com
>
> This e-mail message is intended exclusively for the addressee(s). Please
> inform us immediately if you are not the addressee.
>
> ___
> 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: Archetype relational mapping - a practical openEHR persistence solution

[Seref Arikan]

Hi Pablo,
I agree with you re the indirect use of IM. I don't necessarily see a big
problem with this paper's approach because every approach has its
downsides. In fact, some really successful projects and products are built
on designs that are shunned by the "collective wisdom" of academia and
engineering communities, but they work, they do the job, and most important
of all, the cost of dealing with design related issues is acceptable, given
the expectations from the system.
This is the key: what is the expectation? What defines success in an
openEHR implementation? It is very context specific, with human,
institutional and other factors having their effect on technical factors.
I'm not saying that you're suggesting anything on the contrary, just trying
to make a point that this is an implementation that made it to a
functioning state and many factors in that process is unknown to us. The
authors may not even be able to share those factors.
If my memory is correct, when I read this paper some time ago, it mentioned
an earlier study, probably by the same group, but I could not access it.
That'd be interesting to read as well.



On Tue, Jan 26, 2016 at 1:52 AM, pablo pazos  wrote:

> ORM is not a problem with current tools. In fact frameworks like Hibernate
> and Grails make Object-Relational Mapping something enjoyable to work with.
> I think the problem with the described approach is the growth of the
> relational schema when your knowledge base grows.
>
> But there are design challenges, ORM doesn't solve all the problems
> itself. IMHO, the object model that should be mapped to relational, if
> relational is chosen as DBMS, is not the raw openEHR IM. Simplifications
> over the IM are needed in order to prevent excessive JOINs and huge
> hierarchies. In fact I teach this in one of my courses and this was part of
> the tutorial we did on MEDINFO. For example, the OBJECT_REFs can be
> designed as simple relationships, because plays the role of a FK in the
> object model. There are many simplifications that can be done to reach an
> object model that is compatible with the openEHR model but more "relational
> friendly".
>
> --
> Kind regards,
> Eng. Pablo Pazos Gutiérrez
> http://cabolabs.com 
> 
>
> --
> Date: Mon, 25 Jan 2016 18:42:01 +0100
> Subject: Re: Archetype relational mapping - a practical openEHR
> persistence solution
> From: bert.verh...@rosa.nl
> To: openehr-technical@lists.openehr.org
>
>
> Another problem is you have to convert your object oriented model (which
> RM is) to a relational model, which becomes complex in converting
> templates/aql to SQL. I have been that way. More then five years ago I left
> it. It is difficult doable, if you want a full featured openehr kernel. I
> would never recommend going this way, unless someone has a really smart
> idea.
>
> It can work for a light featured openehr light derived application model.
>
> Best regards
> Bert
> Op 25 jan. 2016 15:26 schreef "pazospa...@hotmail.com" <
> pazospa...@hotmail.com>:
>
> I talked about this approach with a colleague from China during MEDINFO.
> The problem is your schema grows with your archetypes. Also, that storing
> data from many templates that don't use all the fields in the archetype,
> will generate sparse tables (lots of null columns). I told him it was
> easier to do an ORM from the IM, because the schema doesn't change and
> allows to store data from any archetype/template. But they already have a
> system working this way.
>
>
> Sent from my LG Mobile
>
> -- Original message--
>
> *From: *Ian McNicoll
>
> *Date: *Mon, Jan 25, 2016 10:06
>
> *To: *For openEHR technical discussions;
>
> *Subject:*Archetype relational mapping - a practical openEHR persistence
> solution
> Interesting paper from China
>
>
> http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0
>
> 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
>
>
> ___ openEHR-technical mailing
> list openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing 

Re: New EHRServer v0.5 and roadmap

[Seref Arikan]

Hi Pablo,
Just wanted to say well done. I have not had the chance to look at your
work, mainly because work and studies forced me to take a step back from
open source efforts, but it is great to see the continuous progress you're
making.

It is very important that there is an open source implementation of openEHR
out there that is actively developed. Don't worry about the performance
either. If someone wants to use it and they think it is not fast, they
should pay you to make it faster.

I hope it gets adopted and you keep working on it.

All the best
Seref


On Thu, Jan 14, 2016 at 5:42 AM, pablo pazos  wrote:

> Hi all!
>
> I'm very excited to share the good news with all my openEHR friends here.
>
> We have released EHRServer v0.5! This version is what we could call
> "feature complete", so it includes all the minimum features of a real
> openEHR server, the latest ones related to securing the API, and before
> that, supporting multi-tenancy.
>
> I'll release user documentation and a full REST API documentation in the
> next couple of days, and will record a demo in English on YouTube via
> Hangout. I made a demo in Spanish not so long ago:
> https://www.youtube.com/watch?v=84YiNfkLGMA
>
> Also, we have a staging server to test the EHRServer*, you are very
> welcome to try it and give us some feedback to continue improving the tool:
> https://cabolabs-ehrserver.rhcloud.com/ehr
>
> * You can create an account and start using it.
>
> Note: the server is not so fast, but is usable.
>
>
> I'm working hard on v0.6 right now, hopefully we'll have a release before
> February. This version will include fixes to the UI, REST API, and security
> checks, more testing, testable REST API docs, among other things. The focus
> will be on robustness, security, and consistency more than adding new
> features. We can call the EHRServer v0.6 a "production ready" system.
>
> I started to meet with some friends and colleagues interested on using the
> EHRServer as an open-source openEHR backend. My next focus will be on
> building pilot projects with some companies, to let them try the EHRServer
> and see if it fits their needs and gathering information to improve it. If
> anyone is interested, please give me a ring or ping my by email!
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Gutiérrez
> http://cabolabs.com 
> 
>
> ___
> 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: Trial of openEHR's own 'stackExchange' on the openEHR wiki

[Seref Arikan]

Ok, logged in, upvoted the question, then watched the question. The answer
was accepted and I received an e-mail telling me that. So it all seems to
be working.

The point about making this publicly visible is a good one, but is it
possible?

Finally, even though I'm in favour of a less strict format for Q, I think
there should still be something that separates this site from the e-mail
groups. Not to trigger another trip to a rabbit hole, but some mail lists
are simply moving to SO completely due to overlap. Better make sure that we
don't end up with the 'old wiki' problem (in which there is always an old
wiki somewhere and some critical information is written in it, except no
one knows where the old wiki is now...)



On Thu, Jan 7, 2016 at 2:15 PM, Thomas Beale 
wrote:

>
> I made a response but I suspect noone will see it because noone is
> 'watching'. Could a few people try watching, upvoting (assuming you don't
> hate the response :), to see what happens in terms of notifications - I
> don't really know how this Questions feature works on Confluence, so I
> think we just need to test it a bit.
>
> - thomas
>
> On 06/01/2016 08:07, Bakke, Silje Ljosland wrote:
>
> I just posted a real question, hope someone can give me a good answer that
> solves my problem! J
>
>
>
> Btw, does anyone else experience a strange behaviour of the wiki editor,
> where it automatically capitalises some words as you type?
>
>
>
> Mvh.
>
> *Silje*
>
>
>
> *From:* openEHR-technical [
> mailto:openehr-technical-boun...@lists.openehr.org
> ] *On Behalf Of *Thomas Beale
> *Sent:* Tuesday, January 05, 2016 2:33 PM
> *To:* Openehr-Technical
> *Subject:* Trial of openEHR's own 'stackExchange' on the openEHR wiki
>
>
>
>
> one of the features we don't use on the wiki is 'Questions', which you can see
> here .
>
> This supposedly is the same kind of function as StackExchange, which we
> didn't get off the ground. So maybe we should try locally.
>
> My proposal would be for some community members to raise a question or two
> at the above link and see what the experience is like for creating answers,
> upvoting etc. We might find it is good enough.
>
>
>
> ___
> 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: Advantage of ISO

[Seref Arikan]

Greetings,
Just to clarify my understanding of your understanding of the term: would
you say HL7 and Snomed CT are proprietary ?

On Thu, Sep 3, 2015 at 6:29 AM, "Gerard Freriks (privé)" 
wrote:

> *What do I misunderstand?*
>
> The definition of ‘proprietary’ according to GOOGLE  is clear.
> proprietary
> prəˈprʌɪət(ə)ri/
> *adjective*
> adjective: *proprietary*
>
>1. *1*.
>relating to an owner or ownership.
>"the company has a proprietary right to the property"
>- behaving as if one owned something or someone.
>   "he looked about him with a proprietary air"
>   2. *2*.
>(of a product) marketed under and protected by a registered trade name.
>"proprietary brands of insecticide"
>
> Origin
> late Middle English (as a noun denoting a member of a religious order who
> held property): from late Latin *proprietarius* ‘proprietor’, from
> *proprietas* (see property
> 
> ).
>
> On the openEHR website we all can read about the Legal Status.
> And that is clear, also.
> OpenEHR specs are owned by the company that is owned by UCL, only.
>
>
>
> Gerard
>
> On Sep 3, 2015, at 2:07 AM, Ian McNicoll  wrote:
>
> Hi Bert,
>
> I am certainly conscious of rumours. Some of these are due to general
> suspicion of open source licensing (and we can, I think, do more to
> alleviate this)  but I am afraid some of anxiety is also caused by
> inaccurate and misleading information "openEHR is proprietary",  regularly
> stated by a small number of individuals. I have had to ask for these to be
> corrected in a number of documents e.g. The SemanticHealthNet report where
> it was agreed by the principal authors, including Dipak, to be incorrect.
>
> Since a significant number of companies and national organisations now
> make use of openEHR specifications or artefacts, these statements are being
> regarded as commercially hostile and the Foundation Boards both agree that
> legal action should now be taken where the authors are not prepared to
> promptly correct this inaccuracy.
>
> Leaving that aside. I am not convinced that ISO is a good home for
> openEHR. The specifications, development and revision process in ISO remain
> completely closed and quite at odds withopenEHR principles but I would be
> interested in other's views.
>
> I do think that some sort of association with a formal standards body
> would help alleviate some of the anxieties you mention (though these are
> imaginary) but I am not sure that ISO would be my first choice as it is
> currently constructed. I will raise the issue of whether to submit AOM2
> with the Management Board.
>
> I am interested in other people's opinions.
>
> Ian
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 1 September 2015 at 16:48, Bert Verhees  wrote:
>
>> On 01-09-15 17:16, Bert Verhees wrote:
>>
>>> I have written a text (reply to Erik) in Stackoverflow, describing why
>>> it will be good for OpenEHR if AOM2.0 will become an ISO-standard in the
>>> context of ISO13606 renewal.
>>>
>>>
>>> http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve/
>>>
>>
>> I must add, it is not that I suspect anyone of having secret IP on
>> OpenEHR.
>> I have no reason to suspect this.
>>
>> But I know people who have such suspicions, and having the AOM-part as an
>> ISO standard, surely will fight these rumors.
>>
>> I think it will help OpenEHR-implementations to have more customers.
>>
>> 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
>
>
>
> ___
> 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: Advantage of ISO

[Seref Arikan]

Thanks for your response.
Based on this response and another one you gave to Silje, do you think you
could give a number of owners of a standard, which you'd consider to be
sufficient to make a standard not proprietary? In layman terms: how many
owners should a standard have so that you would not call it proprietary?



On Thu, Sep 3, 2015 at 8:11 AM, "Gerard Freriks (privé)" <gf...@luna.nl>
wrote:

> In the case of CEN, ISO, HL7, SNOMED all members are the owner.
>
> Gerard
>
>
>
> On Sep 3, 2015, at 9:00 AM, Seref Arikan <
> serefari...@kurumsalteknoloji.com> wrote:
>
> Greetings,
> Just to clarify my understanding of your understanding of the term: would
> you say HL7 and Snomed CT are proprietary ?
>
>
>
> ___
> 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: difference and relationship between openEHR and EN13606

[Seref Arikan]

Sorry, but I have to ask: are you doing a homework?

On Friday, 28 August 2015, 王海生 edwin_ue...@163.com wrote:

 could we just add  a page on openEHR website to illustrate these points
 thx


 --
 王海生
 15901958021


 在 2015-08-28 01:54:58，Thomas Beale thomas.be...@oceaninformatics.com
 javascript:_e(%7B%7D,'cvml','thomas.be...@oceaninformatics.com'); 写道：

 On 26/08/2015 16:46, Erik Sundvall wrote:

 Hi!

 Where can one find proposals/diagrams describing the refreshed RM
 (reference model) in the new 13606 revision? Will 13606 keep using the
 old data types or harmonize more with CIMI or OpenEHR?

 Is there now consensus/majority regarding using ADL/AOM 2.0 for 13606? If
 so, great!

 When it comes to simplifying the RM (or perhaps moving complexity to
 another meta/design-pattern layer) I think CIMI has gone further than
 13606. Are there any plans of aligning 13606 with CIMI?


 I would suggest that CIMI has been simiplified to the point of not being
 directly usable as an RM by openEHR or 13606 - most of the needed context
 information is gone in CIMI, and it doesn't distinguish any kind of 'Entry'
 or clinical statement.

 This was a conscious choice in the CIMI community, designed to get buy-in
 from a much wider range of stakeholders than openEHR or 13606 deals with.
 Technically, the CIMI approach is to soft-model nearly everything in
 'reference archetypes'.

 - thomas



 夏日畅销榜大牌美妆只要1元
 http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=n...@163.com

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

Re: difference and relationship between openEHR and EN13606

[Seref Arikan]

All of it is very, very generalizable :)


On Thu, Aug 27, 2015 at 9:43 AM, Ian McNicoll i...@freshehr.com wrote:

 Presumably the outline syntax, SELECT, CONTAINS etc is generalisable?

 Ian

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

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

 On 27 August 2015 at 08:22, Bert Verhees bert.verh...@rosa.nl wrote:

 Like the Ocean Archetype editor. It only supports the OpenEhr RM only.
 That is understandable and no problem. The market will fill in that gap.
 Op 27 aug. 2015 01:49 schreef Heath Frankel 
 heath.fran...@oceaninformatics.com:

 Technical, the original grammar for AQL was bound to openEHR RM classes,
 composition, version, observation, etc. theoretically it could be
 generalised to be a RM agnostic and should be the goal of the current AQL
 specification work if it hasn't already been done in the antlr grammar.

 Regards

 Heath

 On 26 Aug 2015, at 9:40 pm, Ian McNicoll i...@freshehr.com wrote:

 Hi Diego,

 I was not aware of any 13606 implementations that support AQL , although
 I am sure there is some sort of path-based querying. AFAIK AQL is not part
 of the 13606 scope.

 Happy to be corrected.

 Ian

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

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

 On 26 August 2015 at 13:03, Diego Boscá yamp...@gmail.com wrote:

 I agree with most of the points, but I'm curious why you say that 13606
 does not support AQL (and in any case wouldn't be AQL does not support
 13606?)

 2015-08-26 12:32 GMT+02:00 Ian McNicoll i...@freshehr.com:

 This might help a little


 http://www.slideshare.net/atalagk/implementation-and-use-of-iso-en-13606-and-openehr

 Similarities:

 Both use archetypes and ADL and two-level information modelling.
 Both share the EHR, FOLDERS,COMPOSITIONS, ENTRY, ELEMENT classes.
 Some archetype tools can work with both styles of archetype e.g
 LinkEHR and Archetype Workbench.
 The just announced ADL2 Archetype editor/ template designer tools
 (beware!!! Early developer versions!!)

 http://ehrscape.marand.si/designer/template-editor.html

 http://ehrscape.marand.si/designer/archetype-editor.html

 should be relatively easy to adapt to 13606 or other archetype-based
 reference models such as CIMI. They will be open sourced very soon.

 Differences:

 The EHR reference models are different
  In spite of sharing the classes above, the attributes within those
 classes differ
  openEHR sub-classes ENTRY into ADMIN_ENTRY, OBSERVATION, EVALUATION,
 INSTRUCTION and ACTION
  The datatypes are different

 The demographic models are different
 The EHR Extract formats are different

 13606 is intended primarily for the communication of EHR extracts
 across systems but some persistence repositories exist.
 openEHR is intended primarily for data persistence and querying within
 systems but it is possible to message openEHR data.

 13606 does not (currently) support templates but ADL/AOM2 is being
 considered
 13606 does not support AQL Archetype Query Language

 13606 is  formal ISO standard but is closed source i.e. behind a
 paywall, as in normal for ISO published material
 openEHR is open source and freely available

 There is a great deal of cross-communication between the two
 communities and a number of people work with both formalisms. It is
 possible to transform data between the two formalisms but they are not
 directly compatible.

 I hope that is accurate and non-contentious!

 Ian





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

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

 On 26 August 2015 at 10:14, 王海生 edwin_ue...@163.com wrote:

 dear all ,
 how could i  explain to someone difference and relationship
 between openEHR and EN13606
 thx
 --
 王海生
 15901958021



 夏日畅销榜大牌美妆只要1元
 http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=n...@163.com

 ___
 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

 

Re: difference and relationship between openEHR and EN13606

[Seref Arikan]

Well, technically, it is not part of the openEHR scope either. Happy to be
corrected :)

On Wed, Aug 26, 2015 at 1:09 PM, Ian McNicoll i...@freshehr.com wrote:

 Hi Diego,

 I was not aware of any 13606 implementations that support AQL , although I
 am sure there is some sort of path-based querying. AFAIK AQL is not part of
 the 13606 scope.

 Happy to be corrected.

 Ian

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

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

 On 26 August 2015 at 13:03, Diego Boscá yamp...@gmail.com wrote:

 I agree with most of the points, but I'm curious why you say that 13606
 does not support AQL (and in any case wouldn't be AQL does not support
 13606?)

 2015-08-26 12:32 GMT+02:00 Ian McNicoll i...@freshehr.com:

 This might help a little


 http://www.slideshare.net/atalagk/implementation-and-use-of-iso-en-13606-and-openehr

 Similarities:

 Both use archetypes and ADL and two-level information modelling.
 Both share the EHR, FOLDERS,COMPOSITIONS, ENTRY, ELEMENT classes.
 Some archetype tools can work with both styles of archetype e.g LinkEHR
 and Archetype Workbench.
 The just announced ADL2 Archetype editor/ template designer tools
 (beware!!! Early developer versions!!)

 http://ehrscape.marand.si/designer/template-editor.html

 http://ehrscape.marand.si/designer/archetype-editor.html

 should be relatively easy to adapt to 13606 or other archetype-based
 reference models such as CIMI. They will be open sourced very soon.

 Differences:

 The EHR reference models are different
  In spite of sharing the classes above, the attributes within those
 classes differ
  openEHR sub-classes ENTRY into ADMIN_ENTRY, OBSERVATION, EVALUATION,
 INSTRUCTION and ACTION
  The datatypes are different

 The demographic models are different
 The EHR Extract formats are different

 13606 is intended primarily for the communication of EHR extracts across
 systems but some persistence repositories exist.
 openEHR is intended primarily for data persistence and querying within
 systems but it is possible to message openEHR data.

 13606 does not (currently) support templates but ADL/AOM2 is being
 considered
 13606 does not support AQL Archetype Query Language

 13606 is  formal ISO standard but is closed source i.e. behind a
 paywall, as in normal for ISO published material
 openEHR is open source and freely available

 There is a great deal of cross-communication between the two communities
 and a number of people work with both formalisms. It is possible to
 transform data between the two formalisms but they are not directly
 compatible.

 I hope that is accurate and non-contentious!

 Ian





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

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

 On 26 August 2015 at 10:14, 王海生 edwin_ue...@163.com wrote:

 dear all ,
 how could i  explain to someone difference and relationship between
 openEHR and EN13606
 thx
 --
 王海生
 15901958021



 夏日畅销榜大牌美妆只要1元
 http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=n...@163.com

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

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



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

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



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

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



 ___
 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: difference and relationship between openEHR and EN13606

[Seref Arikan]

Maybe this would help:
http://search.informit.com.au/documentSummary;dn=950616334398351;res=IELHEA


On Wed, Aug 26, 2015 at 10:14 AM, 王海生 edwin_ue...@163.com wrote:

 dear all ,
 how could i  explain to someone difference and relationship between
 openEHR and EN13606
 thx
 --
 王海生
 15901958021



 夏日畅销榜大牌美妆只要1元
 http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=n...@163.com

 ___
 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: openEHR @ StackExchange - getting close

[Seref Arikan]

Just tweeted for help. Feel free to do the same or RT

On Wed, Jun 10, 2015 at 11:56 PM, Thomas Beale 
thomas.be...@oceaninformatics.com wrote:


 We are getting closer
 http://area51.stackexchange.com/proposals/87508/openehrto the next
 step. We have 76 followers.

 We still need 17 questions with 10 votes. We have the requisite number of
 questions, it's just a case of people using their votes on them (don't
 worry if they don't really interest you, they are example questions - to
 get a stackexchange site, the community has to demonstrate interest).

 Many of the questions with  10 votes do have some votes, so we probably
 need a total of about 120 up-votes to get through this stage. I think each
 user gets 5 votes, so that's equivalent to 24 users.

 Remember, there is no value in up-voting a question that already has 10 or
 more votes.

 - thomas

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

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

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

Re: openEHR @ StackExchange - getting close

[Seref Arikan]

Thanks, can someone write a comment (shamelessly in capitals..)  under the
highest voted (16 the moment) question asking visitors to NOT to vote for
questions with  10 votes? My user can't do it for some reason.

There are ~19 wasted points that could have been used on other questions
a.t.m and people will just arrive and keep upvoting the top 5 ones. (This
is a weird design; if  10 votes do not help, why let users vote beyond 10
at that stage?)

On Thu, Jun 11, 2015 at 4:12 PM, Cavero Barca, Carlos 
carlos.cav...@atos.net wrote:

 Done! 90 followers :)

 Regards.
 Carlos.

 -Original Message-
 From: openEHR-technical [mailto:
 openehr-technical-boun...@lists.openehr.org] On Behalf Of Arild Faxvaag
 Sent: Thursday, June 11, 2015 3:46 PM
 To: For openEHR technical discussions
 Subject: Re: openEHR @ StackExchange - getting close

 done signing up and upvoting.

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

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 This e-mail and the documents attached are confidential and intended
 solely for the addressee; it may also be privileged. If you receive this
 e-mail in error, please notify the sender immediately and destroy it.
 As its integrity cannot be secured on the Internet, the Atos group
 liability cannot be triggered for the message content. Although the sender
 endeavors to maintain a computer virus-free network, the sender does not
 warrant that this transmission is virus-free and will not be liable for any
 damages resulting from any virus transmitted.

 Este mensaje y los ficheros adjuntos pueden contener información
 confidencial destinada solamente a la(s) persona(s) mencionadas
 anteriormente y pueden estar protegidos por secreto profesional.
 Si usted recibe este correo electrónico por error, gracias por informar
 inmediatamente al remitente y destruir el mensaje.
 Al no estar asegurada la integridad de este mensaje sobre la red, Atos no
 se hace responsable por su contenido. Su contenido no constituye ningún
 compromiso para el grupo Atos, salvo ratificación escrita por ambas partes.
 Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor
 no puede garantizar nada al respecto y no será responsable de cualesquiera
 daños que puedan resultar de una transmisión de virus.
 ___
 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: openEHR @ StackExchange - getting close

[Seref Arikan]

You're probably right. It is hard to find the acceptable level of strategic
voting :)

On Thu, Jun 11, 2015 at 4:54 PM, David Moner dam...@gmail.com wrote:

 I would not do so. This is not an automatic process, this first phase is
 just a way of filtering proposals. For sure the people in StackExchange
 will evaluate each proposal in detail, and if they find that votes and
 questions are clearly addressed or governed the proposal won't be accepted.

 2015-06-11 17:41 GMT+02:00 Seref Arikan serefari...@kurumsalteknoloji.com
 :

 Thanks, can someone write a comment (shamelessly in capitals..)  under
 the highest voted (16 the moment) question asking visitors to NOT to vote
 for questions with  10 votes? My user can't do it for some reason.

 There are ~19 wasted points that could have been used on other questions
 a.t.m and people will just arrive and keep upvoting the top 5 ones. (This
 is a weird design; if  10 votes do not help, why let users vote beyond 10
 at that stage?)

 On Thu, Jun 11, 2015 at 4:12 PM, Cavero Barca, Carlos 
 carlos.cav...@atos.net wrote:

 Done! 90 followers :)

 Regards.
 Carlos.

 -Original Message-
 From: openEHR-technical [mailto:
 openehr-technical-boun...@lists.openehr.org] On Behalf Of Arild Faxvaag
 Sent: Thursday, June 11, 2015 3:46 PM
 To: For openEHR technical discussions
 Subject: Re: openEHR @ StackExchange - getting close

 done signing up and upvoting.

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

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 This e-mail and the documents attached are confidential and intended
 solely for the addressee; it may also be privileged. If you receive this
 e-mail in error, please notify the sender immediately and destroy it.
 As its integrity cannot be secured on the Internet, the Atos group
 liability cannot be triggered for the message content. Although the sender
 endeavors to maintain a computer virus-free network, the sender does not
 warrant that this transmission is virus-free and will not be liable for any
 damages resulting from any virus transmitted.

 Este mensaje y los ficheros adjuntos pueden contener información
 confidencial destinada solamente a la(s) persona(s) mencionadas
 anteriormente y pueden estar protegidos por secreto profesional.
 Si usted recibe este correo electrónico por error, gracias por informar
 inmediatamente al remitente y destruir el mensaje.
 Al no estar asegurada la integridad de este mensaje sobre la red, Atos
 no se hace responsable por su contenido. Su contenido no constituye ningún
 compromiso para el grupo Atos, salvo ratificación escrita por ambas partes.
 Aunque se esfuerza al máximo por mantener su red libre de virus, el
 emisor no puede garantizar nada al respecto y no será responsable de
 cualesquiera daños que puedan resultar de una transmisión de virus.
 ___
 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




 --
 David Moner Cano
 Grupo de Informática Biomédica - IBIME
 Instituto ITACA
 http://www.ibime.upv.es
 http://www.linkedin.com/in/davidmoner

 Universidad Politécnica de Valencia (UPV)
 Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
 Valencia – 46022 (España)

 ___
 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: openEHR @ StackExchange - progress

[Seref Arikan]

To all who are helping with this: there are questions with upvotes  10. I
think this is a waste of your upvotes; we need to get as many as possible
to 10, upvoting beyond 10 does not help with our goal of creating an
openEHR area.
Also, some of the questions do not comply with QA format; generic
discussions can be problematic if someone reviews them. Again, these would
be waste of upvotes.

On Mon, Jun 8, 2015 at 9:52 PM, Thomas Beale 
thomas.be...@oceaninformatics.com wrote:

  For all those who suffer from 'not enough expert resources for openEHR'
  you can make it happen - if we can create an openEHR StackExchange
 area.

 To get a StackExchange area, we still need to get 16 more followers and
 create 38 more example questions with a score of 10 or more
 http://area51.stackexchange.com/proposals/87508/openehr. We actually
 only need 10 new questions - we have 28, they just need more votes.

 To up the scores on the questions, just upvote them (but not beyond 10).
 Remember these are example questions - the idea is just to show that there
 are enough people interested to make it worthwhile.
 Please use all your possible upvotes to get more questions to a score of
 10!

 Please forward to colleagues in your institution or company to get us over
 the line.

 thanks

 - thomas


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

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

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

OpenEHR and Oracle XML DB problems

[Seref Arikan]

Hi Birger,
Thanks for link to Katrin's work.

Regards
Seref


On Thu, Apr 16, 2015 at 10:32 AM, Birger Haarbrandt 
birger.haarbrandt at plri.de wrote:

  Hi Thomas,

 do we really need realistic data sets? At least in the beginning, many
 programmers that are new to openEHR would already be happy with some valid
 data instances.

 If anyone likes to do such a synthesier: Katrin Dentler has done some work
 on patient data generation (
 http://www.cs.vu.nl/~frankh/postscript/KR4HC-2013-APDG.pdf)... maybe she
 can provide some existing code and knowledge if anybody wants to build such
 a thing :) (It might be a little out of scope for my department)

 Best,

 Birger

 Am 16.04.2015 um 11:13 schrieb Thomas Beale:


 Indeed, it would be a great thing. The reason it doesn't exist so far, is
 that to be useful we need synthesised data sets that have some realistic
 statistical spread of values. Since we are talking at multiple levels - not
 just vital signs measurements, but covariance of all kinds of measurements
 with assessments (diagnosis etc), plans and orders and actions, the
 complexity is not trivial.

 A data synthesiser to do this for openEHR would be a fantastic Master's
 project (hint :).

 - thomas

 On 16/04/2015 10:02, Dmitry Baranov wrote:

 Diego,
 that'll be great.
 Hope that OpenEHR github owners will provide us with an instance samples
 repository some day or other :)

 I can generate random sample instances from current archetypes for you
 if you need them. Generated data may not make much sense as it only
 tries to follow the archetype constraints, but it should be enough for
 application testing and benchmark




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

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



 --
 *Birger Haarbrandt, M.Sc.*

 Peter L. Reichertz Institut f?r Medizinische Informatik
 Technische Universit?t Braunschweig und
 Medizinische Hochschule Hannover
 M?hlenpfordtstra?e 23
 D-38106 Braunschweig

 T +49 (0)531 391-2129
 F +49 (0)531 391-9502
 birger.haarbrandt at plri.de
 http://www.plri.de

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150416/9436b7d2/attachment.html

OpenEHR .oet XML schema

[Seref Arikan]

Hi Ian,
I'm not sure if you're prescribing the right medicine here :) My
understanding is Dmitry is looking for a schema to use as the basis of
persistence. Opt(operational template)s define models, not actual data
instances that conform to models.

Assuming that this is the case, the canonical schemas published along the
specifications is more likely to be the answer. Dmitry, have you asked
yourself the following question: what will happen when new templates are
introduced? Will you create a set of tables for each new template? If you
are to drive persistence implementation through a schema, you'd better
invest into one that does not change as models change. The canonical schema
satisfies this property.

Regards
Seref




On Tue, Apr 14, 2015 at 12:57 PM, Ian McNicoll ian at freshehr.com wrote:

 The correct artefact to use for this purpose is the operational template
 originally developed by Ocean.

 If you look at the Marand ehrscape API dev.ehrscape.com you will see how
 it used

 The Ocean, code24, Privantis, Infinnity , ADOC. Cabolabs and Nousco
 backends all use this format.

 Ian
 On Tue, 14 Apr 2015 at 12:32, Dmitry Baranov baranovda at yandex.ru wrote:

 Hi Ian,
 I'm trying to implement a EHR module that uses Oracle XML DB as a storage
 for clinical records in form of clinical document. A  template defines the
 structure of such document (consultation note, evaluation note, operation
 note and so on), and EHR module produces a document that match particular
 template. So I just need an XML-schema-based template definition format but
 can't decide which one is more suitable.
 Got your links, thank you.


  .oet is an internal Ocean format used by the Template Designer.
  As far as I know this is the current version
 
 https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/xsd/CompositionTemplate.xsd
  The key template schema which you should probably be investigating is
 the Operational
  Template .opt (which is generated by the Template Designer).
 
 https://github.com/openEHR/java-libs/blob/master/oet-parser/src/main/xsd/Template.xsd
  It depends on what are you trying to do. Can you tell us more about
 your project?

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

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


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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150414/006fd7cb/attachment.html

OpenEHR .oet XML schema

[Seref Arikan]

In that case, kudos and apologies to Ian. His suggestion is spot on.

On Tue, Apr 14, 2015 at 2:33 PM, Dmitry Baranov baranovda at yandex.ru wrote:

 Hi Seref, persistence is clear for me, and I was looking for an
 appropriate model XML-schema, of course.

  Seref Arikan
  Hi Ian, I'm not sure if you're prescribing the right medicine here :) My
 understanding is Dmitry is looking for a schema to use as the basis of
 persistence.

 Regards, Dmitry

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150414/9ff6e93f/attachment.html

CRUD Restlet

[Seref Arikan]

I've managed not to respond for some time but this discussion got to a
point where I can't help commenting :)

REST is a fact of the industry, due to whatever mysterious dynamics that
pushes various solutions down our throat as we get old in front of our
computers. So we live with it.

This does not change the fact that trying to push complex shaped objects
through a few holes shaped as a rectangle, circle and a triangle will leave
some parts of those objects broken. Then we have people discussing for ages
what the right verb mapping would be for an operation. If you try to
express an infinite number of API calls and their semantics with a bunch of
HTTP operations and status codes, this is what you get.

REST may make things easy for some use cases, but do complex use cases in
healthcare fall into that category? I should probably look at Erik's
research at one point but my dislike for being forced to express semantics
with a very limited number of some text transfer protocol based concepts
will not go away.

Best regards
Seref


On Mon, Jan 19, 2015 at 5:59 AM, Bert Verhees bert.verhees at rosa.nl wrote:

 I checked on how the large companies like Google, Amazon, PayPal, github
 do it.

 They all have a hybrid solution. They all use an own error schema was
 verbal terms, sometimes hierarchical, and they all map their errors to the
 http numerical status schema.

 This means that a query with no result is qualified as a 404 error.
 However this seems unlogical to me, is that how the big guys it do. It is
 the same error which is fired when you try to call a non existing method.
 But the accompanying message is different.

 It is difficult for me to qualify a query which has no result as an error.
 Have you ever been sick? No? That is a 404 error.

 But on the other hand, that is how the big guys do it.

 Bert

 Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees at rosa.nl het
 volgende geschreven:

 Ok, you are right, but http is a very generic application layer, not to
 designed to serve specific application needs, but designed to serve web
 servers which only serve documents.
 As you know, a web server is a very generic application, which, from the
 time Http was designed, was only recource driven.

 Maybe the error is that Rest uses a generic application layer which is
 defined as a resource driven application layer, but in fact Rest is used as
 a service oriented application protocol. I think that an OpenEhr kernel, or
 PayPal-service, or many other Rest using applications are also service
 oriented, not only resource oriented, and that therefor, a resource
 oriented error handling is unable to serve the needs of a service oriented
 application.

 You could call that misusing http, because it was not designed for that,
 but on the other hand, with some new thinking, Http can be used to serve a
 service oriented architecture. Or do you not agree with this statement?

 By the way, nowhere is written that Rest must use the Http status
 mechanism for communicating application needs. It is written that Rest must
 used http statuses for http-needs, and Restlet does do that.

 best regards
 Bert

 Op maandag 19 januari 2015 heeft Peter Gummer 
 peter.gummer at oceaninformatics.com het volgende geschreven:

  Bert Verhees wrote:

   The point for me is separation of transport layer and application
 layer, and each domain has its own errorhandling.



  Hi Bert,

  HTTP is not a transport layer protocol:

  http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

  ?The *Hypertext Transfer Protocol* (*HTTP*) is an application protocol
 http://en.wikipedia.org/wiki/Application_protocol ?

  Thanks for the discussion, though. I?ve learned a lot from it.

  Peter



 --

 *This e-mail message is intended exclusively for the addressee(s). Please
 inform us immediately if you are not the addressee.*



 --

 *This e-mail message is intended exclusively for the addressee(s). Please
 inform us immediately if you are not the addressee.*


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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/a8116c6b/attachment-0001.html

CRUD Restlet

[Seref Arikan]

Birger and Diego,
Thanks for the useful pointers. I'll take these as starting points to see
how healthcare IT embraces REST.

Best regards
Seref

On Mon, Jan 19, 2015 at 10:31 AM, Birger Haarbrandt 
birger.haarbrandt at plri.de wrote:

  The medrecord openEHR server is also based on REST and worth looking at.
 There was a lot to learn from for me as the API is pretty neat.

 Best,

 Birger

 Am 19.01.2015 11:29, schrieb Diego Bosc?:

 I will just add that if you are making a server you probably want to
 take a look and how FHIR does things. They have some pretty cool ideas
 for common problems that you can probably reuse (e.g. using atom for
 query responses)

 2015-01-19 11:25 GMT+01:00 Seref Arikan serefarikan at 
 kurumsalteknoloji.com serefarikan at kurumsalteknoloji.com:

  I've managed not to respond for some time but this discussion got to a point
 where I can't help commenting :)

 REST is a fact of the industry, due to whatever mysterious dynamics that
 pushes various solutions down our throat as we get old in front of our
 computers. So we live with it.

 This does not change the fact that trying to push complex shaped objects
 through a few holes shaped as a rectangle, circle and a triangle will leave
 some parts of those objects broken. Then we have people discussing for ages
 what the right verb mapping would be for an operation. If you try to express
 an infinite number of API calls and their semantics with a bunch of HTTP
 operations and status codes, this is what you get.

 REST may make things easy for some use cases, but do complex use cases in
 healthcare fall into that category? I should probably look at Erik's
 research at one point but my dislike for being forced to express semantics
 with a very limited number of some text transfer protocol based concepts
 will not go away.

 Best regards
 Seref


 On Mon, Jan 19, 2015 at 5:59 AM, Bert Verhees bert.verhees at rosa.nl 
 bert.verhees at rosa.nl wrote:

  I checked on how the large companies like Google, Amazon, PayPal, github
 do it.

 They all have a hybrid solution. They all use an own error schema was
 verbal terms, sometimes hierarchical, and they all map their errors to the
 http numerical status schema.

 This means that a query with no result is qualified as a 404 error.
 However this seems unlogical to me, is that how the big guys it do. It is
 the same error which is fired when you try to call a non existing method.
 But the accompanying message is different.

 It is difficult for me to qualify a query which has no result as an error.
 Have you ever been sick? No? That is a 404 error.

 But on the other hand, that is how the big guys do it.

 Bert

 Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees at rosa.nl 
 bert.verhees at rosa.nl het
 volgende geschreven:


  Ok, you are right, but http is a very generic application layer, not to
 designed to serve specific application needs, but designed to serve web
 servers which only serve documents.
 As you know, a web server is a very generic application, which, from the
 time Http was designed, was only recource driven.

 Maybe the error is that Rest uses a generic application layer which is
 defined as a resource driven application layer, but in fact Rest is used as
 a service oriented application protocol. I think that an OpenEhr kernel, or
 PayPal-service, or many other Rest using applications are also service
 oriented, not only resource oriented, and that therefor, a resource oriented
 error handling is unable to serve the needs of a service oriented
 application.

 You could call that misusing http, because it was not designed for that,
 but on the other hand, with some new thinking, Http can be used to serve a
 service oriented architecture. Or do you not agree with this statement?

 By the way, nowhere is written that Rest must use the Http status
 mechanism for communicating application needs. It is written that Rest must
 used http statuses for http-needs, and Restlet does do that.

 best regards
 Bert

 Op maandag 19 januari 2015 heeft Peter Gummerpeter.gummer at 
 oceaninformatics.com peter.gummer at oceaninformatics.com het volgende 
 geschreven:

  Bert Verhees wrote:


  The point for me is separation of transport layer and application
 layer, and each domain has its own errorhandling.



 Hi Bert,

 HTTP is not a transport layer protocol:
 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

 ?The Hypertext Transfer Protocol (HTTP) is an application protocol ?

 Thanks for the discussion, though. I?ve learned a lot from it.

 Peter



 --
 This e-mail message is intended exclusively for the addressee(s).
 Please inform us immediately if you are not the addressee.



 --
 This e-mail message is intended exclusively for the addressee(s).
 Please inform us immediately if you are not the addressee.


 ___
 openEHR-technical mailing listopenEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman

CRUD Restlet

[Seref Arikan]

Hi Ian,
Thanks for the response. Just to clarify: as I've written, REST works for
some simple cases and delivers an economic advantage as you've also
expressed in the form of getting non specialist developers involved.

I for one am happy to see FHIR exploring this, which is apparently
delivering good results. As I've written, we'll leave with REST, it is an
industry standard now for many things. As long as we don't try to push
everything into it, we should be able to see benefits.

Best regards
Seref


On Mon, Jan 19, 2015 at 10:51 AM, Ian McNicoll ian at freshehr.com wrote:

 Hi Seref,

 You are of course correct that FHIR or any other RESTful approaches
 may struggle in more complex scenarios but I think there is increasing
 evidence that simpler approaches can bring immense benefit and are an
 order of magnitude easier to implement for non-specialist developers.

 In the UK, FHIR is rapidly becoming the de-facto Industry standard for
 GP system interfaces butt here is strong recognition that the clinical
 content development/ maintenance is not going to scale, which is why
 openEHR has now been picked up (again) by the NHS.

 I think the openEHR implementer community has a huge opportunity to
 show how it can play very effectively in this emerging space.

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

 Director, freshEHR Clinical Informatics
 Director, openEHR Foundation
 Director, HANDIHealth CIC
 Hon. Senior Research Associate, CHIME, UCL


 On 19 January 2015 at 10:25, Seref Arikan
 serefarikan at kurumsalteknoloji.com wrote:
  I've managed not to respond for some time but this discussion got to a
 point
  where I can't help commenting :)
 
  REST is a fact of the industry, due to whatever mysterious dynamics that
  pushes various solutions down our throat as we get old in front of our
  computers. So we live with it.
 
  This does not change the fact that trying to push complex shaped objects
  through a few holes shaped as a rectangle, circle and a triangle will
 leave
  some parts of those objects broken. Then we have people discussing for
 ages
  what the right verb mapping would be for an operation. If you try to
 express
  an infinite number of API calls and their semantics with a bunch of HTTP
  operations and status codes, this is what you get.
 
  REST may make things easy for some use cases, but do complex use cases in
  healthcare fall into that category? I should probably look at Erik's
  research at one point but my dislike for being forced to express
 semantics
  with a very limited number of some text transfer protocol based concepts
  will not go away.
 
  Best regards
  Seref
 
 
  On Mon, Jan 19, 2015 at 5:59 AM, Bert Verhees bert.verhees at rosa.nl
 wrote:
 
  I checked on how the large companies like Google, Amazon, PayPal, github
  do it.
 
  They all have a hybrid solution. They all use an own error schema was
  verbal terms, sometimes hierarchical, and they all map their errors to
 the
  http numerical status schema.
 
  This means that a query with no result is qualified as a 404 error.
  However this seems unlogical to me, is that how the big guys it do. It
 is
  the same error which is fired when you try to call a non existing
 method.
  But the accompanying message is different.
 
  It is difficult for me to qualify a query which has no result as an
 error.
  Have you ever been sick? No? That is a 404 error.
 
  But on the other hand, that is how the big guys do it.
 
  Bert
 
  Op maandag 19 januari 2015 heeft Bert Verhees bert.verhees at rosa.nl
 het
  volgende geschreven:
 
  Ok, you are right, but http is a very generic application layer, not to
  designed to serve specific application needs, but designed to serve web
  servers which only serve documents.
  As you know, a web server is a very generic application, which, from
 the
  time Http was designed, was only recource driven.
 
  Maybe the error is that Rest uses a generic application layer which is
  defined as a resource driven application layer, but in fact Rest is
 used as
  a service oriented application protocol. I think that an OpenEhr
 kernel, or
  PayPal-service, or many other Rest using applications are also service
  oriented, not only resource oriented, and that therefor, a resource
 oriented
  error handling is unable to serve the needs of a service oriented
  application.
 
  You could call that misusing http, because it was not designed for
 that,
  but on the other hand, with some new thinking, Http can be used to
 serve a
  service oriented architecture. Or do you not agree with this statement?
 
  By the way, nowhere is written that Rest must use the Http status
  mechanism for communicating application needs. It is written that Rest
 must
  used http statuses for http-needs, and Restlet does do that.
 
  best regards
  Bert
 
  Op maandag 19 januari 2015 heeft Peter Gummer
  peter.gummer

Does anyone implemented a transformation between AQL and XML?

[Seref Arikan]

Ok, I think I see what you mean now.

AQL is not part of the official specification and there is not much other
than the grammar for the implementers so you're right about not having a
lot to work with.
On the other hand, if you're going to do AQL, you're going to have to have
a parser. Marand has kindly provided an ANTLR grammar here:
https://openehr.atlassian.net/wiki/display/spec/AQL-+Archetype+Query+Language

To use this grammar, you're going to have to invest into learning ANLTR and
inevitably into parser generators. Not an easy topic if you're not familiar
with it but I personally think it is worth it.

due to way ANTLR works, Marand's grammar should get you really close to
what you're asking without much effort. You'll probably have more of a
challenge when trying to map the output of the parser to your query
mechanism.

So the obvious pointer is the ANTLR grammar, the rest depends on your
efforts :)

All the best
Seref


On Wed, Dec 17, 2014 at 8:31 PM, pablo pazos pazospablo at hotmail.com wrote:

 Hi Seref, what I asked here was if anyone did implemented that, so I don't
 have to :)

 As I said, my experience tells me it requires more hours-man to work with
 a syntax, a model and a parser than having XML and parse parts of it when
 required (so I can have 1. many ad-hoc parsers, 2. no model just ad-hoc
 data structures, 3. no API, 4. no parser e.g. it requires a lot of time to
 find a problem update the jj, generate the parser and test).

 Hope that clarifies my vision.

 Of course, I didn't started yet to do anything about AQL support, just
 trying to make the community aware that I'll do so and maybe generate some
 collaboration momentum. Maybe the syntax definition is very stable and
 there are a lot of good parsers for Java, but the syntax definition I found
 seems to be old (
 https://openehr.atlassian.net/wiki/display/spec/Archetype+Query+Language+Grammar
  
 https://openehr.atlassian.net/wiki/display/spec/AQL-+Archetype+Query+Language)
 and I don't know about AQL parsers for Java (just found this old
 discussion, no response about the parser:
 http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2009-March/004400.html
 ).

 I'm sure I need to do more research, but I doubt I can find the basic
 building blocks, even to start working with AQL directly.

 Please if you know where I can find stuff to help me, any pointers will be
 very welcome!

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home
 http://twitter.com/ppazos

 --
 Date: Wed, 17 Dec 2014 19:03:28 +

 Subject: Re: Does anyone implemented a transformation between AQL and XML?
 From: serefarikan at kurumsalteknoloji.com
 To: openehr-technical at lists.openehr.org

 Hi Pablo,
 Sorry but I still don't get it :) How are you going to do the following
 without an AQL parser?:

 AQL (syntax) =(transformation)= XML (syntax)


 If you have an xml form of AQL and use only that, you'd have to force your
 users write queries in the xml form of AQL which would defeat the whole
 purpose of the AQL.

 So I'm still not seeing how you're gaining anything with an XML form of
 AQL.

 Best regards
 Seref


 On Wed, Dec 17, 2014 at 4:17 PM, pablo pazos pazospablo at hotmail.com
 wrote:

 Hi Seref,

 Yes! Just need the transformation to have an AQL in XML syntax.

 What I was thinking is trying to add support to AQL in the EHRServer,
 doing something like this:

 AQL (syntax) =(transformation)= XML (syntax) =(mapping)= EHRServer
 Query Model (OO) =(ORM)= Query Storage

 I already have the part for Evaluating/Executing queries that are
 represented in the EHRServer Query Model.

 Having this I can import and export AQL, and I don't need to actualy
 execute AQL.


 This is in fact one way of implementing The point of AQL is sending the
 same query to multiple implementations.


 Why not dealing with AQL directly?

 In my experience in implementing software with ADLs and OPTs, managing
 OPTs in XML is way simpler: I can write my own parsers for specific tasks
 without the need of parsing the whole structure and then deal with an
 object instance in memory (sometimes buggy, difficult to access specific
 data, APIs not so well defined, non implemented methods, etc). So it is a
 matter of risk management and cost reduction (since I'm the only one
 working on the EHRServer I need to search for the shortest path to do each
 task will a certain level of quality).

 So I have the same idea with AQL: not deal with AQL parsers or object
 instances, just the XML. The idea of this request is that I don't want to
 develop an XML syntax for XML: it would be great if someone else already
 have that done so I can reuse.

 This way I don't need to have to deal with an AQL parser :)


 Hope that helps!

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/home
 http://twitter.com/ppazos

 --
 Date: Tue, 16 Dec 2014 

Problem-oriented records and querying by problem

[Seref Arikan]

My bad: using a consistent terminology is hard sometimes. When I say data
view, I mean openEHR data.

So my 100 compositions are good old openEHR compositions in an openEHR
implementation.
All my layers are in openEHR, building on top of each other. So if you (and
I) take openEHR clinical data as information (even though I called it data
previously) I'm suggestion transformations of information to higher levels.

Each level knows about what is below it (Problem lists know about clinical
data, they don't know about care plans) but does not know in which context
it is going to be used. So problem lists would not have any references to
care plans.

I can't agree or disagree with you regarding how fundamental problem
orientation is; I am not a clinician. But I could enforce it in a clean and
customisable way if I use the architecture I suggested. Some of these
layers I've suggested may not be easily definable (if there is such a
word..) in openEHR but that is OK, this is why there are PhD programmes out
there.

So I guess my point is; when Pablo asks how do I do problem oriented
records with openEHR, I'd say using an architecture like this, based on a
slight modification of Tom's (IMHO) correct suggestion of computable care
plans. Your points would all be mapped into that architecture and become
software implementation tasks and decisions.

Best regards
Seref


On Thu, Nov 20, 2014 at 1:03 PM, Karsten Hilbert Karsten.Hilbert at gmx.net
wrote:

 On Wed, Nov 19, 2014 at 02:00:46PM +, Seref Arikan wrote:

  Maybe I'm losing some clinical context by adopting a data view of the
  setting but would not a problem oriented record be a 'view' on clinical
  data ?

 Ah, putting it that way makes sense, too: the POMR approach
 to be a view integrating data into information.

 My point would be that problem orientation is so fundamental
 a view that it should really be mandatory (even if only
 internally -- if physicians can't be bothered with thinking
 about which problem to attribute items to a coarsely grained
 ordering, say along the lines of ICPC, might get applied
 based on, say, provider speciality or some such).

  The clinical problem is obviously context dependant (cancer,
  diabetes etc) so this sounds like a higher order view on top of clinical
  data to me. I'd see problem list as a 2nd order construct like you, but I
  guess I'd consider problem oriented record at 3rd and Care plan at 4th
  level.

 Interesting idea: comprehensive care plan, not necessarily
 per-problem.  Maybe per-goal (for which health goals must not
 be per-problem ;-) ?

  If care plan is what the name implies than it involves actions to be
 taken
  on top of a particular problem view so I'd feel safer having that in its
  own layer.  So I'd consider something like:
 
  Say an EHR with ~100 compositions (1st level).

 IOW, a data store rather than an EHR.

  A problem list as a persistence composition (2nd level),

 The minimum requirement for the data store to become an EHR.

 Thanks,
 Karsten
 --
 GPG key ID E4071346 @ eu.pool.sks-keyservers.net
 E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141120/8240b3ef/attachment.html

Problem-oriented records and querying by problem

[Seref Arikan]

Maybe I'm losing some clinical context by adopting a data view of the
setting but would not a problem oriented record be a 'view' on clinical
data ? The clinical problem is obviously context dependant (cancer,
diabetes etc) so this sounds like a higher order view on top of clinical
data to me. I'd see problem list as a 2nd order construct like you, but I
guess I'd consider problem oriented record at 3rd and Care plan at 4th
level.

If care plan is what the name implies than it involves actions to be taken
on top of a particular problem view so I'd feel safer having that in its
own layer.  So I'd consider something like:

Say an EHR with ~100 compositions (1st level).
A problem list as a persistence composition (2nd level),
A problem oriented view that consist of compositions that are related to a
power set of the problem list (3rd level)
A care plan that uses the problem view and other computable care action
concepts (4th level)

The definition of problem oriented view belongs to 3rd level and you can
have different care plans for the same problem view at the 4th etc etc..


On Wed, Nov 19, 2014 at 1:35 PM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

  On 18/11/2014 03:34, pablo pazos wrote:

 Hi all, just re-sending this question on the clinical list too.

  I'm wondering how to handle the link between documents and health
 problems in a problem-oriented record.


 I think the future will be that a Care Plan informational construct (note:
 for US, something very closely related to an 'order set'), partially
 manually written, partially machine populated with links to relevant items,
 will be the thing that ties it together. Consider: the proof that something
 really is considered a 'problem', out of all the non-problems and trivial
 problems (e.g. one-off throat infection) is that some clinical professional
 wants to create a care plan, to define ongoing treatment and track
 interventions (all medications, other interventions etc).

 A flexible model of a Care Plan (for each major ailment) that allows tying
 together of such information, and is machine-updated, I think will end up
 being the main way clinical professionals can interact with the raw data.
 We can imagine a Care Plan 'service' with an API for add/update/remove
 items/rules and apps for looking at care plans.

 Behind the Care Plan(s) in the EHR we still need managed medication
 list(s) and problem list.

 I see the latter two as 2nd order informational constructs, and Care Plans
 as 3rd order constructs.

 - thomas

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141119/c4e2c330/attachment-0001.html

openEHR-technical Digest, Vol 32, Issue 31

[Seref Arikan]

Programmers waste enormous amounts of time thinking about, or worrying
about, the speed of noncritical parts of their programs, and these attempts
at efficiency actually have a strong negative impact when debugging and
maintenance are considered. We *should* forget about small efficiencies,
say about 97% of the time: *premature optimization is the root of all evil*

Knuth, Donald E. Structured Programming with go to Statements. *ACM
Computing Surveys (CSUR)* 6.4 (1974): 261-301.

On Tue, Oct 7, 2014 at 9:46 PM, William Goossen wgoossen at results4care.nl
wrote:

 Take care of a big caveat please: all health information systems start and
 end with the human being. We should use the IT support that Thomas suggests
 where possible, but to the extend that humans cannot make mistakes. And
 the governance of archetypes / DCMs / valuesets / etc does require human
 intervention and hence human understanding. So naming conventions are
 important and are a different beast than the versioning of the file /
 content.
 Thomas' trick with the software reading the meta information is fine for
 one
 specific purpose eg a record handling 100 archetypes or a composition of 88
 DCMs. However, what if that same system must do this for all 100 archetypes
 for 25 - 100 diseases per specialty, with 30 specialties (100 x 25 x 30)
 and
 allowing all kinds of combinations so x n. Beside the safety and quality
 also performance comes into the picture. And I am not speaking yet of each
 use of these combinations, e.g. for screens / data entry, storage,
 communication, querying, aggregation, decision support etc.

 All the best,

 William Goossen

 -Original Message-
 From: openEHR-technical [mailto:
 openehr-technical-bounces at lists.openehr.org]
 On Behalf Of openehr-technical-request at lists.openehr.org
 Sent: Tuesday, October 07, 2014 18:00
 To: openehr-technical at lists.openehr.org
 Subject: openEHR-technical Digest, Vol 32, Issue 31

 Send openEHR-technical mailing list submissions to
 openehr-technical at lists.openehr.org

 To subscribe or unsubscribe via the World Wide Web, visit


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

 or, via email, send a message with subject or body 'help' to
 openehr-technical-request at lists.openehr.org

 You can reach the person managing the list at
 openehr-technical-owner at lists.openehr.org

 When replying, please edit your Subject line so it is more specific than
 Re: Contents of openEHR-technical digest...


 Today's Topics:

1. Re: Archetype Naming proposals - do we need V0? (Thomas Beale)
2. Re: Archetype Naming proposals - do we need V0? (Thomas Beale)
3. Re: Archetype Naming proposals - do we need V0? (Shinji KOBAYASHI)
4. Re: Archetype Naming proposals - do we need V0? (Ian McNicoll)


 --

 Message: 1
 Date: Mon, 06 Oct 2014 17:00:45 +0100
 From: Thomas Beale thomas.beale at oceaninformatics.com
 To: openehr-technical at lists.openehr.org
 Subject: Re: Archetype Naming proposals - do we need V0?
 Message-ID: 5432BCAD.3090902 at oceaninformatics.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On 03/10/2014 22:08, Bert Verhees wrote:
  On 03-10-14 22:28, Thomas Beale wrote:
  Filename is irrelevant, and has been freely choosable for 5-10 years
  in all archetype modelling tools that I know of.
  Except from CKM, it offers, when I click Export Archetype (ADL) a
  file named after the archetypeId with extension ADL or XML, if I click
  on the other.


 well that's normal - that's on download - the file has to be called
 something ;-)

 - thomas



 --

 Message: 2
 Date: Mon, 06 Oct 2014 17:40:46 +0100
 From: Thomas Beale thomas.beale at oceaninformatics.com
 To: openehr-technical at lists.openehr.org
 Subject: Re: Archetype Naming proposals - do we need V0?
 Message-ID: 5432C60E.6060007 at oceaninformatics.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 On 06/10/2014 16:52, Shinji KOBAYASHI wrote:
  Hi Thomas Beale,
 
  openEHR-EHR-ADMIN_ENTRY.encounter.v1 =
  org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v0.0.1 = review 
  changes = org.openEHR::openEHR-EHR-ADMIN_ENTRY.encounter.v1.0.0
  Would file name nomenclature be changed? There is no spec for file
  name of archetype, but archetype ids have been assigned to file names.
  Whereas, : is not available for file name in Windows OS (and old Mac OS).
 

 well, as mentioned before, filenames don't matter, but of course when a
 tool
 generates a file, it should use an obvious name, something related to the
 id. And you are right - ':' won't work on Windows (we'll never stop cursing
 the stupid Windows directory and file-naming will we).
 So it will need to be something else, maybe just using the '-'
 character. So for that reason, we had better add a file-system friendly
 variant of the full id...

 I'll 

Archetype Naming proposals - do we need V0?

[Seref Arikan]

Hi Ian,
Personally I think V0 has significant costs in exchange for not so
significant benefits. Semver compatibility would be nice, but nice is not
worth the implementation cost for parser etc here. I don't know if V0
support would break things deep down in actual openEHR implementations but
even that may be a possibility if there is a reg-ex sitting in some code
that expects v1 as the starting point.
The features in adl 1.5 would probably help provide a workaround to express
the semantics that would otherwise be expressed with V0

Best regards
Seref


On Wed, Oct 1, 2014 at 11:23 AM, Ian McNicoll ian at mcmi.co.uk wrote:


 Hi all,

 Apologies for cross-posting in both clinical and technical but this does
 neatly cross that divide.

 We are getting close in CKM to implementing the ADL1.5 archetype naming
 /versioning rules proposed at

 *http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification*
 http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Identification

 mostly by adding the metadata to the ADL other_details section, which
 means we can carry the information in ADL 1.4 archetypes without disturbing
 current systems.

 These latest proposals are now very much in line with the de-facto
 standard SemVer 2.0 see http://semver.org which allows

 major revision
 minor revision
 patch
 build

 but one of the questions which remains controversial is whether to support
 a major revision of V0 (as allowed in SemVer).

 In Semver, V0 is allowed for very immature ?first draft? semantic
 artefacts/APIs prior to initial release but SemVer allows for any revision
 to appended with a pre-release modifier

 e.g. v2.0.0-alpha or v1.0.0-unstable

 This is recognised as meaning that the artefact is unstable and the
 version numbering cannot be relied on e.g to assert backward compatibility.

 In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their
 ?stability? and lack of commitment to the versioning rules.

 So the question for us in the openEHR world is whether tooling should
 support v0.0.0, or simply use v1.0.0-unstable

 V0 Advantages

 1. The archetype is clearly marked as immature
 2. Full compliance with SemVer
 3. Supported in current test build of CKM

 V0 Disadvantages

 1. Tooling e.g Archetype Editor (actually ADL Parser) needs to change to
 support V0
 2. Add another layer of complexity to the archetype naming/versioning rules
 3. Question arises of whether / if to convert current draft V1 CKM
 archetypes to V0 with overhead of explanation to current users.
 4. Adds complexity where V0 archetypes are being used within templates,
 when the archetype is published and needs to be updated to V1 within these
 templates.


 V1- Advantages

 1. Compliant with SemVer
 2. Does not need any changes to Archetype Editor.
 3. Easier transition between draft and publication states when used within
 templates i.e does not need V0-v1 change


 V1- Disadvantages
 1. Does not so clearly differentiate ?first draft? archetype from others


 Before a final decision is made, we are interested in feedback from the
 community on whether V0 should be implemented in CKM and other openEHR
 tools, although in practice V1- will do an identical job in terms of
 version number governance.

 Regards,

 Ian McNicoll
 Heather Leslie
 Sebastian Garde
 Thomas Beale



 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/cb621a28/attachment.html

Composition commit format to EHR

[Seref Arikan]

Hi Pablo,
I may be wrong, but I'm getting the impression that you are considering the
extra data you're talking about as something that is outside the
composition. It can certainly be processed that way, but the openEHR spec
has significant consideration for this type of information. The context,
composer, setting fields of your composition would let you keep a lot of
information. We keep sender system ids etc in these fields regularly. If
this is what you meant, then you may consider asking more specific openEHR
modelling questions, as in, 'how do I represent this hl7 id in a
composition?' etc. If you're talking about some out of openEHR mechanism,
you may not need it, keeping things within openEHR would help you make them
available to queries in a more consistent way plus all the other benefits
where you'd like to have interoperability.

There is a limit to what you can model within openEHR of course, and if you
start talking about logging etc, then you would probably like to consider
mechanisms which are not necessarily specified in the specs. My personal
opinion is that there is always some non openEHR functionality an
implementer would have to support: audit, some demographics, terminology
services etc. You have to set priorities though as an implementer, add
these things on top of your EHR related functionality as use cases arise.
If you try to develop in advance for everything you can think of you'll
have a lng journey ahead :)

Best regards
Seref



On Thu, Apr 10, 2014 at 12:04 AM, pablo pazos pazospablo at hotmail.comwrote:

 Hi all!

 I'm wondering how implementers are sending/committing COMPOSITIONs to
 their openEHR EHR implementations.

 A little context about what I'm doing right now:

 1. I've implemented an openEHR Service-Oriented (REST) repo that accepts
 commits of COMPOSITIONS in XML
 2. I use flat archetypes to define those COMPO's (i.e. one archetype with
 all slots resolved, so it's auto-contained)
 3. Now I'm changing the flat archetypes for OPT support, yay! :)
 4. The XML accepted by the EHRServer have version as the root node
 (VERSION contains one COMPOSITION).
 5. The commit is composed by an EHR_ID and an array of VERSION.


 I was thinking of adding more info to the commit so the EHRServer can keep
 a better log of the messages received and the sending applications,
 something like the MSH in HL7v2.x or like the Transmission Infrastructure
 Domain Model of HL7 v3 (basically info about sending and receiving
 apps/devices and facilities, info about the protocol e.g. the ACK mode, id
 of the message, date, ...).


 What information do you send in your commits?
 Do you send more info for tracking  logging?
 Did anyone mix the commit with HL7-like communication info?

 It would be very nice to know your thoughts, thank you!

 BTW: for anyone wanting to follow the development and/or contribute:
 https://github.com/ppazos/cabolabs-ehrserver (there is a demo here:
 https://www.youtube.com/watch?v=D-hs-Ofb8SY)

 --
 Kind regards,
 Eng. Pablo Pazos Guti?rrez
 http://cabolabs.com http://cabolabs.com/es/homehttp://twitter.com/ppazos

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140410/fcdba6e3/attachment.html

How to start

[Seref Arikan]

Dear Lexis,
A piece of early warning: If someone assigned only you to develop an EHR
based on openEHR, assuming that you'll figure out everything on your own
and deliver a solution, they are making a big mistake: this is not a one
man job.
Based on your questions, I get the feeling that you have never been exposed
to openEHR, and you have a massive amount of learning to do.

Threre is nothing wrong about your goal or being in your position: every
once in a while, someone in your position drops by, asks questions, and
gets frustrated because he/she can  not find what he/she was expecting to
find.
If this is not an academic exercise, I strongly suggest that you take a
look at the vendors that deliver openEHR based solutions, and discuss your
requirements with them. Regarding your how do I do this? type of
questions,
http://serefarikan.com/2012/11/08/openehr-for-practical-people-cleaned-up/
 and http://openehr.codeplex.com/documentation might help get your head
around the concepts.

All the best


On Wed, Aug 7, 2013 at 1:50 AM, Lexis Nexis lexisnexis5490 at gmail.comwrote:

 I am a Java developer. I am assigned to develop EHR based on OpenEHR. I
 read some specifications and they seem very complex to me. For instance, I
 want to create a web page like:

 Last Name:
 First Name:
 Date of Birth Date:
 Gender:
 Phone:
 Email:
 Emergency Contact Person:

 How do I map this object to Archetype?


 David

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130807/e3913b19/attachment.html

AQL / ADL BNF specifications...

[Seref Arikan]

As far as I know Marand open sourced their Antlr grammar for aql, though I
did not download it. it would probably be much more helpful than a bnf form
alone. google is your friend :)

the bnf specification for adl 1.5 is in Eiffel form, but I guess someone
produced an html version of it or something nice. I suggest you clone Tom's
eiffel code and look for it.

Regards
Seref



On Mon, Jul 15, 2013 at 5:00 PM, Athanasios Anastasiou 
athanasios.anastasiou at plymouth.ac.uk wrote:

 Hello everyone

 I am primarily interested in the BNF form of AQL and i was wondering if
 it would be available from somewhere on the project's github space
 (?)...(so far i can not locate it. )

 Also, the java reference implementation included the javacc definitions
 for parsing dADL and cADL but is there a stand-alone BNF specification
 for ADL 1.5 now?

 Looking forward to hearing from you
 Athanasios Anastasiou

 This email and any files with it are confidential and intended solely for
 the use of the recipient to whom it is addressed. If you are not the
 intended recipient then copying, distribution or other use of the
 information contained is strictly prohibited and you should not rely on it.
 If you have received this email in error please let the sender know
 immediately and delete it from your system(s). Internet emails are not
 necessarily secure. While we take every care, Plymouth University accepts
 no responsibility for viruses and it is your responsibility to scan emails
 and their attachments. Plymouth University does not accept responsibility
 for any changes made after it was sent. Nothing in this email or its
 attachments constitutes an order for goods or services unless accompanied
 by an official order form.

 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130715/875bca8f/attachment.html

openEHR website is down

[Seref Arikan]

works for me as well.


On Mon, Jul 8, 2013 at 11:08 AM, Diego Bosc? yampeku at gmail.com wrote:

 Both website and CKM are down. Was this stop intended?

 Regards

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130708/00cc4cf2/attachment.html

Trying to understand the openEHR Information Model

[Seref Arikan]

I'm glad you've considered doing that. In my humble opinion, AQL is the
most neglected, yet, probably one of the most important components of an
openEHR implementation. It is not part of the implementation, but it has
been implemented by at least two vendors that I know of, with a third
having something quite similar to it. Personally, I'm happy that it is
being cooked in real life before becoming a part of the implementation. If
you're interested in implementing openEHR, I suggest that you keep AQL as a
high level priority, rather than saying: let me use
sql/whatever_other_query_language_that_my_persistence_layer_uses for now
and I'll implement AQL later


On Thu, Apr 18, 2013 at 2:00 AM, Randolph Neall
randy.neall at veriquant.comwrote:

 Seref, I was simply trying to take your hint. :).


 On Wed, Apr 17, 2013 at 5:08 PM, Seref Arikan 
 serefarikan at kurumsalteknoloji.com wrote:

 AQL is not part of the official specification yet.

 Regards
 Seref



 On Wed, Apr 17, 2013 at 10:04 PM, Randolph Neall 
 randy.neall at veriquant.com wrote:

 Thomas, somehow I'm not finding the AQL specification. It's probably
 right under my nose on your specification/release page. Also, do you have
 any references describing the AQL processor? Did you write *that* from
 scratch?? It would seem that the AQL processor would indeed function as
 a formidable DBMS in its own right, at least with regard to reads, capable
 of managing AND/OR logic trees and serving up flat tables of joined data
 structures like any RDBMS.

 Randy


 On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale 
 thomas.beale at oceaninformatics.com wrote:

  On 17/04/2013 18:47, Randolph Neall wrote:

 The performance is perfectly adequate in all of these systems for the
 kinds of queries used in point of care (e.g. typically sub 1-second), and
 in some cases where ETL is implemented, the performance is also acceptable.
 It's also true that quite a lot of effort and thinking has gone into
 optimising AQL queries. There is always a query that can be written that
 will take a long time to answer, but so far there is no overlap between
 those type of queries and point of care latency requirements i.e. such
 queries are always report-oriented, research queries or some other kind of
 population query, where a (let's say) 5 second response is perfectly
 acceptable.

  That's excellent! Can you give any idea how long it takes to retrieve
 into live memory and screen on a user's computer an entire EHR record of
 typical size and complexity? Or does that not generally happen, with
 records instead being fetched in smaller pieces?


 Right - you wouldn't ever pull an entire EHR to the screen. I have seen
 openEHR applications pulling the main managed lists (say 6-8 Compositions),
 latest lab results, plus a chronological list of consultations / events for
 the last year or so, plus key demographic data, all sub 0.5 sec. Then the
 user starts clicking on things, and more comes back.

 More interesting screens contain a mixture of text and e.g. vital signs
 real-time graphs, which AQL copes with nicely - you can bring back just a
 2-D array of numbers and timestamps for the graph, using AQL.

 - thomas


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

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



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

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



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

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



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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130418/2a308576/attachment.html

Trying to understand the openEHR Information Model

[Seref Arikan]

On Wed, Apr 17, 2013 at 1:16 AM, Randolph Neall
randy.neall at veriquant.comwrote:

 Using path-based blobbing probably isn't a million miles from such DBs.
 Personally I used a wonderful object database called Matisse (still around
 today), which essentially operates as a graph db with write-once semantics,
 and I would love to have a side-project to build an openEHR system on that.

 I'll talk to you off line sometime about that. I can tell you from my own
 experience that it might not be as forbidding as one would think. The more
 I've examined the archetypes and seen how they are linked and the linkage
 rules are defined, the more excited I've become. There's definitely a way
 to do this.

 Nevertheless, there are a couple of container levels that have
 significance in models like openEHR, 13606, CDA and so on: the Composition
 (can be seen as a Document) and the Entry (the clinical statement level).
 So it's not completely mad to do blobbing at these levels, or build in
 other assumptions around them.

 I agree it's not completely mad to use your approach partly because you
 really do need the information in chunks that smell and feel like
 parchments. But what if you could have it both ways?


Hint: think about how you're going to get data out before thinking how
you're supposed to keep it. There are lots of possibilities, but you need
to anchor those with a single method of access. I suggest  a  brief look at
Archetype Query Language (AQL)


 ah - don't blame me for it. I added some engineering understanding and
 integration along the way, but this work started with a bunch of very smart
 clinical people who gathered the best set of requirements for the 'EHR'
 concept, during the Good European Health Record project. One of them, Dr
 Dipak Kalra (now head of department of CHIME at UCL), wrote his PhD 
 thesishttp://eprints.ucl.ac.uk/1584/ on
 EHR requirements, and one outcome of that was the ISO 18308 standard, on
 the same topic. Sam Heard and other physicians were key in developing these
 requirements and the understanding they have given to the domain have
 greatly affected the quality of the development. This plus numerous
 technical people, debates, conferences etc have led to the 
 specificationshttp://www.openehr.org/programs/specification/releases/currentbaseline
  you
 see today. Have a look at the revision histories, particularly on the EHR
 IM and Data types - you'll see a lot of names.

 Of course you'd say that. I've looked at the names. And using a bit of
 networking logic, it's not hard to deduce who has been at the center of it
 all--and doing much of the writing. But yes, there were also others, and
 you know better than I how it all actually balances out.

 Thanks for the considerable time you've spent answering my questions.

 Randy


 On Tue, Apr 16, 2013 at 4:46 PM, Thomas Beale 
 thomas.beale at oceaninformatics.com wrote:

  On 16/04/2013 18:55, Randolph Neall wrote:

 Hi Thomas,

  Again, you've advanced my grasp of openEHR.

  the change set in openEHR is actually not a single Composition, it's a
 set of Composition Versions, which we call a 'Contribution'. Each such
 Version can be: a logically new Composition (i.e. a Version 1), a changed
 Composition (version /= 1) or a logical deletion (managed by the Version
 lifecycle state marker). So a visit to the GP could result in the following
 Contribution to the EHR system:

- a new Composition containing the note from the consultation
- a modified Medications persistent Composition
- a modified Care Plan persistent Composition.

 Your comment here is in the context of persistent Compositions, and I
 think what you're saying is that these are a special case: persistent
 Compositions, unlike event Compositions, contain only *one* kind of
 persistent information, and no event information, thus allowing clean
 substitutions when that persistent information is later updated. This would
 avert the horrible scenario I suggested, involving updating heterogeneous
 persistent Compositions. If I'm grasping you, this makes perfect sense.


 to be 100% clear: the change set versioning model works for all
 Composition types - a single change set (what we call a Contribution) can
 contain versions of persistent and even Compositions.

 Semantically, your understanding above is correct: persistent
 Compositions are always dedicated to a single kind of information, usually
 some kind of 'managed list' like 'current medications', 'vaccinations' etc.



  Systems do have to be careful to create references that point to
 particular versions.

  Does that mean that tracing a web of connections with current relevance
 requires systems to present invalidated Compositions to users? Or are the
 links themselves revised to point to the replacement Compositions?


 Normally when a Composition is committed (within a Contribution) and it
 contains a LINK or DV_EHR_URI, that link points to the logical 'latest
 available' target. So the link is 

Trying to understand the openEHR Information Model

[Seref Arikan]

AQL is not part of the official specification yet.

Regards
Seref



On Wed, Apr 17, 2013 at 10:04 PM, Randolph Neall
randy.neall at veriquant.comwrote:

 Thomas, somehow I'm not finding the AQL specification. It's probably right
 under my nose on your specification/release page. Also, do you have any
 references describing the AQL processor? Did you write *that* from
 scratch?? It would seem that the AQL processor would indeed function as
 a formidable DBMS in its own right, at least with regard to reads, capable
 of managing AND/OR logic trees and serving up flat tables of joined data
 structures like any RDBMS.

 Randy


 On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale 
 thomas.beale at oceaninformatics.com wrote:

  On 17/04/2013 18:47, Randolph Neall wrote:

 The performance is perfectly adequate in all of these systems for the
 kinds of queries used in point of care (e.g. typically sub 1-second), and
 in some cases where ETL is implemented, the performance is also acceptable.
 It's also true that quite a lot of effort and thinking has gone into
 optimising AQL queries. There is always a query that can be written that
 will take a long time to answer, but so far there is no overlap between
 those type of queries and point of care latency requirements i.e. such
 queries are always report-oriented, research queries or some other kind of
 population query, where a (let's say) 5 second response is perfectly
 acceptable.

  That's excellent! Can you give any idea how long it takes to retrieve
 into live memory and screen on a user's computer an entire EHR record of
 typical size and complexity? Or does that not generally happen, with
 records instead being fetched in smaller pieces?


 Right - you wouldn't ever pull an entire EHR to the screen. I have seen
 openEHR applications pulling the main managed lists (say 6-8 Compositions),
 latest lab results, plus a chronological list of consultations / events for
 the last year or so, plus key demographic data, all sub 0.5 sec. Then the
 user starts clicking on things, and more comes back.

 More interesting screens contain a mixture of text and e.g. vital signs
 real-time graphs, which AQL copes with nicely - you can bring back just a
 2-D array of numbers and timestamps for the graph, using AQL.

 - thomas


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

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



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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/83f32baa/attachment-0001.html

PhD thesis online: Scalability and Semantic Sustainability in Electronic Health Record Systems

[Seref Arikan]

Erik,
Congrats, it must feel really nice to be able to reach this point. Best of
luck for the defense :)

Best regards
Seref


On Sun, Jan 27, 2013 at 3:44 PM, Erik Sundvall erik.sundvall at liu.se wrote:

 Hi!

 My thesis entitled Scalability and Semantic Sustainability in Electronic
 Health Record Systems is now available online. It contains many
 openEHR-related papers and discussions (see abstract included below).

 Permanent link to electronic version of the thesis:
 http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-87702

 Public PhD defence will be held the 15:th of February, in Link?ping,
 Sweden. Faculty opponent: prof. Dipak Kalra, UCL.
 Temporary event-information page: http://www.imt.liu.se/~erisu/2013/phd/
 (That page also contains a form where you have the possibility to indicate
 interest in online participation or in getting a recording.)

 Best regards,
 Erik Sundvall
 erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

 Abstract
 This work is a small contribution to the greater goal of making software
 systems used in healthcare more useful and sustainable. To come closer to
 that goal, health record data will need to be more computable and easier to
 exchange between systems.
 Interoperability refers to getting systems to work together and semantics
 concerns the study of meanings. If Semantic interoperability is achieved
 then information entered in one information system is usable in other
 systems and reusable for many purposes. Scalability refers to the extent to
 which a system can gracefully grow by adding more resources. Sustainability
 refers more to how to best use available limited resources. Both aspects
 are important.

 The main focus and aim of the thesis is to increase knowledge about how to
 support scalability and semantic sustainability. It reports explorations of
 how to apply aspects of the above to Electronic Health Record (EHR)
 systems, associated infrastructure, data structures, terminology systems,
 user interfaces and their mutual boundaries.

 Using terminology systems is one way to improve computability and
 comparability of data. Modern complex ontologies and terminology systems
 can contain hundreds of thousands of concepts that can have many kinds of
 relationships to multiple other concepts. This makes visualization
 challenging. Many visualization approaches designed to show the local
 neighbourhood of a single concept node do not scale well to larger sets of
 nodes. The interactive TermViz approach described in this thesis, is
 designed to aid users to navigate and comprehend the context of several
 nodes simultaneously. Two applications are presented where TermViz aids
 management of the boundary between EHR data structures and the terminology
 system SNOMED CT.

 The amount of available time from people skilled in health informatics is
 limited. Adequate methods and tools are required to develop, maintain and
 reuse health-IT solutions in a sustainable way. Multiple levels of
 modelling including a fixed reference model and another layer of flexible
 reusable ?archetypes? for domain specific data structures, is an approach
 with that aim used in openEHR and the ISO 13606 standard. This approach,
 including learning, implementing and managing it, is explored from
 different angles in this thesis. An architecture applying Representational
 State Transfer (REST) to archetype-based EHR systems, in order to address
 scalability, is presented. Combined with archetyping this architecture also
 aims at enabling a sustainable way of continuously evolving multi-vendor
 EHR solutions. An experimental open source implementation of it, aimed for
 learning and prototyping, is also presented.

 Manually changing database structures used for storage every time new
 versions of archetypes and associated data structures are needed is likely
 not a sustainable activity. Thus storage systems that can handle change
 with minimal manual interventions are desirable. Initial explorations of
 performance and scalability in such systems are also reported.

 Graphical user interfaces focused on EHR navigation, time-perspectives and
 highlighting of EHR content are also presented ? illustrating what can be
 done with computable health record data and the presented approaches.

 Desirable aspects of semantic sustainability have been discussed,
 including: sustainable use of limited resources (such as available time of
 skilled people), and reduction of unnecessary risks. A semantic
 sustainability perspective should be inspired and informed by research in
 complex systems theory, and should also include striving to be highly aware
 of when and where technical debt is being built up. Semantic sustainability
 is a shared responsibility.

 The combined results presented contribute to increasing knowledge about
 ways to support scalability and semantic sustainability in the context of
 electronic health record systems. Supporting tools, architectures and
 

Handling internalization for openEHR terminology xml. Do we need a schema update?

[Seref Arikan]

Greetings,
Ian and I have been working on internalization of openEHR terminology XML
for a project. Being the lazy person that I am, I wrote an Xquery snippet
to reuse the existing work in the Archetype Editor's terminology file,
which is quite comprehensive in terms of the languages it contains.
However, this did not help perform the full internalization.

The problem is, the group elements' name attributes are the only
identifiers for group elements, and even if one translates the concepts
under groups, the group name is still in English. An example with Turkish:

group name=null flavours
concept id=271 rubric=bilgi yok/
concept id=253 rubric=bilinmiyor/
concept id=272 rubric=maskelenmis/
concept id=273 rubric=bu duruma uygun degil/
/group

the group name is null flavours. Group element has no attribute such as
conceptID, that would allow me to fully internationalize the xml file. The
concept id for null flavours actually exits in the Archetype Editor xml
file, but if I use that code here, I'll probably be inventing a
non-standard hack.

Does it make sense to add a conceptId attribute to group element? (and
could anybody let me know the location of the latest schema for openEHR
terminology XML?)

Best regards
Seref
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130129/f1d30ace/attachment.html

ADL Worbench for Linux

[Seref Arikan]

from the top of my head: reads like a path problem with the images embedded
into AW, due to fact that it is being developed under Windows, and you're
trying to run it under Linux.
Any chance you can check out mechanism of image paths?

On Fri, Jan 18, 2013 at 7:15 AM, Bert Verhees bert.verhees at rosa.nl wrote:

 Someone any idea?

 Thanks
 Bert

 verhees at kubuntuwerk:~/adl_**workbench-linux$ ./adl_workbench

 adl_workbench: system execution failed.
 Following is the set of recorded exceptions:

 ** Thread exception
 *
 In thread   Root thread0x0 (thread id)
 
 ***
 --**--**
 ---
 Class / Object  RoutineNature of exception  Effect
 --**--**
 ---
 ISE_EXCEPTION_MANAGER
 raise @9   Could not load image file.:
 F66CFFE8 Developer exception.  Fail
 --**--**
 ---
 ISE_EXCEPTION_MANAGER
 raise @9
 F66CFFE8 Routine failure.  Fail
 --**--**
 ---
 DEVELOPER_EXCEPTION raise @1
 F66CFF88  (From EXCEPTION)   Routine failure.  Fail
 --**--**
 ---
 EXCEPTIONS  raise @3
 F66CFF10 Routine failure.  Fail
 --**--**
 ---
 EV_PIXMAP_IMP   read_from_named_file @4
 F66CFB38 Routine failure.  Fail
 --**--**
 ---
 EV_PIXMAP   set_with_named_file @1
 F66CFB08 Routine failure.  Fail
 --**--**
 ---
 SPLASH_WINDOW   recursive_load_pixmaps @8
 F66798A0  (From SHARED_APP_UI_RESOURCES)
Routine failure.   Fail
 --**--**
 ---
 SPLASH_WINDOW   recursive_load_pixmaps @20
 F66798A0  (From SHARED_APP_UI_RESOURCES)
Routine failure.   Fail
 --**--**
 ---
 SPLASH_WINDOW   icon_pixmaps @2
 F66798A0  (From SHARED_APP_UI_RESOURCES)
Routine failure.   Fail
 --**--**
 ---
 SPLASH_WINDOW   get_icon_pixmap @2
 F66798A0  (From SHARED_APP_UI_RESOURCES)
Routine failure.   Fail
 --**--**
 ---
 SPLASH_WINDOW   adl_workbench_icon @1
 F66798A0  (From SHARED_APP_UI_RESOURCES)
Routine failure.   Fail
 --**--**
 ---
 SPLASH_WINDOW   initialize @10
 F66798A0 Routine failure.  Fail
 --**--**
 ---
 SPLASH_WINDOW   default_create @5
 F66798A0  (From EV_ANY)  Routine failure.  Fail
 --**--**
 ---
 SPLASH_WINDOW   make_with_shadow @2
 F66798A0  (From EV_POPUP_WINDOW) Routine failure.  Fail
 --**--**
 ---
 SPLASH_WINDOW   make @1
 F66798A0 Routine failure.  Fail
 --**--**
 ---
 GUI_APP_ROOTshow_splash_window @1
 F57C1CA4 Routine failure.  Fail
 --**--**
 ---
 GUI_APP_ROOTmake_and_launch @3
 F57C1CA4 Routine failure.  Fail
 --**--**
 ---
 GUI_APP_ROOTroot's creation
 F57C1CA4 Routine failure.  Exit
 --**--**
 ---


 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 

ADL Worbench for Linux

[Seref Arikan]

I know it is cross platform :) That is why I wrote, developed under
Windows, which implies that the developer might have used Windows style
relative paths for images.

On Fri, Jan 18, 2013 at 10:14 AM, Peter Gummer 
peter.gummer at oceaninformatics.com wrote:

 On 18/01/2013, at 20:11, Seref Arikan wrote:

  from the top of my head: reads like a path problem with the images
 embedded into AW, due to fact that it is being developed under Windows, and
 you're trying to run it under Linux.


 Yes, an image path problem; but no, ADL Workbench is cross-platform. It
 works under Linux just as well as Windows. Regardless of the platform, the
 image files have to be in the correct place.

 Bert, did you build this yourself or did you install it from
 http://www.openehr.org/downloads/ADLworkbench/home ?

 Peter
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130118/cb9eb443/attachment.html

Questions about the XSD-files.

[Seref Arikan]

I'll attempt to comment on Bert's problem, hoping I understand it :)
When you do not have a root element definition in an XSD, you can't create
XML documents which will be valid according to that XSD. What Bert is
saying is, if we had a bunch of root elements in the XSDs, it would allow
us create valid XML with these root elements. At the moment, if you create
an XML element with a DVQuantity subclass as the root, it would not be
valid according to XSD, because the XSD does not explicitly list DvQuantity
as a root element

As it is, the XSDs define larger units of documents, and having finer
granularity requires having more root elements defined as options in the
XSDs.

Bert, did I get it?



On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel 
heath.frankel at oceaninformatics.com wrote:

 Bert,
 The rule you reference says nothing about concrete types. As far as I am
 concerned the items element is satisfying this rule.
 You are welcome to change the schema in your system as you see fit just as
 linkEHR have done, but I suggest any additional element declarations are
 done in a different namespace otherwise you will be producing incompatible
 instances.

 I am still not understanding you issues with this element other than
 styling. If you have any technical issue please raise a jira issue.

 Heath
 On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote:

 Op 27-11-2012 9:07, Heath Frankel schreef:


 Bert,
 You can define elements to be type of an abstract type allowing any
 concrete subtype in an instance. This is the intent of the items element,
 to allow any rotatable concrete type to be represented in a document with
 root element of items.
 Heath


 Hi Heath,

 You can just have one globally element from Locatable in the XSD, and say
 that XML-instances must comply to that. (just joking)
 
 There is no other globally defined element in the structures.xsd, so
 there is no other root-element.

 Every valid XML-instance has one (only one) root-element. So, many
 schema-processors need at least one root-element in the XSD for
 validation-purpose, and the XML instance must conform to that. Many
 schema-processors can only access root-elements directly. I think that for
 usability and portability the structures.xsd should have that also.

 I think this is a left-over situation because (I am looking quite some
 years at OpenEHR), in the past, it was not done to archetype
 ITEM_STRUCTURE's as root, they did only appear as property. I don't know
 when the first ITEM_STRUCTURE derived archetypes appeared in CKM.

 I remember Sam mentioning, some years ago, that he didn't like the
 demographics-classes, but that they should be replaced by generic
 structures derived from ITEM_STRUCTURE. I had this discussion with him in
 the context of the Ocean-archetype editor which is build (maybe partly) by
 Sam, and also does not support demographics (It is sometime ago I looked
 for the last time)

 It is a valid opinion, but this advice was not followed by the community.
 However, the demographic-specs are valid inside the OpenEHR specs. They
 also appear in CKM.

 But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for
 other purposes than demographics.
 There can be XML-instances from ITEM_STRUCTURE-derived.
 So also for this reason, the XSD should declare ITEM_STRUCTURE derived
 elements globally.


 And also besides this all, the globaly defined items, must be meant to
 be a property of other definitions, because there is no class in the
 reference model which is called items.
 Considering that, I think, the  items is (originally ) meant of type
 LOCATABLE to satisfy all possible appearances of the property items in
 structures, which have a semantically other meaning. But this is not
 following the granularity of the specs. So the items properties which are
 in the structures have a more fine-grained definition. Maybe this is
 corrected, anyway, this how it should be.
 So I think, the items element it is a left over, an element should be
 declared globally if it is used in more then one complex type, but it isn't
 used at all. So it is there doing nothing.

 That is why I asked about that.
 -
 Besides the portability among schema-processors

 As you can see it in the demographics.xsd which comes from LinkEHR, there
 is for every concrete class a global element declaration.
 It has a very precise interface, which makes it easier to develop code
 against it. That is why it is like that. LinkEHR uses it in code. So, this
 is the usability-argument.

 See also this tutorial http://www.herongyang.com/XML-**
 Schema/Language-Basic-Declare-**Root-Element.htmlhttp://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html
 by Dr. Herong Yang:

 Rule 1. A schema must have at least one Element Declaration Component to
 declare a root element for the conforming XML document.

 That is how it should be, also in my opinion, as I said, for portability
 to all kind of schema-processing 

Questions about the XSD-files.

[Seref Arikan]

Greetings,
Did I get this right? There are XSDs on openEHR web site. There are also
XSDs which are different than the first set, provided by LinkEHR.
If these are XSDs of the published parts of the openEHR specifications,
such as RM or AOM, then there should only be one XSD set, published by
openEHR.
If the XSDs belong to parts which are not part of the openEHR specs, having
more than one XSD theoretically would not hurt interoperability, since they
are not openEHR XSDs until they're published by the foundation, but in
practice, this would be a problem waiting to emerge in the future.
Am I missing something here? Multiple XSDs sounds like a big can of worms
to me.

Best regards
Seref


On Mon, Nov 26, 2012 at 5:02 PM, Bert Verhees bert.verhees at rosa.nl wrote:

 Thanks Athanasios and Diego,

 It is easier to download then to write it myself ;-)

 But still I wonder why the OpenEHR-community is not offering these.

 cheers
 Bert




 On 11/26/2012 05:51 PM, Diego Bosc? wrote:

 Hello Bert,

 We created a XML Schema for the demographics part some time ago. You
 can download it from here.

 http://pangea.upv.es/linkehr/**wp-content/uploads/2009/03/**
 Demographics.xsdhttp://pangea.upv.es/linkehr/wp-content/uploads/2009/03/Demographics.xsd

 Regards

 2012/11/26 Bert Verhees bert.verhees at rosa.nl:

 Hi,

 I was studying the OpenEHR XSD files, I found they validate fine against
 Saxon-EE 1.0 and 1.1

 But I have a few points which are not clear to me.

 1)
 In the Structure.xsd I find this line, I don't know why it is there.
 xs:element name=items type=LOCATABLE/

 I commented it out, and it still validates fine.

 2)
 There were some more things in the same file.
 There were no element-declarations to the concrete classes, like
 ITEM_TREE,
 CLUSTER, and so on.
 I would expect them because there are also archetypes in CKM based on
 these
 classes/elements and can be instantiated in XML.

 I added them, and now I can generate example XML with these classes as
 root,
 which was not possible before.

 3)
 It would be nice to have elements in the base-types XSD too. There is no
 need for it in the OpenEHR implementation, because they will never be
 root-element, but it is good to see their XML-structure isolated, for
 convenience.
 I will try that and see if they will be a problem.

 4)
 And the last point is, I missed the Demographics.xsd, although these
 RM-classes are also archetypeable and can lead too to XML-instances.

 Thanks
 Bert Verhees



 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121126/28922bb2/attachment.html

Questions about the XSD-files.

[Seref Arikan]

I think I misunderstood the original question. Thanks for all the responses
everyone.

Best regards
Seref


On Mon, Nov 26, 2012 at 8:16 PM, Timothy Cook
timothywayne.cook at gmail.comwrote:

 Hi Seref,

 The openEHR schemas have been there for many years.
 http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html

 --Tim


 On Mon, Nov 26, 2012 at 3:13 PM, Seref Arikan 
 serefarikan at kurumsalteknoloji.com wrote:

 Greetings,
 Did I get this right? There are XSDs on openEHR web site. There are also
 XSDs which are different than the first set, provided by LinkEHR.
 If these are XSDs of the published parts of the openEHR specifications,
 such as RM or AOM, then there should only be one XSD set, published by
 openEHR.
 If the XSDs belong to parts which are not part of the openEHR specs,
 having more than one XSD theoretically would not hurt interoperability,
 since they are not openEHR XSDs until they're published by the foundation,
 but in practice, this would be a problem waiting to emerge in the future.
 Am I missing something here? Multiple XSDs sounds like a big can of worms
 to me.

 Best regards
 Seref



 On Mon, Nov 26, 2012 at 5:02 PM, Bert Verhees bert.verhees at rosa.nlwrote:

 Thanks Athanasios and Diego,

 It is easier to download then to write it myself ;-)

 But still I wonder why the OpenEHR-community is not offering these.

 cheers
 Bert




 On 11/26/2012 05:51 PM, Diego Bosc? wrote:

 Hello Bert,

 We created a XML Schema for the demographics part some time ago. You
 can download it from here.

 http://pangea.upv.es/linkehr/**wp-content/uploads/2009/03/**
 Demographics.xsdhttp://pangea.upv.es/linkehr/wp-content/uploads/2009/03/Demographics.xsd

 Regards

 2012/11/26 Bert Verhees bert.verhees at rosa.nl:

 Hi,

 I was studying the OpenEHR XSD files, I found they validate fine
 against
 Saxon-EE 1.0 and 1.1

 But I have a few points which are not clear to me.

 1)
 In the Structure.xsd I find this line, I don't know why it is there.
 xs:element name=items type=LOCATABLE/

 I commented it out, and it still validates fine.

 2)
 There were some more things in the same file.
 There were no element-declarations to the concrete classes, like
 ITEM_TREE,
 CLUSTER, and so on.
 I would expect them because there are also archetypes in CKM based on
 these
 classes/elements and can be instantiated in XML.

 I added them, and now I can generate example XML with these classes as
 root,
 which was not possible before.

 3)
 It would be nice to have elements in the base-types XSD too. There is
 no
 need for it in the OpenEHR implementation, because they will never be
 root-element, but it is good to see their XML-structure isolated, for
 convenience.
 I will try that and see if they will be a problem.

 4)
 And the last point is, I missed the Demographics.xsd, although these
 RM-classes are also archetypeable and can lead too to XML-instances.

 Thanks
 Bert Verhees



 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



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

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




 --
 
 Timothy Cook, MSc   +55 21 94711995
 MLHIM http://www.mlhim.org
 LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
 Academic.Edu Profile: http://uff.academia.edu/TimothyCook
 Google Scholar: http://goo.gl/MMZ1o

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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121126/c87f22b2/attachment-0001.html

What should AQL return in this case?

[Seref Arikan]

Greetings,
Here is the setting in which AQL is being used:
We are interested in outcomes of a particular clinical instruction  in
cases where a particular observation has been recorded.
We want to get an attribute of both the observation and the and the
instruction from patient EHR. The patient's EHR has multiple observations
and instructions, as shown in the following diagram (the dual line
connections are from the partial graph representation domain, meaning a
child contained somewhere) The diagram also contains the query and other
details, which I'll discuss below

[image: Inline image 1]


The problem here is that the observation and instruction tuple can be
represented in 4 ways. (I hope the diagram represents why it is so) Should
AQL implementation return all 4? Then the consumer of the result set would
have to sort things out. This is similar to RDMS behaviour when a select
statement is issued on two tables without any joins.
I'm inclined to accept this as the expected behaviour, but I'd like to hear
what others think.

(of course, adding some constraint that would enforce the instruction to
have a creation time later than the observation would return only two
tuples, but that is not the case I'm asking for)

Best regards
Seref
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/d32e102f/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: aql-result-set-question.png
Type: image/png
Size: 35089 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/d32e102f/attachment-0001.png

What should AQL return in this case?

[Seref Arikan]

Ascii would take time

iPad + Notability + a proper stylus
I love it.



On Mon, Aug 20, 2012 at 12:52 PM, Hugh Leslie 
hugh.leslie at oceaninformatics.com wrote:

  You could have done the diagram in ascii...

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/3735b18a/attachment.html

What should AQL return in this case?

[Seref Arikan]

Thanks,
I think this is the best thing to do.

On Mon, Aug 20, 2012 at 1:17 PM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

 On 20/08/2012 05:47, Seref Arikan wrote:

 Hi Tom,
 Your comments are quite helpful, but they do not belong to the context
 I'm asking about. I'm asking the default behaviour for returning results
 when no constraints are there.
 It may not be a meaningful use case for using AQL, but it is a
 technically valid one. My question is: how should the implementation behave
 when it faces this technically valid AQL, on this EHR?


 in that case, whatever is matched is matched, which will include all your
 combinations ;-)

 - thomas


 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/b00bbd90/attachment.html

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

Hi Heath,
Maybe semantics is not the right word for it, but it is what would help
me/my code easily express that the interest is in a particular element,
given a bunch of options. The lack of node identifier is thus at least lack
of information, if not semantics.

Not to suggest that you're wrong in this specific example, but the
following quote from page 47 of the adl 1.5 spec makes one inclined to
assign the responsibility of expressing semantics to node identifiers, or
at least that is my impression:

The node identifier also performs a semantic function, that of giving a
design-time meaning to the
node, by equating the node identifier to some description

Maybe I've incorrectly generalized this statement.

Kind regards
Seref



On Wed, Aug 15, 2012 at 1:10 AM, Heath Frankel 
heath.frankel at oceaninformatics.com wrote:

 Hi Seref/Thomas,

 Node IDs at0022 and at0023 have no semantic significance, they are just a
 value of a speed limit element no matter if they are in km/h or mph. These
 are just alternative value constraints on the value due to different units
 allowed and range when using that unit. When you query you would want to
 get all speed limit values and if you needed to compare then you need to
 convert based on the units.

 ** **

 The instance should actually look like the following

 ** **

 items = 

 [1] =  --
 ELEMENT

 archetype_node_id = at0004

 value =  --
 QUANTITY

 units = mph

 magnitude = 25

 

 

 [2] = 

 etc

  

 ** **

 However, one area that is problematic is in the validator, how do we know
 which constraint we should use when the constraints are ambiguous. The
 example provided previously does no have this issue but if you consider an
 element with an alternative values of type DV_TEXT allowing free text and
 DV_CODED_TEXT in some specified terminology. 

 ** **

 ELEMENT[at0004] matches { 

 value matches {

 DV_TEXT matches { * }

 DV_CODED_TEXT matches { -- km per hour

 defining_code matches { |SNOMED-CT::| }

 }

 }

 }

 ** **

 This cases doesn?t require at-codes because they are different types, but
 they are still ambiguous due to the inheritance allowing any coded term to
 be used, not just the specified term.

 ** **

 Here it would be nice to have an at-code in the instance to differentiate
 which alternative is being used.

 ** **

 Heath

 ** **

 *From:* openehr-technical-bounces at lists.openehr.org [mailto:
 openehr-technical-bounces at lists.openehr.org] *On Behalf Of *Thomas Beale
 *Sent:* Wednesday, 15 August 2012 2:07 AM

 *To:* openehr-technical at lists.openehr.org
 *Subject:* Re: Should not node identifiers in runtime paths be mandatory?*
 ***

 ** **

 On 14/08/2012 10:34, Seref Arikan wrote:

 Greetings,
 According to adl 1.5 document on the openEHR web site (issued 25 Jan
 2012), Section 5.3.6.3, the runtime paths for single valued attributes can
 omit node identifer.
 The example given in the document uses miles per hour and km per hour
 alternatives. The thing is, if the runtime path is what is going to be
 persisted (and I can't see any other practical cases), the persisted data
 will have no information to mark the semantics of the selection of an
 option among alternatives.


 actually, this text is a bit misleading. If we have the archetype

 ELEMENT[at0004] matches { -- speed limit
 value matches {
 QUANTITY[at0022] matches { -- miles per hour
 magnitude matches {|0..55|}
 property matches {velocity}
 units matches {mph}
 }
 QUANTITY[at0023] matches { -- km per hour
 magnitude matches {|0..100|}
 property matches {velocity}
 units matches {km/h}
 }
 }
 }

 then the data instance created from the at0022 form of the QUANTITY will
 be (in dADL):

 items = 
 [1] =  --
 ELEMENT
 archetype_node_id = at0004
 value =  --
 QUANTITY
 archetype_node_id = at0022
 magnitude = 25
 
 
 [2] = 
 etc
 

 so the path items[at0004]/value[at0022] will choose the quantity,
 although items[at0004]/value would do just as well. (Remember, the Xpath
 equivalents are
 items[@archetype_node_id='at0004']/value[@archetype_node_id='at0022'] etc
 - the [at0022] is just a shorthand selection predicate.)

 The paths are not 'persisted' as such - just the data. The paths are
 always derivates of the data.


 


 In case of a query such as get me all Xs where value is expressed as km
 per hour, the system can not know what which option was used: kmph or mph,
 because

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

Greetings,
According to adl 1.5 document on the openEHR web site (issued 25 Jan 2012),
Section 5.3.6.3, the runtime paths for single valued attributes can omit
node identifer.
The example given in the document uses miles per hour and km per hour
alternatives. The thing is, if the runtime path is what is going to be
persisted (and I can't see any other practical cases), the persisted data
will have no information to mark the semantics of the selection of an
option among alternatives.

In case of a query such as get me all Xs where value is expressed as km per
hour, the system can not know what which option was used: kmph or mph,
because there is not node identifier.
In decision support/ machine learning use cases, having different units of
measurements would lead to mayhem etc etc.

So there is a potential loss of information here, in exchange for
flexibility, but what is the use of that flexibility? Should not the node
identifier be mandatory in runtime paths when there is a decision among
alternatives?

Kind regards
Seref
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/65eb9df6/attachment.html

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

To comment on my own query:
Section 5.3.12 of the same document says that node identifiers are
mandatory for the case I've referred to in 5.3.6.3, but there is no
explicit metion of runtime paths. So does this rule cover runtime paths
too? I think it should, not due to ambiguity, but due to loss of semantics

Regards
Seref


On Tue, Aug 14, 2012 at 10:34 AM, Seref Arikan 
serefarikan at kurumsalteknoloji.com wrote:

 Greetings,
 According to adl 1.5 document on the openEHR web site (issued 25 Jan
 2012), Section 5.3.6.3, the runtime paths for single valued attributes can
 omit node identifer.
 The example given in the document uses miles per hour and km per hour
 alternatives. The thing is, if the runtime path is what is going to be
 persisted (and I can't see any other practical cases), the persisted data
 will have no information to mark the semantics of the selection of an
 option among alternatives.

 In case of a query such as get me all Xs where value is expressed as km
 per hour, the system can not know what which option was used: kmph or mph,
 because there is not node identifier.
 In decision support/ machine learning use cases, having different units of
 measurements would lead to mayhem etc etc.

 So there is a potential loss of information here, in exchange for
 flexibility, but what is the use of that flexibility? Should not the node
 identifier be mandatory in runtime paths when there is a decision among
 alternatives?

 Kind regards
 Seref


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/50305db0/attachment-0001.html

Should not node identifiers in runtime paths be mandatory?

[Seref Arikan]

Thank Tom,
Somehow the text gave me the impression that use of archetype Node Id was
optional, which is clearly not the case.

Kind regards
Seref


On Tue, Aug 14, 2012 at 5:37 PM, Thomas Beale 
thomas.beale at oceaninformatics.com wrote:

  On 14/08/2012 10:34, Seref Arikan wrote:

 Greetings,
 According to adl 1.5 document on the openEHR web site (issued 25 Jan
 2012), Section 5.3.6.3, the runtime paths for single valued attributes can
 omit node identifer.
 The example given in the document uses miles per hour and km per hour
 alternatives. The thing is, if the runtime path is what is going to be
 persisted (and I can't see any other practical cases), the persisted data
 will have no information to mark the semantics of the selection of an
 option among alternatives.


 actually, this text is a bit misleading. If we have the archetype

 ELEMENT[at0004] matches { -- speed limit
 value matches {
 QUANTITY[at0022] matches { -- miles per hour
 magnitude matches {|0..55|}
 property matches {velocity}
 units matches {mph}
 }
 QUANTITY[at0023] matches { -- km per hour
 magnitude matches {|0..100|}
 property matches {velocity}
 units matches {km/h}
 }
 }
 }

 then the data instance created from the at0022 form of the QUANTITY will
 be (in dADL):

 items = 
 [1] =  --
 ELEMENT
 archetype_node_id = at0004
 value =  --
 QUANTITY
 archetype_node_id = at0022
 magnitude = 25
 
 
 [2] = 
 etc
 

 so the path items[at0004]/value[at0022] will choose the quantity,
 although items[at0004]/value would do just as well. (Remember, the Xpath
 equivalents are items[@archetype_node_id='at0004']/value
 [@archetype_node_id='at0022'] etc - the [at0022] is just a shorthand
 selection predicate.)

 The paths are not 'persisted' as such - just the data. The paths are
 always derivates of the data.



 In case of a query such as get me all Xs where value is expressed as km
 per hour, the system can not know what which option was used: kmph or mph,
 because there is not node identifier.


 in this case, use the path items[at0004]/value[at0022].
 *
 * - thomas


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

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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/70ae8568/attachment-0001.html