Thursday, July 24, 2003, ITC Software com, info@itcsoftware.

com
Health Care Information System
REQUIREMENTS
A. GENERAL REQUIREMENTS
1. The required Integrated Health Care Information System is expected to include the
following modules in order to support the clinical, administrative and financial
activities of a modern hospital.
1. Patient Administration
2. Coding of Diseases / Operations / Procedures (ICD10/OPCS4, SNOMED/
CPTS, ICD or other)
3. Hospital Order Entry and Management System
4. Clinical Laboratory
5. Histopathology
6. Blood Bank
7. Radiology/PACS
8. Doctor’s Pharmacy Prescription
9. Billing/Costing
10. Personnel Management
11. Stock Control/Inventory
12. Health Smart Card
13. Electronic Health Record.
2. The required system shall be a ready-made package with no or minimal modifications
and is expected to meet the requirements of the Document.
3. It is a mandatory requirement for the Integrated Health Care Information Solution
proposed to be installed and be operational in at least 3 hospitals in EU Country/ies,
with at least 200 beds each.
4. Be based on server architecture, with windows based clients (client-server model).
5. Be based on a friendly graphical user interface (GUI).
6. Be web enabled via a secure Internet connection.
7. Offer the possibility of remote use of the system.
7/24/2003, ITC Software com, info@[Link]
2
8. Be fully year 2000 compliant.
9. Provide on-line enquiry facilities about information held in the system.
10. Support a multilingual user interface and data entry (in the initial stage, both English
and Greek).
11. Support concurrent use of other software such as word processing, databases,
spreadsheets and graphics.
12. Have no limitation as to the number of users it is able to support concurrently.
13. Provide extensive, context sensitive on-line help.
14. Facilitate the introduction of an Electronic Health Record based on European
Standards.
15. Allow for the possibility of eventual conversion of hospitals and clinics into paperless
& film less organisations.
16. Support the latest versions of codifications such as ICD-10, ICD-9 CM, OPCS4 and
CPT-4.
17. Comply with the current legislation of the European Union, relevant to each of the
applications used by the system.
18. Support the introduction of a Smart Card.
19. Allow for the provision of remote medical services (internet, telemedicine, robotics)
20. Provide access to external and internal data banks.
21. Be available 24 hours a day/365 days a year.
22. Allow up to 15% workload increased per annum.
23. Support an automatic log-off after a certain time period. e.g. 2 minutes or system
administrator configurable time period.
24. Support of European Accession.
25. Support the needs of a Health Monitoring System compliant with European
requirements.
26. Support the framework of heath indicators identified in Decision No 1400/97/EC of
the European Parliament and of the Council of 30thJune 1997 adopting a programme of
Community action on health monitoring.
27. Support the framework and set of health indicators used by OECD countries (OECD
Health database as well as OECD guidelines for collecting health financing/health
accounts information.
7/24/2003, ITC Software com, info@[Link]
3
28. Support the framework and the set of health indicators in the WHO Health For All
Database.
29. Be capable of generating data compatible with the definitions of the health indicators
included in the above-mentioned frameworks in order to ensure alignment and
comparability with the EU format.
30. Allow the sharing of information between all healthcare professionals.
31. Be capable of stepwise and modular implementation in order to give personnel
reasonable time to adjust to the new procedures and practices that the system will
introduce.
32. Provide Database and application software system mapping (Tables, DR Sets e.t.c.)
33. Ability to communicate through any interface and standard to machines and
applications.
Utilization of legacy systems
34. Make the fullest possible use of the existing hardware and software.
Support auditing and logging
35. Provide constant monitoring and troubleshooting of security system function.
36. Support active smart card system management.
37. Support host-based system security and card-based system security.
Standards
38. Enhance interoperability and information exchange between computer systems by
complying with European and/or international standards of medical terms names,
definitions and structures. Comply with the CEN / TC 251 European standards of
Health Informatics and Communications Technology (ICT)
39. Comply with European standards for information storage and exchange.
40. Adopt the latest European standards on Electronic Healthcare Record architecture.
41. Be compatible with all open standards such as RDBMS, OODBMS, ORDBMS,
ODBC, COM, DICOM III e.t.c.
42. Comply with communication protocols and standards widely accepted within the
European Union and internationally such as TCP/IP, SQL, HL7, EDIFACT e.t.c.
43. Follow the standards of the European Standards Organizations (ESO.s), CEN,
CENELEC and ETSI.
44. Support of XML for export and import.
Integration
45. The organisational complexity of Healthcare Information Systems requires a modular
7/24/2003, ITC Software com, info@[Link]
4
structure, with a number of independent components or modules. The component
parts must be independent in order to enable their acquisition from multiple sources
and ensure their capacity for migration, so that components that are outdated can be
replaced with new ones. These independent modules must, nevertheless, be able to
communicate and interoperate with each other freely. This requires an effective
integration mechanism that employs reliable interfaces.
46. Be capable of integration with other systems through stable and public interfaces.
47. Allow for the future introduction of the following subsystems or modules i.e:
� Specialties Patient Information Systems (including primary care)
� Dental Patient Information System
� Mental Health Services Module
� Thalassaemia Files
� Health Inspection
� Immunisation Control
� Intensive Care Units
� Telemedicine/ Telematics e.t.c.
Openness
48. Be a non-proprietary solution, in order to prevent the creation of an isolated inflexible
system, characterized by dependence on external factors and escalating
maintenance costs.
49. Allow any subsystem or module to be replaced or added independently of the other
subsystems.
50. Follow widely accepted European standards to ensure interoperability with other
information systems and freedom of exchange of information within the European
Union.
51. Be capable of utilising all the technological possibilities of efficient, modern
communications to exchange information between hospitals, other health
organisations, countries and citizens.
52. Be capable of employing any connectivity system such as PSTN, ISDN, Radio,
GSM, and GPRS e.t.c.
53. In order to ensure the use of open standards for the interfaces of the integration
mechanism the providers are required to include a statement of conformance with the
adopted open standards.
54. The proposed software should be capable of running on different number of
platforms of open technology produced by different manufacturers. Interested suppliers
shall give evidence that the proposed software conforms to the above requirements
(Supporting documentation etc).
Adaptability
55. Exploit its Object Relational Database Management System (ORDBMS) capability to
facilitate the incorporation of new information subsystems, developed by the user or
7/24/2003, ITC Software com, info@[Link]
5
third parties, through the use of Rapid Application Development tools.
56. Allow the optional use of any available method for the capture of data such as
keyboard, touch screen, stylus, voice recognition, voice transcription e.t.c.
57. Provide for the optional use of any available equipment enabling the entry of
information into the system and the viewing of data at the point of care.
58. Be capable of adapting to future changes in procedure, workload, volume of data
input or volume of data storage.
Decision support
59. Support compliance with clinical and administrative guidelines and protocols.
60. Support a clinical alert system that monitors, detects and organizes patient data
quickly and effectively in order to provide real-time notification to clinicians.
61. Warn physicians of medication errors, and possible adverse drug effects and drug
interactions.
62. Display and/or transmit alerts to clinicians and administrators through a
communication device such as e-mail, fax or mobile phone.
63. Be capable of accommodating additional alerting devices as they become available.
Data entry and capture
64. Allow the use of a wide variety of devices for the capture or access of data such as
PC.s, notebooks, palmtops and mobile phones.
65. Interface with a wide variety of measuring instruments and equipment from which
test results and image data may automatically be captured.
66. Allow for the possibility of introduction of mobile computing and wireless local
network systems to allow personnel to move freely in the hospital and have real time
access to information without having to return to a fixed location to enter or view data.
67. Support voice recognition.
68. Be capable of accepting image files from sources such as digital cameras,
ultrasound, nuclear medicine and endoscopies.
Data Storage
69. Be capable of well-organised and indexed storage of information to allow efficient
and reliable data retrieval for clinicians, researchers and other authorised health
professionals.
70. Supports secure media archiving.
71. Be capable of maintaining an archive of scanned authentic report texts.
72. Provide easy and reliable procedures for backup and restore operations to be
carried out at regular intervals.
7/24/2003, ITC Software com, info@[Link]
6
Report generation
73. Support a powerful report generator module based on a graphical user interface
(GUI) to allow the creation of user defined clinical, managerial and administrative
reports.
74. Comply with European standards regarding the processing of personal data.
75. Include a wide variety of predefined reports, which can be viewed on screen, printed
or exported to a file.
76. Be capable of exporting or publishing reports in other software programmes such as
word processors, spreadsheets, databases and statistical tools.
Data Access
77. Provide a simple and effective way for healthcare personnel to retrieve, view and
print data from workstations connected with the system subject to authorisation.
78. Allow clinicians and other authorised personnel to request the release of results from
remote locations.
79. Allow clinicians search for and view chronological records of results, according to
customisable search criteria.
80. Allow clinicians to see the results of examinations, including the text of the diagnostic
reports.
81. Be able to obtain results through the Internet by using a web browser.
Quality control
82. Handle all the appropriate quality assurance procedures in all departments.
83. Be capable of multilevel security procedures to check and approve results either
automatically or by the staff according to standards.
On-line help/ Documentation
84. When necessary, inform the user which steps are to be taken, and give general or
specific "help" information on demand.
85. Provide on-line, context sensitive help.
86. Support spelling and grammar checking in all supported languages.
87. Provide documentation in digital form e.g. User manual, Technical manual or user
manual reference in writing.
Access to knowledge resources
88. Allow for easy access to internal and external knowledge databases to search
the literature for relevant information on specific clinical problems.
Systems Administration
89. Support a formalised Systems Administration for the management of:
7/24/2003, ITC Software com, info@[Link]
7
� Backups
� Anti-virus
� Standards of clinical practice and hospital management
� Software upgrades
� Network management
� Database administration
� Security issues
� Data processing and management control
Security
90. Include the necessary mechanisms for safeguarding the continuous availability,
confidentiality and integrity of the data stored in the system.
91. Comply with the Directive 95/46/EC of the European Parliament.
92. Comply with the European Convention for the Protection of Individuals with regard to
automatic processing of personal data.
93. Ensure that before connecting to the system the user's identity, authority level and
security profile are verified.
94. Be capable of preventing the use of unique identification numbers for any other
purpose other than the provision of healthcare services.101. Be able to detect and
report any breaches of security.
95. Provide the necessary technical specifications for recognition of passwords, digital
signatures, fingerprints and other personal recognition methods to prove the integrity
and authenticity of data and protect against forgery.
96. Comply with European standards, technical specifications and guidance for
electronic signatures in order to reinforce the defensibility of electronic clinical records in
case of legal challenge.
97. Use trusted archiving services to ensure that electronic signatures remain valid for
long periods so that they can be presented later as evidence in case of dispute.
98. Utilize private keys for creating digital signatures and public keys to verify them.
99. Utilize a public key certificate format to meet the requirements of the relevant EU
Directive.
100. Be ready to incorporate the forthcoming European standardization on
personal data protection and privacy enhancing technologies.
101. Allow the application of consent by multiple authorised users for the opening
and processing of certain files containing identification fields and sensitive personal
data that can possibly be matched with external files.
102. Support a single password to access different modules and levels of data.
103. Use audit trails to track, all activity of data editing and editing person at all
7/24/2003, ITC Software com, info@[Link]
8
times in order to minimise the possibility of undetectable alteration of data.
104. Support of the security mechanisms and a list of the European and
international standards used in each module.
General Health Scheme
105. Be designed to address the needs of the forthcoming General Health Scheme
that will be characterised by a robust primary care sector.
106. Take into account that private doctors and clinics will be given access, where
appropriate, to the hospital medical record of a patient.
B. MODULE REQUIREMENTS
1. PATIENT ADMINISTRATION MODULE (The list is not exhaustive)
The Patient Administration Module shall have the following main characteristics:
1. Be the core application that will seamlessly interconnect all the other modules to
create a unified, integrated Hospital Information System.
2. Be the central reference point for capture, storage and distribution of encounter
information for all other modules.
3. Ensure the accessibility of patient data by all authorised users in the healthcare
system.
4. Use a repository where all information collected from the various departments of
the hospital will be safely stored.
5. Manage the administrative aspects of patient care.
6. Record details of admissions and outpatient appointments.
7. Make all information available to all departments and locations of the hospital at
all times.
8. Provide for the optional use of notebooks and hand held computers to enable the
entry of information into the system and the viewing of data at the point and time
of care.
9. Be capable of accommodating the introduction of an electronic patient record
based on European standards.
10. Offer the potential of developing into a fully paperless hospital information system.
11. Accurately record all important care pathways, from clinical activities to clinical
outcomes and financial outcomes.
12. Facilitate appropriate analysis and reporting of the cycle of clinical activities and
outcomes.
7/24/2003, ITC Software com, info@[Link]
9
13. Be capable of adapting to any procedure, workload or organizational structure.
14. Be fully integrated with the personnel management, prescription, billing and stock
control modules.
15. Provide information on resource utilization by clinical staff.
16. Be capable of producing documentation of the financial aspects and quality of
clinical services of the hospital.
17. Be capable of handling the supply of organized collective services to groups such
as insurance, sports or private company check-ups.
18. Maintain personal, demographic and financial summaries of each patient
encounter.
19. Allow editing of the patient history numbers and medical record number subject to
authorisation.
20. Provide access to the electronic patient record, order entry, drug prescription,
laboratory and radiology results, the appointment system and other modules
directly from the selected patient.s demographic screen.
21. Allow the sharing of information with other hospitals.
22. Allow the sharing of information with primary care physicians.
23. Be inclusive of the activities of all participants in a patient.s care by
interconnecting all the modules necessary for the provision of uniform,
comprehensive and standards based care to all patients.
Patient demographic data
24. Be capable of communicating with or accepting and utilizing the demographic
database
25. Provide for the demographic register to include at least the following fields:
� Identity Card Number (to serve as unique identification number)
� Social Security Number
� Passport number
� National identification number
� Medical card number
� Existing hospital medical record numbers
� Date of first registration
� Surname
� Middle name
� Name
� Date of birth
� Sex
� Marital status
� Nationality
� Place of birth
7/24/2003, ITC Software com, info@[Link]
10
� Occupation
� Religion e.t.c.
26. Allow previewing and modification of existing patient details subject to
authorisation.
27. Provide for the demographic register to include at least the following health
insurance cover fields:
� Payment category code
� Amount payable
� Discount category
� Private Health Insurance scheme
� Private Health Insurance scheme number
� Private Health Insurance scheme telephone number
� Employment status
Patient search
28. Allow searching for a particular patient by using a variety of alternative selection
criteria such as complete or partial:
� Surname
� Name
� Date of birth
� Identity Card Number
� Social Security Number
� Telephone
� Admitting department
� Admitting ward and floor
� Physician in charge
� Date of admission
� Date of discharge or
� Any combination of the above.
Admissions
29. Facilitate the creation of charts at admission.
30. Simplify admission by on line verifying and updating patient information.
31. Be capable of admitting a patient either as an emergency or from a waiting list.
32. Keep a register of all admissions.
33. Provide for the display of a billing discharge summary for each patient being
discharged.
Bed management
34. Prioritise bed reservations according to medical condition.
35. Display all available beds on a single screen.
36. Provide for bed management stations to communicate with waiting list and
appointments management for better coordination of bed utilisation.
7/24/2003, ITC Software com, info@[Link]
11
37. Allow previewing of current inpatient activity, bed statistics and projected bed
occupancy.
38. Include a field for the expected date of discharge.
39. Track movements of in-patients including temporary visits to other departments.
40. Display the current location of each patient.
41. Display the length of time a patient has occupied a bed.
42. Allow for recording a temporary discharge of an in-patient.
Census / Registration
43. Be capable of capturing and storing admission, outpatient and procedures
registration data.
44. Manage admissions, discharges and transfers of patients.
45. Allow for cancellation of admissions and discharges.
Waiting list management
46. Create and manage waiting lists for in-patients, outpatients, day cases and
procedures.
47. Allow for additions, transfers, reviewing, selection, and deletion of patients on a
waiting list.
Clinical scheduling
48. Manage efficiently inpatient and outpatient appointments scheduling.
49. Manage patient flow according to the type and priority of appointment.
Appointments
50. Manage a centralised system of appointments that can be made by clinic
receptionists, the medical records department, ward nurses, secretaries and other
authorised staff.
51. Print lists of the patients due to attend in advance of each clinic so that they can
be used by the medical records department to retrieve the correct notes.
52. Analyse information about past and future appointments for planning purposes.
53. Allow the scheduling of a particular appointment slot.
54. Allow overbooking only for urgent cases.
55. Allow the user to find a speciality, subspecialty, physician, or clinic or to enter
them directly.
2. CODING OF DECEASES/ OPERATIONS/ PROCEDURES (ICD10/OPCS4,
7/24/2003, ITC Software com, info@[Link]
12
SNOMED/CPTS, ICD or other)
The Coding of Deceases/Operations/Procedures shall have the following main
characteristics:
1. Support a classification system widely accepted within the European Union
and internationally such as ICD-10.
2. Ensure that the use of such classification systems will be able to facilitate
clinical care and allow statistical analysis and transmission of information.
3. Be capable of supporting an automatic codification system that captures the
clinical detail of symptoms, signs, diagnoses, procedures, disabilities, drugs
as well as management and administration terms.
4. Provide the option of appending an unlimited number of new codes to the
system.
5. Provide an option for easy cross mapping between the codification system
used and other commonly used codification systems.
6. Be regularly updated with regard to the codification system whenever a new
update is released.
7. The system should also be able to use SNOMED, CPTS and have the ability
to support all future ICD´s and recognise ICD codes and their reference to
new or older as against the standard.
3. HOSPITAL ORDER ENTRY AND MANAGEMENT
The Order Entry Management Module shall have the following main characteristics:
1. Handle all necessary communications with the order entry and management
module.
2. Handle all the functions involved with the recording of all clinical orders such
as orders for laboratory tests, radiological and other examinations,
prescriptions, drug requisitions, requisition of equipment and consumables,
referrals, consultations e.t.c..
3. Provide information about a patient.s status and assist clinical decisionmaking
based on protocols and guidelines, for which the patient is eligible,
during clinical encounters.
4. Allow system administrators to modify default drug and default dosing and
frequencies of drugs, depending on the latest scientific evidence.
5. Provide for a free-text field for the optional entry of any necessary comments
by the requesting health professional.
6. Provide the health professionals with the ability to send alert and hazard
messages to the appropriate colleagues.
7. Support a bar-coding system for patient identification, labelling, tracking and
7/24/2003, ITC Software com, info@[Link]
13
entering data when a specimen needs to be sent with the order.
8. Print bar codes whenever and where needed.
9. Print an order form and/or instructions to accompany any specimens sent or
patients attending for examinations.
10. Provide for an efficient and secure linkage of the order form to any specimens
sent.
11. Allow the users to have the option of cancelling an order.
4. CLINICAL LABORATORY MODULE
The Clinical Laboratory Module shall have the following main characteristics:
1. Be fully integrated with all other hospital information systems including:
� Hospital Patients Administration System
� Electronic Patient Record
� Hospital Pharmacy Module
� Blood Bank Module
� Hospital Order Entry and Management Module
� Hospital Radiology System
2. Be flexible, adaptable and capable of interfacing with other systems.
3. Be able to handle all necessary communications with an order entry and
management module where such a module exists.
4. Support all the scientific and administrative functions of a clinical laboratory.
5. Support the functionality of the clinical laboratory as an in-patient and/or a
reference laboratory.
6. Offer the potential of developing into a paperless laboratory department.
7. Include a comprehensive set of applications and tools that will automate most
aspects of clinical laboratory processing.
8. Handle all the functions involved with the recording of clinical laboratory
orders.
9. Support patient bookings (scheduling).
10. Manage referrals.
11. Provide bar-coding capability.
12. Monitor the testing process and report the final test results.
13. Track specimens over time and locations.
7/24/2003, ITC Software com, info@[Link]
14
14. Be able to handle the appropriate quality assurance procedures.
15. Monitor and report on personnel activity in order to facilitate management of
the human resources of the laboratory.
16. Support the distribution of results to authorised staff throughout the healthcare
system.
17. Support all clinical laboratory sites.
18. Support a laboratory with multiple sites of analysis processing.
19. Provide for the following main categories of tests:
� Haematology
� Biochemistry
� Microbiology
� Immunology / Virology
20. Include the following additional categories of tests:
� Blood Bank (separate module)
� Cytogenetics
� Endocrinology
� Cytology
� Histopathology
� PAP
� Thalassaemia
21. Be capable of adapting to any laboratory procedure, workload or
organizational structure.
22. Make full use of the existing laboratory equipment.
23. Be capable of unrestricted assimilation of any laboratory equipment likely to
be acquired in the future.
24. Provide information on utilization of resources by clinical and laboratory staff.
25. Support autodial and auto fax modems.
26. Be capable of complying with the policies and procedures the state
and private laboratories have developed in their specific environment.
Order Entry for laboratory tests
27. Handle all necessary communications with an Order Entry and Management
module where such a module is installed.
28. Handle all the functions involved with the recording of orders for analysis.
29. Allow laboratory tests to be easily entered on to the order form.
7/24/2003, ITC Software com, info@[Link]
15
30. Support a bar-coding system for patient identification, labelling, tracking and
entering data.
31. Save the order before printing the order form and sticky bar codes.
32. Include a unique specimen number on the bar code
33. Allow for the order form to contain instructions to the patient such as "nothing
to be taken 3 hours before the test", e.t.c.
34. Print bar codes either at the time of ordering or at the time of specimen
collection or at the time when the specimen and form are received at the
laboratory.
35. Provide the users with the option of cancelling a test.
36. Provide the users with the ability to flag a test to be notified to the requesting
clinician as soon as it is completed.
37. Support collection of blood by nursing staff on clinical wards.
38. Support mobile blood collection units.
39. Handle the arrival of specimens at the laboratory by using bar code readers to
record the reception of each specimen with its order form.
40. Be capable of handling multiple specimens for each order form.
41. Be capable of handling multiple tests for each specimen.
42. Automatically distribute each specimen and order form to the appropriate
laboratory site and analyser for testing.
43. Utilise the bar code labels for automatic and/or manual instrument operation.
44. Redirect specimens and order forms to the next laboratory analyser, when
one analyser completes its analysis on the specimen.
45. Allow for urgent specimens that arrive to "jump the queue" without interfering
with the routine work.
46. Allow Automatic capture of data.
47. Have the capability of accepting the data directly from the electronic devices
that produce them.
48. Handle in a standardised manner all the relevant laboratory analysers that
produce electronic output.
49. Be capable of automatically capturing data from blood-analysis machines that
may be used at the bedside.
7/24/2003, ITC Software com, info@[Link]
16
50. Have the ability to track each specimen and order form with precision in order
to reduce errors and improve productivity.
51. Support activity, workflow and process tracking.
52. Use the bar codes to identify patients, specimens, staff, tests ordered, and
locations.
53. Handle all the appropriate quality assurance procedures.
54. Give an alarm if a certain limit is breached.
55. Evaluate the need of each analyser to daily statistical analysis.
56. Subject the results of each analyser to daily statistical analysis.
57. Evaluate the need of each analyser for calibration on a daily basis.
58. Allow access for the authorisation officer to the quality control results of each
analyser.
59. Be capable of monitoring the testing process of each analyser.
60. Include an audit trail for analyser maintenance procedures.
61. Report all cases of technical malfunction for each analyser.
Critical values and alerts
62. Keep and utilise data on normal values and critical values according to the
patient.s age, sex, and pregnancy status, kidney and liver function and other
relevant pathology.
63. Provide real-time notification of alerts to clinicians through a communication
device such as e-mail, fax or mobile phone.
64. Support a powerful report generator module based on a graphical user
interface (GUI) to allow the creation of user defined reports.
65. Be able to generate clinical, managerial and administrative reports.
66. Include a wide variety of predefined reports, which can be viewed on screen
or printed.
67. Be capable of producing reports sorted by test, category of test, origin of
order, schedule, payment category, patient type, patient, and priority category.
68. Be capable of producing a users activity report.
69. Include a digital dictation module, which will allow laboratory physicians to
create voice recordings for reports.
70. Allow dictation to be done remotely, from any Internet location.
7/24/2003, ITC Software com, info@[Link]
17
71. Allow the option for the report text or voice file to be automatically e-mailed to
the referring physician.
72. Facilitate manual transcription of voice recordings into text.
73. Allow accurate voice recognition software, to be optionally utilised in order to
convert the laboratory physician.s speech to text.
74. Support voice recognition in both Greek and English.
75. Allow the attachment of digital signatures to voice recordings and transcribed
texts.
76. Provide a simple and effective way for authorised laboratory personnel,
clinicians and other staff to enter, retrieve and view examination data.
77. Allow clinicians and other authorised personnel to request the release of
results from remote locations.
78. Be able to present results through the Internet by using a web browser.
79. Be able to report the patient results and billing details to the appropriate
location.
80. Be fully integrated with the Billing/costing module.
81. Automatically generate billing information based on examinations performed
and supplies used.
82. Be fully integrated with the stores control inventory module
83. Manage expiry dates.
84. Provide low stock warnings.
5. HISTOPATHOLOGY
The Histopathology Module shall have the following main characteristic:
1. Support multiple levels of verification / authorization.
2. Be fully integrated with the other modules of the EHR.
3. Support a unique, system generated protocol number for each specimen,
which is automatically set to zero on the first day of each year.
4. Provide full support for data entry and export with full support of HL7,
EDIFACT e.t.c. formats.
5. Be capable of linking to the Cancer Registry Database.
7/24/2003, ITC Software com, info@[Link]
18
6. Be based on a graphical user-friendly interface.
7. Support multilingual OCR, voice recognition and bar code readers.
8. Support multi bar code readings without the need for keyboard entries.
9. Control access to data according to authorization.
10. Support indefinite on-line retain of Histopathology and Clinical Cytology
results.
11. Support the capability to store data of a certain age to external archival media.
12. Support histology, cervical cytology, non-gynaecological cytology, autopsy,
immunology and semenology.
13. Support user defined and or modified SNOMED codes.
14. Support a user definable address book for individuals and organizations.
15. Demand the electronic signature of the histopathologist before the final
release of the results.
16. Allow the histopathologist to access the electronic patient record.
17. Support tele-pathology to allow for sending and receiving studies to and from
other destinations.
18. Support a full audit trail to log modifications to all patient data.
19. Store the audit log data indefinitely.
20. Support the indefinitely kept of the audit log.
21. Support storage and retrieval of specimens and preparations.
Order Entry
22. Support a unique, system generated protocol number for each specimen as
mentioned above.
23. Support bar code label printing.
24. Support document printing to accompany the specimen.
25. Support cancellation of entry request at any time.
26. Support the avoidance of duplications.
27. Support searching for patients by patient name, identification number, patient
number, date of birth e.t.c. or combinations of the above fields.
7/24/2003, ITC Software com, info@[Link]
19
28. Store information about the requesting part (hospital, clinic, ward, medical
officer, clinical information, collection date and time e.t.c.)
29. Store information about the receiving part (received date and time, assign
histopathologist, dates for preliminary and final report e.t.c.) for each
specimen.
30. Have the facility to flag patients (e.g. as high-risk, staff, patients of interest
e.t.c.).
31. Restrict access, based on user security level, to particular classes of flagged
patients.
32. Have the facility to alert histopathologist for a flagged patient.
33. Support an automatic display of previous entries for a patient.
34. Support categorization of specimens.
35. Support categories for source of smear for cytological samples.
36. Facilitated the handling of non-patient specimens (e.g. environmental, animal
e.t.c.)
Data entry
37. Support digital dictation to allow histopathologists create voice recordings for
reports.
38. Support voice recognition for data entry.
39. Be fully integrated with picture Archiving Computer System (PACS).
40. Support the use of barcodes, multilingual OCR and other computer-readable
formats for data entry.
41. Support diagnostic codes, such as ICD-10, ICD-0, SNOMED-CT e.t.c.
42. Support a user-friendly word processor with an embedded spell checker.
43. Support the import of data between applications (drag and drop or copy and
paste)
Reporting
44. Support a flexible operational report generator.
45. Support user definable and configurable report formats.
46. Support multiple types of reports e.g. single sample reports, cumulative
reports, reports for specific hospitals, clinics, wards, requesting physicians
e.t.c.
7/24/2003, ITC Software com, info@[Link]
20
47. Support reporting to different output streams e.g. paper, remote printer, fax
machine, E-mail, interfaces e.t.c.
Enquiry
48. Support user definable filters to restrict the display of results e.g. by sex,
location, specimen type, test code e.t.c.
49. Support the display of results in chronological or reverse chronological order.
50. Support restriction of viewing of .sensitive. results in enquiry screens, subject
to user authorization level.
6. BLOOD BANK
The Blood Bank Module shall have the following main characteristics:
1. Be fully integrated with the other modules of the hospital information system
such as patient administration, billing, order entry, laboratory, stock control
e.t.c.
2. Allow for extension of integration with the entire healthcare information system.
3. Comply with the provisions of the law that regulates Blood
Donations.
4. Comply with any relevant Regulations issued by the Council of Ministers.
5. Be a web-enabled, real-time, interactive, computer system, encompassing all
the functions of a modern blood bank.
6. Integrate donor, blood and patient information.
7. Cover and integrate the following areas of activity:
� Recruitment.
� Donors.
� Donor groups.
� Credits for donors and donor groups.
� Scheduling of donations.
� Transportation of blood and blood products.
� Blood unit testing.
� Quarantine and disposal of unsuitable blood.
� Blood processing.
� Tracking.
� Blood inventory
� Clinicians. requests.
� Patient details.
� Cross matching.
� Transfusions.
� Billing.
� Reporting.
7/24/2003, ITC Software com, info@[Link]
21
8. Be capable of converting, verifying, accepting and integrating the donor and
patient data stored in previous software packages used by any of the blood
banks.
9. Allow for complete freedom of choice for any future procurement of
equipment.
10. Offer a high degree of parameterisation to allow system administration to
easily modify the operation of the system according to varying needs of the
users.
11. Allow results to be viewed by authorized users anywhere in the network.
12. Be capable of generating customisable alerts.
13. Have a report module capable of compiling statistical data.
14. Allow for the permanent storage of information on:
� Donor demographic data.
� Donor history and other details.
� Patient's blood group.
� Cross-match results.
� Antigens/Antibodies.
� Transfusion details.
� Blood unit history.
15. Track all information from the time of recruitment of blood donors to
transfusion of patients.
16. Provide querying and reporting functionality in all modules of the application.
17. Provide complete order entry features.
18. Allow for entry of special messages in free text fields.
19. Allow scalability and ease of interfacing with the laboratory information system
and the hospital information system.
20. Include integrated bar coding and labelling technology.
21. Automatically print transfusion slips and cross-match labels.
Recruitment
22. Flexibly accommodate the blood bank.s recruiting needs.
23. Allow recruiting to be performed interactively.
24. Support correspondence and other forms of communication with registered
blood donors.
Eligibility of donors
7/24/2003, ITC Software com, info@[Link]
22
25. Maintain a modifiable list of the criteria used for the selection of eligible blood
donors.
26. Be able to create selective lists of prospective, eligible donors.
27. Allow the users to view all previously recorded details of each donor in order
to verify his identity and eligibility before each blood donation.
28. Allow for the recording of any written certification of eligibility issued by the
donor.s personal physician.
29. Keep a record of the reasons for permanent or temporary exclusion of blood
donors while ensuring the protection of personal data.
Donor registration
30. Keep a unified registry of all blood donors.
31. Support the use of blood donor cards.
32. Use the donor.s identity card number as a unique identifier.
33. Use other identifiers when an identity card number is currently unavailable.
34. Include the following demographic data fields in the registry of blood donors:
� Name
� Surname
� Date of birth
� Sex
� Identity card number
� Address
� Telephone numbers
� Previous medical history
� Social behaviour
� Occupation e.t.c.
35. Be capable of secure, on-line donor data entry at any workstation on the
network.
36. Be capable of providing the necessary information on past donation history
including adverse effects.
37. Be capable of handling special donation types and products.
38. Keep a chronological record of the activities of donor groups.
39. Support a system of awarding credits for blood donations by donors and
donor groups.
Scheduling
40. Allow for appointments to be scheduled at multiple sites.
7/24/2003, ITC Software com, info@[Link]
23
41. Allow for mobile units of blood collection to be scheduled electronically.
42. Include, in the registry of blood donations, a field for an international unique
identifier code for each blood collection centre.
Donations
43. Keep a registry of all blood donations.
44. Track all activities on each donated unit of blood from the time of blood
collection to the time of clinical assessment of the patient following transfusion.
45. Identify each donor attendance by a unique .attendance ID. field.
46. Support the proper labelling of blood units and blood products.
47. Record the volume of each blood donation.
48. Record the date/time of each blood donation.
49. Record the duration of each blood donation.
50. Allow the option of issuing deferral and cancellation notes automatically.
Mobile services
51. Support mobile units used for blood donations at places remote from the
blood bank.
52. Allow users to operate portable, wireless computers such as notebooks and
palm-tops.
53. Allow mobile units to have on line access to the data repository.
54. Allow mobile units to have the same deferral capability as the blood bank.
55. Allow the mobile units to determine donation eligibility.
56. Allow registration information to be exchanged between the blood bank and
the mobile units.
57. Allow mobile units to record details of blood product transportation.
Labelling
58. Provide full bar coding and labelling capability for efficient and accurate donor
specimen processing.
59. Support the printing of labels.
60. Be capable of customizing the formats of labels for different blood
components.
7/24/2003, ITC Software com, info@[Link]
24
Blood testing
61. Support both manual entry and automatic capture of results from testing
equipment.
62. Record the completion of testing for each donated blood unit.
63. Record the results of the following tests for each donated blood unit:
� ABO group
� Rhesus group
� Syphilis
� Hepatitis-B surface antigen (HbsAg)
� Hepatitis-C (Anti-HCV)
� HIV antibodies (Anti-HIV1 and anti-HIV2)
� Malaria antibodies (whenever indicated)
� Other optional tests
64. Ensure that donor and unit information are accessible immediately at all
workstations.
65. Record and report the presence of significant antibodies.
66. Allow for the proper management of situations where components of blood
and specimens of a single unit are distributed and processed at multiple sites.
67. Allow for emergency situations when there is a need to begin preparation and
testing before the details of the donation are recorded in the system.
Blood processing
68. Use customisable rules to determine the suitability of blood units for certain
types of processing.
69. Support the organisation of plasma fractionation.
70. Support transportation of plasma to other countries for contract fractionation.
71. Handle component creation, pooling, processing, quarantine, labelling, issuing
and distribution of products.
72. Automatically communicate product information and requirements to the
appropriate departments.
Immunohaematology testing
73. Support the activities of the Immunohaematology and Pre-natal testing
laboratory
74. Support the process of testing blood units for compatibility for the patient for
whom the blood is requested.
75. Allow for the possibility of the need to add new serology profiles and new
phenotypes in addition to standard ones.
7/24/2003, ITC Software com, info@[Link]
25
76. Provide support for the appropriate use of Anti-D immunoglobulin where there
is an indication.
Deferral tracking
77. Securely handle deferrals and cancellations.
Blood Bank Order Entry
78. Allow for the recording of orders for blood products.
79. Allow for the recording of remote order entry for specific patients.
80. Provide order status information (e.g. .waiting., .being processed., .ready.
e.t.c.)
81. Enable stock and order status to be viewed for all locations at any workstation.
82. Allow for patient information on antigen, antibody and transfusion reactions to
be entered while processing the order.
83. Allow for patient order requirements to be defined, based on previous history.
Blood Stock control
84. Support the availability of adequate amounts of blood and blood products to
satisfy the needs of all patients at all times.
85. Provide .low blood stock. warning messages
86. Allow for the inclusion of all existing blood banks.
87. Support the transportation of blood products between blood banks.
88. Utilize the full bar coding and labelling capability of the system for efficient and
accurate stock management.
89. Support all activities concerning importation of blood and blood products.
90. Allow staff to record detailed stock locations including refrigerating centrifuges
refrigerators, mobile units, ward refrigerators and emergency refrigerators.
91. Provide detailed, customisable reporting and querying capability on stock.
Transfusions
92. Provide information on blood units designated for use by specified patients.
93. Include customisable rules for determining whether a given unit is suitable for
transfusion to a particular patient.
94. Be capable of recording, storing, analysing and reporting transfusion results.
95. Maintain a permanent, detailed, chronological record of any adverse reactions
in all patients who receive blood transfusions.
7/24/2003, ITC Software com, info@[Link]
26
Autologous transfusions
96. Be capable of managing autologous blood transfusions.
97. Record all relevant details of autologous blood collection.
98. Be capable of handling the recording of the patient.s consent.
99. Print a consent form to be signed by the patient.
100. Handle clinical order entry for autologous transfusions.
101. Allow for the management of autologous units transported from other
blood banks.
102. Handle the labelling and distribution of autologous blood units and
components separately from the other blood products.
103. Be capable of reporting on the availability of autologous blood.
Plasmapheresis/ Cytapheresis
104. Support the organisation of plasmapheresis/cytapheresis.
105. Support the organisation of therapeutic plasmapheresis/cytapheresis
in accordance with widely accepted medical rules.
106. Maintain a modifiable list of additional eligibility criteria used in
selecting donors for plasmapheresis/cytapheresis.
107. Support the proper labelling of the bags containing the products of
plasmapheresis/cytapheresis.
Billing
108. Be integrated with the hospital information system billing module to
manage all its financial aspects.
109. Enable variable pricing to ensure accurate charges.
110. Enable special credits for unique products, blood types, locations, and
special product testing and processing.
Reports
111. Include a powerful report generator module based on a graphical user
interface.
112. Allow for user defined reports.
113. Be capable of reporting on:
� Data on any specified donor
� Details of any specified donation session
� Blood products obtained from each donation session
7/24/2003, ITC Software com, info@[Link]
27
� Detailed descriptions of any given component.
� Administrative data.
� Donor eligibility in real-time
� Serology results
� Blood group information
� Correspondence
� Autotransfusions
� Plasmapheresis
114. Maintain and report data for individual donors, donor groups, patients
and other hospitals or clinics.
115. Be capable of producing reliable statistical reports on all activities
undertaken by the blood banks.
116. Communicate with external partners using multiple communication
formats EDI, e-mail, CXML, Fax, mail.
Safety functions
117. Provide critical safety functions covering all the processes in the
system.
118. Utilize customisable rules based on lists of contraindications and
interactions.
119. Provide unique passwords for authorisation to override error
messages.
Quality control
120. Allow for regular automatic checks on each type of activity during the
handling of blood and components.
121. Allocate batch numbers to blood units according to the equipment
used in the processing of blood.
122. Allow for the possibility of exclusion of all blood units in a particular
batch when a problem is identified.
7. RADIOLOGY / PACS
The required Radiology Module shall have the following main characteristics:
1. Support the clinical and administrative functions of the radiology department.
2. Be capable of automatically acquiring, transmitting, viewing, post-processing
and archiving images and other forms of examination results.
3. Be able to handle all necessary communications with an order entry and
management module.
4. Allow hospital radiology staff to store demographic, billing, and essential
background medical information on each patient.
7/24/2003, ITC Software com, info@[Link]
28
5. Offer the potential of eventually developing into a paperless and filmless
medical imaging department with the introduction and integration of a Picture
Archive Communication System (PACS).
6. Transport and store digital images in compliance with DICOM III standard
(NEMA and ACR).
7. Allow for immediate and simultaneous access to all examination data and
images, from any workstation.
8. Offer the ability to view and manipulate examination images.
9. Offer the ability to view diagnostic reports from within the PACS interface.
10. Allow the transfer of DICOM or HL7 task lists to image acquisition devices,
based on orders.
11. Use picture archives that can be recognised by all DICOM III compatible
systems in order to allow free exchange of information, even between systems
that may be incompatible in other respects.
12. Allocate, to each picture archive, an identification number related to the
patient.s demographic data and clinical record.
13. Allow full access to picture and video archives from the electronic patient
record when such a record is in operation.
14. Allow comparative presentation of images in order to facilitate research.
15. Allow access to picture and video archives from the picture management
system.
16. Support the film/file room.
17. Support a centralised system of printing on film.
18. Support a quality assurance system.
19. Allow the radiologist to access laboratory results that may be relevant to
radiological procedures for certain patients, online in real-time.
20. Support a teleradiology module to allow for sending to and receiving studies
from other destinations.
21. Support CT, MR, US, CR, Secondary Capture, Traditional X-ray, X-ray
Angiography, X-ray R&F, NM.
22. Provide configurable HIS/RIS support.
23. Include a data acquisition module for film digitisation, video capture, document
7/24/2003, ITC Software com, info@[Link]
29
scanning and TWAIN-32 support.
Order entry and management
24. Allow clinicians to order radiology examinations for their patients.
25. Automatically generate printed forms associated with order entry.
26. Be capable of printing customisable labels for film envelopes, including bar
codes representing the patient unique identification number and the
examination number.
27. Be capable of printing examination and patient information on films.
Scheduling
28. Support a scheduling system that will facilitate optimal resource allocation.
29. Support a scheduling system for patient appointments and examinations.
30. Support a schedule system for all the resources of the radiology department.
31. Provide a simple and effective way for radiologists, clinicians and other staff to
manage schedules.
Activity tracking
32. Support activity, workflow and process tracking.
33. Support film and envelope tracking.
34. Support examination acknowledgment.
35. Allow bar codes to be used in order to identify patients, staff, examinations,
supplies and locations.
36. Ensure that all the movements of the envelopes are registered into the
database.
37. Keep an up to date and accessible record of the current location of every film.
Report Generation
38. Support interpretation of examinations and reporting.
39. Support management and administrative reporting.
40. Include a built-in digital dictation system, which will allow radiologists to easily
create voice recordings for any study.
41. Allow dictation to be done remotely, from any Internet location.
42. Allow the report text or voice file to be automatically e-mailed to the referring
physician so that he can hear it and act on the preliminary findings without
delay.
7/24/2003, ITC Software com, info@[Link]
30
43. Allow accurate voice recognition software, to be optionally utilised in order to
convert the radiologist's speech to text.
44. Allow radiologists provide a digital signature for their report.
45. Provide a customisable report generator to facilitate the creation of lists,
cross-tabulation, and distribution reports based on any of the data entered into
the system.
PACS (Picture Archiving Communication System)
46. Have the capacity to integrate with a Picture Archiving and Communication
System.
47. Provide DICOM connectivity that makes it easy to connect, view and transmit
images from multiple modalities into an integrated PACS environment.
48. Provide a PACS environment with full integration of information from the
Radiology Information System and other image producing departments.
49. Provide picture archiving that supports radiology, pathology, ultrasound,
medical photography, endoscopies and nuclear medicine.
50. Allow for each department to use the same PACS system in order to provide
consistency of user interfaces throughout the hospital.
51. Offer an export option, allowing the writing of copies of patient studies to
external media in DICOM III format.
Access to reports and images
52. Provide a simple and effective way for radiologists, clinicians and other staff to
enter and retrieve examination data and view medical images.
53. Allow clinicians to view digital examination images, if available, or find out
where a particular film is currently located.
54. Offer functionality to manage archive media, such as showing if the required
media has been loaned out, damaged or lost.
Information storage
55. Support an archive system that will accept all types of diagnostic imaging,
including X-rays, ultrasound, CT scans, MRI, radioisotope scans and
mammography.
56. Support a user friendly, effective and secure system of film archiving.
57. Support all aspects of record keeping and communication for a diagnostic
imaging department.
58. Be capable of allowing storage and retrieval of image information on CD.s.
Image Viewing
7/24/2003, ITC Software com, info@[Link]
31
59. Provide a simple and effective way for radiologists, clinicians and other staff to
enter and retrieve examination data.
60. Allow healthcare professionals to view, manipulate and annotate medical
images.
61. Automate the process of searching for specific medical images or studies.
62. Allow a radiologist to view medical images while preparing his report.
63. Allow for measurement of distance, angle, profile, ROI and Cobb angle.
64. Allow for copying images to the clipboard.
65. Allow for printing images to DICOM and Windows NT printers.
66. Allow for exporting of ROI statistics to Excel.
67. Allow for exporting of images to TIFF, BMP and JPEG.
68. Allow for immediate access to all DICOM information.
69. Provide an auto deletion option (rule based).
8. DOCTOR’S PHARMACY PRESCRIPTION
The Required Doctor.s Pharmacy prescription shall have the following main
characteristics:
1. Automatically retrieve patient information that may interfere with drug therapy
such as renal or hepatic disease, enzyme deficiency, history of drug allergy e.t.c.
2. Provide full audit trail.
3. Be capable of supporting many users concurrently.
4. Obtain and utilise information from the hospital formulary of the hospital
pharmacy.
5. Accommodate contingency manual operations in case of temporary system
failure.
6. Support the writing of free text prescriptions for complex medications that must be
compounded manually.
7. Reserve stock upon order entry.
8. Substantially reduce the possibility of fraud.
9. Support inventory control.
10. Provide the Pharmacy with all information necessary to support its logistic
activities.
7/24/2003, ITC Software com, info@[Link]
32
11. Support the preparation of pharmaceutical products, such as infusion fluids,
cytostatic drugs, total parenteral nutrition e.t.c.
12. Support the preparation and administration of intravenous drugs.
13. Routinely check for duplicate prescriptions for the same individual.
14. Be capable of checking the physical compatibility of parenteral medications.
15. Give warnings for Y-site and in-solution compatibility of combinations of
medications.
16. Provide an option for printing a drug education leaflet for the patient.
17. Be capable of supporting the traditional method of supplying drugs to the ward
where a standard stock of frequently prescribed drugs is available.
18. Support inventory control on the ward.
19. Easily display complete drug histories for a patient.
20. Ensure that contact information on all patients is immediately available (in the
event of a drug recall or newly discovered adverse interactions).
21. Avoids costly downtime events
22. Support clinical pathways
Entry forms
23. Provide a user-friendly electronic prescription form for doctors to enter drug
and other material prescriptions.
24. Provide a user-friendly electronic requisition form for nurses to enter drug and
other material ward requisitions.
25. Be capable of creating electronic prescriptions by employing methods of data
entry such as point click e.t.c.
26. Handle the three main entry documents, namely:
� Prescriptions from outpatients.
� Ward requisitions.
� Individual in-patient treatment chards.
27. Allow the following information to be entered:
� Patient age category
� Pregnancy
� Breast-feeding
� Renal disease
� Hepatic disease e.t.c.
7/24/2003, ITC Software com, info@[Link]
33
28. Enable the display of relevant patient's health data and current medications.
29. Be capable of presenting a list of available alternative matching medications
for selection.
30. Support repeat prescriptions.
31. Allow the order details to be modifiable until the order is confirmed.
32. Include an encrypted electronic signature on each prescription form.
33. Support doctor's standing order sets and multiple medication orders.
34. Accommodate ordering of floor stock pharmacy items, return medication
credits/adjustments, and doctor's standing orders.
35. Notify physicians of discontinuing orders for the ability to reorder.
Decision support
36. Assess prescriptions of drugs by integrating patient data from the electronic
health record.
37. Facilitate drug prescriptions by using a national drug database, containing
information on contraindications, drug interactions, dosages and prices.
38. Provide information to clinicians in the form of medication profiles, drug
formulary information e.t.c.
39. Be able to screen for compliance against the formulary as soon as the
prescription is entered into the computer.
40. Facilitate communication with other modules of the hospital information
system by accommodating the Anatomic Therapeutic Chemical Classification
system and the British national Formulary.
41. Permit the issue of repeat prescriptions up to a maximum number defined by
system administration.
42. Be able to offer suggestions for lower-cost alternatives to a prescribed drug.
43. Provide alerts for the following by communicating with the patient.s electronic
health record:
� Drug-disease contraindications and precautions.
� Drug-drug interactions.
� Dosing errors
� Pregnancy and lactation precautions.
� Age-related precautions.
� Gender-related precautions.
� Drug-previous allergy conflicts.
� Allergic cross-reactivity.
� Drug-food interaction.
7/24/2003, ITC Software com, info@[Link]
34
� Drug-ethanol interaction.
� Drug-tobacco interaction.
� Drug-lab interference.
� Drug radiology interference.
� Therapeutic duplications and conflicts.
� Ingredient duplication.
� Therapeutic antagonisms e.t.c.
44. Allow for patient-specific dose checking to help clinicians eliminate dosing
errors based on patient-specific criteria such as gender, age, height, weight,
serum creatinine, hepatic function, pregnancy, lactation and prematurity.
45. Be capable of providing lists of products that are free of certain ingredients,
such as tartrazine, gluten, or lactose.
Printing
46. Enable printing of the prescriptions when required.
47. Allow e-mail and fax-transmission of prescriptions.
48. Print bar codes and print bar code labels to support barcode driven delivery.
49. Print labels, containing codified dosage and instructions, to be attached to
medicines due to be dispensed.
50. Allow for "as needed" printing of IV admixture labels.
51. Allow for creation and maintenance of multiple sizes, formats and texts of
labels.
Reports
52. Enable hospital management and General Health Scheme management
obtain information on drug utilisation through a report generator.
53. Include a powerful report generator module to create user-defined reports.
54. Enable flexible user defined reporting.
55. Enable enquiry on for all the items prescribed by a particular doctor.
56. Be able to perform drug utilisation review.
57. Produce a file with the daily transactions for electronic transmission to a
consolidated stock control system
58. Print a pending prescriptions report
59. Enquire on all the items prescribed to a particular patient during a specified
time period.
Pricing
7/24/2003, ITC Software com, info@[Link]
35
60. Screen prices of medications and suggest alternatives to the physician.
61. Provide pricing and descriptive information for healthcare items, including:
� Prescription pharmaceuticals
� Non-prescription pharmaceuticals
� Nutritional agents
� Bulk chemicals used for compounding
� Medical devices
� Supplies
62. Ensure that each product record includes:
� Code number
� Brand name
� Generic name
� Dosage form
� Strength
� Route of administration
� Package size.
63. Use a clinically oriented, hierarchical drug coding system based on European
and international standards.
64. Suggest prices and allow the user to change the prescription.
9. BILLING / COSTING
The required Billing/Costing Module shall have the following main characteristics:
1. Be fully integrated with all other interacting modules in the hospital information
system such as the Patient Administration System, Electronic Health Record,
Billing, Pharmacy, Inventory control, Laboratory, Blood bank, Radiology,
Dietary module e.t.c. for immediate transfer of data and charges.
2. Support outpatient billing, day-care billing and in-patient billing.
3. Perform individual, collective and insurance billing.
4. Verify insurance and patient pay category.
5. Provide sufficient flexibility for easy customisation of billing-rules and updates.
6. Ensure safe control of receivables and cash inflow.
7. Support hospital liquidity.
8. Handle VAT as required by the legislation and produce all
necessary VAT reports.
9. Allow transactions in different foreign currencies or the Euro.
10. Ensure the completeness and accuracy of invoices with regard to all billable
services provided.
7/24/2003, ITC Software com, info@[Link]
36
11. Support credit card transactions.
Billing Procedure
12. Determine the pay category based on Government and General Health
Scheme regulations.
13. Follow a pricing procedure based on case-type, billing-type and insurance
coverage.
14. Ensure complete and accurate billing by using information on billable services
collected from all interacting modules.
15. Provide automatic generation of invoices according to approved price lists.
16. Automatically check and control limits, reductions, and billing combinations.
17. Ensure appropriate allocation of charges to patient and insurance provider
according to patient-insurance contract.
18. Be capable of notification for services ordered and not approved by insurance
providers.
Out-patients and day-cases
19. Support all types of out-patient charges according to Government and
General Health Scheme regulations.
20. Support billing for day case procedures.
21. Create out-patient and day-case invoices by collecting billing information on
the following:
� Ambulance transport
� Flat rates per case
� Laboratory tests
� __________Radiology examinations.
� Medication charges
� Procedure charges
� Physician consultations
� Consumables e.t.c.
In-patients
22. Support all types of in-patient charges according to Government and General
Health Scheme regulations.
23. Create in-patient invoices by collecting billing information on the following:
� Ambulance transport
� Accidents and emergency service
� Flat rates per case
� Laboratory tests
� Radiological examinations.
� Medication charges
7/24/2003, ITC Software com, info@[Link]
37
� Physician consultations
� Pre-admission treatments
� Procedure charges
� Consumables
� Departmental charges e.t.c.
24. Support interim billing.
Insurance processing
25. Enable insurance claims processing.
26. Enable selective insurance claims processing.
27. Enable automatic generation of secondary claims.
Invoice processing
28. Provide by default, unique and consecutive numbering of invoices, separately
for each case type (out-patient, in-patient)
29. Automatically present detailed patient demographics on the invoice.
30. Provide an overview of all data pertaining to billing such as length of stay,
intensive therapy unit stay, procedures, laboratory tests, imaging
examinations e.t.c.
31. Allow manual charging of patients if required and subject to authorisation.
32. Provide payment details, such as down-payments, co-payments, reductions
e.t.c.
33. Allow for cancellation of selected invoices subject to authorization.
34. Allow for tracking of cancellations.
35. Prohibit any changes after the issue of an invoice.
36. Provide for the name of the user and the establishment.s code to be
presented on the invoice.
37. Be capable of writing off bad debts.
Invoice printing
38. Provide for the invoice to be printed, either immediately during billing or at a
later time with secure preservation of issue date.
39. Allow customisation of the design of forms according to hospital-specific
requirements.
40. Be capable of generating collective invoices (invoice lists) for individual
insurance providers.
7/24/2003, ITC Software com, info@[Link]
38
41. Print a selection of reminder letters.
Quality control
42. Be able to monitor each episode of care from the time of registration, and
track all billable services provided till the time of completion of services.
43. Be capable of automatic display of the billing balance on readmission.
44. Support (Indicate) invoice status information such as preliminary, final,
additional, supplementary e.t.c.
45. Demand the entry of the user.s electronic signature before finalisation of the
invoice.
46. Provide an audit trail on charges, receipts and adjustments.
47. Avoid transaction duplications.
Financial reports
48. Provide a report generator to enable personnel to produce a variety of
customized billing reports.
49. Provide a wide range of built-in reports such as patients insurance, payment
type, case type and totals cash inflow.
50. Produce daily transaction reports with sub-totals by provider, payment type
and accounts receivable totals.
51. Produce accounts receivable reports.
52. Produce statements of accounts on pre-selected dates i.e. existing printout of
the Treasury Department DL14, which includes in-patients hospital fees, outpatient
hospital fees, consulting fees and specialists fees e.t.c.
53. Produce statements of arrears on pre-selected dates.
54. Allow reporting of cash inflow by entity, disease related group, major
diagnostic category, patient, physician, physician group, department e.t.c.
55. Facilitate the production of financial statistical reports.
56. Be capable of providing status reports and processing of outstanding claims.
Additional features
57. Provide a screen with extensive selection/query capability.
58. Be capable of direct billing through the use of bar code readers.
59. Be able to retrieve data by code, identity number, name and patient groups.
10. PERSONNEL MANAGEMENT
The requested Personnel Management Module shall have the following main
7/24/2003, ITC Software com, info@[Link]
39
characteristics:
1. Record personal and official details of healthcare personnel.
2. Support the scheduling of duties of the hospital staff.
3. Record employees' attendance.
4. Handle the basic personnel functions of the ΜΟΗ including:
� Performance appraisals
� Career and promotion history
� Pay information
� Other operational data such as sick leave, annual leave e.t.c.
5. Support career development such as training planning.
Doctors’ registry
6. Maintain a database of doctors.
7. Maintain a database of doctors. groups.
8. Manage personal and demographic data for each doctor.
9. Maintain individual doctor professional details.
11. STOCK CONTROL / INVENTORY
The requested Stock Control / Inventory Module shall have the following main
characteristics:
1. Can be integrated with the Patient Administration System, Medical Equipment
Management Module, Pharmacy Module and Central Stores Module.
2. Manage and maintain the stocks of tools & accessories, consumables,
furniture, raw materials and other items maintained by the hospitals and the
various departments such as:
� Operating Theatres
� Clinical Laboratories
� Urban & Rural Health Centres
3. Allow for the existence of multiple warehouses or branches.
4. Be able to issue items to work orders / jobs / persons.
5. Issue items to various sub-stores against the orders placed.
6. Keep track of items that have been returned due to expiry or damage.
7. Generate purchase orders for the items, which are currently low in stock.
8. Assist the creation of purchase orders to receive the required items.
9. Record the supplier details.
7/24/2003, ITC Software com, info@[Link]
40
10. Allow the various sub-stores of the hospital such as pharmacy, wards,
theatres, A&E e.t.c., to place orders for the items that are currently low in
stock.
11. Allow the Main Stores of the hospital to receive orders from the sub-stores.
12. Issue requested items to the respective sub-stores.
13. Be capable of customizing the re-ordering levels for each item.
14. Edit details of items stored in the database.
15. Identify items that are not used or that are unavailable.
16. Record the opening balances of stock available.
17. Maintain Creditors Ledger.
12. HEALTH SMART CARD
The requested Health Smart Card module shall have the following main
characteristics:
1. Employ a type of plastic smart card with an embedded computer chip able to
store and transact data between users.
2. Be capable of transacting the card data via a reader that will be part of the
computerised information system.
3. Provide vital information in emergencies such as medication, allergies, history
e.t.c.
4. Support a range of chip cards according to the needs of the health care
system
5. Support CPU/MPU Microprocessor Multifunction cards which have on card
dynamic data processing capability.
6. Support a variety of Card Readers, according to the hardware and software
needs.
13. ELECTRONIC HEALTH RECORD
The requested Electronic Health Record Module shall have the following main
characteristics:
1. Store digital health care information about an individual.s lifetime with the
purpose of supporting continuity of care, education and research, and
ensuring confidentiality at all times.
2. Facilitate the provision of patient-centred, shared care through the availability
of both clinical and administrative patient data.
7/24/2003, ITC Software com, info@[Link]
41
3. Provide such data in the form of electronic healthcare records that are
accessible, secure and highly usable in the European multilingual
environment.
4. Be based on the concept of a .virtual. or distributed EHR with data stored and
available at the point of their collection.
5. Be capable of making full use of the new technologies of distributed
databases and the new communication possibilities (e.g. intranet and internet
technologies).
6. Take full advantage of the standards and pre-standards concerning the
architecture and exchange format (e.g. CORBA) that are appearing and being
discussed within standardisation bodies, such as CEN TC 251 in Europe and
ANSI-HISB in the USA.
7. Address the need for interfacing many different administrative and clinical
systems to share records consistently, comprehensively and securely.
8. Be capable of stepwise evolution over time as new software modules are
added to enable the storing of the specialised information generated by the
various distinct specialties in hospitals until the complete EHR concept is
achieved.
9. Ensure that at the final stage, each separate medical specialty will be able to
store its own unique data in the EHR.
10. Include the results of various clinical tests as well as information stored as
text, images, video and voice.
11. Support the needs of a Health Monitoring System compliant with European
requirements.
12. Be capable of communicating with a Community-wide network of information
systems for the free, exchange of health information between countries.
13. Be capable of including, as its core application, a comprehensive,
communicable and secure Electronic Health Record in line with the
recommendations of the Promotion Strategy for European Electronic
Healthcare Records (PROREC).
14. Adopt the latest European standards on Electronic Health Record
architecture.