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

[Boštjan Lah]

Hi,

We can add definition endpoint for archetypes as well, no problem.
Actually we had it in the previous version, so I'll just add it back.

Best regards,
Bostjan


> On 15 Feb 2018, at 17:09, Pieter Bos  wrote:
> 
> I noticed the recent version of the REST api  only works with templates, and 
> not archetypes.
> 
> As our EHR is ADL 2 only, this has some interesting consequences.
> 
> Of course, you can upload just the operational templates and probably create 
> a fully functional EHR, but if you work with ADL 2, you would always need an 
> external tool to create the OPT2 from the ADL repository that you want to 
> use, instead of an EHR that generates the OPT2s from the source archetypes 
> itself. Of course, you could just use the ADL workbench or the Archie 
> adlchecker command-line utility to do it for you, but I’m not sure if it’s a 
> nice thing to do.
> 
> Also if you only use OPT2, you might want to do queries such as ‘retrieve all 
> information that is stored in an EHR that has been derived from archetype 
> with id X, including archetypes specializing from X’ (not just operational 
> template X). An example: retrieve all reports, or all care plans, regardless 
> of the used template. To do that, you probably need a specialization section 
> in the OPT2, which according to the specs should have been removed, and you 
> also need to create operational templates for archetypes that you never use 
> to directly create compositions from. Or the tool querying the EHR must be 
> fully aware of the full archetype specialization tree and use that to create 
> a query with all specializing archetypes included in the query.
> 
> So, is it intended that the REST API only works with operational templates, 
> and never archetypes?
> 
> Regards,
> 
> Pieter Bos
> 
> From: openEHR-technical  on 
> behalf of Thomas Beale 
> Reply-To: For openEHR technical discussions 
> 
> Date: Friday, 26 January 2018 at 14:23
> To: Openehr-Technical 
> Subject: openEHR REST APIs - Release 0.9.0 / invitation for comments
> 
> 
> The REST API Team (Bostjan Lah, Erik Sundvall, Sebastian Iancu, Heath 
> Frankel, Pablo Pazos, and others on the 
> SEC and 
> elsewhere) have made a 0.9.0 Release of the ITS (Implementation Technology 
> Specifications) component, in order to make a pre-1.0.0 release of the REST 
> APIs available for wider comment.
> 
> The key point about this current release is that it is meant to be a 'core 
> basics' foundation of APIs to build on, and some services like CDS, and more 
> sophisticated querying (e.g. that Erik Sundvall has published in the past) 
> will be added over time.
> 
> NOTE THAT IN THE 0.9.0 RELEASE, BREAKING CHANGES ARE POSSIBLE.
> 
> You can see the ITS Release 0.9.0 link 
> here, while 
> the links you see on the specs 'working baseline' 
> page are the 
> result of 0.9.0 plus any modifications made due to feedback. The .apib files 
> are here in 
> Github 
> (see mainly the includes directory).
> 
> We are aiming to release 1.0.0 at the end of February, at which point the 
> formal process kicks in.
> 
> Since we are in Release 0.9.0, the formal PR/CR process is not needed, and 
> you can comment here. However, if you want to raise a PR you can, in which 
> case, please set the Component and Affects Version fields appropriately:
> 
> [cid:image001.png@01D3A67F.BBCA2180]
> 
> - thomas  beale
> --
> Thomas Beale
> Principal, Ars Semantica
> Consultant, ABD Team, Intermountain 
> Healthcare
> Management Board, Specifications Program Lead, openEHR 
> Foundation
> Chartered IT Professional Fellow, BCS, British Computer 
> Society
> Health IT blog | Culture 
> blog
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

RE: Archetype pattern

[Heather Leslie]

Hi Bert,

Unfortunately pattern by itself won't result in good archetypes. Mind you, I 
think the RM classes are brilliant and they have been the cornerstone for our 
modelling experience. In fact I suspect that the lack of these classes is a 
large part of the reason why other modelling paradigms such as CIMI have not 
been able to progress as far and as fast they had wished. 

Clinical medicine is messy, by definition. Our experience is that we often 
identify patterns and then we routinely come across as many examples that break 
those patterns. The slow progress that results is the result of refining those 
patterns to work as universally as possible in the clinical scenarios and how 
to deal with apparently outlying data points.

Then you need to consider clinical diversity that takes into account the range 
of clinicians; differing professional requirements; differing professional 
levels of details; needs of specialists vs generalists; clinical context; 
institution and location; cultural differences; language differences; personal 
health records; requirements for public health and research I could go on. 
We need to identify what a concept is and the appropriate scope; ensure 
minimising overlap as well as minimising gaps between concetps. Good archetype 
design is just not as simple as what you yearn for, despite how logical it 
seems to you. Our job would be much easier if it were so.

The only practical way forward is to start with good representations of 
clinical data and then get broad review from ALL experts - to ensure that the 
clinical data is fit for use as well as to ensure that they are implementable.

As CKM Editors we try to get developers involved in reviews but they are often 
in the minority - not because they are not invited but mostly because they 
don't respond. We have a large list of technicians who were part of the 
companies who funded the original openEHR sprint. Some responded immediately 
with 'Accept' just to try to accelerate the archetype to get a published state. 
Most ignore the invitations to participate. DIPS engineers have been the most 
consistent participants and many modifications in archetypes arose from their 
participation in reviews - this has reflected their requirements for clinical 
content as well as their suggestions regarding the technical implications of 
the archetype design.

The adverse reaction archetype is a case in point - eventually we had 221 
reviews from 92 individuals in 16 countries PLUS an unknown number of 
participants from HL7 Patient care and FHIR communities. Health informaticians 
and IT experts comprised at least a third of reviewers - engineer engagement to 
this level is not our usual experience and if my memory is correct, most of the 
technical input came from the HL7 community, not openEHR.

Patterns have been identified and more are being refined... but don't expect 
them for all concepts, there will always be lots of unique models. Representing 
data that real clinicians can use will not be solved by patterns alone. 
Engaging clinicians is critical. Ontologies are useful but don't necessarily 
cater for the entire reality that is clinical practice. Engineer review and 
input would be much appreciated if it were available.

Why don't you agitate to get more engineers participating in the reviews? I 
would gladly invite anyone who is willing to engage. Get them to adopt an 
archetype today and join in the collective effort - the resulting archetypes 
can only be better for everyone. 

Regards Heather

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Friday, 16 February 2018 2:41 AM
To: For openEHR technical discussions 
Subject: Archetype pattern

An interesting wiki from Heather Leslie

https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns

She concludes that pattern are necessary, I agree with that, and she also 
concludes that clinicians are better modelers then technicians.

Well, that depends, of course it is very important to have domain-knowledge 
when modeling data, and clinicians have the best domain-knowledge. So from that 
point of view, she is right.

But what we have seen until now is that clinicians create archetypes with 
unpredictable paths. And that is bad, because it makes it very difficult to 
find data and it makes it easy to miss important data, because some data were 
on a path where one did not expect them.

OpenEhr works fine to find data which are on a known or predictable path, but 
what if data are on an unknown path?

Let me explain by comparing this to a classical relational health-application. 
There are similarities.

I have seen classical relational systems which experienced a wild-grow in 
number of tables, I have seen once in a prestigious university-hospital where 
they had a grown of 7000 tables in 20 years, more then one per day!! No one 
understood the meani

Re: Archetype pattern

[Thomas Beale]

Indeed, patterns are conceptually what is needed - many of us have 
thought so for a long time. The real question is what lies behind a 
pattern? Consider the OBS/EVAL/INSTR/ACTION set of classes in the RM - 
they are a formal representation of a pattern (each containing some 
micro-patterns), that I would call the 'cognitive loop of care'. It's 
very useful but only solves one problem among many.


There are many patterns and some are more basic than others. Patterns 
that are universal in health care an appear in the RM (you may debate as 
to whether what is actually in the openEHR RM today is correct, but this 
is the principle); others will be realised in archetype or template levels.


An older attempt of mine to categorise some patterns is here on the wiki 
.


The paradigmatic approach for finding patterns is to use ontological and 
epistemological conceptual approaches. In the ontological aspect, 
'reality' needs to be explored and understood. Reality is very complex, 
and we don't capture anything like all its aspects.


Here's an example: in pregnancy and birth, there are the following kinds 
of data items:


 * administrative
 o from pregnancy summary archetype: 'assisted reproduction',
   'planned place of birth', ...
 * clinical - temporal aspect, mostly in OBSERVATIONs
 o historical - i.e. non-tracked variables
 + previous pregnancy information
 o tracked variables
 + e.g. BP (for eclampsia), blood glucose (for diabetes) etc
 o real-time
 + birth process variables, e.g. vital signs, contractions,
   fetal HR, fetal movement
 * clinical - process aspect
 o OBS => EVAL => INSTRUCTION => ACTION cycle
 o schedule of visits, tests etc

and so on. We don't currently distinguish different kinds of variables 
in time that well, nor do we separate adequately various kinds of 
administrative and clinical data items in the current archetypes.


On top of this, things are complicated by what is 'epistemic' and what 
is 'ontological'. For example, the patient tells you she had 10 
miscarriages; do you consider this a 'fact' or not? It depends. 
Statements about events that are not directly observed or performed are 
of the form 'X said that Y'. Do you trust X, or X's method of obtaining 
the information? If X says they are diabetic, probably yes; if they say 
that demons are speaking to them, well...


In the end, reality is fractal and there are finer and coarser levels of 
it. We can think of this as being similar to the levels of molecular 
complexity in biomedicine: proteins are macro-molecules with emergent 
behaviour such as key/lock etc, due to their physical form, also 
chemical binding behaviour, and are constructed of simple molecules 
(amino acids), which have their own chemical characteristics, and so on 
down to atoms.


Models of clinical process (e.g. over a pregnancy, or managing an acute 
stroke) are something like a macro-molecule level, while inside this 
there are many fine-grained elements.


I believe there are patterns we can identify based on various aspects 
and levels of reality, but currently we have poor theories of this. 
Clinicians don't tend to have any formal training in ontology or 
epistemology (but they have some good practical concepts like SOAP, and 
tend to understand the subjective / objective divide quite well), and 
90% of IT people don't either (and accordingly most software is terrible 
because the developers have no idea how to model properly), so everyone 
is weak in this area. But at least clinicians know what they are talking 
about at a medical level.


To do better than we are currently doing would require a better 
engagement with ontology methods (how to investigate reality) and 
concepts from epistemology (how to model gathering and recording of 
information).


Just to finish with a simple example, why is any clinical data item 
included in a data set or model? E.g. why do docs measure BP and blood 
glucose for (some) pregnant women? Because they relate to common risks. 
If the woman has pre-existing risk of pre-eclampsia / eclampsia (such as 
hypertension, family history) then BP needs to be measured. Why don't 
the docs measure her weight (generally speaking) or eye colour? Because 
they don't relate to any particular risks. Tracking variables is work, 
and there is no point in doing useless work. So healthcare professionals 
try to track variables that are indicators of patient state, and can 
quickly indicate deviation into various abnormal states. So properly 
modelling the data for pregnancy for example would require a model of a 
normal pregnancy, and models of abnormal states (various kinds of 
infections, diabetes, eclampsia, and so on), and linkages of the 
relevant variables to the pathological patient states for which they act 
as warnings. Currently we don't model any of this properly - we just 

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

[Pieter Bos]

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

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

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

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

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

Regards,

Pieter Bos

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

Date: Friday, 26 January 2018 at 14:23
To: Openehr-Technical 
Subject: openEHR REST APIs - Release 0.9.0 / invitation for comments


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

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

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

You can see the ITS Release 0.9.0 link 
here, while the 
links you see on the specs 'working baseline' 
page are the 
result of 0.9.0 plus any modifications made due to feedback. The .apib files 
are here in 
Github (see 
mainly the includes directory).

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

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

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

- thomas  beale
--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Archetype pattern

[Anastasiou A .]

Hello Bert

I think that this is an interesting topic from a number of aspects.

Can I please ask what do you mean by "clinicians create archetypes with 
unpredictable paths"? Can you provide one or two examples?

Also about the "something, that is: PATTERN", David Hay has written an 
excellent book "Data Model Patterns: Conventions of Thought", which 
although old (by now), is very well structured. A partial listing of its table 
of contents so that you get what I am trying to say here:
The enterprise and its world
Things of the enterprise
Procedures and Activities
Contracts
Accounting
The Laboratory
Material Requirements and Planning
Process Manufacturing
Documents

The "The enterprise and its world" section outlines basically every "system 
user" database, I dare say, ever.

Are you thinking about taking a look at the healthcare environment and then 
coming up with openEHR patterns that can commonly address each?

I think that this could be done even automatically, given the existence of 
enough archetypes / templates and the fact that they are machine readable with 
enough semantics to infer commonalities and structure.

All the best
Athanasios Anastasiou



-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: 15 February 2018 15:41
To: For openEHR technical discussions
Subject: Archetype pattern

An interesting wiki from Heather Leslie

https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns

She concludes that pattern are necessary, I agree with that, and she also 
concludes that clinicians are better modelers then technicians.

Well, that depends, of course it is very important to have domain-knowledge 
when modeling data, and clinicians have the best domain-knowledge. So from that 
point of view, she is right.

But what we have seen until now is that clinicians create archetypes with 
unpredictable paths. And that is bad, because it makes it very difficult to 
find data and it makes it easy to miss important data, because some data were 
on a path where one did not expect them.

OpenEhr works fine to find data which are on a known or predictable path, but 
what if data are on an unknown path?

Let me explain by comparing this to a classical relational health-application. 
There are similarities.

I have seen classical relational systems which experienced a wild-grow in 
number of tables, I have seen once in a prestigious university-hospital where 
they had a grown of 7000 tables in 20 years, more then one per day!! No one 
understood the meaning of all the tables and data, no one dared to use data he 
did not understand, many data were and still are redundant. Every new 
development in the ICT starts with designing new tables.

How can in such a situation a clinician research a persons medical record, even 
with the help of the current technical staff, this is often impossible. So, 
important information can get lost. Adding to this are software-updates which 
often cause a clean-up, and that clean-up is also done by people who do not 
always know what they clean up. People live long, and a medical problem they 
had 30 years ago can be important to find to solve a current problem. So old 
data, and understand them, and be able to find them, can be important.

This can also happen with archetypes. Every new development in a application 
can start with a new archetype, and at a moment there can be thousands. It is 
impossible for a clinician to search all possible paths for medical 
information, even with the help of the current technical staff this can be 
impossible.

The old data-hell situation will not be solved by OpenEhr if there is not 
something behind it. And that something, that is: PATTERN

It is not only a clinical thing to understand how pattern in paths are best 
modeled, it is in fact also a technical thing. Clinical knowledge is not 
stable, the thinking about clinical facts change all the time, what now is 
important is tomorrow maybe not. So the pattern need a technical, mathematical 
base, that, something like Codd-normalization, but of course then applicable to 
archetypes.

The Wiki from Heather Leslie is a good starting point for the design of pattern 
and stop the proliferation of paths.

I described an approach to solve this problem in a blog, one and a half year 
ago.

http://www.bertverhees.nl/openehr/medical-data-context/

I had some discussion about that, but many had problems against the use of 
SNOMED in this context. So, maybe read it and forget SNOMED ad find something 
else to structure the medical data.

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

Archetype pattern

[Bert Verhees]

An interesting wiki from Heather Leslie

https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns

She concludes that pattern are necessary, I agree with that, and she 
also concludes that clinicians are better modelers then technicians.


Well, that depends, of course it is very important to have 
domain-knowledge when modeling data, and clinicians have the best 
domain-knowledge. So from that point of view, she is right.


But what we have seen until now is that clinicians create archetypes 
with unpredictable paths. And that is bad, because it makes it very 
difficult to find data and it makes it easy to miss important data, 
because some data were on a path where one did not expect them.


OpenEhr works fine to find data which are on a known or predictable 
path, but what if data are on an unknown path?


Let me explain by comparing this to a classical relational 
health-application. There are similarities.


I have seen classical relational systems which experienced a wild-grow 
in number of tables, I have seen once in a prestigious 
university-hospital where they had a grown of 7000 tables in 20 years, 
more then one per day!! No one understood the meaning of all the tables 
and data, no one dared to use data he did not understand, many data were 
and still are redundant. Every new development in the ICT starts with 
designing new tables.


How can in such a situation a clinician research a persons medical 
record, even with the help of the current technical staff, this is often 
impossible. So, important information can get lost. Adding to this are 
software-updates which often cause a clean-up, and that clean-up is also 
done by people who do not always know what they clean up. People live 
long, and a medical problem they had 30 years ago can be important to 
find to solve a current problem. So old data, and understand them, and 
be able to find them, can be important.


This can also happen with archetypes. Every new development in a 
application can start with a new archetype, and at a moment there can be 
thousands. It is impossible for a clinician to search all possible paths 
for medical information, even with the help of the current technical 
staff this can be impossible.


The old data-hell situation will not be solved by OpenEhr if there is 
not something behind it. And that something, that is: PATTERN


It is not only a clinical thing to understand how pattern in paths are 
best modeled, it is in fact also a technical thing. Clinical knowledge 
is not stable, the thinking about clinical facts change all the time, 
what now is important is tomorrow maybe not. So the pattern need a 
technical, mathematical base, that, something like Codd-normalization, 
but of course then applicable to archetypes.


The Wiki from Heather Leslie is a good starting point for the design of 
pattern and stop the proliferation of paths.


I described an approach to solve this problem in a blog, one and a half 
year ago.


http://www.bertverhees.nl/openehr/medical-data-context/

I had some discussion about that, but many had problems against the use 
of SNOMED in this context. So, maybe read it and forget SNOMED ad find 
something else to structure the medical data.


Bert


___
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 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 Würzburg  mail: georg.fe.

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

[Georg Fette]

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/releases/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.
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.
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.

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

AQL Parser

[Georg Fette]

Hello,
What is the best (comfortable, easiest to use, most often used, most 
interoperable, etc.) implementation of an AQL parser currently available ?
After some googleling I found a Git repository of JacSoyYo. 
Alternatively I could cut the parser from the EtherCIS-Server.
Currently I am only interested in a runtime object model of AQL queries 
so I do not need an interpreter engine.

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