Billing
Content
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
02. PATIENT BILLING & ACCOUNT RECEIVABLE
PATIENT BILLING & ACCOUNT (1) Available as standard feature (2) Available as customized feature (3) Implication to JKR/MOH (cost, man hours, etc.) (4) Not available (5) Alternate options (6) Comments
No.
Funtional Requirements
(Y/N)
1 BILLING & ACCOUNTS RECEIVABLE COLLECTION FOR REGISTRATION
(Y/N)
(X)
1.1
1.2
1.3 1.4
1.5 1.6 1.7
2
Ability to classify patient according to patient class as follow: Accident & Emergency Outpatient (Normal/Specialist Clinic) Inpatient Day Care Rehabilitation Haemodialysis. Ability to allow user to classify patient based on the following patient category: - Nationality (citizen/non-citizen) - Patient Type (paying/ non-paying) - Referral Source (government/private) - Visit Type (new case/follow up) - Patient Eligibility (1st / 2nd / 3rd class) Ability to display and collect registration/ consultation fee/deposit amount to be paid by patient according to billing group and ward class. Ability to allow user to capture related information regarding GL such as follow: - GL Holder Name - Relationship with GL Holder - Customer Group - Customer Name - Document Reference - Document Date Ability to alert user if patient has outstanding bill. Ability to display patient previous billing group (history) automatically Ability to change billing grp, if no GL.
DEPOSIT/ PREPAYMENT
Y Y Y Y Y Y Y Y Y Y Y
Y Y Y Y Y Y Y Y Y
2.1 2.2 2.3 2.4 2.5 2.6
Ability to determine deposit amount according to patient eligibility based on ward class and discipline. System should allow deposit amount of zero in the system. Ability to calculate top up deposit. Ability to determine deposit amount based on estimated charges according to orderable scheduled by clinician (for Day Care). Ability to collect deposit for external implant which is not included in patient bill. Ability to collect deposit for external fixator which is not included in patient bill.
Y Y Y Y Y Y
FUNTION : 02. BILL AR
20
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization.
No.
Funtional Requirements
(Y/N)
3 BILLS
(Y/N)
(X)
3.1 3.2 3.3 3.4 3.5 3.6
The system must allow authorized user to create, maintain, view, cancel and reprint bill. Ability to display first bill print date and reprint bill date. Ability to print out bills according to MOH standard format. System must be able to set maximum amount of RM 500 for third class patient (condition applies according to Fee Act). The rounding of bill amount is not required. Ability to generate bill for any charge as follow - Transport charge (ambulance/hearse) - Investigation - Treatment - Procedure - Ward charge - Interim/Final bill - Itemized/Summarized bill - Telephone call charge Transport charges should be in a separate bill. Ability to display - Patient outstanding amount - Deposit amount (if any) - or each service, service charge and amount to be paid by patient/ customer. - Service details (order id, quantity, date, location, etc). Handles and manages retail sales of pharmaceutical items Collection of payment for non-patient related services rendered like courses (parental, prenatal, marital etc). It is mainly cater for walk-in customers, patients, staff
Y Y Y Y Y Y Y Y Y Y Y Y Y N Y Y Y Y Y Y Y Y
3.7 3.8
3.9 3.11
3.12 Doctor payments, charge exemption and class charge 3.13 Update of inventory
4 PAYMENT
4.1
4.2
4.3
System should accept payment of: - Patient billing (against bill, medical report, deposit, prepayment etc.) - Non-patient billing (miscellaneous payment) Ability to allow user to determine mode of payment. - Cash - Credit Card - Debit Card - MEPS Cash - Bank Card - Cheque (Local or Outstation) - Money Order - Postal Order Ability to accept partial/full payment.
Y Y Y Y Y Y Y Y Y Y Y
FUNTION : 02. BILL AR
21
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N) 4.4 For payment using Credit Card/ Cheque/ Postal order/ Money order, system should be able to capture automatically. User should be allowed to record payment details such as:
Credit card settlement
(Y/N)
(X)
- Payer’s name - Credit card number - Type of credit card - Bank’s name - Approval code - Sales draft number - Transaction date - Amount - Remarks
Cheque settlement
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N N Y Y Y Y Y Y Y Y
- Payer name - Cheque number - Cheque date - Cheque due date - Bank’s name - Bank’s Branch - Amount - Batch number - Remarks
PO/MO settlement
- Payer name - PO/MO number - PO/MO date - Remarks 4.5 4.6 Ability to print Medical Report letter (automatically) for medical report payment. Ability to print acknowledgement letter (automatically) for payment received through mail.
Ability to update Accounts Receivable transactions automatically whether it is full/ partial 4.7 payment. Ability to print receipt/coupon accordingly with auto-generated receipt number following 4.8 standard format. Receipt should be given for payment using credit card. 4.9 Ability to produce one receipt for multiple bills (consolidated receipt). Ability to cancel receipt (only on the same day). Once the bank in slip is made, cancellation of 4.10 receipt should not be allowed. 4.11 Ability to display Cost Centre, Department and Account Code. 4.12 Account Codes should be automatically defaulted according to Receipt type/ Encounter type.
FUNTION : 02. BILL AR
22
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
4.13 Ability to select specific Account Code for miscellaneous payment. 4.14 Ability to provide a pop up message to confirm printing receipt (to avoid mistake). Reprint of deposit receipt is not allowed as this document is used for reimbursement and can 4.15 be misused. 4.15.1 Reprint of receipt other then deposit receipt is allowed with “Salinan Pendua” printed on the receipt by authorized users (new AG requirement). 4.15.2 Receipt will be printed as one copy in A4 size (new AG requirement). 4.16 Ability to indicate bills which has been writes off.
5 CREDIT CARD
(Y/N) Y Y Y Y Y Y
(Y/N)
(X)
5.1 5.2 5.3
6 6.1
Ability to recall bills that are settled by using credit card. Ability to generate the total amount received by coding in order to prepare Bank In Statement. Ability to send data to e-spkb according to e-spkb format
BANK IN STATEMENT
N N N
Y Y Y
6.2
Ability to generate the bank in statement according to the standard format (new AG requirement). Ability to capture - Bank in slip number - Bank in date - Bank in amount - Amount by coding - Payment mode
N
Y
N N N N N N
Y Y Y Y Y Y
6.3
7 7.1
System must be able to provide fill for entering subsidiaries account information.
RECONCILIATION
Ability to do revenue reconciliation by account codes according AG requirement. Ability to allow user to segregate transactions accordingly while doing reconciliations. System also must be able to reconcile with soft copy provide by AG/SAD and produce the reconcile transaction in the required format (Lampiran A and B).
REFUND
N
Y
7.2
N
Y
8
8.1 8.2 8.3 8.4
Ability to allow refund by cash or Cheque. Ability to keep track the balance of cash in hand, Cheque in hand and recoupment voucher. Ability to display Cash in Hand amount during refund transactions. System should not allow refund transaction where refund amount is greater than cash in hand.
Y N N N Y Y Y
FUNTION : 02. BILL AR
23
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
8.5 8.6 8.7
Ability to print refund voucher slip (Kew. 50). Ability to display refund amount, payer’s name and refund date. Ability to enter miscellaneous refund request not related to any original document. Maintain Buku panjang wang runcit Maintain Buku tunai kecil kew 249
(Y/N) Y Y
(Y/N)
(X)
N N N N N
Y Y Y Y Y
8.8 8.9
Ability to allow refund cancellation by authorized user. Ability to maintain Akaun Daftar Deposit.
8.9.1 Display cash in hand, Cheque in hand & Recoupment voucher. 8.9.2 Capture Cheque in hand details - Cheque Number - Voucher Number - Voucher Date - Amount - Cheque date - Date received 8.9.3 Capture Recoupment voucher details such as -able to generate buku panjar (petty cash) deposit pesakit correctly - Voucher Number - Amount - Date 8.10 Ability To produce monthly refund report
9 DISHONORED CHEQUE
N N N N N N
Y Y Y Y Y Y
N N N N N
Y Y Y Y Y
9.1 9.2 9.3
Ability to display the Payer’s name. Ability to mark received Cheque as dishonored Cheque. Upon marking, system should be able to capture details such as Reference number Revenue/Trust Account code Date Reason Remarks Provide a pop up message asking for confirmation of marking a dishonored Cheque.
Y Y Y Y Y Y Y Y
9.4
FUNTION : 02. BILL AR
24
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments
No.
Funtional Requirements
(Y/N) 9.5 9.6 After marking a dishonored Cheque, system should activate back the patient’s account. Ability to record replacement Cheque details against dishonored Cheque as follows Cheque number Date Bank’s name Bank’s Branch Y Y Y Y Y Y
(Y/N)
(X)
FUNTION : 02. BILL AR
25
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N)
10 EXEMPTION
(Y/N)
(X)
10.1 Ability to allow exemption whether partial/ full. 10.2 Ability to record exemption amount exemption code reasons & remarks for exemption generate system unit number of exemption. 10.3 System should allow only one exemption per encounter.
11 ADJUSTMENT
Y Y Y Y Y Y
Ability to perform bill adjustment, either debit or credit. Needed in a case where patient is overcharged, undercharged or cancelled. 11.2 Ability to adjust the bill amount by authorised personel with supporting document. 11.3 Ability to capture reasons for adjustment based on standard codes. 11.1
12 REMINDER LETTER
Y Y Y
12.1 Ability to generate reminder letter accordingly i.e. 1st , 2nd and 3rd reminder. 12.2 Ability to provide option to print 1st /2nd /3rd reminder. 12.3 Provide options to print reminder letter individually/grouping. Ability to generate reminder letter according to patient category i.e. Self Pay, Government 12.4 Servant and Third Party Payer. 12.5 Ability to capture dispatched date. Ability to track reminder letter that have been generated according to patient’s ID and by 12.6 Grouping. System should display details of the reminder letter such as - Stage of reminder - Date generated - Dispatched date
13 WRITE OFF
Y N Y Y N Y Y
N N N
Y Y Y
13.1 Ability to generate report for write off according to - year - category (citizen / non-citizen) - class (1st , 2nd , 3rd ) - bill amount (according to MOH standard format) 13.2 Ability to write off bill after approval has been granted by MOH 13.3 Ability to capture MOH reference number for writes off. 13.4 Ability to view bills that has been writes off. 13.5 Ability to collect the bill even has been write off N N N N Y Y N N Y Y Y Y Y Y
FUNTION : 02. BILL AR
26
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments
No.
Funtional Requirements
(Y/N)
(Y/N)
(X)
FUNTION : 02. BILL AR
27
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N)
14 MANAGING CREDIT PATIENT
(Y/N) Y Y Y
(X)
14.1 Ability to print a statement of account on specific customer outstanding. System should provide option for user to specify the customer’s name. 14.2 Ability to settle multiple bills according to customer.
N N N
14.3 Ability to view customer’s account. To be able to send data to e-sph
15 REPORTS
N N
Y Y
15.1 To generate all required reports to be send to MOH/AG. Those reports are as follows: - Buku Tunai Cerakinan (Kew. 248) - Buku Panjar Khas (Kew. 249A) - Report of Dishonored Cheque - Revenue Collection Report - Laporan Pengecualian Bil Hospital - Laporan Baki Pendeposit - Daftar Deposit Hospital - Daftar Caj - Laporan Pindahan Deposit ke Akaun Hasil - Laporan Bulanan/Tahunan Kedatangan Warga Asing bagi Kecemasan/Pesakit Luar/Pesakit Dalam - Laporan Bulanan Kutipan Hasil - Akaun Belum Terima (ABT) - List of Hospital Bill for Write Off - Reconciliation - Surat Bayaran Laporan Perubatan 15.2 To generate all required reports for internal use. See list. System should be able to provide options or filtering by certain criteria/condition (as requested 15.3 by user) to print the required reports.
16 CASH COUNTER
Y Y Y Y Y N N N N Y Y N N N N Y Y Y Y Y Y Y Y Y Y
16.1 Ability to use Smart Card to assess the system. 16.2 Ability to activate and deactivate counter according to shift & operator. 16.3 Ability to track operator transactions according to operator ID. 16.4 Ability to block operator from closing the counter if there is discrepancy exist.
N Y Y Y
Y
FUNTION : 02. BILL AR
28
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments
No.
Funtional Requirements
(Y/N) 16.5 Ability to provide denomination (e.g RM 100, RM 50, RM 10, RM 5, RM 2, RM 1 and coins) fill for closing counter and balancing purposes. Y
(Y/N)
(X)
FUNTION : 02. BILL AR
29
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N)
17 SECURITY
(Y/N) Y
(X)
17.1 Ability to generate audit trail report for all transaction as per required format. All Bills and Receipts generated by the system will be captured and printed daily, sorted by the system assigned running number to ensure there is no missing number or duplicate number. A new Bill or Receipt with new running number will be produced for any cancellation of Bill or 17.2 Receipt. As for reprint of Bill, the same running number in the original Bill will be used and reprint date should be different from the first bill print date. No reprint of Receipt is allowed in the system (refer to 4.15). 17.3 Ability to filter excess priority users according to their responsibility.
18 CHARGING
N
Y
Y
Ability to provide option for the charging point. E.g.: Either “upon ordering” or “upon completion”. - on patient arrival. 18.2 Ability to capture and maintain the charging pattern of each service provided. 18.1
19 REPORTS
Y Y
19.1 List of Reports required: a. Laporan Harian b. Senarai Kutipan Harian Mengikut Operator c. Surat Akuan Penerimaan d. Daftar Mel Harian Unit Hasil e. Daftar Cek Tak Laku f. Senarai Cek Tak Laku Yang Belum Diganti g. Senarai Untuk Tambahan Deposit h. Senarai Pengecualian Bil i. Senarai Baki Cagaran yang Dituntut j. Surat untuk Baki Wang Cagaran Hospital yang Dibayar k. Senarai Bil Batal l. Senarai Resit Batal m. Senarai Sales Draft yang Dibatalkan n. Senarai Pesakit o. Senarai Pesakit Discharge Tanpa Bil p. Ringkasan Kutipan untuk Penyediaan Penyata Pemungut q. Penyata Pemungut r. Senarai Harian untuk Lain-lain Terimaan s. Senarai Bil Tertunggak untuk Pesakit Dalam
Y Y Y N Y N Y Y N N Y Y N Y N N Y N Y Y Y Y Y Y Y Y Y
FUNTION : 02. BILL AR
30
02. PATIENT BILLING & ACCOUNT RECEIVABLE
PATIENT BILLING & ACCOUNT (1) Available as standard feature (2) Available as customized feature (3) Implication to JKR/MOH (cost, man hours, etc.) (4) Not available (5) Alternate options (6) Comments
No.
Funtional Requirements
(Y/N)
1 BILLING & ACCOUNTS RECEIVABLE COLLECTION FOR REGISTRATION
(Y/N)
(X)
1.1
1.2
1.3 1.4
1.5 1.6 1.7
2
Ability to classify patient according to patient class as follow: Accident & Emergency Outpatient (Normal/Specialist Clinic) Inpatient Day Care Rehabilitation Haemodialysis. Ability to allow user to classify patient based on the following patient category: - Nationality (citizen/non-citizen) - Patient Type (paying/ non-paying) - Referral Source (government/private) - Visit Type (new case/follow up) - Patient Eligibility (1st / 2nd / 3rd class) Ability to display and collect registration/ consultation fee/deposit amount to be paid by patient according to billing group and ward class. Ability to allow user to capture related information regarding GL such as follow: - GL Holder Name - Relationship with GL Holder - Customer Group - Customer Name - Document Reference - Document Date Ability to alert user if patient has outstanding bill. Ability to display patient previous billing group (history) automatically Ability to change billing grp, if no GL.
DEPOSIT/ PREPAYMENT
Y Y Y Y Y Y Y Y Y Y Y
Y Y Y Y Y Y Y Y Y
2.1 2.2 2.3 2.4 2.5 2.6
Ability to determine deposit amount according to patient eligibility based on ward class and discipline. System should allow deposit amount of zero in the system. Ability to calculate top up deposit. Ability to determine deposit amount based on estimated charges according to orderable scheduled by clinician (for Day Care). Ability to collect deposit for external implant which is not included in patient bill. Ability to collect deposit for external fixator which is not included in patient bill.
Y Y Y Y Y Y
FUNTION : 02. BILL AR
20
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization.
No.
Funtional Requirements
(Y/N)
3 BILLS
(Y/N)
(X)
3.1 3.2 3.3 3.4 3.5 3.6
The system must allow authorized user to create, maintain, view, cancel and reprint bill. Ability to display first bill print date and reprint bill date. Ability to print out bills according to MOH standard format. System must be able to set maximum amount of RM 500 for third class patient (condition applies according to Fee Act). The rounding of bill amount is not required. Ability to generate bill for any charge as follow - Transport charge (ambulance/hearse) - Investigation - Treatment - Procedure - Ward charge - Interim/Final bill - Itemized/Summarized bill - Telephone call charge Transport charges should be in a separate bill. Ability to display - Patient outstanding amount - Deposit amount (if any) - or each service, service charge and amount to be paid by patient/ customer. - Service details (order id, quantity, date, location, etc). Handles and manages retail sales of pharmaceutical items Collection of payment for non-patient related services rendered like courses (parental, prenatal, marital etc). It is mainly cater for walk-in customers, patients, staff
Y Y Y Y Y Y Y Y Y Y Y Y Y N Y Y Y Y Y Y Y Y
3.7 3.8
3.9 3.11
3.12 Doctor payments, charge exemption and class charge 3.13 Update of inventory
4 PAYMENT
4.1
4.2
4.3
System should accept payment of: - Patient billing (against bill, medical report, deposit, prepayment etc.) - Non-patient billing (miscellaneous payment) Ability to allow user to determine mode of payment. - Cash - Credit Card - Debit Card - MEPS Cash - Bank Card - Cheque (Local or Outstation) - Money Order - Postal Order Ability to accept partial/full payment.
Y Y Y Y Y Y Y Y Y Y Y
FUNTION : 02. BILL AR
21
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N) 4.4 For payment using Credit Card/ Cheque/ Postal order/ Money order, system should be able to capture automatically. User should be allowed to record payment details such as:
Credit card settlement
(Y/N)
(X)
- Payer’s name - Credit card number - Type of credit card - Bank’s name - Approval code - Sales draft number - Transaction date - Amount - Remarks
Cheque settlement
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N N Y Y Y Y Y Y Y Y
- Payer name - Cheque number - Cheque date - Cheque due date - Bank’s name - Bank’s Branch - Amount - Batch number - Remarks
PO/MO settlement
- Payer name - PO/MO number - PO/MO date - Remarks 4.5 4.6 Ability to print Medical Report letter (automatically) for medical report payment. Ability to print acknowledgement letter (automatically) for payment received through mail.
Ability to update Accounts Receivable transactions automatically whether it is full/ partial 4.7 payment. Ability to print receipt/coupon accordingly with auto-generated receipt number following 4.8 standard format. Receipt should be given for payment using credit card. 4.9 Ability to produce one receipt for multiple bills (consolidated receipt). Ability to cancel receipt (only on the same day). Once the bank in slip is made, cancellation of 4.10 receipt should not be allowed. 4.11 Ability to display Cost Centre, Department and Account Code. 4.12 Account Codes should be automatically defaulted according to Receipt type/ Encounter type.
FUNTION : 02. BILL AR
22
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
4.13 Ability to select specific Account Code for miscellaneous payment. 4.14 Ability to provide a pop up message to confirm printing receipt (to avoid mistake). Reprint of deposit receipt is not allowed as this document is used for reimbursement and can 4.15 be misused. 4.15.1 Reprint of receipt other then deposit receipt is allowed with “Salinan Pendua” printed on the receipt by authorized users (new AG requirement). 4.15.2 Receipt will be printed as one copy in A4 size (new AG requirement). 4.16 Ability to indicate bills which has been writes off.
5 CREDIT CARD
(Y/N) Y Y Y Y Y Y
(Y/N)
(X)
5.1 5.2 5.3
6 6.1
Ability to recall bills that are settled by using credit card. Ability to generate the total amount received by coding in order to prepare Bank In Statement. Ability to send data to e-spkb according to e-spkb format
BANK IN STATEMENT
N N N
Y Y Y
6.2
Ability to generate the bank in statement according to the standard format (new AG requirement). Ability to capture - Bank in slip number - Bank in date - Bank in amount - Amount by coding - Payment mode
N
Y
N N N N N N
Y Y Y Y Y Y
6.3
7 7.1
System must be able to provide fill for entering subsidiaries account information.
RECONCILIATION
Ability to do revenue reconciliation by account codes according AG requirement. Ability to allow user to segregate transactions accordingly while doing reconciliations. System also must be able to reconcile with soft copy provide by AG/SAD and produce the reconcile transaction in the required format (Lampiran A and B).
REFUND
N
Y
7.2
N
Y
8
8.1 8.2 8.3 8.4
Ability to allow refund by cash or Cheque. Ability to keep track the balance of cash in hand, Cheque in hand and recoupment voucher. Ability to display Cash in Hand amount during refund transactions. System should not allow refund transaction where refund amount is greater than cash in hand.
Y N N N Y Y Y
FUNTION : 02. BILL AR
23
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
8.5 8.6 8.7
Ability to print refund voucher slip (Kew. 50). Ability to display refund amount, payer’s name and refund date. Ability to enter miscellaneous refund request not related to any original document. Maintain Buku panjang wang runcit Maintain Buku tunai kecil kew 249
(Y/N) Y Y
(Y/N)
(X)
N N N N N
Y Y Y Y Y
8.8 8.9
Ability to allow refund cancellation by authorized user. Ability to maintain Akaun Daftar Deposit.
8.9.1 Display cash in hand, Cheque in hand & Recoupment voucher. 8.9.2 Capture Cheque in hand details - Cheque Number - Voucher Number - Voucher Date - Amount - Cheque date - Date received 8.9.3 Capture Recoupment voucher details such as -able to generate buku panjar (petty cash) deposit pesakit correctly - Voucher Number - Amount - Date 8.10 Ability To produce monthly refund report
9 DISHONORED CHEQUE
N N N N N N
Y Y Y Y Y Y
N N N N N
Y Y Y Y Y
9.1 9.2 9.3
Ability to display the Payer’s name. Ability to mark received Cheque as dishonored Cheque. Upon marking, system should be able to capture details such as Reference number Revenue/Trust Account code Date Reason Remarks Provide a pop up message asking for confirmation of marking a dishonored Cheque.
Y Y Y Y Y Y Y Y
9.4
FUNTION : 02. BILL AR
24
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments
No.
Funtional Requirements
(Y/N) 9.5 9.6 After marking a dishonored Cheque, system should activate back the patient’s account. Ability to record replacement Cheque details against dishonored Cheque as follows Cheque number Date Bank’s name Bank’s Branch Y Y Y Y Y Y
(Y/N)
(X)
FUNTION : 02. BILL AR
25
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N)
10 EXEMPTION
(Y/N)
(X)
10.1 Ability to allow exemption whether partial/ full. 10.2 Ability to record exemption amount exemption code reasons & remarks for exemption generate system unit number of exemption. 10.3 System should allow only one exemption per encounter.
11 ADJUSTMENT
Y Y Y Y Y Y
Ability to perform bill adjustment, either debit or credit. Needed in a case where patient is overcharged, undercharged or cancelled. 11.2 Ability to adjust the bill amount by authorised personel with supporting document. 11.3 Ability to capture reasons for adjustment based on standard codes. 11.1
12 REMINDER LETTER
Y Y Y
12.1 Ability to generate reminder letter accordingly i.e. 1st , 2nd and 3rd reminder. 12.2 Ability to provide option to print 1st /2nd /3rd reminder. 12.3 Provide options to print reminder letter individually/grouping. Ability to generate reminder letter according to patient category i.e. Self Pay, Government 12.4 Servant and Third Party Payer. 12.5 Ability to capture dispatched date. Ability to track reminder letter that have been generated according to patient’s ID and by 12.6 Grouping. System should display details of the reminder letter such as - Stage of reminder - Date generated - Dispatched date
13 WRITE OFF
Y N Y Y N Y Y
N N N
Y Y Y
13.1 Ability to generate report for write off according to - year - category (citizen / non-citizen) - class (1st , 2nd , 3rd ) - bill amount (according to MOH standard format) 13.2 Ability to write off bill after approval has been granted by MOH 13.3 Ability to capture MOH reference number for writes off. 13.4 Ability to view bills that has been writes off. 13.5 Ability to collect the bill even has been write off N N N N Y Y N N Y Y Y Y Y Y
FUNTION : 02. BILL AR
26
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments
No.
Funtional Requirements
(Y/N)
(Y/N)
(X)
FUNTION : 02. BILL AR
27
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N)
14 MANAGING CREDIT PATIENT
(Y/N) Y Y Y
(X)
14.1 Ability to print a statement of account on specific customer outstanding. System should provide option for user to specify the customer’s name. 14.2 Ability to settle multiple bills according to customer.
N N N
14.3 Ability to view customer’s account. To be able to send data to e-sph
15 REPORTS
N N
Y Y
15.1 To generate all required reports to be send to MOH/AG. Those reports are as follows: - Buku Tunai Cerakinan (Kew. 248) - Buku Panjar Khas (Kew. 249A) - Report of Dishonored Cheque - Revenue Collection Report - Laporan Pengecualian Bil Hospital - Laporan Baki Pendeposit - Daftar Deposit Hospital - Daftar Caj - Laporan Pindahan Deposit ke Akaun Hasil - Laporan Bulanan/Tahunan Kedatangan Warga Asing bagi Kecemasan/Pesakit Luar/Pesakit Dalam - Laporan Bulanan Kutipan Hasil - Akaun Belum Terima (ABT) - List of Hospital Bill for Write Off - Reconciliation - Surat Bayaran Laporan Perubatan 15.2 To generate all required reports for internal use. See list. System should be able to provide options or filtering by certain criteria/condition (as requested 15.3 by user) to print the required reports.
16 CASH COUNTER
Y Y Y Y Y N N N N Y Y N N N N Y Y Y Y Y Y Y Y Y Y
16.1 Ability to use Smart Card to assess the system. 16.2 Ability to activate and deactivate counter according to shift & operator. 16.3 Ability to track operator transactions according to operator ID. 16.4 Ability to block operator from closing the counter if there is discrepancy exist.
N Y Y Y
Y
FUNTION : 02. BILL AR
28
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments
No.
Funtional Requirements
(Y/N) 16.5 Ability to provide denomination (e.g RM 100, RM 50, RM 10, RM 5, RM 2, RM 1 and coins) fill for closing counter and balancing purposes. Y
(Y/N)
(X)
FUNTION : 02. BILL AR
29
VOLUME 2: FUNCTIONAL REQUIREMENTS COMPLIANCE TABLE
PATIENT BILLING & ACCOUNT
(1) Available as standard feature
(2) Available as customized feature
(3) Implication to JKR/MOH (cost, man hours, etc.)
(4) Not available
(5) Alternate options
(6) Comments To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization. To be provided through customization.
No.
Funtional Requirements
(Y/N)
17 SECURITY
(Y/N) Y
(X)
17.1 Ability to generate audit trail report for all transaction as per required format. All Bills and Receipts generated by the system will be captured and printed daily, sorted by the system assigned running number to ensure there is no missing number or duplicate number. A new Bill or Receipt with new running number will be produced for any cancellation of Bill or 17.2 Receipt. As for reprint of Bill, the same running number in the original Bill will be used and reprint date should be different from the first bill print date. No reprint of Receipt is allowed in the system (refer to 4.15). 17.3 Ability to filter excess priority users according to their responsibility.
18 CHARGING
N
Y
Y
Ability to provide option for the charging point. E.g.: Either “upon ordering” or “upon completion”. - on patient arrival. 18.2 Ability to capture and maintain the charging pattern of each service provided. 18.1
19 REPORTS
Y Y
19.1 List of Reports required: a. Laporan Harian b. Senarai Kutipan Harian Mengikut Operator c. Surat Akuan Penerimaan d. Daftar Mel Harian Unit Hasil e. Daftar Cek Tak Laku f. Senarai Cek Tak Laku Yang Belum Diganti g. Senarai Untuk Tambahan Deposit h. Senarai Pengecualian Bil i. Senarai Baki Cagaran yang Dituntut j. Surat untuk Baki Wang Cagaran Hospital yang Dibayar k. Senarai Bil Batal l. Senarai Resit Batal m. Senarai Sales Draft yang Dibatalkan n. Senarai Pesakit o. Senarai Pesakit Discharge Tanpa Bil p. Ringkasan Kutipan untuk Penyediaan Penyata Pemungut q. Penyata Pemungut r. Senarai Harian untuk Lain-lain Terimaan s. Senarai Bil Tertunggak untuk Pesakit Dalam
Y Y Y N Y N Y Y N N Y Y N Y N N Y N Y Y Y Y Y Y Y Y Y
FUNTION : 02. BILL AR
30
