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).
* 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.
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.
* 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.
* 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.
Greetings
Georg
--
---------------------------------------------------------------------
Dipl.-Inf. Georg Fette Raum: B001
Universität Würzburg Tel.: +49-(0)931-31-85516
Am Hubland Fax.: +49-(0)931-31-86732
97074 Würzburg mail: [email protected]
---------------------------------------------------------------------
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
