This wiki has undergone a migration to Confluence found Here
Difference between revisions of "CTS2/doc/CTS2 SFM EntityAttributes"
Jump to navigation
Jump to search
m (1 revision: Re-import CTS2 documentation pages with appropriate links) |
|
(No difference)
| |
Revision as of 22:30, 27 November 2015
CTS2 SFM CodeSystemEntityVersion, AssociationType and DefinedEntityProperty alignment
This section builds on the simplified PIM model described in the entity class alignment section. Note that the SFM model used below is the result of the simplification steps described in the previous document.
| Class | SFM | PIM | Reason |
|---|---|---|---|
| CodeSystemEntityVersion | id | about | The SFM specifies id as an "optional unique identifier" the scope of which is clearly intended to be limited that of the containing CodeSystem. The CTS2 PIM requires that the about identifier be in the form of a URI. This present a problem in the HL7 environment as the HL7 model uses the CD data type to represent the code system / concept code combo and, to the best of our knowledge, does not allow for a stringified equivalent that can be used in a URI. The CD data type is not currently being used outside of the HL7 environment and, as it was highly unlikely that the RDF, OWL and Semantic Web community could be convinced to forgo the use of URI's for HL7 concepts, the PIM authors determined that all resources, including concepts, should be represented as URIs in the PIM and, that, subsequently, a HL7 specific PSM should be issued that will formally describe how concept and code system URIs would map to the corresponding CD based equivalent.
This, however, leaves us with two outstanding issues:
Note that the proposals for official URI's are currently being pursued with various member organizations, and we hope to arrive at an official NLM URI scheme for the UMLS. The HL7 proposals, however, are merely suggestions. |
| isConceptInitiator | (see: Entity Versioning) | ||
| code[0..*] | alternateEntityId | The alternate entity id attribute allows multiple unique identifiers to be assigned to a given entity. (insert example here) | |
| versionId | (see: Entity Versioning) | ||
| effectiveDate | (see: Entity Versioning) | ||
| previousVersion[0..1] | (see: Entity Versioning) | ||
| status | entryState | entryState covers the semantic part of the status, identifying an entity as ACTIVE or INACTIVE | |
| status[0..1] | status reflects the workflow status of the entity, as defined by the code system authors | ||
| statusDate[0..1] | (see: Entity Versioning) | ||
| provenanceDetails[0..1] | (see: Entity Versioning) | note also serves a portion of this role | |
| description[0..1] | definition[0..*] | if the description serves in a defining role | |
| example[0..*] | if the description serves in a exemplar role | ||
| note[0..*] | if the description serves as a different sort of annotation (change note, history note, editorial note or generic comment) | ||
| CodeSystemConcept | |||
| AssociationType | description[0..1] | (same as CodeSystemEntityVersion.description) | |
| associationKind | (none) | "A type that describes the nature of the association (e.g. ConceptMap vs. Hierarchic relationship within a code system)." - the CTS2 PIM does not encode this information directly, believing that it can be derived from the definition, description, and other information associated with the association concept. Note also that the CTS2 PIM differentiates Maps from Associations meaning that the particular distinction described above could be derived, in part, from the area of the service in which it was used.
Note: associationKind is not present in the SFM UMLS model(!) | |
| forwardName[0..1] | PredicateDescription.forwardName[0..1] | ||
| reverseName[0..1] | PredicateDescription.reverseName[0..1] | ||
| isDirected | ObjectPropertyDescription.directed | Note: We disagree with the definition of this property in the SFM. Its intent should be to indicate whether the association is based on set-theoretical constructs (e.g. automobile hasPart tire --> for every automobile there is at least one tire that participates in the hasPart relationship) or is based on class level semantics (e.g. humanBody hasPart bone). In the first case, it is not valid to infer across the association in the reverse direction (forward: given an instance of automobile, you've got an instance of tire, reverse: given an instance of tire you've got ???). In the second case, reasoning is allowed in both directions on the class level. To the best of our knowledge, this has nothing to do with the notion of "semantic equivalence". | |
| ruleSetId | (not directly implemented) | The CTS2 PIM architecture group wasn't clear on the intent of this attribute. The documentation refers to the CreateConceptAssociation functional model, but rule set is not mentioned there. The conclusion, however, was that this was intended to represent some aspect of the business rules of a specific terminology authoring process and, as the rule set referent was not standardized, we determined that this could be relegated to the property bucket | |
| provenanceDetails[0..1] | (same as CodeSystemEntityVersion.provenanceDetails) | ||
| DefinedEntityProperty | id | (same as CodeSystemEntityVersion.id) | |
| name | (same as CodeSystemEntityVersion.name) | name would be equivalent to the preferred designation for the target language | |
| description[0..1] | (same as CodeSystemEntityVersion.description) | ||
| status | (same as CodeSystemEntityVersion.status) | ||
| statusDate[0..1] | (same as CodeSystemEntityVersion.statusDate) | ||
| provenanceDetails[0..1] | (same as CodeSystemEntityVersion.provenanceDetails) | ||
| ruleSetId[0..1] | This appears to be an error in the SFM, as there is no further documentation. | ||
| effectiveDate | (same as CodeSystemEntityVersion.effectiveDate) | ||
| (CodeSystem contains 0 or more DefinedEntityProperties) | To the best of our knowledge, this is intended to represent the intent of the note that states:
"These identify the defined or 'allowable' properties and associations that may be applied to concepts within a code system". The PIM authors concluded that this is one of many possible types of business rule that could be used for the creation and update of specific code systems. The AG decided that the representation and interchange of authoring business rules was outside of the scope of the required solution and questioned whether a standard for the interchange of authoring business rules even made sense, given the small number of authoring environments currently available. | ||
| (unlabeled association with AssociationType) | This is not further documented in the SFM and the AG was unable to determine its intended purpose. |
