Current Version - Under Revision
When designing or implementing a SNOMED CT enabled application, 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 terminology services that only interact with the terminology and record services which apply the terminology to instance data. These services are described in separate sections of this guide
Figure 2.4-1: SNOMED CT Enabled Terminology services
Figure 2.4-2: SNOMED CT Enabled Record Services
A SNOMED CT enabled application 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 ( terminology services) and functions that involve using the terminology as part of an application such as an electronic health record ( record services ).
Terminology services can be generalized, so that they are independent of the way the terminology is used in a particular clinical record application. Terminology services include support for the following types of function.
Record services are intimately related to ways in which information is entered, stored and retrieved by a particular application. Therefore, while these services interact with terminology services they are usually specific to a particular application or to a family of applications with a common underlying record design. Record services include support for the following types of function:
These two sets of services can be developed and provided separately. This approach allows record service to access required terminology services through an Application Programming Interface ( API). The guide does not specify an API but, by making a clear distinction between terminology services and record services , 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 components. Commercial and technical concerns about dependence on third-party components 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 record services into separate components may offer a more robust approach, allowing future extensibility and migration at lower cost.