This wiki has undergone a migration to Confluence found Here
CTS2/doc/CTS2 SFM CodeSystemArea
Jump to navigation
Jump to search
The diagram below contains the main model elements from the CTS2 SFM and the corresponding CTS2 PIM analogs. The sections that follow explain the differences between the two models and the rationale for the differences.
| SFM | PIM | Reason |
|---|---|---|
| CodeSystem | CodeSystemCatalogEntry | The PIM Resource Oriented Architecture (ROA) allows code system metadata (who publishes it, what it is for, how often it is released, etc.) to exist independently of both the versions and the content. The PIM authors decided that the name "CodeSystem" was ambiguous and added the "CatalogEntry" suffix to make it clear that the resource only contained metadata about the code system itself - not its versions or concepts. |
| CodeSystemVersion | CodeSystemVersionCatalogEntry | (Same rationale as CodeSystem/CodeSystemCatalogEntry) |
| CodeSystem contains one or more CodeSystemVersions | CodeSystemCatalogEntry references zero or more CodeSystemVersionCatalogEntries | The ROA approach used in the PIM requires that resources be loosely coupled. The SFM is correct in the sense that every CodeSystem must have at least one CodeSystemVersion. The PIM, however, does not require that the details of any (or all) versions of a code system be supplied when publishing metadata about the code system itself. Similarly, the PIM does not require that metadata about a code system must be supplied when publishing information about a specific version, so associations in both directions are derived from the referencing URIs. |
| One CodeSystem CodeSystemVersion association | Two associations - one identical to SFM and a second currentVersion relationship | Use case analysis determined that one of the common usage paths was to access the "current" version of a code system. It was determined that the notion of "current" was service specific - Mayo's CTS2 implementation could show a different version as being "current" than might Intermountain Healthcare's. This shortcut makes it easy to traverse this path without having to formulate a separate query |
| CodeSystemSupplement | includes and imports relationships | The PIM authors determined that a CodeSystemSupplement characteristics were almost identical to those of CodeSystem and CodeSystemVersion. Supplements carried the same metadata, had multiple versions, current versions, etc. In addition, supplements needed to target not just a CodeSystem, but a specific CodeSystemVersion to be of value. The imports semantics, as derived from the W3C community provided everything necessary to support the required "supplement" functionality, so CodeSystemSupplement was factored into CodeSystemCatalogEntry and CodeSystemVersionCatalogEntry, and the supplement/targetCodeSystem relationship was represented in the CodeSystemCatalogEntry includes relationship, with the imports representing the version specific dependencies. |
| 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 |
