In an ideal world you probably would just ask if the code is in the subset (both as parameters). From the snomed evaluation cost of both operations (give me all the codes and is this code in the subset) cost virtually the same (or less). Also several caching techniques could be used in both scenarios so recurring queries are instant even for the "A in B" operation
El 17 feb. 2018 8:58 a. m., "A Verhees" <bert.verh...@rosa.nl> escribió: Hi, sorry to interfere, if II understand well, I think a possible problem could be that respiratory infection caused by a virus can return some derived codes to be returned although in this case it are not so many. However to use this mechanism generally, it can happen that really many derived codes will be returned from the SNOMED engine, and in that case the AQL query would need to be executed many times. Once for each possible derived code. One could also consider to hand over the result set from AQL to the SNOMED engine to see if it is derived, which could cause less executions. But in both cases it is datamining which is always difficult to estimate what the best strategy in a specific case is. A good idea maybe to design an intelligent query-strategy-decision engine which offers advice to see what works best. This engine could execute limited queries, for example, with a count operator so that it does not need to go all the way when a limit is reached. It is true what you write that datamining queries seldom are expected to return in real time, but I have seen situations in marketing were they ran for hours and queried almost one million dossiers, we even created in between databases. That decision engine could also be an external service. It is good to hear that you think about separated services anyway. That works in the advantage of a microservices architecture. Bert Op za 17 feb. 2018 04:30 schreef Pablo Pazos <pablo.pa...@cabolabs.com>: > Hi Pieter, > > On Fri, Feb 16, 2018 at 12:27 PM, Pieter Bos <pieter....@nedap.com> wrote: > >> Sounds like a good proposal Pablo. >> >> > The idea came from a PoC I did last year integrating SNOMED expressions > into openEHR queries. > > IMO complex queries will need external very specialized micro services to > be evaluated, and ADL syntax is not enough to represent some complex > queries. > > For instance, "give me all patients that had a diagnosis of respiratory > infection caused by virus, from any composition whose archetype is > specialized from X". > > > 1. "diagnosis" = archID (Problem/Diagnosis) + path_to_coded_diagnosis > 2. "respiratory infection caused by virus" = SNOMED Expression (<< > 275498002 |infección del tracto respiratorio (trastorno)| : 246075003 > |agente causal| = 49872002 |virus|) > 3. "composition defined by a specialization of archetype X" = list of arch > IDs in a specialization hierarchy > > > 1. Is part of openEHR and the internal data repo model > 2. Should be evaluated against a service that will return codes in a plain > list > 3. Should be evaluated against a service that will return archetype ids in > a plain list > > With 2 and 3 resolved, it is easy to transform everything into SQL or > whatever, execute the query, get results and transform results in some > representation (JSON, XML, CSV, etc). > > We could still add complexity to the query, and will need more external > microservices to resolve instead of implementing everything internally > generating unmaintainable/unescalable/less interoperable systems. > > Another idea is to think of query "features", so we can define profiles, > for instance my queries support SNOMED expressions, your queries support > querying by archetype hierarchies, etc. If we standardize the features it > will be easy to have compliance statements for each system, marking which > features are implemented on an openEHR CDR. And the idea of having external > micro services that can help implementing those features would help to have > full featured query interfaces on many different systems, and even reach > query interoperability (we are far from that right now). > > > >> For ADL 2 a single archetype api can be used for both archetypes and >> templates. However, it makes sense to allow the get api of archetypes to >> specify the form you want the result in: differential, flattened, or >> operational template (opt2). >> > > IMO most endpoints on the API should be agnostic of the ADL version and > work with template ids, archetype ids and paths. But of course, if we have > template management endpoints, that will be ADL/OPT version dependant, > since formats and models differ. > > >> >> Our EHR still will integrate the archetype part and query part, as well >> as the option to choose a used archetype for a slot at runtime. Could all >> be built with separate services and apis, but once you have everything >> integrated it makes for a very easy to use API for both EHR and >> datawarehouse usage. without needing sophisticated client libraries. >> However, you need much more complex server side tools in the EHR of course. >> > > Of course, that is a design/implementation decision. I agree having all > the "features" implemented in one place adds a lot of complexity to the > system, while might improve performance. > > A little thought about performance, I think most queries don't need to be > executed in real time, and a lot of background work and caching can be done > to make things work fast, so I don't see an issue on having complex queries > and use multiple external micro services to be able to evaluate the whole > query. > > > Best, > Pablo. > > >> >> Regards, >> >> Pieter >> >> Op 16 feb. 2018 om 15:48 heeft Pablo Pazos <pablo.,@cabolabs.com> het >> volgende geschreven:Ivo >> >> Hi Pieter,s >> >> Besides the API, I think for ADL2 archetypes and templates/OPTs have the >> same model, and archetype IDs / template IDs will follow the same >> structure.So for ADL2 using archetypes or templates would be the same in >> the API. >> >> Which endpoints do you find problematic in terms of using ADL2? >> >> >> About querying, analyzing your use case, I think there are two ways of >> knowing the full specialization hierarchy, one is to query an archetype >> repo/CKM while evaluating a query and do not have that info in the data >> repo. Like "give me all archetype IDs that specialize arch ID X", this will >> be [A, B, C], then use that list on the query in your data repo like >> "archetype_id IN [A, B, C]". >> >> The other option is to have the archetype repo/CKM integrated with the >> clinical data repo (which I don't like architecturally speaking), so the >> "give me all the archetype IDs that specialize arch ID X" is resolved >> internally. >> >> Considering there is a component that has knowledge about the >> specialization, and that can be used internally (behind the API) I don't >> see the need of adding explicit support in the API for archetypes. >> >> What I think is better is to define an archetype repo/CKM API to manage >> archetypes and to resolve specialization queries among other queries like >> "this path exists for this archetype ID?", etc. If this is possible, we can >> have interoperability between archetype repos and your queries can use my >> repo to get specialization info, and vice-versa. >> >> >> Best, >> Pablo. >> >> >> >> On Thu, Feb 15, 2018 at 1:09 PM, Pieter Bos <pieter....@nedap.com<mailto: >> pieter....@nedap.com>> 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 <openehr-technical-boun...@lists.openehr.org >> <mailto:openehr-technical-boun...@lists.openehr.org>> on behalf of >> Thomas Beale <thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> >> Reply-To: For openEHR technical discussions <openehr-technical@lists. >> openehr.org<mailto:openehr-technical@lists.openehr.org>> >> Date: Friday, 26 January 2018 at 14:23 >> To: Openehr-Technical <openehr-technical@lists.openehr.org<mailto: >> openehr-technical@lists.openehr.org>> >> 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<https://www.openehr.org/ >> programs/specification/editorialcommittee> 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<https://www.openehr.org/ >> programs/specification/latestreleases>, while the links you see on the >> specs 'working baseline' page<https://www.openehr.org/ >> programs/specification/workingbaseline> are the result of 0.9.0 plus any >> modifications made due to feedback. The .apib files are here in Github< >> https://github.com/openEHR/specifications-ITS/tree/master/REST_API> (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<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 >> openEHR-technical@lists.openehr.org<mailto:openEHR- >> techni...@lists.openehr.org> >> http://lists.openehr.org/mailman/listinfo/openehr- >> technical_lists.openehr.org >> >> >> >> -- >> Ing. Pablo Pazos Gutiérrez >> pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com> >> +598 99 043 145 >> skype: cabolabs >> [https://docs.google.com/uc?export=download&id=0B27lX- >> sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4 >> VXBxWFZ6OXNnPQ] <http://cabolabs.com/> >> http://www.cabolabs.com<http://www.cabolabs.com/> >> https://cloudehrserver.com<https://cloudehrserver.com/> >> Subscribe to our newsletter<http://eepurl.com/b_w_tj> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org<mailto:openEHR- >> techni...@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 > > > > > -- > Ing. Pablo Pazos Gutiérrez > pablo.pa...@cabolabs.com > +598 99 043 145 <+598%2099%20043%20145> > 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
