On 17-02-18 13:11, Diego Boscá wrote:
Maybe it is possible to generalize it in a way that it could be
external calls that return a value or list of values. Maybe this is
enough for SNOMED, CDSS, but also for queries to linked data such as
drug-drug interaction and other services availabe in bioportal, etc.
Hi Diego, I don't know what bioportal is, and how you want to find
drug-drug interactions. In the Netherlands we have a large and well
maintained data-vendor for this purpose, called Z-index. But I found
that SNOMED itself also has drug-drug interactions, and it can, maybe,
also become a national extension to SNOMED, because drugs often differ
from country to country.
Maybe this can be decided later, and that first the focus will be on the
SNOMED part.
I was thinking in your suggested way too (I think), that a special
value-list-layer is added inside the AQL query-engine, which can do some
comparison at the moment the AQL engine creates a result-set (internal)
What is important to decide is that the AQL is using a SNOMED resultset,
and not the other way, so the AQL has the deep magic layer.
So the magic will happen at a deep internal level the AQL part using the
SNOMED part cannot be at AQL-API-level, because that would be the same
as doing the queries separately, and that would be very costly.
Although, for a start, this is possible.
For SNOMED, I found there are API's defined or being defined, so that
would be the stable part.
What is very important, but maybe that is already taken care of, we need
a formal way to include a SNOMED expression into an AQL query.
If we are able to separate a SNOMED part from the AQL part, and define
how it interacts with the AQL part, then we can parse that SNOMED part
in a microservice and hand over the result to the database-specific AQL
engine maintainers/developers.
Bert
2018-02-17 9:23 GMT+01:00 A Verhees <[email protected]
<mailto:[email protected]>>:
The discussion Pablo has makes me think it could be good to have
in an AQL-engine an entry to have external query languages
executed like SNOMED expressions which can treat result data as
hierarchies of data and so add an extra functionality layer
Bert
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
--
VeraTech for Health SL <https://htmlsig.com/t/000001C268PZ>
Twitter <https://htmlsig.com/t/000001C47QQH>LinkedIn
<https://htmlsig.com/t/000001C4DPJG>Maps
<https://htmlsig.com/t/000001BZTWS7>
Diego Boscá Tomás / Senior developer
[email protected]<mailto:[email protected]>
[email protected] <mailto:[email protected]>
VeraTech for Health SL
+34 961071863 <tel:+34%20961%2007%2018%2063> / +34 627015023
<tel:+34%20627%2001%2050%2023>
www.veratech.es <http://www.veratech.es/>
Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF
B98309511) cuya finalidad es la de mantener el contacto con usted.
Conforme a La Ley Orgánica 15/1999, usted puede ejercitar sus derechos
de acceso, rectificación, cancelación y, en su caso oposición,
enviando una solicitud por escrito a [email protected]
<mailto:[email protected]>.
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
