The best way to resolve this is to make the terminology server part of the local system, and have the resolution a dynamic one between the systems. That allows you to optimise the performance implications of large value sets.
Grahame On Tue, Sep 13, 2016 at 1:21 AM, Thomas Beale <[email protected]> wrote: > Bert, > > these are just selectors; what I mean is that in the generated result - > the actual value set - that IS-A relationships are returned as well as > concept codes. Without IS-A relationships a user can't navigate a value set > larger than a few terms in a useful way in a real system. > > - thomas > > > On 12/09/2016 10:23, Bert Verhees wrote: > >> Op 12-9-2016 om 10:30 schreef Thomas Beale: >> >>> does the expansion preserve IS-A relationships (at least optionally)? >>> That's crucial for making any value set of more than about 20 terms usable >>> in a real system. >>> >> >> I think you need to do that by additional refinements, f.e. >> >> < 19829001 |disorder of lung|: 116676008 |associated morphology| = >> 79654002 |edema| >> >> or >> >> 19829001 |disorder of lung|: 116676008 |associated morphology| = 40829002 >> |acute edema| >> >> or >> >> 19829001 |disorder of lung|: 116676008 |associated morphology| = 44132006 >> |abscess| >> >> >> Examples from: http://snomed.org/expressionconstraint >> >> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_ > lists.openehr.org > -- ----- http://www.healthintersections.com.au / [email protected] / +61 411 867 065
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
