LexEVS 6.1 Design Document - Detailed Design - Performance - Value Set Resolution (Persistence)

 

Revision History

Overview

Resolving rule based value sets against a large set of terminologies has proven to have poor performance. Given that a large number of value sets may normally be dynamically resolved over a wide variety of code systems the problem can be compounded. Resolving value sets and persisting them can provide a static value set that does not have to be constructed by a potentially complex algorithm against a set of elements in some terminology service code system or systems.

Curation Strategy

Value sets will have to be chosen for resolution by the terminology service administrator based on user demand before loaded via a LexEVS Value Set Definition resolution loader to a persistence strategy.

Resolved Value Set Loader

Currently LexEVS can load a value set definition to the underlying database, but does not persist the resolution of that definition. Additional persistence functionality will be added to the LexEVSValueSetDefinition API to provide the needed loader for resolved value sets. Since value sets are comprised of LexEVS entities, the resolution of these value sets can be persisted to a coding scheme created specifically as a container for that value set. Since terminology services will want to distinguish between value set coding schemes and actual coding schemes a coding scheme property named codingschemetype with value valueset will allow internal APIs for coding schemes to distinguish between the two types, preventing external users from seeing value set coding schemes in the terminology service list of terminologies. The effect will be that the coding scheme API will never "see" the coding scheme value sets and the resolved value set API will only see the value set type coding schemes.

Resolved Value Set Client API

A new client API will need to be developed for LexEVS to provide Value Set Definition like access to the persisted value sets.