This wiki has undergone a migration to Confluence found Here

Difference between revisions of "CTS2/doc/CTS2 SFM MappingArea"

From HL7Wiki
Jump to navigation Jump to search
 
Line 4: Line 4:
 
This section describes the alignment of the SFM Association Class and the MapEntry Classes in the CTS2 PIM.  This addresses the "ConceptMapping" <tt>associationKind</tt> in the SFM.  The <tt>MAP</tt> profile was separated from the <tt>ASSOCIATION</tt> profile in the PIM because the mapping models in the SNOMED-CT to ICD-10 mapping, the UMLS Mapping model and the GEM mapping model added a number of requirements regarding rules, mapping order, target types and completion criteria that simply weren't realizable in a basic subject-predicate-target type of model.
 
This section describes the alignment of the SFM Association Class and the MapEntry Classes in the CTS2 PIM.  This addresses the "ConceptMapping" <tt>associationKind</tt> in the SFM.  The <tt>MAP</tt> profile was separated from the <tt>ASSOCIATION</tt> profile in the PIM because the mapping models in the SNOMED-CT to ICD-10 mapping, the UMLS Mapping model and the GEM mapping model added a number of requirements regarding rules, mapping order, target types and completion criteria that simply weren't realizable in a basic subject-predicate-target type of model.
  
[[CTS2/doc/File:MapArea.png]]
+
[[File:MapArea.png]]
  
  

Latest revision as of 07:21, 22 December 2015

Prev Contents Next

Alignment between the CTS2 SFM Association Class and the CTS2 PIM MapEntry Class

This section describes the alignment of the SFM Association Class and the MapEntry Classes in the CTS2 PIM. This addresses the "ConceptMapping" associationKind in the SFM. The MAP profile was separated from the ASSOCIATION profile in the PIM because the mapping models in the SNOMED-CT to ICD-10 mapping, the UMLS Mapping model and the GEM mapping model added a number of requirements regarding rules, mapping order, target types and completion criteria that simply weren't realizable in a basic subject-predicate-target type of model.

MapArea.png


SFM PIM Reason
AssociationType (none) None of the use cases that were uncovered by the PIM authors required a predicate beyond the generic "maps to" - which was usually left undefined. It was decided that AssociationType added no value to a map.
CodeSystemEntityAssociation MapEntry - MapSet - MapTarget The more complex triple structure allowed the basic semantics of non-trivial mapping rules to be represented within the CTS2 Structure. The simplest sort of entry with one subject and one target would be represented by MapEntry containing exactly one MapSet and MapTarget, where the mapTo URI would reference the target entity.
CodeSystemEntityAssociation.associationKind (none) The Map portion of the SFM represents the "ConceptMapping" associationKind
CodeSystemEntityAssociation.status MapEntry.entryState The SFM defines associationKind as "A status (status) to identify the state (mainly for curation)". entryState provides the state of the association with respect to the service (ACTIVE or INACTIVE)
MapEntry.status[0..1] The status of the association within an external workflow, which covers the "curation" portion of the definition
CodeSystemEntityAssociation.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.
CodeSystemEntityAssociation.id[0..1] Association.associationId (which is equivalent to Association.entryID Association identity represents an interesting challenge in the ROA environment - some notion of identity is required if one is to inactivate, change the status of or otherwise modify a specific association, and identity is not as simple as the subject-predicate-target triple - targets can be lists or bNodes. The CTS2 PIM chose to remain neutral on how an associationID is generated. The choice is (fairly) obvious when the association comes from SNOMED-CT, as every Relationship entry has a unique SCTID. It isn't, however, when one is loading, say, the Wine Ontology. In the latter case, the PIM suggests (but does not require) that an association be assigned a GUID when loaded. This is a less than perfect solution, however, as the same association in two different service instances will not have the same ide.
CodeSystemEntityVersion.isSourceOf MapEntry.mapFrom See discussion in Association discussion regarding containment relationship.
CodeSystemEntityVersion.isTargetOf MapTarget.mapTo

See discussion in Association discussion regarding containment relationship.

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