CTS2/doc/CTS2 SFM CodeSystemVersionAttributes
The diagram below contains the attributes described in the CTS2 SFM and the those in the CTS2 PIM. The sections that follow explain the differences between the two models and the rationale for the differences.
Note: releaseFormats and supportedLanguages have been changed in the model below to the singular form and the cardinality has been changed to reflect the intent of the original authors. It is an unfortunate artifact from the fact that earlier versions of the SFM used the ISO Healthcare Data Types (21090), which carry cardinality in the data type itself rather than in the containing model.
Also, the cardinality of releaseDate has been changed from 0..1 to 0..* because the accompanying documentation states that the element is "a set of dates that represent when the version of the Code System became available within a particular domain"
CTS2/doc/Image:CodeSystemVersionAttributes.png
| SFM | PIM | Reason |
|---|---|---|
| versionId | codeSystemVersionName | The SFM defines this as "- "a version identifier that uniquely identifies each version of a code system", but does not address the scope of the "uniqueness". codeSystemVesionName provides a version identifier that is unique within the context of the service instance. |
| entryId | entryId provides a version identifier that is globally unique. Note that this is implemented as codeSystemVersionURI in the CTS2 REST and SOAP Platform Specific models | |
| effectiveDate | ChangeDescription[0..1].effectiveDate (not shown in the above model) |
The description of this element implies that there may be multiple effective dates per server instance, depending on the context. The PIM authors determined that this was a level of complexity that added little value to the model and reduced it to a single occurrence. The attribute was factored into ChangeDescription element because the ability to retrieve historical and temporal elements was decided to be a separate compliance point. |
| officialActivationDate[0..1] | While the SFM doesn't call for this, the PIM authors determined that the "effective date" officially published by the code system publishers was often an important piece of information | |
| previousVersion[0..1] | predecessor[0..1] | Name was changed because this is a generic attribute and applies to a variety of versionable elements such as ValueSetDefinition. The NameAndMeaningReference type requires an ExternalURI, but allows the service to provide an optional href that can be resolved to the service rendering of the resource as well as the local name of the previous version for human readability. |
| releaseDate[0..*] | officialReleaseDate[0..1] | As with effectiveDate, the notion of managing a collection of dates qualified by context and domain was considered unnecessarily complex and, if it was needed, it could be added as additional properties. Instead, it was determined that the date that the terminology officially became available in whatever domain or realm the service represented seemed to be a more useful field. |
| releaseFormat[0..*] | sourceAndNotation | After examining a number of code systems, it was determined that the actual content of the code system almost always depended on the release format. As an example, the RF1, RF2, UMLS, "Spackman OWL" and "Kaiser OWL" formats of SNOMED CT all resulted in content differences that effected the final content. The first question that one had to ask when discussion a particular version of almost any resource was "Which format (syntax) and rendering (semantics) did you use to load this?" The PIM authors determined that the identity of a code system version included the format - that the "Spackman OWL" and RF2 renderings of SNOMED-CT 20120131 both constituted different releases.
The net effect of this is that there is only one release format per version in the CTS2 PIM. At the moment, there is no easy way to enumerate the possible formats for a given code system, although this might make a useful addition to the CodeSystemCatalogEntry resource in a subsequent release. |
| releaseLocation[0..1] | documentURI | The SFM defines this as "- "the official location in which the version of the code system is made available"". The CTS2 PIM interpreted "official location" as the URL of a definitive digital resource. This attribute was made mandatory because it provided a key link back to the origin of the content of the code system version itself. |
| supportedLanguage[0..*] | supportedLanguage[0..*] | |
| defaultLanguage[0..1] | this was added as a way for the service to state (a) which language would be assumed if it was not supplied in a query and (b) what language would be used in simple attributes that don't carry multiple interpretations (e.g. resourceSynopsis and the like).
Note: the OpaqueData type does allow multiple language renderings to be embedded in the type itself. The model and interpretation, however, are outside the scope of the CTS2 document and implementers are encouraged to refer to the appropriate ISO and W3C standards. | |
| status | entryState | The definition in the SFM says that "A status to identify the state of the Code System Version". The CTS2 PIM divides these into two aspects:
entryState represents the first of these aspects - whether it is ACTIVE or INACTIVE |
| <tt>status[0..1]</tt> | represents the second - this is workflow status specific to the terminology authoring environment | |
| statusDate[0..1] | (Included in the update model) | There are a variety of things that can change over time in a CTS2 resource, so the model has been generalized. Services that support the HISTORY and TEMPORAL profiles have the ability to say what changed between two points in time, which includes any status changes. |
| description[0..1] | resoureSynopsis[0..1] | See: Code System Attributes for details |
| provenanceDetails[0..1] | (many) | sourceAndRole, additionalDocumentation, the update model, etc. all make parts of this explicit. In addition, any "details" that aren't specifically included can be placed in the property attribute - a collection of tag/value pairs. |
| fullName[0..1] | formalName[0..1] | |
| localName[0..1] | codeSystemVersionName | The description "normally referred to" is a bit ambiguous. The CTS2 PIM states that every code system version will have a name that is unique within the context of the implementing service. The use of normal names between services is prohibited. |
| copyRight[0..1] | rights[0..1] | The term "rights" was chosen over copyRight because it matched the Dublin Core in purpose and definition. |
| source[0..1] | sourceAndRole[0..*] | Code system versions frequently have multiple sources. Instead of trying to enumerate the list of roles (the approach taken by the OMV), the CTS2 PIM allows roles (e.g. author, distributor, creator, ...) to be selected from external terminologies such as the Dublin Core. |
