When designing or implementing a , the first step is to assess the range of services necessary to meet user requirements. The two main categories of services required by applications are that only interact with the terminology and which apply the terminology to instance data. These services are described in separate sections of this guide

The Terminology Services Guide describes services that access reference data. These services are summarized in .

SNOMED CT Enabled Terminology services

The Record services guide describes services that apply to represent information in a clinical record. These services are summarized in .

SNOMED CT Enabled Record Services

Service architecture

A may be completely self-contained, delivering all the required services as part of a single development. Alternatively, service delivery may be modularized so that separately developed reusable modules are used to meet specific sets of requirements.

A distinction can be made between functions that only require interaction with terminology resources ( ) and functions that involve using the terminology as part of an application such as an ( ).

can be generalized, so that they are independent of the way the terminology is used in a particular clinical record application. include support for the following types of function.

are intimately related to ways in which information is entered, stored and retrieved by a particular application. Therefore, while these services interact with they are usually specific to a particular application or to a family of applications with a common underlying record design. include support for the following types of function:

These two sets of services can be developed and provided separately. This approach allows to access required through an ( ). The guide does not specify an but, by making a clear distinction between and , it identifies the functions that such an interface should support.

Self-contained and modular approaches offer different profiles of advantages, some of which are summarized below.

The approach chosen depends on a careful consideration taking into account the cost and functionality of available . Commercial and technical concerns about dependence on third-party may be a valid reason for in-house development of all the required services. However, even where all the development is undertaken within a single organization, separation of terminology and into separate may offer a more robust approach, allowing future extensibility and migration at lower cost.