Difference between revisions of "CTS2/doc/CTS2 SFM ValueSetArea"
m (1 revision: Re-import CTS2 documentation pages with appropriate links)
Revision as of 22:30, 27 November 2015
Alignment between the CTS2 SFM and PIM Value Set Classes
The value set model is one of the areas where there was significant deviation between the SFM and the PIM. One of the primary differences between the models is that the SFM treats an "extensionally defined" value set as being (almost) identical to a resolved value set, while the PIM does not differentiate "extensional" from "intensional" definitions - a definition can include individual concept references, queries or any combination of the two. This came about, in part, because the PIM authors did not want to have to explain why a definition that references the individual concepts (A, B and C) would be represented in an entirely different fashion than the definition that references (A, B and the children of C). A second motivation involved validation - a value set definition could say "concepts (A, B, and C) from version 2012AA of code system X", which would always return A, B and C assuming that they were active in version 2012AA of code system X, but the definition could also just say "concepts (A, B, and C) from code system X", where the code system version would be specified in the resolution step. This would yield different results if, say, it was applied to version 2011AA of the code system, where, perhaps, concept C was not present and 2012AB where concept B may have been retired.
While both models addressed the abstract notion of "Value Set", the SFM leaves the intensional definition of the contents of a value set (ruleSet) outside the of the model scope. The PIM specifies a set of semantics that will allow the interchange of most common value set definitions. The SFM states that "the 'resolution' of a value set version is not explicitly represented in the model". There were several use cases and requirements that arose in other situations, however, that called for the treatment of resolutions as first class resources - often the only information that will be available will be the resolution itself.
The diagram above shows the SFM alongside the three resources that comprise the PIM value set:
- ValueSetCatalogEntry, which carries persistent information about the value set, such as its name, who publishes it, what code systems it uses, etc.
- ValueSetDefinition which carries the set of rules about how a value set is constructed. In this model, we only show one type of rule - SpecificEntityList, which, when it is the sole entry in a definition, closely approximates the SFM notion of an extensional definition.
- ResolvedValueSet which is the result of applying a definition to specific versions of one or more code systems.
We have included both the definition and resolution because, while the SFM doesn't include resolved value sets in its scope, its definition of extensional definition sits on the boundary of definition and resolution.
|ValueSet||ValueSetCatalogEntry||The containment relationship between ValueSet and ValueSetVersion was changed to a derived reference from the resolved value set to the entry. This ROA approach allowed ResolvedValueSets to be exchanged as first class elements without requiring the presence of the associated metadata. The name "ValueSet" was changed to "ValueSetCatalogEntry to make it clear that the class represented metadata about the set itself and that the definitions and their resolutions would be found by reference.|
|ValueSetVersion||ValueSetDefinition||With the exception of "extensional" definitions, the rules for constructing value sets implicitly referenced via the ruleSetId and ruleSetVersionID|
|(none)||ResolvedValueSet||Note that "extensional" definitions are considered to be part of ValueSetDefinition|
|ConceptValueSetMembership||SpecificEntityList.referencedEntity||For extensional definitions are viewed as definitions|
|ResolvedValueSet.member||For extensional definitions viewed as actual resolved value sets|