can be implemented in a wide range of clinical record applications. These include systems developed for use with other code systems that have been adapted to support as well as systems designed with the assumption that would serve as the primary terminology. The features that applications support and use may vary, partly due to differences in user requirements and partly due to development priorities. Against this background of variability, it is reasonable to ask what is a or what is a good . While there is not a single or simple answer to these questions, this section identifies some key dimensions which determine the capability of enabled clinical record systems.

Each of the following sections describes a dimension and outlines a spectrum of capabilities ranging from absence of support (Level 0) to full support (Level 2). A mixture of Level 0 and Level 1 capabilities are likely to be found in existing systems that have been adapted to work with . A system specifically developed to work with should be expected to have capabilities that are at least at the high end of the Level 1 spectrum and should ideally have Level 2 capabilities.

The specification of different levels is not intended to suggest a step-by-step development path. Those needing to rapidly enable an existing clinical record system are recommended to follow a two stage approach.

  1. Design, develop and deploy a revision to the current system to support Level 1 capabilities that meet known short or medium term requirements:
  2. Design and develop a new or substantially revised system (including revised record structures) to support a mixture of high-end Level 1 and Level 2 capabilities:

Developers who do not require a rapid deployment based on a revision of an existing systems are recommended to skip the first step and proceed to design and develop a flexible solution that utilizes the key strengths of .

Each of the following sections describes one dimension that contributes to the overall implementation level. It is important to recognize that:

Implementation Level - Scope of use

A clinical record system may use to represent some or all of the types of information outlined in the list below. The types of information for which can be used may be limited by the structure used to store the . The significance of these limitations depends upon the intended use of the clinical record system.

The following check-list identifies some of the elements in which might be used. The list is not complete but it covers many of the areas in which use of has been discussed in working groups. It is intended to assist consideration of the areas in which should be used to meet the needs of users and organizations. The inclusion of an item in this list does not imply that the provides comprehensive content to populate that part of the record.

  1. Disorders, diagnoses and problems:
  2. Symptoms:
  3. Allergies and adverse reactions:
  4. Procedures:
  5. History:
  6. Examination findings:
  7. Investigation information:
  8. Other types of clinical information:
  9. Administrative information:
  10. Other values:

Implementation Level - Record structure

The logical model underlying the structure of the record has a direct effect on the ability of a enabled clinical record system to take advantage of the features of . An application may use an optimized proprietary internal representation of the . However, consistent use of across a range of applications requires a common reference model to which proprietary structures are mapped. In addition to this, the ways in which are used within a common need to be constrained to improve predictability and minimize ambiguity.

Implementation Level - Expression storage

Support for storing and determines the extent to which can be used to represent detailed information within an .

Implementation Level - Data entry

The categorization in this section in based on the extent to which the system enables entry of . In addition, this section indicates the importance of a well-designed user-interface.

.

Another important data entry issue is the ease of use which depends on the usability, relevance and performance of searches. Where data entry is supported the approach to selecting or constructing is also significant.

An attempt to categorize specific approaches to the user-interface is subjective as alternative may be appropriate to different uses. However, for most environments a flexible range of configurable aware user-interface tools is likely to offer a better user experience than reliance on a one-size fits all or search engine.

Implementation Level - Data retrieval

A major strength of is its ability to support meaning based selective retrieval. The extent to which this feature is used by a clinical record system determines the value of entering and storing the data.

Implementation Level - Communication

The ability to send and received in messages or other communication is partially dependent on data entry, storage and retrieval capabilities. However, some types of communication may be supported by mapping or human-readable renderings even in the absence of internal support for .