Currently Supported Features

Deployment Options

SEDRI-LIMS can be installed on a single, self-contained workstation, a local server serving local clients or in the cloud for a completely managed solution.  The first two options do not require internet access.

User Interface

The UI is a web-app which runs under all modern browsers and will interact with the back-end installation whether on the same machine, separated via a local network or in the cloud. It incorporates "responsive design" meaning that it will adapt to different screen sizes and device types and will render well on phones, tablets, laptops and desktops.

The UI is intuitive, internally consistent and conforms to modern user experience guidelines to minimize acclimatisation. The layout is flexible and full-screen mode is supported for list-views, record-views and forms. Also, list-views support both grid and card style item display, the latter being more suitable for mobile devices. List-views support flexible searching, filtering and column ordering, with configurable presets. It is both multi-lingual and able to support regional dialects or terminology differences through cloning and specialisation.

The UI has also been optimised for keyboard usage, supporting streamlined tab-ordering for data entry and hot-keys for fast screen navigation. Data entry is simplified through a policy of only soliciting relevant information, hence form pages, fields and field options may appear or disappear based on previous selections, limiting the scope for error.

Security

Access to the server is secured via standard SSL with the opportunity for "tailgating" minimized through a configurable inactivity timeout, should a user forget to log out.

Client Portal

To facilitate self-service operation from a client organisation (which could be a hospital ward, a clinic or a health centre, etc.), it is possible to add client users to the system and extend the UI to their point of access.  Data visibility is restricted to that pertaining to client-collected specimens, with actions restricted to specimen test requests. Access is provided via the same web-app, with views and actions restricted only based on permissions and organisation membership. This allows, for example, a system generated specimen label (with barcode) to be printed and attached to a specimen container before it is sent to the test lab, then scanned in on arrival as a system recognised barcode.  This considerably reduced the scope for error that is present, e.g. when hand-written notes are attached to specimens.

Data Entry

The system can capture and store appropriate data for the following items:

Patients

A patient record will be required only when a new specimen record is being added for which an associated patient record does not already exist. It will contain fields such as name, age, date-of-birth, gender, address and one or more reference numbers (although the precise content will be configurable). Multiple specimens may be associated with a given patient and these can be viewed from within the patient record-view or from the specimen list-view.

Specimens

A specimen record may be created on receipt of a new specimen or in advance of specimen arrival and will contain information such as type, site, location of collection, date and time, client establishment, tests requested or specified, suspected diagnosis, etc. (the precise content will be configurable). A state will be associated with a specimen and this state will change as the specimen is processed to completion. States include "Pending Arrival", "Specimen Received", "Specimen Active", "Pending Culture", "Pending ID/AST", "Pending Approval" and "Specimen finalised", and the configurable workflow control built into the system will determine what actions can be performed in each state.

Direct Tests

These are tests to be performed directly on a specimen, such as a gram stain or an India ink test. The types and content of these tests are configurable. While rules can be configured to determine which tests should be automatically added for a given specimen type, the selection can be adjusted at any time up until the specimen is finalised.

Direct Test Results

Results are entered once a direct test has been performed, changing the state of the direct test.

Cultures

These capture the type of culture(s) to be attempted for a given specimen type. Rules can be configured to determine which culture type(s) should be automatically added for a given specimen type. Any number of culture records can be associated with a given specimen.

Culture Results

Results, including the organism identified and the extent of growth (or lack thereof), are entered once a culture has been performed.

AST Tests

These are antibiotic susceptibility tests to be performed on a specific isolate and hence are associated with a single culture. While rules can be configured to automatically associate test patterns or antibiotic panels of tests to a given organism type or scope, the associated set can be modified at any time, to add, remove or edit an individual antibiotic test. The system supports both disk and MIC tests, with configurable dosages and guidelines (e.g. EUCAST versus CLSI).

AST Results

Susceptibility results are entered once the corresponding tests have been performed, whether manually or using a suitable analyser. A qualitative susceptibility determination is automatically computed from a zone diameter or MIC reading based on configured breakpoints, but this can be overridden if required. It is also possible to exempt individual results from inclusion in the corresponding specimen report.

Optimised Bench-Read Workflow

An optimised "bench-read" workflow has also been incorporated which allows a technician to process large numbers of specimens very quickly, both on the day of receipt and as cultures are examined on subsequent days.

Diary

For patients and specimens, a "diary" feature is available which allows a user with suitable permissions to view a complete activity log for the patient or specimen in scope, including what actions were taken, when and by whom.

Custom Forms

The precise content of each data entry form, including contained fields, field ordering, field types, field options and whether optional or mandatory can be configured per installation, according to need. The caveat at time of writing is that this must be configured on request, as part of installation. However, a road-mapped enhancement is to expose this level of configuration via the UI, which already allows full control over drop-down field options and option names.

Labels and Barcodes

A label with configurable content (and format) can be printed for patients and/or specimens for attaching to a name tag (patient), a specimen container or a culture plate, etc. The label content can include a linear and/or QR barcode (automatically generated if required) and/or any number of patient or specimen attributes (from the list of information collected for each entity). Subsequently scanning the barcode into the search field of the specimen list-view will automatically select the corresponding specimen. However, if a specimen already has a "foreign" barcode, e.g. attached by the container manufacturer, this can be scanned in as an "Additional Barcode" field for the specimen and used subsequently to locate the specimen in the same way as scanning in a natively generated barcode.

Specimen Reports

An interim specimen report can be generated at any point in the specimen life-cycle. Once generated, a snapshot of the specimen state will be named, dated and stored against the specimen for PDF generation at any subsequent point in time. Once a specimen reaches the "Finalised" state, a final specimen report is automatically generated. Report names are auto-generated but can be overridden before the report is committed. A single PDF can also be generated for a batch of specimen reports based on a date range and other flexible criteria.

Exports

At time of writing, the only export option is WHONET. A WHONET compatible wide-format CSV file is generated, on request, for a specified date range. In future, other export formats, such as DHIS2 will be supported, along with more flexible inclusion criteria.

Alerts

Alerts can be provisioned such that notifications are generated when the configured criteria are met, such as the recording of a rare or significant organism, a suspicious or important susceptibility result is detected for a certain bug/drug combination or any other condition that can be configured using the rich alert specification.

Role Based Access Control

User access to data, menu options and actions is provided though association with one or more roles. A role is a set of permissions that is given a name, e.g. "technician" or "supervisor" or "laboratory clerk". Any number of roles can be configured in the system and each role can have any combination of the highly granular system permissions. Once a role is assigned to a user, that user will inherit the permissions defined for the role. It is expected that, while a potentially large number of users may need to be provisioned for a given installation, with potentially high user turn-over, there will be a much smaller set of roles. While defining a role will take significant effort and testing, once established, assigning a user to a role is trivial.

Laboratories

A single installation can be segmented into multiple laboratories for an organisation that has more than one. Specimens can then be assigned to an initial laboratory, on receipt, and optionally moved to another at a later stage, if appropriate.

Audit Logging

For traceability, all system actions impacting data are logged in the database, along with the user responsible, any applicable object references and a timestamp.  With suitable permissions, this list can be viewed from the UI and filtered using various criteria.  As mentioned earlier, there is a "diary" feature for patients and specimens, available as part of the patient and specimen list and record view screens, that provides a patient or specimen specific view of the audit log.

Administration and Configuration

Administration functions include the following:

User Management

Users can be added, edited, removed, deactivated and reactivated.  Each user can be assigned one or more roles which will define what actions and information are available to them.  A user can belong to one or more specific laboratories, if more than one has been set up, or a client organisation if accessing the system via the client portal.

Role Management

Any number of named roles can be created.  Each role is defined by its menu and event permissions.  Menu permissions determine the main menu options that will appear and event permissions relate to actions that impact data and are organised into various categories.  Roles can also be edited, deleted or cloned.  However, a role has no impact on the system until it is assigned to a user, whereupon that user inherits all permissions associated with the role.

Laboratory Management

Multiple laboratories can be created for a single system, with each user bound to one or more laboratories.  Each laboratory must be given a name and assigned both a language and an organism list.

Client Organisation Management

Client organisations are created to represent real client establishments.  These are then associated with a specimen, once created, which is automatic if the specimen is created via the client portal.

Location Management

Hierarchical location data can be added to the system and associated with both client organisations and patients.  While territories differ, a common example of such hierarchical data is: [ Province : District : Village ].

Translation Management

As an extension to the multi-lingual capability of the system, specialisations relating to local dialect or terminology can be created by cloning an existing language and modifying individual translations.

Table management

Table management allows manipulation of the options available to each drop-down field in the system.  Existing options can be modified or removed and new options can be added.  Furthermore, if there are hierarchical dependencies between options from different fields, these can be modified or removed.

Label configuration

Patient and specimen labels can be customised to suit local needs.  A label can include a linear and/or QR barcode (or none), any number of patient or specimen attributes and the information can be sized and arranged as required.

Microbiology Data

Organism Lists

A master list of more than 70,000 standard organisms is available with every install and can be fully searched when entering a culture result.  However, for convenience, it is possible to create local organism lists (which can differ per laboratory) containing the organisms more commonly encountered in the region.  These organisms can have their own, locally recognised name and short-code, but would still map to the equivalent organism in the master database.  Custom organisms can be created for organisms that are not present in the master list or represent non-taxonomic organism groupings that may not need to be further sub-classed in some or all cases.

Test Patterns

Any number of test patterns (aka antibiotic panels) can be configured and associated with a particular organism or organism scope, e.g. order, family or genus.  Each test pattern contains any number of antibiotic tests that specify the antibiotic, test method, e.g. disk or MIC, dosage (disk only) and test guidelines, e.g. EUCAST or CLSI.  In operational use, when an organism is identified that falls within the organism scope bound to one or more test patterns, those test patterns will automatically appear in the AST test screen for the corresponding culture.

Breakpoints

Any number of breakpoints can be configured and associated with a particular organism or organism scope, e.g. order, family or genus.  Each breakpoint defines a specific antibiotic, test method, e.g. disk or MIC, dosage (disk only), test guidelines, e.g. EUCAST or CLSI and one or more susceptibility ranges, typically resistant, intermediate or susceptible.  These ranges specify the zone diameter or concentration measurements that an AST result must fall within to be interpreted as such.  In operational use, when an AST test measurement is entered into an antibiotic test result on the AST test screen, the system will apply any breakpoints with relevant organism scope for which the antibiotic, test method, dosage (if relevant) and guidelines match and set the susceptibility result accordingly.

Was this article helpful?
0 out of 0 found this helpful