CTS2/doc/CTS2 SFM EntityAttributes

Prev Contents Next

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: How should one construct a URI for a specific version of a HL7 code system? The CTS2 PIM remains agnostic on this matter, but the PIM authors have proposed the following: For external code systems, use the official URI where one is provided (e.g. http://id.who.int/icd/icd9/2011 or similar for ICD9, http://snomed.org/sctidid/900000000000380005/version/20120731 for the July 2012 release of the SNOMED CT Core module, etc.) For external code system with no official URI, use the NLM's MRSAB VSAB (e.g. http://id.nlm.nih.gov/cui/C3260726 for LOINC 2012AA For code systems without a current version in the UMLS, use something in the form: http//id.hl7.org/codesystem/AdministrativeGender/version/215''' How should one construct the URI for a specific concept in a HL7 code system? Again, while the CTS2 PIM makes no statement on the matter, the PIM authors propose: For external code systems, use the official URI scheme where one is provided (e.g. http://id.who.int/icd/icd10/A17.0 for Tuberculous meningitis in ICD10, http://snomed.org/sctid/19551004 for Herpes zoster in SNOMED CT) ## For code systems with no official URI, use the NLM CUI (e.g. '''<nowiki>http://id.nlm.nih.gov/cui/C0800916 for LOINC Urine Hematocrit) For codes not in the UMLS, use something of the form: http://id.hl7/codesystem/AdministrativeGender/M. 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.

Prev Contents Next

---

Navigation – Common Terminology Services (CTS2)

Home
About CTS2
Purpose
CTS2 History
Business Case
How it works
Federation
Functionality
Implementing CTS2
Architecture
Development
Resources
Purpose
FAQ
Business Case
Glossary of Terms
Specification
REST
SOAP
HL7 SFM
Development
CTS2 Development Framework
Implementations
Github Page
Community
Who is Using CTS2?
Get Help
Links