The following principles were used to guide modifications made to the Release Format:
- Consistent history representation across all components and across all artifacts deemed in scope of the Release Format.
- Consistent identification of all components throughout their lifecycle and clear identification of all other artifacts in scope of the Release Format.
- Consistent representation of allowable values for component characteristics.
- Consistent means of extending component data structures to meet future requirements without modification to the existing table structures.
- Consistent non-centralized means of loosely coupled Identifier assignment for components and component characteristics.
- Consistent means of representing localizations and translations for all components.
- The data structures should assist implementers to consistently implement SNOMED CT. Component data structures ideally should not have to change to accommodate changes in editorial policies.
- Ideally component data structures should be simple, generic and flexible.
- Ideally component data structures should be self-contained, removing dependence on external artifacts.
- Dependencies between components should be explicitly stated and machine-readable. For example, it should be possible to express that a reference set released as part of an extension is dependent upon version X of the Acme Extension and version Y of the SNOMED CT International Edition.
- There must be a consistent means of identifying modules and their versions --including the SNOMED CT International Release itself.
- The Release Format should minimize the total effort of meeting requirements where possible by reuse of existing data structures.
- Metadata should be machine-readable.
-
Component data structures that enable software reuse are preferred over data structures that require special development of parsers.
- It should be possible to produce from a Release Format an instance of that release in the immediately prior Release Format.
- Specifications should be based on requirements derived from use cases that describe the scope and environment of their intended use.
-
IHTSDO specifications should provide a common global foundation that permits the development and maintenance of SNOMED CT enabled applications that are interoperable across national and organizational boundaries.
- Changes to IHTSDO specifications should only be made if the impact on implementation is considered to be proportionate to benefit. Such changes should be recorded.
- Changes to IHTSDO specifications should be evolutionary and should deliver incremental benefits to implementers with a minimum of disruption and re-engineering.
- The SNOMED CT release format and associated guidance should facilitate a consistent implementation for known use cases.
- The specifications that support implementation of use cases should be done in a way that doesn't limit the ability to realize other use cases within the scope of SNOMED CT.
- The Release Format is intended to be a distribution format and is not designed to be an implementation format.
- The Release Format should be designed to be consumed efficiently.
