[USMA:35396] Re: proper use of SI symbols in healthcare

[Scott Hudnall]

Title: Re: [USMA:35389] Re: proper use of SI symbols in healthcare

In our LabWare LIMS (Laboratory Information Management System) the UNITS table contains a field called DISPLAY_TEXT which can handle symbols, and I use it so that our reports display units properly. This field is not the primary key field for the table, though. Keeping the primary key field as small as possible is optimal in clinical systems because, although adding a few bytes here and there may seem trivial, when you are talking tables that have millions of rows, or queries that contain Cartesian products it can consume a lot of processor overhead – not to mention storage capacity. Every action we take in the LIMS also triggers a write to system audit log tables – again additional storage and processor overhead. Also, with clinical systems – such as we use in pharmaceutical development, we are regulated by the US and EU agencies.. We can not go in and arbitrarily make a change to a validated LIMS, we have to justify, document, and run a test script that tests out various data scenarios. We must do a paper-capture of every action and result in the script: screen shots, reports, et cetera. Every page has to be signed, dated, and kept on file open for inspection by US and EU auditors to comply with cGLP (current Good Laboratory Practices) requirements. It is not uncommon for change-control documentation to exceed 100 pages for a single change to the system.

 
--
Scott Hudnall

---

From: Pierre Abbat <[EMAIL PROTECTED]>
Reply-To: <[EMAIL PROTECTED]>
Date: Sun, 11 Dec 2005 20:38:16 -0500
To: "U.S. Metric Association" <usma@colostate.edu>
Subject: [USMA:35389] Re: proper use of SI symbols in healthcare

On Saturday 10 December 2005 20:58, Scott Hudnall wrote:
> Since I work as a programmer in laboratory informatics, perhaps I could
> lend some insight as to why you often see these sort of abbreviations
> sometimes make their way into lab reports. It has nothing to do with an
> understanding of SI and everything to do with a compromise programmers have
> to make to get their software as database-independent as possible. This
> means if you use standard SI and chemistry symbols in your database you run
> into a
> primary-key violation on the UNITS table since every unit has to have a
> unique value. Some database products are case-sensitive, others are not ­
> so some databases can distinguish between mm (millimeter) and mM
> (millimolar), while others can not. The best way to ensure that all
> databases understand what you mean is to always use all capitol letters ­
> but that means you have to use non-SI symbols in order to have unique
> values for every entry.
>
> Also, to be able store symbols such as Greek letters and math symbols in
> text fields, you would need to define the fields as UNICODE....and that is
> going to cost you a lot of processor overhead.

This is one reason I'm developing the code. Instead of storing symbols, which
can get a bit long such as dK*m^2/W, you store a four-byte integer. The high
16 bits tell you the kind of quantity measured, so you can extract all speeds
(if a column contains both speeds and some other quantity) with a single
condition.

phma