CTS2/doc/CTS2 SFM ValueSetAttributes

From HL7Wiki
Revision as of 21:09, 8 August 2012 by Hsolbrig (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Prev Contents Next

CTS SFM and PIM attribute mapping

This section describes the relationship between the attributes and associations described in the CTS2 SFM and the corresponding entries in the PIM

top CTS2/doc/Image:ValueSetAttributesPIM.png

Class SFM PIM Description
ValueSet id ValueSetCatalogEntry.about (redefines ValueSetCatalogEntry.entryID) This must be a URI in the PIM - value set OIDs can be converted to URI's by prefixing "urn:oid:" to the OID itself.
name[0..1] ValueSetCatalogEntry.valueSetName Note that the name is currently required in the PIM. valueSetNames must be locally unique within the context of a service and, worst case, could be identical to id
description[0..1] ValueSetCatalogEntry.resourceSynopsis[0..1] See code system attributes section for description of the name change
ruleSetID[0..1] (none) The PIM views the identity of the generic rule set as equivalent to the identity of the value set itself.
status ValueSetCatalogEntry.entryState The SFM defines status as "A status (status) to identify the state (mainly for curation)". entryState provides the state of the value set with respect to the service (ACTIVE or INACTIVE)
ValueSetCatalogEntry.status[0..1] The status of the value set within an external workflow, which covers the "curation" portion of the description
statusDate[0..1] ChangeDescription.changeDate
(Not shown in this diagram)
The date that the last change occurred. Note that this applies to all changes - a client will have to locate a METADATA change type where the status changed or, if not present, the CREATE change type where the first entry was created.
isImmutable (none) While the SFM doesn't say anything more about this requirement, the PIM authors concluded that its purpose is to identify value sets that should not be extended or modified in "the field". Assuming this is the case, it represents one instance of a business rule - a rule enforced by a specific service implementation for a specific purpose. The CTS2 PIM tried to steer clear of the specific rules for authoring one or another terminological resource and, as a result, did not include this as part of the PIM.
ValueSetVersion versionId ValueSetDefinition.documentURI Every definition version must have a unique URI
effectiveDate ValueSetDefinition.officialActivationDate[0..1] Note that the SFM treats this as a mandatory field. There were use cases where this date was not known or wasn't relevant, so the PIM made it optional.
releaseDate[0..1] ValueSetDefinition.officialReleaseDate[0..1]
previousVersionID[0..1] ValueSetDefinition.predecessor[0..1]
rulesSetVersionID[0..1] (none) The PIM doesn't differentiate the definition from the definition rules.
supportedLanguages[0..1] (none) The PIM doesn't directly associate languages with value set definitions and, instead, views the available languages as a function of the referenced code system(s)
status ValueSetDefinition.entryState The SFM defines status as "A status (status) to identify the state (mainly for curation)". entryState provides the state of the value set definition with respect to the service (ACTIVE or INACTIVE)
ValueSetCatalogEntry.status[0..1] The status of the value set definition within an external workflow, which covers the "curation" portion of the description
statusDate[0..1] ChangeDescription.changeDate
(Not shown in this diagram)
The date that the last change occurred. Note that this applies to all changes - a client will have to locate a METADATA change type where the status changed or, if not present, the CREATE change type where the first entry was created.
provenanceDetails[0..1] (multiple attributes) ValueSetDefinition.property can be used to add any additional provenance details that aren't made explicit in the model
ConceptValueSetMembership effectiveDate[0..1] (none) The SFM is a tad unclear about the whole purpose of this attribute. The definition says that it is "required for 'intensionally' defined Value Sets where the resulting concepts from applying the algorithm..., which runs counter to the earlier assertion that resolved value sets are not a part of the model. In addition, the spec asserts that "The absence of date attributes on this class deliberately imposes the restriction that a new concept being added would require a new value set version...", which is doubly confusing, as effectiveDate certainly appears to be a date attribute.

From the perspective of definitions, it would be the ValueSetDefinition.officialActivationDate that would apply to all the members of the definition. From the perspective of resolutions, the PIM doesn't consider the date that the resolution occurred as being the determiner and, instead, records the URI's of the code system version(s) and the value set definition that was used in the resolution process.

valueOverride[0..1] (none) The PIM authors were uncertain of the exact use case that drove this requirement. One possibility was that it was an artifact of the CodeSystemConceptCode CodeSystemConcept dichotomy, where the value set definer wanted to select from several possible codes to identify the entry. A second possibility was that this was intended to prevent code collisions when value sets were drawn from multiple sources. Yet another possibility was that this was intended, in some way, to begin to model the equivalent of "permissible value" from the ISO 11179 perspective, where the intended meaning may be represented by local values in some databases.

The CTS2 PIM attempts to address all three of these concerns through the use of URI's. Every concept in a value set is represented by a unique URI. A entry in a resolved value set may include a local namespace, code and designation of the service's choosing, the identity of the entry is determined solely by the URI. Early versions of the CTS2 specification included a "pick list" resource, which controlled the ordering, representation and various aspects of value set display. This was removed from the final OMG submission, however, because it still needed review and time was running short.


Prev Contents Next