Hospital Management System/p5

General ledger:

1.1	Ledger Relationships
q	The system will provide the facility to have multiple, independent general ledgers.
q	It will be possible for information to be consolidated within and across general ledgers for month end reporting purposes.
q	Each general ledger will be capable of supporting and be fully integrated with the sales and purchase ledgers, payroll and cash book.
q	Each subsidiary ledger will relate to a separate control account in the general ledger.
q	Postings to subsidiary ledgers will result in automatic postings to the control accounts in the general ledger.

1.2	Account coding
q	The system will support an account code of the following format:
	* at least three alphanumeric characters for the cost centres (departments),
	* at least five alphanumeric characters for the expense / income account codes,
	* at least 3 alphanumeric characters for the analysis codes.
q	It will be possible for individual elements of the code to be set up separately, so obviating the need to set up every valid combination of elements.
q	The system will only prompt for analysis codes on those expense / income codes for which they are relevant.

1.3	Budgets
q	The system will allow for three sets of budgets to be held against an account:
	* original budget,
	* revised budget,
	* latest forecast.
q	The system will allow the following year's budget(s) to be set up without overwriting current year budgets.
q	It will possible to budget at a higher level than that at which transactions are input, e.g. some accounts are only budgeted at income/expense code level, others at a more detailed level.
q	There will be facilities for phasing an annual budget over the various accounting periods on the basis:
	* of equal monthly apportionment,
	* a specified monthly profile (of which there can be more than one).
q	It will be possible for budgets to be generated automatically from previous year actuals or budgets, with a percentage increase or decrease by income / expense code range.
q	There will be facilities for loading budgets from a micro computer based spreadsheet.

1.4	Transaction input
q	Transactions will be online but with a facility for batching.
q	If transaction batching is used by the system, it will support batch control on input. Agreement of batch controls will be mandatory before batches are accepted for posting.
q	Batch numbers will be allocated by the system.
q	Batches will be limited to:
	* a single period,
	* a single transaction type.
q	Batches will be written to a 'holding' file, and be available for recall and modification before posting.
q	It will be possible for valid batches to be posted selectively by the user.
q	The system will provide the facility for the users to define their own transaction types, e.g. month end allocation journals, payroll journals etc.
q	It is anticipated that the following fields will be input on transactions:
q	Header level:
	* transaction type (unless input at batch level),
	* transaction reference,
	* transaction narrative (minimum 20 characters),
	* transaction date,
	* accounting period (unless automatically derived from date).
q	Line level:
	* account code,
	* description (minimum 20 characters),
	* value,
	* debit/credit indicator,
	* quantity (optional),
	* analysis code (see below).
q	Analysis codes will be available on transaction records for analysis separate from that based on the account code, e.g. on some transactions a staff code will be entered, to facilitate analysis of certain types of expense by staff member.
q	Separate tables of valid analysis codes will be maintained for validation purposes and appropriate descriptions displayed on entry of the analysis code.
q	The system will support the following types of journal:
	* accrual and prepayment journals, which automatically reverse themselves in the following period,
	* skeleton journals, where the bulk of the information is pre-coded, only the date and amounts needing to be entered,
	* recurring journals, which are similar to skeleton journals but with the values pre-entered, though capable of modification.
q	It will be possible for account codes to be looked up during data entry (on the basis of all or part of the account name).
q	It will be possible for trial month ends to be carried out, i.e. month end reports produced etc, but still allowing for further transactions for the month to be subsequently input, and reports re run.
q	It will be possible for bank statement information to be entered, and a bank reconciliation statement automatically produced.
q	The system will allow bank statement information to be entered automatically from a magnetic tape supplied by the bank.
q	It will be possible for specified account balances to be automatically reallocated over a range of other accounts, according to pre-determined apportionment ratios, i.e. a number of account balances are apportioned over departments using various bases, such
q	The system will automatically transfer balance sheet account balances forward at the end of each financial year, and zero-ise P&L account balances.
q	It will be possible to keep the previous year open for at least six months while processing the next year's data.

1.5	Data stored
q	The general ledger will hold balances for each account code as follows:
	* each period,
	* year to date,
	* budgets for each period,
	* budgets for year to date,
	* budgets for year,
	* each period previous year,
	* total for previous year,
	* year to date last year.
q	The general ledger transactions will contain the following fields:
	* full account code
	* transaction type,
	* batch number,
	* transaction reference,
	* transaction date,
	* accounting period,
	* transaction narrative,
	* value,
	* debit/credit indicator.

1.6	Data output
1.6.1	Enquiries
q	Account level enquiry: The following information will be available on entry of account code:
	* net movement by period,
	* net movement by period compared with:
	- budget, and variance,
	- previous year, and variance.
	* on selection of a period it will then be possible to see all the transactions making up the net movement,
	* the following fields will be displayed at transaction level:
	- transaction type,
	- transaction reference,
	- transaction date,
	- transaction narrative,
	- transaction value,
	- supplier or customer code for postings derived from purchase or sales ledgers.
	* it will be possible to see all the other general ledger entries relating to a particular transaction on the screen, if required.
q	Transaction enquiry: It will be possible to enquire on the transaction file on a variety and combination of different fields, the system displaying all transactions which meet the defined criteria. Such criteria will include:
	* transaction type,
	* period,
	* range of transaction references,
	* range of account codes,
	* range of transaction values.
q	It will be possible for wild carding to be used in the search criteria (e.g. display all transactions with 04 in positions 3 and 4 of the account code).

1.6.2	Reporting
q	The following reports will be available:
	* trial balance,
	* profit and loss account at company, cost centre and analysis levels,
	* balance sheet,
	* net movement by account, showing opening balance at start of month, net transactions value (or detailed transactions) and closing balance,
	* current months transaction listing (by account code).
q	Other ad hoc reports, particularly in relation to transactions, will be available.
q	The report writer will be able to access all data items in the database to enable a wide range of custom reports to be written.
q	It is anticipated that most reports will be produced by means of a general ledger report writer. At a minimum, it will be able to report the following values:
	* current month actual,
	* current month budget,
	* current month last year,
	* current month variance,
	* year to date actual,
	* year to date budget,
	* year to date last year,
	* year to date variance.
q	It will support the following features:
	* sort routines,
	* extraction by criteria,
	* control level breaks,
	* suppression of zero prints,
	* ability to round reports to the nearest thousand,
	* automatic formatting,
	* on line view,
	* variable width,
	* user defined columns,
	* user defined rows,
	* arithmetic calculation facilities.
q	The system will maintain a transaction history file online for at least 2 years.
q	The user will be able to define a range of account codes, so that each account and its description and other selected fields is automatically displayed (i.e. no need to define each code and description individually).
q	It will be able to access transaction data as well as account level data.
q	The system will maintain an organisational structure for cost centres, but will also be able to use alternative hierarchies for reporting purposes.
q	It will be possible for wild-carding to be used in the selection and format criteria (e.g. display total values for each cost centre that has a 1 in the third position for expense/income codes that have a 0 in their first position).

Human Resource Development


HR1	The HR module will be integrated to the payroll and general ledger.
HR2	Each employee will have a unique employee number.
HR3	The employee numbers can be either manual or system generated.
HR4	The module will hold the following details about each employee:
	* Personnel Number
	* Surname
	* First name
	* Middle name
	* Job title
	* Department name
	* Section name
	* Head of department
	* Payroll reference
	* Employment status - probation, contract, permanent.
	* Passport Number and Expiry Date
	* Iqama Number and Expiry Date
	* Gosi Number
	* Government Licence Number for Health Worker
	* ID number
	* Bank and branch
	* Bank account number
	* Date employed
	* Date contract expires - for expatriate employees
	* Permit details
	* Date of Birth
	* Nationality
	* Sex
	* Marital Status
	* Spouses full names - if married
	* Address
	* Telephone Number
	* Place of Origin
	* Dependants
	* Estate of residence
	* Start Date
	* Emergency Contact Number
	* Next of kin contact
HR5	The following items of rewards and performance information will be in the module:
	* Appraisal date
	* Appraisal rating
	* Disciplinary action code
	* Date of disciplinary action
HR6	The following health and safety information will be included in the module:
	* Accident type
	* Date of accident
	* Days absent
	* Date(s) of birth of children
	* Emergency Contact Name(s)
	* Emergency Contact Address(es)
	* Emergency Contact Telephone Number(s)
HR7	The system will support the following employment history details for each employee:
	* Name of previous employer(s)
	* Previous job title
	* Start Date
	* End Date
	* Source of recruitment
HR8	The following education and training details will be held:
	* School qualification level
	* School qualification subject
	* School year of qualification
	* College/University level – diploma, undergraduate, etc.
	* College/University area of specialisation
	* Year of certification
	* Professional qualifications
	* Qualification area of specialisation
	* Qualifications awarding body
	* Year other qualification obtained
HR9	The following details will be held about the current job:
	* Date job started
	* Job title
	* Cost Centre
	* Permanent/Temp/Casual status, Acting
	* Current monthly basic salary
	* Current monthly Gosi basic salary
	* Current monthly HRA and TA
	* Grade
	* Pay review date
	* Passage Details for Expatriate employee and his kins
	* Contractual hours
	* Bonus entitlement
	* Benefits held
	* Quit notice required
	* Medical cover number
	* Others
HR10	The system will be able to produce the following reports:
	* Letters of employment
	* Letters of regret
	* Invitations to interview
	* Applications for salary advance
	* Leave application and approval form
	* Personnel action form
	* Personal details form
	* Nationalitywise, positionwise, religionwise reports
HR11	The system will handle the following aspects about all employees:
	* promotions,
	* demotions,
	* joiners/leavers,
	* grade profiles,
HR12	The system will keep track of training sponsored by Mohammad Dossary HospitalService CO.
HR13	The following data will be maintained about employee training:
	* course name,
	* course duration,
	* training provider,
	* internal training flag,
	* course completion date,
	* course result,
	* cost - employee or employer
HR14	The system will maintain a training schedule for employees.
HR15	The system will come with a report generator to allow for user-defined reports.
HR16	Searches for employee details can be done using either employee names or number.
HR17	The system will keep the following details about each post:
	* the post name
	* cost code
	* holiday entitlement
	* benefit entitlement
	* skills profile
	* job description
HR18	The system will maintain a record movement of inter-departmental transfers.
HR19	The system will maintain a balance of medical cover used to date.
HR20	The following data will be maintained about track employment:
	* internal recruitment
	* external recruitment
HR21	The system will make a provision for vacant positions arising from either:
	* retirement
	* resignation
	* termination
	* new post
HR22	With the correct authorization it will be possible to modify and delete employee records.
HR23	The system will have an audit trail.
HR24	The System will generate alerts for following conditions
	Passport Expiry Iqama Expiry Visa Expiry Late Comings Late reporting after vacations Vacation due Ticket Bookings

PAYROLL

1.1 General
(a)	Payroll will be prepared monthly.
(b)	A maximum of 15 addition elements are allowed.
(f)	A maximum of 20 deduction elements are required.
(h)	A record of the payments made will be kept.
(l)	The system will maintain holiday records in terms of days entitlement and usage.
(m)	The system will allow for the following additional elements to make up gross pay:
	* a basic monthly rate
	* up to 10 overtime rates,
	* expenses,
	* bonus payments,
	* up to five permanent variations,
	* up to five temporary variations.
(n)	Permanent variations will run for a fixed time span of two or more periods or for an open-ended time.
(o)	Temporary variations will run for the current period only.
(p)	For temporary variations it will be possible for the user to define the description of the variation, such description appearing on output reports including payslips.
(q)	The system will allow for pay elements to be calculated on the basis of a standard period basic pay.
(r)	The system will be able to calculate back pay when backdated rises are made.
(s)	The system will cater for deductions as follows:
	* PAYE,
	* Gosi
	* up to five temporary variations.
	* up to five permanent variations,
(t)	For each employee it will be possible to maintain up to five reducing balance loans.

1.2 Data input
(a)	All input will be subject to full validation and reasonability checking.
(b)	It will be possible to delete leavers from the system once all their year end reports have been produced.
(c)	When inputting variable pay data it will be possible:
	* to optionally cycle through employees rather than entering each employee number,
	* to use an abbreviated alpha code rather than number to locate the employee.
(d)	When changing pay data or reference data for a number of employees, the system will default to the same field on the next record rather than requiring the user to tab through fields before editing.
(e)	When payroll payments are made to employees outside the system, e.g. manually, it will be possible to amend the employee record to reflect the payment.
(f)	It will be possible to suspend an employee or one of their pay elements for one or more pay periods; it will be possible for the period of suspension to be open ended.
(g)	The payroll will be integrated to the cashbook and general ledger, with :
	* default general ledger codings for posting the expense items,
	* automatic posting of relevant control accounts,
(h)	It will be possible to define a default general ledger coding for each pay component.
(i)	It will be possible, alternatively, to allocate the expense for each employee in proportions to one or more general ledger expense/cost centre accounts; it will be possible to allocate each expense item in this way to up to up to 15 different expense accounts.

1.3 Data stored
(a)	The following details will be maintained for each employee :
	Standing Data:
	* upto Eight digit employee number,
	* status e.g. starter, transfer, left etc,
	* name (surname, title, initials),
	* grade,
	* payment method,
	* budget centre code,
	* department,
	* date of birth,
	* start date,
	* monthly rate,
	* date left or end of contract,
	* private address,
	* values for user-defined pay elements,
	Pay History:
	* gross for each pay period,
	* Gosi for each pay period,
	Bank Details:
	* bank account number,
	* bank account name,
	* bank branch name,
	* bank code,

1.4 Data output
1.4.1	Payslips
(a)	For each pay period payslips will be produced and will comply with the existing format.
(b)	Payslips will be sorted into employee number sequence within department.
(c)	It will be possible for users to revise payslip formats.

1.4.2	Reports
(a)	The following reports will be produced for each pay period :
	* payroll summary (current period and Y T D build to gross and deductions for each employee),
	* cash requirements,
	* manual cheque listing,
	* Gosi Paid Details
	* pay elements for period and to date in summary and for each employee,
	* arrears
	* balances on outstanding loans for each employee,
	* Denomination report for cash paying employees,
	* overtime analysis by employee within department.
(b)	It will be possible to sort all of the above reports into any of the following sequences:
	* employee reference number within budget centre sub totalling on budget centre/department,
	* employee surname.
(c)	At the year end the following reports will be produced :
	* Employee Salary Drawn Montwise
	* Employee salary ledger
(d)	Each employee will be able to be paid by:
	* bank transfer
	* manual cheque,
	* cash.
(e)	The report writer will be able to access all data on the system and produce reports with summaries, sub-totalling and sorting.
(f)	All modifications to pay elements will be shown on an audit trail report.

Security

System security is a very essential feature of any application. In a system where there are multiple users logging in and handling varied kinds of data, the system calls for a process to restrict users to specific kind of data that they are eligible to handle or view. The system has to be flexible enough to grant privileges and access to the minutest of process in the system. The below describes system attempts to provide a flexible and reliable process to safeguard the hospital information system and data from misused.

Security - System Privileges - Description.

· Every menu item / command button that invokes a process or a functional part of process should be available as privilege levels in the system.

· Every department / store or in brief a hospital location should also be available as a privilege in the HMS security system.

The main features are :

· The system administrator is responsible for creating and removing users for the system.

· No person other than registered users in the system can access the HMS system.

· A user cannot access a process that has not been granted to him / her by the system administrator.

· A system log file is to be maintained.

· The system may have more than one system administrator at a time.

· Creating, modifying, and deleting user profiles.

· Change of user password.

Appendix C

Quality Assurance

Software quality assurance is generally characterized as the verification that software products (including documentation) are meeting standards during the initiation, development, and operation phases of the IPMS lifecycle.

The objectives of SQA are summarized as the following:

· Provide management with the data necessary to be informed about software quality.

· Verify that software work confirms to documented requirements and standards.

To ensure technical qualities we will be using rational Rose suite to check the performance of the code and optimised the unnecessary codes. Following principles will be applied :

· Structured walkthroughs or peer reviews are conducted on work products for every stage of the project.

· A report of each structured walkthrough findings (i.e., defects) is maintained.

· In-Stage Assessments (independent reviews) of software work products and deliverables are performed for each stage of the project life cycle.

· Software quality representatives audit software work products to ensure compliance with standards and procedures and to facilitate the early detection of problems, which could affect the quality of the software product.

· Software quality representatives periodically report their results to the project team.

· Deviations in software activities and work products are identified, documented, and controlled according to a documented procedure.

· Non-compliance issues that cannot be resolved project managers will be addressed by project director.

Project Tracking

Software project tracking is generally characterized as a process for establishing an status of actual activity against planned.

The objectives of software project tracking are summarized as the following:

· Tracking and reviewing actual software accomplishments and results against documented estimates, commitments and plans.

· Revising the project plan to reflect actual accomplishments and replanning the remaining work to be done and/or taking action to improve the performance.

· Providing visibility into the actual progress so that management can make corrective actions when project performance deviates significantly from the original software plans.

Testing

Testing is generally characterized as validation that requirements have been met and that the deliverables are at an acceptable level in accordance with existing standards during the initiation, development, and operation phases of the IS life cycle.

The objectives of testing are summarized as:

· Provide confidence that a product performs as expected without undesirable side effects.

Training

The objectives of training are summarized as follows:

· Ensure all assigned personnel are able to use the system commensurate with their function and responsibilities.

· Ensure the system documentation accurately reflects the system.

· Ensure the structure for future training is established.

Page 1 - 2 - 3 - 4 - 5 - 6 -7 -8 - 9