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

Provides a graph API around SNOMED CT structures.

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

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. 

A backing key value store implemented using LMDB.

LMDB has very fast read access, which makes it highly suitable as hermes
operates principally in read-only mode. We use netty's direct buffers, and a
shared pool because of allocation overhead compared to on-heap buffers.

We use the key value store in one of two ways. The first is to store entities.
These are usually keyed by the identifier, except for descriptions, which are
keyed by a tuple of concept identifier and description identifier. That
optimises the common fetch of all descriptions for a given concept. The second
is to store null values as part of an index, with compound keys. This means
we can rapidly iterate across a range of keys, which are always sorted, and
stored big-endian. The compound key structures are defined below.

It would be possible to create a generic key-value protocol, but this instead
contains domain-optimised code.

Members creates a Lucene search index for reference set members.

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

Search creates a Lucene search index for descriptions.

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.