Many laboratories strive for accreditation based on the technical requirements of the ISO/IEC standard 17025, 'General requirements for the competence of testing and calibration laboratories'. A 2006 version, with no changes to technical requirements, has been published in May. Labs must maintain their own copies

These are hefty standards and open to varied interpretation but ultimately implemented by local accreditation officers

The purpose of this document is to invite discussion towards a specification acceptable internationally. Current Bika measures improve on the ISO specification in many aspects but some elements need to be elaborated

Participation is invited on the bika-users mailing list, updates will be distilled and added to this doc here. Join

2 Lingo

Context: Wine lab of demo installation and movies at www.bikalabs.com

1 Analysis, many analyses

AR = Analysis Request, the collection of analyses requested for a specific sample by a lab client

3 Additional views

At SourceForge.net:

New Bika AR view

New Bika results email view

4 ISO/IEC 17025 LIMS implications

4.1 Security, access control and authorisation

Bika complies

All access to the system proceeds per password authentication - users logging in are authorised to subsets of data and functions corresponding the roles assigned to them in the LIMS configuration by the systems administrator

In the standard Bika implementation, the following roles are defined:

administrator - the highest authority. She configures the LIMS and do systems admin tasks like user and group administration
labmanager - access to all LIMS functions and data. The only role-player allowed to verify, publish or retract analysis results or access the LIMS set-up and trace logs
labtechnician - authorised to create Job cards, capture results data and submit them for verification
labclerk - receives samples and creates Job cards. Has access to client contact details
client contact - only allowed access to the data in her client organisation, nobody else's and none of the internal lab functions. Clients get to see the statuses of their analyses at all times but results only after it has been verified by a labmanager. Clients have access to, and are expected to maintain, their own contact and address details

As additional security measures, lab managers may set Bika to automatically log any user off after a given period of inactivity and may also specify a password expiry period. These help to prevent unauthorised access from open sessions and password theft

Only users themselves are allowed to maintain their passwords, not even the LIMS administrator has access to it. When a user loses her password, she may request it to be mailed to the address kept for her in the system. She is requested to go on-line and change her password immediately. Users are not allowed to share email addresses

Low level security

Our Zope administrators can be asked to write a lengthy piece on low level security implemented in Bika installations on the Plone platform, but enough is said by the use of these in defense and other classified institutions

Our platform of choice includes FreeBSD and Apache, generally accepted to be the most secure on the Internet. Sound security policies are implemented, amongst them the use of non standard ports, disabling remote root logins and enforced password changes

Upgrades to low level software are carried out regularly as soon as stable new releases are available

4.2 Test reports

Bika reports test results as

Analysis Request (AR) page views
Test result emails
Data Query results - similar multi sample lay-out as email view

All ISO requirements relating to unique numbering, lab and client contact details and addresses, dates and page numbering are strictly adhered to

Biggest current shortcoming, no sample specific minimum and maximum range for test results, will be resolved in an upcoming Product Specification module. Bika already reports out of range values in bold red, but not per sample type - different specifications apply for sweet, dry and fortified wines etc

In the New Bika functions design, the Product Specification module is further expanded to allow clients to set their own valid ranges

The Method used per analysis and corresponding Measure of Uncertainty also goes unreported at the moment, have been designed and will be added

Remarks to the AR are recorded in Bika but only shown where remarks were added. We suggest it reads 'None' elsewhere to re-assure clients that everything went well

The lab manager responsible for the analyses must be listed in client views too. To this purpose, the lab manager who published the results will be shown on reports

The Disclaimer and Terms and Conditions texts at the bottom of reports are tightened as per attached html mock-ups

On multi-AR reports, like emailed or faxed results, Specifications and Remarks are not shown in the main table as it would make for a very cluttered and unreadable lay-out. These are shown lower on the page or hyper-linked to full displays on the web

4.3 Electronic amendments to test reports

Published results can absolutely not be amended. The labmanager is authorised to retract results submitted for verification back to status 'in the lab' for re-testing. Clients do not see non verified results and no 'report' needs amendment

In next versions of Bika, work flow is planned to indicate odd looking results as 're-tested' where it was found to be out of range in subsequent analysis

It might be necessary to add workflow to deal with typos that slipped through on published reports?

4.4 Data storage, retrieval and processing

By default, Bika employs the secure Zope object database (ZODB) renowned for its rugged security. It can only be accessed via the Zope or Plone interfaces and these are tightly controlled by the Bika password authentication and role authorisation

Where labs request SQL database backends, these be set-up accessible only by the Bika Zope 'user' and database administrator

Laboratory Instruments interfaced to the LIMS currently do so via import files under physical authorisation of labtechnicians or labmanagers, and logged as such, via the standard Bika web interface

No other data entry method, other than manual or file upload, is currently used

No processing is done on results in the LIMS. Weight calculations are foreseen for some analyses in which case calculation validations will be integrated as is the norm

4.5 Data transfer integrity

For reports on the web. Bika uses the Internet's secure socket layer (SSL) and 128 bit encryption. This practice ensures intercepted data to be useless to the thief

Site authentication, to prevent criminal sites posing as the LIMS, is carried out via digital certification and any of the recognised authentication authorities like Thawte or Verisign

Above strict measures are similar to that implemented by banks and financial institutions

For performance purposes it is considered to use certificates issued by Bika or Laboratory herself, authorised and generated in Apache

Should clients request, emailed results can also be encrypted. Nobody has asked thus far but maybe it is necessary to say on emailed results that 'email can be intercepted, altered, destroyed or lost ...'?

4.6 Traceability

Logs are kept of all status changes of ARs and Jobcards - the action, user responsible, date and time is logged for each of:

sample reception - a sticker is printed with sample and AR identification, client and analysis texts and stuck on the sample. Bar codes in future
assigning to Job card
submit for verification (data capture)
verification
retraction
publication

Since status changes for individual analyses are already tracked, these also be made available to labmanagers in future

Physical sample 'chain of custody' will be implemented in future Bika Sample inventory modules and does not apply to the current version

4.7 Interpretation of results

No interpretations of results are currently catered for in Bika. It is a major design wish for Bika to move to interpreted results. Any ideas for accreditation?

"Terms and Conditions apply. Interpretations are subject to..." ?

4.8 Software documentation and validation

All functionality is documented in Laboratory and Client manuals

Is it a requirement to have technical documentation and in what form? Bika code itself is documented internally and being written in Python, known for its English-like constructs, is considered 'self documented'

During testing all software modules were validated against data sheets of expected results and workflow behaviours for given inputs

4.9 Equipment maintenance and failures

Laboratories may decide on their own disaster recovery policies, but bika recommend and would implement, also to ensure 99.9% uptime:

Two physically separated servers in fail over mode. The main server DB is backed up to a 2nd server regularly, say every half hour or even shorter. When the main server goes down the backup server takes over operations and notifies the labmanager and sysadmin. At max ½ hour's data will be lost. Virtual hosting is currently evaluated to drastically shorten this period

Separating the servers physically, the 2^nd should be off-site, guarantees minimum data loss during on-site disaster

Servers have a minimum of 2 hot swappable RAID hard discs

Servers have dual power supplies - power supplies are the most common component to fail

For archival purposes, weekly back-ups are burned to CD and kept off-site for a 3 year period, or however long necessary

Bika encourages labs to obtain hardware from their local suppliers to ensure quick turnaround for maintenance and repairs. Where Bika supplies hardware too, these are acquired from reliable suppliers under 24h return contract

Data restore procedures test and validate backups

5 Links

Most ISO web resources seem commercially minded, ISO herself sells the Specification for 112 Swiss Francs, fair enough

The United Kingdom Accreditation Service has a very helpful site and some handy cases at http://www.ukas.com/information_centre/publications.asp

News 22 June 2006 Bika 1.2 'Accreditation Ready'

Specification

Discussion document

1 Purpose