This wiki has undergone a migration to Confluence found Here
CTS2/doc/CTS2 SFM MappingArea
Jump to navigation
Jump to search
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.
| 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. |
| 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 |
