Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

On 17-02-18 16:33, Pablo Pazos wrote: I think that is the expected behavior, also what is returned depends on the operators in the SNOMED expression, like << will return all descendants. The expression can be tuned to return just what you want, and the process of the result should work

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

On 17-02-18 16:39, Pablo Pazos wrote: That is why SNOMED alone can't be used for querying. I agree with that, else, you would not need OpenEhr at all ;-) ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

IMO what gives context is the OPT that constrains the underlying reference model, queries are based on archetypes and paths defined in OPTs and SNOMED expressions are just a way of creating semantically complex criteria for querying, nothing more. That is why SNOMED alone can't be used for

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

On 17-02-18 11:21, GF wrote: That context/epistemology is defined by meta-data in COMPOSITION that as committed to databases and documents. That is why OpenEhr and SNOMED can be a strong combination. ___ openEHR-technical mailing list

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

Hi, In order to reach full interoperability and interpretability we need a clearcut separation between constituting models that are part of the Interoperability standards stack. It is the function of a Terminology to create a system of concepts that coherently defines concepts in a domain. And

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

Hi Pieter, On Fri, Feb 16, 2018 at 12:27 PM, Pieter Bos 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

HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

Sounds like a good proposal Pablo. 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). Our EHR still will