On 16/02/2018 10:50, Georg Fette wrote:
Hi Thomas,
I have taken a look at the abstract service model interfaces and have
compared them to the interfaces we have developed for our own data
warhouse architecture:
* IQueryService:
In our experience we noticed that queries can take quite some time to
finish, so a synchonized/blocking method call did not work well as an
interface. Queries can fail because of lack of memory or lack of disc
space when the result sets get too large. An asynchronous query
execution worked better. Additionally to the execute methods which
return a running_query_ID there have to be methods that check the
status of running queries. The result sets are as well accessed via
the running_query_ID. A running query should be cancelable. When
possible, a running query should provide the expected amount of time
it still needs to finish (in total% or in seconds).
good point - we have thought about this a lot in the past, but never
formalised it. The obvious approach would seem to be that point of care
queries, that are usually pre-built and part of UI app screens, should
be served fast, and synchronously, ideally from a dedicated query
service instance. Secondly, research queries, business process queries
and most population queries (e.g. on reports) should probably be
asynchronosly served.
So I think we need both kinds. I think you are asking for calls that
enable an async execution to start, and return a handle to the 'running
query'. That seems eminently sensible. If you want to propose it more
formally, let me know, otherwise I can put in some features to do this,
as I understand the idea.
* Definition package
It is sometimes useful for query designers to be able so work with and
save unfinished or syntactically incorrect queries. The definition
interface should provide methods that check the syntactic correctness
of methods and provide comments (String-based) on the state of a given
query.
The provenance of queries that are used for medical research should be
as strictly logged as all code, specifications and data that is
involved in the provision of clinical data. Therefore the query
descriptor calls needs members for versions and who created the query.
good point. We could make 'authored queries' be based on the same
AUTHORED_RESOURCE
<https://www.openehr.org/releases/BASE/latest/docs/resource/resource.html#_authored_resource_class>
class or AUTHORED_ARCHETYPE
<https://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_authored_archetype_class>
as archetypes perhaps, or some subset. This provides a lot of meta-data.
To support the management of queries they should be able to be stored
in a kind of file structure (treelike). A query should therefore
belong to a folder to which it is associated.
we coined the term 'query set' to cover the idea of a set of related
queries, but we have not yet formalised it. If you have specific
suggestions here, we can incorporate them.
* Admin package
An important part of querying is logging of executed queries. There
should be an Interface for the history of all executed queries,
including AQL code, user, execution time, execution duration, amount
of results.
Good point - I'll add this.
* I_EHR service interface
Our data warehouse system is based on an EAV schema. Therefore it was
easy to provide methods that return all instances of a certain
attribute. With this kind of access it is easier to debug or create
summary reports instead of using the query interfaces for doing the
same job. I have to admid that I have no idea how to provide this kind
of access in an archetype based model. The sole access at the moment
is via the ehr_id. More methods that provided orthogonal access
possibilities based on archetype IDs would be nice.
well the general idea I think is an ETL concept, whereby AQL querying
can be used to export out flat DB tables of the kind you want. Ocean at
least did this in the past, and built some template additions, from
memory, that mapped template paths to dB table columns. I don't have any
detailed spec for this however, and would in any case need input from
people who work more in this area, such as your team ;)
- thomas
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
