SNOMED Documentation Search


 Other Documents
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Current Version - Under Revision

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:
    • The level achieved in this stage will depend on customer requirements and the design limitation of the existing system.
  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:
    • The level at which this development is target should be one that meets anticipated medium to long term requirements;
    • Even if the initial target of the work is limited to the high-end of Level 1, the design should be sufficiently flexible to enable Level 2 capabilities to be added when required.

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:

  • This is not a formal scoring scheme:
    • Some dimensions are more significant than others;
    • The significance of reaching a particular level depends on the nature of the application and the user requirements it seeks to address.
  • Many of the dimensions are inherently interdependent:
    • For example, Level 2 data entry capabilities are not compatible with Level 1 data storage.

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.

  • Level 0: No support for

    .
  • Level 1: Support for use of

    limited to particular types of clinical data:
    • Addressing the requirements for a particular type of use;
    • Addressing a set of requirements specified by a particular organization .
  • Level 2: Support for consistent use of

    across a broad scope of information types:
    • Providing a general purpose approach to the use of

      within an

    • Allowing configuration to vary the scope of coverage to meet specific requirements.

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:
    • Problem list entries;
    • Admission diagnosis;
    • Discharge diagnosis;
    • Provisional or working diagnosis;
    • Differential diagnosis.
  2. Symptoms:
    • Presenting symptoms;
    • History of current condition;
    • Other symptoms.
  3. Allergies and adverse reactions:
    • Adverse reaction events;
    • Allergies and other propensities to adverse reactions.
  4. Procedures:
    • Operative procedures.
    • Diagnostic procedures.
    • Medications:
      • Current medication;
      • Prescriptions;
      • Dispensing records;
      • Drug charts.
    • Other therapeutic procedures:
      • Other therapy requests;
      • Other therapy delivery and outcomes.
  5. History:
    • Medical and surgical past history;
    • Medication history;
    • Family history.
  6. Examination findings:
    • Vital signs;
    • Clinical examination findings.
  7. Investigation information:
    • Laboratory investigations:
      • Laboratory investigation requests;
      • Laboratory investigation procedures;
      • Laboratory investigation results.
    • Diagnostic imaging:
      • Diagnostic imaging requests;
      • Diagnostic imaging procedures;
      • Diagnostic imaging results.
    • Other investigations:
      • Other investigation requests;
      • Other investigation procedures;
      • Other investigation result.
  8. Other types of clinical information:
    • Planned actions;
    • Risk, goal and expected outcomes;
    • Scale based assessments;
    • Progress notes.
  9. Administrative information:
    • Admission, transfer and discharge events.
  10. Other values:
    • Body sites, structures and locations;
    • Organisms;
    • Substances (other than drugs);
    • Pharmaceutical and biological products (drugs).

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.

  • Level 0: A proprietary structure that is neither aligned with nor mapped to a standard

    :
    • Low: Text only record with no use of clinical codes;
    • High: Structured record supporting use of clinical codes.
  • Level 1: A structure that is aligned with or mapped to a standard

    :
    • Low: Proprietary structure mapped to a standard model to support limited messaging requirements. Supports the use of

      coding within that structure.
    • High: Structure aligned with a standard

      that supports that supports use of

      coding.
    • Examples of standard

      include:
      • The

        Version 3

        (RIM);
      • The

        Health informatics -

        communication - Part 1: Reference model (

        ).
  • Level 2: An aligned or mapped structure in which

    are used in accordance with agreed guidelines for use of a standard

    :
    • In Level 2

      is used in accordance with

      guidance to minimize the semantic gaps and overlaps between the terminology and the information model. Without constraints, these gaps and overlaps lead to inconsistent representation of similar data and thus limit the effective reuse of information.
    • Example of agreed guidelines for using use of

      in particular reference models include:
      • The

        DSTU - Guide to the Use of

        in

        Version 3;
      • Guidance on

        developed by the

        Logical Record Architecture for use in an

        based logical model.

Implementation Level - Expression storage

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

  • Level 0: No support for storage of

  • Level 1: Support for storage of

    :
    • Support for storage of a

      implies the ability to store a representation of a

      as part of each item for which

      is used:
      • The

        may be represented as a 64-bit integer or as an 18-digit string ;
      • Other internal representations may be used provided they can be resolved to the appropriate

        for display, communication or processing.
  • Level 2: Support for storage of

    :
    • Support for storage of

      implies the ability to store a representation that captures the logical model of a

      :
      • The simplest representation of a

        is the

        . Due to the open-ended nature of

        , this representation results in a string of variable length with no clear-cut maximum length.
      • The guide discusses alternative representations including the use of

        reference table which enables use of a fixed length reference within the records. This approach uses a UUID which can be represented as a 128-bit integer or as a hexadecimal string (see Storing expressions ) .
    • This level has variants depending on the extent of support for

      storage:
      • Low: Storage of

        limited to specific fields in the record structure;
      • High: Full support for storage of

        allowing any valid

        to be stored and retrieved.

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.

  • Level 0: No support for entry of

    .

.

  • Level 1: Support for

    entry:
    • Low: Access limited to fixed set of

      ;
    • Medium: Access to full content of

      ;
    • High: Access to full content of

      with configurable

      matched to user requirements.
  • Level 2: Support for

    entry:
    • Low: Access to limited

      (matching data storage restrictions);
    • Medium: Access to full range of

      supported by the

      ;
    • High: Access to

      with configurable

      matched to user requirements.

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.

  • Level 0: No native support for

    enabled data retrieval:
    • This level has variants depending on whether it can map code in exported data to

      :
      • Low: No support for

        based analysis;
      • High: Support for extracting a specified set of locally coded data and mapping the local codes to appropriate

        for central aggregation and analysis.
  • Level 1: Support for retrieval of

    :
    • This level has a spectrum of variants depending on the level of support for the following features:
      • Query expressivity: The ability to express query predicates that explicitly include or exclude

        of specifically identified

        ;
      • Subsumption testing: Use of

        to interpret and evaluate queries;
      • : The ability to retrieve equivalent information even if it is represented in different structures within the record;
      • Context awareness: The ability to take account of contextual information, derived from the record structure and/or the

        , when interpreting and evaluating queries;
      • Performance: The ability to interpret and evaluate queries within an appropriate period of time and without causing deterioration in other system functions.
  • Level 2: Support for retrieval of

    :
    • This level has a spectrum of variants depending on the level of support for the following additional aspects of the features specified for Level 1:
      • Query expressivity: The ability to represent

        predicates in a query ;
      • Subsumption testing: Use of

        and

        (or a

        ) to determine whether

        are subsumed by query predicates;
      • : Use of

        and

        (or a

        ) to determine

        between different

        and in different structures within the record;
      • Context awareness: The ability to take account of contextual information derived from the record structure and/or

        , when interpreting and evaluating queries;
      • Performance: The ability to interpret and evaluate queries that support

        representations within an appropriate period of time and without causing deterioration in other system functions.

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 .

  • Level 0: Mapping based support for communication of

    :
    • Inbound communications containing

      :
      • Low: Not supported.
      • Medium: Rendered as human-readable text. Unless the inbound message also contains the term text, this requires access to some

        enable

        to lookup and display the relevant terms .
      • High: Mapped to an internal coding scheme or classification. This may be feasible to support specific use cases but not for the full scope of clinical information.
    • Outbound communication containing

      :
      • Low: Not supported;
      • Medium: Supported for a few specific types of clinical data in the existing system by mapping to from an existing code system to

        ;
      • High: Supported for most clinical data in the existing system by mapping to from an existing code system to

        .
  • Level 1: Native support for communication of

    :
    • Inbound communications containing

      :
      • Low: Supported for some types of information but constrained by data entry and

        storage capabilities;
      • High: Supported for most types of information.
    • Outbound communications containing

      :
      • Low: Supported but limited by data entry and storage and retrieval capabilities;
      • High: Supported for most types of information.
  • Level 2: Native support for communication of

    :
    • Inbound communications containing

      :
      • Low: Support limited to particular attributes (e.g. |laterality|, |causative agent|) in

        ;
      • Medium: Support for general

        applied to some types of information;
      • High: Able to receive, process and store any valid

        .
    • Outbound communications containing

      :
      • Low: Support limited to particular attributes (e.g. |laterality|, |causative agent|) in

        ;
      • Medium: Support for outbound communication of any

        that can be entered or stored in the system;
      • High: Support for outbound communication of any valid

        .

Feedback
  • No labels