This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

CTS2/doc/CTS2 SFM CodeSystemArea

From HL7Wiki
Revision as of 00:50, 18 December 2015 by Cts2admin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Prev Contents Next

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.

CodeSystemArea.png

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.
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