4. The Laboratory Information System shall implement the functionality for the following processes:

• Tests Ordering (Electronic)
• Storing and Processing Information of samples
• Laboratory Testing
• Delivering of Test Results (Electronic)

5. The system shall implement the functionality for the send/transmit/report of lab results via the following methods streams:

• Through the system (to the referring doctor);
• Remote printer;
• Fax machine;
• E-mail;
• Possible interface.

15. The system shall implement the functionality, so that each referral examination contains at least the following data elements:

• Patient Registry Number
• Identification Number or Social Security Number
• Patient Name
• Father’s name
• Date of birth
• Insurance Fund
• Date and time command
• Date, time and staff (collector) of clinical sample
• Department of the hospital sent the order
• Physician and contact telephone number
• Responsible for order entry
• Numeric Code review
• Medical examination code (abbreviated review)
• Full test name
• Type tests
• Sample tests (blood etc.)

16. Priority (Three levels Normal – Stat – Emergency)

• Timing – Indication status exam
• Notes referrer
• Observations of laboratory staff
• Symptoms of the patient
• Clinical disease
• Short patient history
• Sample Material
• Last Menstrual Date Total number of the recorded referral examinations
• Whether the patient is taking and which antibiotic treatment or not.

24. The system shall implement the functionality to:

• automatically assign orders and specimens to an appropriate laboratory site (local or remote) and analyzer for testing.
• manually select an order and specimen and assign it to an appropriate laboratory site (local or remote) and analyzer for testing.

46. The system should provide for the unique identification (i.e. by the utilization of a unique order number) of any order (for any kind of specimen) with the utilization of at least the following characteristics:

• number
• coding (not as a serial number but have a logical construction e.g. type of order | date | ordering physician or nurse number | department of ordering | number).Each unique order number should not be re-used.

50. The system must be able to support the general procedures as followed by a laboratory, such as:

• Procedures for quality control and calibration of the automatic analyzers, for critical values.
• Alerts invoked by the system.
• The rest of the steps after the provision of test results.

60. The system shall implement the functionality to interface with the following equipment and / or applications:

• Chemistry Analyzer;
• Immunoassay Analyzer;
• Hematology Analyzer;
• Coagulation Analyzer;
• Urine Strip Reader;
• Microbiology Analyzer;
• Other laboratory instruments;
• Reference Laboratory.

82. The system shall implement the functionality to record reasoning of the cancellation by logging the following information:

• test code;
• patient name
• reason;
• date and time;
• tech ID.

91. The system shall implement the:

• functionality of reporting of numerical results to lab-defined number of significant digits per test.
• functionality of reporting of alpha results: Single word (e.g. positive or negative) and free text (e.g. short phrases or longer paragraph).

94. The system shall implement the functionality to allow user to:

• Accept a test;
• Reject a test;
• Rerun a test.

102. The system shall implement the functionality to maintain information (in table format) of the following:

• lab-defined panic values;
• delta values and;
• reference result ranges based on age and sex.

116. The system shall implement the following:

• functionality to define rules-based logic where laboratory personnel can define criteria in “if-then” statements to assist in decision support.
• functionality to evaluate all rule entries for tests, not just the first one, so that complex or “cascading” rules may easily be designed, where several rules can be invoked based on one scenario.
• functionality to implement rules-based report routing.

119. The system shall implement the following functionality:

• Functionality to highlight abnormal results on patient reports without relying solely on color text.
• Functionality to flag test results based on failed lab-defined delta checks.
• Functionality to flag routine orders when timed pick-up, stats, etc. are ordered, to prevent multiple sticks.

130. The system shall support patient-based quality control procedures and implement the following functionality as it relates to Quality Control procedures:

• Implementation of Westgard QC rules and flags.
• Ability of flagging of out-of-range QC values..
• Ability to enter comments by QC result.
• Ability to view and print QC graphs (Levey-Jennings).
• Ability to plot multiple levels of control on one graph.
• Ability to enter, store, and retrieve corrective action comments.
• Automatic extraction of QC results from analyzers interface without the intervention of users
• User defined control limits and targets according to manufacturer or laboratory
• Visual representation (user defined) of Westgard rules
• Automatic and manual approval of the QC results
• Support of comments and Lab incidents (e.g. “Broken Needle”, “Maintenance” etc.) and visual representation on QC graphs
• LEVEY-JENNINGS, EWMA and Cumulative Sum graphical interface in the same view

131. – Quality Control Module supports internationally recognized standards such as LEVEY JENNINGS, Westgard Rules, EWMA, Cusum as well as offering many unique features.

• All QC reports (Data & Diagrams including) can be exported in any common format (rtf, xls, pdf etc.)
• Graphical representation of multiple Tests QC results one after the other for comparison
• External QC interface for national and international QC programs
• Full control of the controls, Lot No. and test procedures
• Instrument integration for data collection automation
• QC Workflow management
• Traced and calculated clinical outcome through the online results analysis
• Laboratory fully logs all controls, results, and incidents of analyzers
• Automatic translation for results flagging
• Exporting data in various formats
• Conformity to national and international regulatory reviews
• Organization-wide regularization of processes
• QC results automated transfer in Patient results review screens
• The QC module provides the results of the various tests and materials arranged both according to work areas and also in a separate form for precision and accuracy.

132. – A tabular overview and a curve diagram of the values can also be invoked.

• Color coding of any out-of-tolerance results and indication of the validating employee complement the functionality of this facility.
• Aside from presenting the values in tabular and graphic form, additional detailed information relating to the various controls can also be retrieved.
• Laboratory, laboratory-area or work-area related statistics provide you with additional material for evaluating the quality of your work.
• A fully configurable quality control form provides you with an overview of all the checks and controls performed during the day which have revealed nonconformities.
• A warning function for indicating trend and positional errors

133. The system shall implement the functionality to calculate the following Quality Control (QC) statistics:

• Cumulative mean.
• Observed mean over a specified date range.
• Standard deviation.
• Coefficient of variation.

138. The system shall implement the functionality to:

• Ability to create completion reports by date.
• Ability to create billing summary reports by date.
• Ability to create reports of failed medical necessity checks.
• Ability to create cancelled test reports that include test name and reason for cancellation.
• Ability to create turnaround time reports by date.

139. The system shall provide the following reports:

• Customizable overdue report that would indicate tests such as urine cultures that become overdue at 4 days while blood cultures become overdue at 7 days and CBC overdue at 4 hours.
• Summary report for test usage over a user-definable period of time.
• Physician utilization report (e.g. number of tests requested by a physician).

141. The system shall implement the functionality to create the following reports:

• Report of previous day test results.
• Abnormal test value report.
• Critical test value report.

157. The system should be able to accommodate the following requirements as it relates to the ordering process:

• There should be generated alphanumeric and numeric codes samples.
• The system should allow for the utilization of numeric codes samples, as there are analysers who do not accept characters in the sample code.
• The system should allow for the utilization digits for the specification of the codes samples, as there are analysers who do not accept more than four digits in the sample code. In this case the system should provide the configuration to send a sample of the code A / A day in the laboratory and the A / A day results should be provided either automatically when registering for referral, or by user intervention.
• The system should allow for the specification of different sample codes of samples for the same order. For example, a serum sample and a urine sample for which will be requested the same test using the same order , must take a different code and will be printed different Barcodes.
• The system should not allow the utilization of the same sample types in the same order, unless there is a differentiation on the receiving site (egg. Wound swabs).

158. The system should provide the functionality to record the cause of unfitness sample (improper sample) if it cannot carry out a test. The functionality should be provided with the following mechanisms:

• with simple recording of sample unsuitability reasons;
• with choice of tabulated reasons unsuitable in a special application of the table (Serum hemolysis, Quantity not sufficient, Silica etc.);
• via the communication system analysers (reception and recording of Flags messages) on sample suitability;

160. The system must be able to allow the consolidation / codification of the various types of tests, such as:

• Simple tests (single);
• examinations Parameter Lists (combined) where a custom ordered series of tests parameters (e.g. Urine Chemical or Microbiological Analysis);
• Tests that require multiple responses over time;
• Various complex tests (e.g. cultures, etc.);
• Other types of tests.

161. The system should provide detail data sheet per examination which should include:

• the support of various threshold values (Normal, Panic Values ,Accepted values);
• The management of the kind of the sample (sample type, materials, sampling Area);
• The parametric management of calculated examinations;
• The management of physiological test values by gender, age, etc.;
• The measurement units
• The proper way
• The functions to be performed automatically by the system by test and shaped according to the requirements of the Laboratory how to perform the tests;
• Through the properties of the test should be given the moldability / customization of the appearance in compliance with the requirements of the laboratory, so that when it appears, to be processed in the respective forms of the system, to facilitate the workflow of users. Especially for multi-parameter tests, as it is primarily microbiological tests, this option is taken for granted and will be evaluated with attention.

162. The system shall implement the following functionality:

• Ability to configure algorithms-effects on a per test basis;
• Ability to evaluate a quantitative result and the automatic conversion (or addition) into a quality result.

171. The system shall implement the functionality to:

• automatically assign orders and specimens to an appropriate laboratory site (local or remote) and analyzer for testing.
• manually select an order and specimen and assign it to an appropriate laboratory site (local or remote) and analyzer for testing.

175. The system should provide at a minimum the following real time monitoring of information/tasks:

• Outstanding work per examination;
• Outstanding Per Laboratory Section;
• Completed Tasks for approval;
• Emergency pending tasks per test.

176. The system should support the import of results (qualitative or quantitative, for the following types:

• Numerical results;
• Scrambled (codified) comments (e.g. positive, negative, etc.);
• Free text (rtf format);
• Graphs;
• Any combination of the above.

179. The system should allow the insertion of results for the following data elements:

• Sample Number
• Test Code
• Referral number
• Patient’s Code

186. The system should provide the functionality/ mechanisms to:

• Review results;
• modify results (where required) and;
• confirm results prior to releasing.

187. The system should be able to support the definition and full analysis of normal values on a per following type:

• Per sex
• By age
• For special cases (pregnancy, etc.).

204. The system shall implement the functionality to connect to the existing Midware (i.e. Observer (BioMerieux), Epicenter (BD),etc.) in order to provide the following:

• to present and combine the possible antibiotics for each organism based on international guidelines (CLSI, EUCAST).
• to integrate additional data (clinical, epidemiological information, infection control, etc.) and provide access to the specific medical records of the patient (e.g. medical history on antibiotic use).

205. The system shall implement the functionality to include (through the communication with the analysers) the following operational rules:

• tag nosocomial pathogens
• tag mandatory pathogens for reporting
• automated ordering of media
• auto-negatives (blood culture)
• duplicate specimens
• organism-matched antibiotic panel

207. For printing, the system must implement the functionality:

• Ability to print 2 or 3 antibiograms on a single page as part of the result of a culture.
• Ability to print reports in Greek and English.
• Ability to print on both sides of the report paper.

210. The system should be able to provide the following (data and functionality) permissions management / security requirements for the functionality of results approval:

• Ability to define access rights / permissions on a per role or users basis;
• Ability to define data access rights / permissions at the test level;
• Ability to define permissions rights on the following approvals / validations types:
• Technical Validation
• Medical Validation

213. The system should integrate documentation based results, results based in numerical controls and / or alphanumeric limits, where checks should be based on the following:

• Normal test values;
• Panic values;
• Accepted values;
• Results of ‘relative’ exams;
• Complete history results of each test per patient in terms of value and graphical charts;
• Medical comments from the laboratory;
• Medical comments from the referring physician / clinic;
• Full and clear history diseases (Medical Records);
• Complete and prominent patient symptomatology (Symptoms incident).

214. Prior to the final approval and the release of the test results, the system should allow to authorized users (based on the defined access rights) the following functionality:

• the ability to add (and print) comments;
• The ability to request (create) additional examinations orders;
• The ability to hide test results depending on the user rights (e.g. celebrities, patients with AIDS, VIPs, etc.);
• The ability to restore test results incorrectly withheld;
• The ability to choose/provide the report results to multiple recipients;
• The ability to process numerical results and texts (supported from word processors if the answer to an exam is a diagnosis in free text);
• The ability to retain references and reports (no release);
• The ability to adopt and document massively produced results for selected patients or tests;

216. The system should provide laboratory medical staff with a list of test results in the form of a Dashboard and accordingly display their current approval status based on the following types of statuses:

• Examination without result
• Examination with result without approval
• Examination Technically confirmed
• Examination Medically confirmed

218. The system should support the following types of exam codes:

• Alphanumeric code (e.g.A1, A2, A3, ……, A999999)
• Numeric Code e.g. (1,2,3, ……, 999999)
• Medical test code (Glug, Urea, Crea, …., TSH, TT3, Full Blood Count, )
• Full test name (Glucose, Creatinine Urine 24h, ….)

223. The system shall implement the following functionality:

• Functionality to define if the print results will automatically take place after the approval of results;
• Functionality to define whether to print automatically only when approved all the results of a command or whether to print upon completion of each “group” tests;
• Functionality to define whether a user is allowed to print;
• Functionality to define whether a user is allowed to print only approved results.

228. The system shall implement the functionality of allowing the issuance of multiple copies of a reports. For each test, the system shall implement the functionality to define the status of the printing based on the following types:

• Not printed result;
• Printed result;
• Multiple printed result.

238. The system shall implement the functionality to support at least the following barcode encodings:

• CODABAR
• CODE 39
• INTERLEAVED 2 of 5

239. The system shall provide the capability so that the generated tags can be of different types of tests per group, in order to:

• address the modulation required by the existence of several analysers with different specifications in relation to the format of the label;
• address the phenomenon of having different types of vials and sample collection containers in a variety of sizes.

242. The system shall implement the functionality to register at least the following information for each patient exam:

• ordering code;
• date and time order;
• date and time clinical sample collection;
• at the bottom of the referral to the printed sampler instructions, ordering physician at once (provided by the Microbiology department in electronic form);
• date and time of sample receipt at the laboratory;
• date and time the test;
• date and time approvals (technical-medical) examination;
• Patient code;
• result;
• Normal values;
• specific indication if the value is out of Normal Value. – Panic value – acceptable value units;
• physician comments;
• Laboratory comments;
• analyzer details that performed the analysis;
• details of the job description and the user;
• numerical, graphical and alphanumeric display all the results for each patient examination (history);
• recording patient history diseases;
• type of method (ELISA, IFT, PCR).

244. The system shall implement the functionality to create, at a minimum, the following reports as part of the laboratory administration:

• Value Fluctuations over a period of time (average, extreme values, borexceeded limits, standard deviation, etc.)
• Comparisons of different sizes (number of tests per laboratory / analyzer, etc.) between period of times
• Number of orders per laboratory / analyzer / etc. monthly / yearly basis
• Longitudinal comparisons of test values in specific patient populations
• Correlation of test results in specific patient populations
• Number of orders not served (pending orders)
• Number of tests which needed further analysis (re-run)
• Compare data of days / hours during on call vs the normal operating days
• Monitoring of daily work (activity logs)
• Number of patients served at selected time

248. The system shall implement the functionality to automatically combine the results from different test samples so as to create a single reference (cumulative – comparative). The combination of tests and samples might be:

• Multiple tests on a sample and several samples, (e.g., insulin-examination).
• Many samples from more than one type (blood – urine, etc.)

253. The search functionality for an order search should be based on utilizing, at a minimum, the following parameters (fields) for the record identification:

• Patient Identification Number
• Social Security Number
• Patient Name
• ID patient
• Order number Microbiology Department (e.g. B125 / 12), the number should be printed in barcodes.