Knowledge Modelling

PROforma is a knowledge representation language which supports the definition of clinical guidelines and protocols in terms of:

* A well-defined set of tasks that can be composed into networks representing plans or procedures carried out over time. These tasks enable the high level structure of a guideline to be represented;

* Logical constructs such as situations, events, constraints, pre- and post-conditions, and inference rules which allow the details of each task and inter-relationships between tasks to be defined (via templates).

PROforma Tasks

Four types (or sub-classes) of task are defined in a class hierarchy:

PROformaTasksPROformaTasks

  • Plans : sets of tasks to be carried out to achieve a clinical (e.g. therapeutic) goal. Plans are the basic building blocks of a guideline, and may contain any number of tasks of any type, including other plans, usually with an ordering imposed. (A protocol or guideline is a plan, but we usually use the word protocol or guideline to mean a "top level" plan i.e. the container for all the guideline tasks.)
  • Decisions: tasks which involve choices of some kind, such as a choice of investigation, diagnosis or treatment. The PROforma specification of a decision task defines the decision options, relevant information and a set of argument rules which determine which of the options should be chosen according to current data values.
  • Actions: typically clinical procedures (such as the administration of an injection) which need to be carried out.
  • Enquiries: actions returning required information; typically requests for information or data from the user. The specification of an enquiry includes a description of the information required (e.g. the type, range and other properties of a clinical parameter) and a method for getting it (e.g. by querying a local patient record or a remote laboratory database; by processing an image or by creating a data entry form).
  • General characteristics of tasks

    Any specific clinical task is seen as an instance of some more general class of tasks. Each class is eventually a specialisation of a root task. Any class can be further specialised into particular sub-types. For example, plans may be specialised into research protocols and routine guidelines and decisions can be specialised into diagnosis and treatment decisions etc:

    DecisionsDecisions

    When tasks are enacted, the communication of information between tasks is achieved by passing messages between encapsulated task objects, rather than by explicit procedure calls or other mechanisms that require access to the internal definition of a task.

    Every task inherits part of its specification from the classes above it in the hierarchy, expressed as a set of attributes. A task is distinguished from its parents by the possession of additional attributes, and distinguished from its siblings by different values for their common attributes.

    Task attributes
    The properties and behaviour of each task type are determined by its attributes and the values attached to them. These determine how and when a task is processed when the electronic guideline of which they form a part, is enacted.

    Attributes of the (top level) root task are generic and are inherited by each task class and sub-class; attributes of task classes are specific to that class and only inherited by sub-classes of that type.

    Attributes and their allowable values are specified in templates. These show us, for example, that every task has a description, a title and preconditions, but only tasks of type action have a procedure, and only tasks of type decision have candidates. The attributes of the root (generic) task are shown in the table below.

    Attributes of the generic task
    Attribute Description
    Name Unique Identifier of task
    Caption Descriptive title of task
    Description Textual description of task
    Goal Purpose of task
    Pre-conditions Conditions necessary before a task may be started
    Trigger conditions Conditions which will initiate a task
    Post-conditions Conditions true on task completion


    "PROFORMALISING" GUIDELINES

    PROforma applications are designed to support the management of medical procedures and clinical decision making at the point of care. PROforma software, consisting of a graphical editor to support the authoring process and an engine to enact the "proformalised" guideline specificatio, has been developed to support the design, testing and execution of guidelines. Development of a PROforma application is a two-step process:

    1- Developing a high level diagram which describes the outline of guideline in terms of the PROforma set of tasks (logical and temporal relationships between tasks are captured naturally by linking them as required with arrows);

    2- Converting this graphical structure into a database, and populating it, using software implementations of the task templates, with the detailed procedural and medical knowledge required to execute the guideline.

    Both these steps are carried out using a graphical editor (or knowledge authoring tool) such as the Arezzo Composer . The resulting computerised enactable clinical guideline is tested and executed using a PROforma-compatible engine, such as Arezzo Performer .