Provides a terminology service, wrapping the SNOMED store and
search implementations as a single unified service.

Implementation of the SNOMED CT expression constraint language.
See http://snomed.org/ecl

Support for SNOMED CT compositional grammar.
See http://snomed.org/scg

Provides a graph API around SNOMED CT structures.

SNOMED language and localisation support.
There are four ways to consider locale in SNOMED CT.
1. A crude language label (e.g. "en" in each description.
   This should generally not be used.
2. Requesting using one or more specific language reference sets.
   This provides the most control for clients but the burden of work
   falls on clients to decide which reference sets to use at each request.
3. Request by a dialect alias.
   This simply maps aliases to specific language reference sets.
4. Request by IETF BCP 47 locale.

Options 1-3 are defined by SNOMED.
Option 4 provides a wrapper so that standards-based locale priority strings
can be used effectively.

Arguably, there are two separate issues. For clients, they want to be able
to choose their locale and this should use IETF BCP 47. For any single
service installation, there will need to be a choice in how a specific
locale choice is met. 

Optimised hand-crafted serialization of SNOMED entities.

Store provides access to a key value store.

Provides import functionality for processing directories of files

Specifications for the RF2 SNOMED format.
See https://confluence.ihtsdotools.org/display/DOCRELFMT

Package snomed defines the specification for SNOMED-CT releases in the RF2
format.

See the [release file specifications](https://confluence.ihtsdotools.org/display/DOCRELFMT/SNOMED+CT+Release+File+Specifications)

These are, in large part, raw representations of the release files with some
small additions, predominantly relating to valid enumerations, to aid
computability.

These structures are designed to cope with importing any SNOMED-CT
distribution, including full distributions, a snapshot or a delta.

* Full	   The files representing each type of component contain every version
           of every component ever released.
* Snapshot The files representing each type of component contain one version
           of every component released up to the time of the snapshot. The
           version of each component contained in a snapshot is the most
           recent version of that component at the time of the snapshot.
* Delta	   The files representing each type of component contain only
           component versions created since the previous release. Each
           component version in a delta release represents either a new
           component or a change to an existing component.

Specifications for the core API of hermes.